I’m learning to write my own module and poking around on this forum. I am not sure about when to put code in the init, start, or loaded functions of the node helper. I’m basically starting with the SampleModule by Sam. I’ve got my script working from the operating system running it with “node myscript.js” and it even uses a node package (was really proud of myself over that). And now I want to make it into a module for MagicMirror.

I’m wondering what and when to put code in init, start or loaded sections of the node_helper example?

I’ve look at the modules repository for examples and it seem like its all over the place.

Kelly

P.S. I’m very new to node.js and this is my first from scratch attempt to do anything with it at all. I feel like I’m halfway there. But not I"m stuck.

@sdetweil I agree with Sam or the dev ends up rewriting so much that it really isn’t mergable at all. Perhaps renaming and just a comment mentioning the idea came from so-and-so is better solution.

@aunrea did you run?
first switch to the MagicMirror folder like this

cd /home/pi/MagicMirror/

then run this command

npm run config:check

@teegray1124 I’m only displaying Major league Baseball right now but I do see scores. This module relies on different apis and scrapes some websites and any one of those could change and wouldn’t be the fault of the module. I think I also remember there is a setting for how many days to show something… I could be wrong.

But you’ve got to give a lot more info If anyone using that module could try to help you.

What league are you actually trying to display? What is your config for it?

@史新瑞

Did you run /home/pi/Magicmirror/npm run check:config
to verify your config.js?

@doubleT

for the screen size, look in the magicmirror doc for the electron options, you’ll want the full screen option probably. but you can set width and height too. You make these changes in your magicmirror config.js

When messing with modules and stuff, I generally set my screen size width and height to about half of my monitor so I can edit config and things comfortable on the same screen.

tips:
Ctrl+m will minimize electron and thus magic mirror, if you need to get to the desktop and are running full screen.

click on teh electron instance then ctrl+r will reload magic mirror. That way you don’t have to completely stop and reload when you are messing with css or config. At least 90% of the time ctrl+r wll be enough.

@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.