@aunrea
What is happening is that npm can’t find config:check in /home/pi/

You have to move into the Magicmirror folder before running
npm run config:check

I often move a mirror between my parents home to my home so I can work on it. Or take mine to my parents to show them something new I did to mine, to see if they want the change on their mirror.

It would be nice if I could set our mirrors address in the config.
Lazy of me I know since all I have to do is edit it. BUT… it would be nice.

I haven’t coded in python since my first attempt at a magic mirror. In the past couple of months I’ve built 2, a working one for my Dad and now another for me. First I decided that I needed to rewrite the MMM-Flick module because it was crashing my mirror. So, I dove into that. I abandoned the Flick because it really isn’t very reliable and am replacing that with buttons that turn the mirror display on and off and a small adafruit gesture sensor for changing screens. Python was a must. I made a mess but a working mess at that.

Last week, I decided I liked all of Erik Flowers weather icons and that the default weather just didn’t use enough of them. Thus I needed to change the default weather module so it uses the openweathermap weather.id instead of the weather.icon. I’ve been working intermittently for a week and being super frustrated. Today I got the brilliant idea (DUH!) to use a syntax checker on it. Python syntax check… BOOM! DUH! I was putting python in a javascript. DUH! It doesn’t work. DUH!

Just had to share that. 'Cause I laughed so hard my soda squirted through my nose. So now I have a mess of code to clean up and a wet puddle on my desk.

I’m getting a cleaning rag after I hug myself in sympathy pains and pat myself on the back for figuring it out. If I could only figure out how to get 7 evenings of my life back now…

@luisestrada

I’ll swing it back to this thread…

I got access to the extra fontawesome 6 by just copying the contents over the font awesome 4 in the vendors folder. NOT the right way to do it because it will get wiped out if I ever update my mirror. Correct me if I"m wrong, but I think it should have been a subfolder in the mm css folder in order to preserve it.

Also I copied the provider file for openweathermap.js (and gave it a new name) and changed the constants for the weathertype to the following.

(note, i have access to the pro fontawesome so I can use the duotone icons in my mirror).

	/*
	 * Convert the OpenWeatherMap icons to a more usable name.
	 */
	convertWeatherType(weatherType) {
		const weatherTypes = {
			"01d": "fa-duotone fa-sun", 
			"02d": "fa-duotone fa-sun-cloud",
			"03d": "fa-duotone fa-cloud-sun",
			"04d": "fa-duotone fa-clouds-sun",
			"09d": "fa-duotone fa-cloud-sun-rain",
			"10d": "fa-duotone fa-cloud-showers-heavy",
			"11d": "fa-duotone fa-cloud-bolt",
			"13d": "fa-duotone fa-snowflake fa-spin-pulse",
			"50d": "fa-duotone fa-sun-haze",
			"01n": "fa-duotone fa-moon-stars night", 
			"02n": "fa-duotone fa-moon-cloud night", 
			"03n": "fa-duotone fa-clouds-moon night", 
			"04n": "fa-duotone fa-cloud-moon-rain night", 
			"09n": "fa-duotone fa-cloud-showers night", 
			"10n": "fa-duotone fa-cloud-moon-rain night", 
			"11n": "fa-duotone fa-cloud-bolt night", 
			"13n": "fa-duotone fa-snowflake fa-spin-pulse night", 
			"50n": "fa-duotone fa-cloud-fog night" 
		};

I think these used to be configurable for the old weather modules in the config.js, but now they are constants defined in the provider file. Make sense because each profider sends differnt weathertype codes and it would be really confusing for people help one another. But then you have geeks like us who ust keep digging and we can usually figure it out maybe with nudges in the right direction.

For Openweathermap (OWM) those constands/weathertypes are based on the “icon” info that OWM sends. I thought about changing that to use the codes that OWM provides since ErikFlowers weathericons now have so many more weathericons and he actually provides a definition for the OWM codes to his icons too.

I did the kickstarter to help Fontawesome create 6, so have all the paid version 6 icons too without subscription fees. I love their weather duotone icons and they do work on the mm if the css is set correctly. They work in the calendar too. I’m sure they’d also work with the same fixes in the third party modules. I think a lot of folks just used the default modules as models of how to build their own so a lot of the hard coded stuff (that should have been config enabled instead) just carried through to their own modules.

All of us need to remember that Mich did this for himself and knew what he wanted. I probably would have hard coded it myself in that situation. We are lucky we have free access to what he began and gave to the public for free. I’m so glad he did. This is a great learning project with a great looking usable end product.

@sdetweil I totally get the difficulty in supporting people. I have been picking njk apart by examples already in the njk templates that I’ve found.

it would have been nice if the fontawesome 4 prefixes weren’t hardcoded into the module sources/templates. Would have made changing the icons to something else in so much easier.

@sdetweil true, and it also allows for a remote file, an extra config file if you will. I think the weather should do the same for it’s templates.

@MagicBeginner Quite a few of the third party modules actually access a python script to do some processing. The gestures and sensor modules are great examples of that. If you need to use python in combination with the mm.

The compliments module is great. I love the remoteFile config variable so that I can add my own custom list of special date messages and other things. The beauty is that a custom file of compliments doesn’t get erased upon updating the mm and is easy to copy to another mirror instance. It is also easy to find to add or alter the compliments.

The weather module uses external template files like current.njk and forcast.njk. It is possible to modify them to make the weather appear as we like. But they are at risk of being overwritten by an update to the mirror.

I think that having a weather module config variable for a custom template would make updating less stressful and easier.

To that end I have modified my local weather module instance as follows.

In the weather module weather.js defaults section I added

	defaults: {
		remoteTemplate: "current.njk",

and I altered the getTemplate function to the following:

	// Select the template depending on the display type.
	getTemplate: function () {
		
		if (this.config.remoteTemplate !="") {return this.config.remoteTemplate}
		 else {
		
			switch (this.config.type.toLowerCase()) {
				case "current":
					return "current.njk";
				case "hourly":
					return "hourly.njk";
				case "daily":
				case "forecast":
					return "forecast.njk";
				//Make the invalid values use the "Loading..." from forecast
				default:
					return "forecast.njk";
			}
	   }
	},

Thus, if I do not create or set a remote template, the module will not fail, it will get the template it should.
But I want to use a custom template becuase I want control to the css tags used in the html so I can more easily customise the weather. I also wanted a different layout. So made copies of current.njk and forecast.njk and put them in the mm config folder. I also renamed them to be very clear they were my custom template.
Then,
in the weather section of my config.js
I added the relative path to my custom template file.

config: {
  remoteTemplate: "../../../../config/kellyforecast.njk",

I actually have a custom version of current and forecast templates. I can quickly tweak the templates and not get into the folder structure of the mm default modules.

I would like to contribute this to the mm repository.

@SJK this is very cool! This method could be used for an eInk type display. It’s really making me think those old pi zeros could be very useful again.