Can anyone explain why the Free API from OpenWeatherMap shows 7 Day Forecast but the discussion here (and what I actually see) is only being able to retrieve 5 days?

In looking at the documentation from the weather site, it appears that the URL should be constructed differently than how this weather module is building it out. Specifically, the URL should be something like:

https://api.openweathermap.org/data/2.5/onecall?lat={lat}&lon={lon}&exclude={part}&appid={API key}

But the URL is -actually- being built as:

https://api.openweathermap.org/data/2.5/forecast?id={id}&appid={API key}

It seems that the URL needs be different?

You can’t make this stuff up…

Mirror has been running for a couple of hours now without crashing as it has been doing intermittently in the past. However, there is now a “pop up” on the screen stating that Chromium couldn’t be updated and that I’m missing out on features and fixes.

I found what might be a fix in the way of potentially “configuring” Chromium to ignore updates, but I won’t know if this truly works until probably tomorrow at the earliest.

I simply opened the github page, copied the link, and used wget to download it to the mirror. So, it’s entirely possible that the way I downloaded it was partly to blame. Figured I would mention it because I’m likely not the only one that might run into this, and at a minimum it could become a troubleshooting step if others run into issues.

Based on the directions you gave in this thread, the run-start.sh script won’t work. I didn’t take the time to look through the github content to see if this is covered there, but you have to do

chmod +x run-start.sh

Or the script won’t actually execute. Based on old habits, I was executing the chmod statement without even thinking about it. But, after downloading the newest script, I purposefully left it untouched and it wouldn’t run.

Cool. I download the latest one and try it out.

Glad I can help you keep improving your code! lol

One tweak to the run-start.sh script seems to have fixed it. I changed this line:

serveronly=$(grep -v '^[[:blank:]]*//'  config/config.js | grep -i serveronly: | awk '{print tolower($2)}' | tr -d ,\"\'\\r)

To this:

serveronly=$(grep -v '^[[:blank:]]*//'  config/config.js | grep -i serveronly: | awk '{print tolower($1)}' | tr -d ,\"\'\\r)

The awk command seems to have been looking for a variable that wasn’t being passed and by changing the variable number that it was looking for, it no longer starts electron and now starts chromium.

Welp…

No change. System still crashes on the Pi using Chromium.

In looking at the most recent core file, it’s still showing that electron is what’s faulting.

There are no running processes of chromium and electron is still being started. Something is amiss with the configuration to where your run-start.sh script is either not being called or is not launching the correct browser for some reason.

I’ve made no changes to run-start.sh, I’ve edited package.json so that this line is gone:

"start": "DISPLAY=\"${DISPLAY:=:0}\" ./node_modules/.bin/electron js/electron.js",

And has been replaced with this one:

"start": "./run-start.sh",

config/config.js has the following setting:

var config = {
	address: "0.0.0.0", 	// Address to listen on, can be:
							// - "localhost", "127.0.0.1", "::1" to listen on loopback interfac
e
							// - another specific IPv4/6 to listen on a specific interface
							// - "0.0.0.0", "::" to listen on any interface
							// Default, when address config is left out or empty, is "localhost
"
	port: 8080,
	basePath: "/", 	// The URL path where MagicMirror is hosted. If you are using a Reverse proxy
					// you must set the sub path here. basePath must end with a /
	ipWhitelist: ["127.0.0.1", "192.168.192.0/24", "::1"], 	// Set [] to allow all IP addresses
															// 
or add a specific IPv4 of 192.168.1.5 :
															// 
["127.0.0.1", "::ffff:127.0.0.1", "::1", "::ffff:192.168.1.5"],
															// 
or IPv4 range of 192.168.3.0 --> 192.168.3.15 use CIDR format :
															// 
["127.0.0.1", "::ffff:127.0.0.1", "::1", "::ffff:192.168.3.0/28"],

	useHttps: false, 		// Support HTTPS or not, default "false" will use HTTP
	httpsPrivateKey: "", 	// HTTPS private key path, only require when useHttps is true
	httpsCertificate: "", 	// HTTPS Certificate path, only require when useHttps is true

	language: "en",
	logLevel: ["INFO", "LOG", "WARN", "ERROR"],
	timeFormat: 24,
	units: "metric",
	// serverOnly:  true/false/"local" ,
	serverOnly:"local",

Good info.

I’m interested to see how for the MM will make it now using Chromium instead of Electron. Since I have two with the same setup, I’ll set both to use Chromium for an additional level of testing it out.

Why was Electron chosen as the browser up to this point? And, what potential downsides are there to Chromium?

I’ve made the change to Chromium - we’ll see how that does going forward.

I do recall reading plenty about the severe lag of Electron in terms of the version that’s part of MM, so that part wasn’t “news” really. What I genuinely don’t understand is why this specific, basic configuration continues to have issues for me while Electron mostly does what it needs to do for so many others without creating this sort of problem.

I have confirmed that only Electron crashes on the Pi itself. The MM server does not experience any hiccups and remote browser connections remain functional.

I at least now understand WHAT is crashing. Next steps might be to figure out WHY it’s crashing and potentially remedy it.