@sdetweil - I don’t use PM2, but I went ahead and replicated the steps you suggested to create that some file.txt log file and the appropriate searches. The only thing of note I saw was an error about MMM-CalendarExt3 not having permission to enter objects. Not sure if that would have any bearing on the MMM-GoogleCalendar module. Image attached.
By the way, I tried git pull to update MagicMirror, but being told I can’t fast-forward for some reason.
@reilley what MagicMirror version are you on? There was a bug fixed when scanning for changes
Version 2.34.0
@sdetweil - Hi Sam! Surprisingly, the error may not show up for a while after you make changes and restart.
A couple of weeks ago, MagicMirror started displaying a message that the MMM-GoogleCalendar module is behind by two commits, but I’ve git-pulled and installed, merged as required, and ran the npm install but it’s still showing as being behind. I ran npm audit fix and two moderate issues appear, but not sure how to fix them. I’ve installed the latest GAXIOS version as suggested but no joy.
Any ideas?
So for a few weeks now, I continue to get the messsge that my MMM-GoogleCalendar module is two commits behind, even though I’ve git pulled and installed the latest version. Merged as needed and ran NPM audits but see two moderate issues. Screenshots attached!
@sdetweil - you’re gonna laugh, but I found the issue. I was using an inactive API key. My backup was too old and was before the v2.29.0 API 3.0 requirement. Sorry to drag you through this!
@reilley - oh, I think I know what’s wrong now.
@sdetweil - nope, same result
@sdetweil said in "Invalid Date" appears in Weather module. MM v2.29.0:
@reilley said in "Invalid Date" appears in Weather module. MM v2.29.0:
So my code worked for you and the only change was the API key?
correct
That’s nuts. Why would an API key work two days ago and not today? Seems like maybe there’s a configuration problem elsewhere but I not sure where it would be since I made no changes to weather.js or other .js files associated with the Weather module.
@sdetweil said in "Invalid Date" appears in Weather module. MM v2.29.0:
@reilley I copied your config and used my apikey
no other changes (well I wrapped your config in code block to keep the quotes correct for copy/paste)
So my code worked for you and the only change was the API key? This key worked two days ago, so not sure what’s happening here.
Had to rebuild my mirror from scratch after my SSD croaked five months after purchase and my backup USB was corrupted, argh. Most everything works now except for my Weather modules, which are using OpenWeatherMap with API 3.0.
When current weather loads, I see "Invalid Date where the time should be above the temperature. To add insult to injury, the temp displays as “NaN”. What the heck? Here’s my config:
{
module: 'weather',
position: 'top_center',
header: 'Current Weather - Canton',
config: {
weatherProvider: 'openweathermap',
appendLocationNameToHeader: false,
type: 'current',
weatherEndpoint: '/onecall',
lat: '34.17188',
lon: '-84.57056',
apiVersion: '3.0',
apiKey: "XXXX"
}
},
{
module: 'weather',
position: 'top_center',
header: 'Forecast - Canton',
config: {
weatherProvider: 'openweathermap',
appendLocationNameToHeader: false,
type: 'forecast',
weatherEndpoint: '/onecall',
lat: '34.17188',
lon: '-84.57056',
apiVersion: '3.0',
apiKey: "XXXX"
}
},
Units are set to imperial in the config.js file and my Raspberry PI time seems correct.
Thoughts?
@sdetweil - I feel ya! Back from dinner with the wife and your script ran perfectly - thanks! Now, I’m tracking down a pesky weather module issue, grrrrr. I’ll definitely be taking advantage of your backup scripts as soon as I get this all working again. I don’t ever want to reinstall from scratch again, ugh.
@sdetweil - I’ve been running on Bullseye up until until the SSD croaked. I just installed Bookworm 64 bit before I saw your reply and once it’s done updating, I’ll give your script a whirl. Weird that this was happening since I installed NodeJS with no problems a few months ago. Argh!!!
Thanks for the help as always!!!
@sdetweil - Sam, will your scripts install Nodejs and NPM? My SSD died and I’m having a hell of a time getting Nodejs installed on it. I keep getting errors about glibcc_3.4.29 and 3.4.30 not being found.
@HeikoGr - lol, adjusted my headers and saw that the timezone was concatenated to the header. Snapped a photo to post and saw your comment. That fixed it!!! Thank you and Sam both!!!
@HeikoGr - sorry, I didn’t copy/paste from the actual editor. I typed all that in and made a few errors! Sorry for the goose chase!
@sdetweil - sure, I’d be happy to force my header if that’s possible. So for example, with forecast I would want it to say:
Forecast - Canton, GA
Or similar, of course. I could test it if you could let me know where to insert that line of code.
@HeikoGr - so as it was said before, we’re not going to see our city the way we did under v2.5 of the API. That’s going to likely need a response from the MM2 dev team because if /open call is used, it’s timezone/city only. It seems api 3.0 broke the location/locationID functionality when using “current” or “forecast”. Or did someone else get it to work?
@Peter - Unfortunately, not yet. I’m wondering if anyone has been able to using the 3.0 API!
OK, it would appear when /onecall is used, the OpenWeatherMap.js script controls the header and you’re either going to get:
${data.timezone}
or
${data.city.name},${data.city.country}
I’m see the first option, timezone. It’s correct, but I don’t want timezone. I want city/country. Booooo!!!