-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
Fix for envcanada Provider to use new Environment Canada weather data access #3878
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tahnks for the PR, just minor things to change :-)
|
||
// Set the default config properties that is specific to this provider | ||
defaults: { | ||
debug: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please just use Log.debug for places you want to have a debug output
* 1. Query the MSC Datamart Index page, which returns a list of all the filenames for all the cities that have | ||
* weather data currently available. | ||
* | ||
* 2. With the city filename identified, build the approrpiate URL and get the weather data (XML document) for the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldnt our spellcheck task get this "approrpiate" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Until now we don't run the spell checker on Pull Requests.
When the spell checker was introduced (#3623), I thought it could be too annoying for PRs. But now I would be in favor of activating it. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for having a look! I updated the code to use Log.debug, fixed the spelling mistake, and added an 'acknowledgement' in the beginning comments. Changes have been tested and committed, as well.
Apologies, not sure if this is the place for this, but I find this is not working for me? |
You loaded the new file from the MagicMirror develop branch, right? actually the file hasn’t made it to develop yet. Did you get it from the pull request? |
Yes, I got it from the pull request. |
Hi there! Can you tell me what's not working? The code has been running fine on my MM for a few weeks. FWIW I'm running on a Rasp Pi 4 + Bookworm and the latest version MM (v2.32.0). The changes are all within envcanada.js and are not reliant on anything special with the MM framework, so you I think you should be able to simply replace your existing module code with the updated version I created. |
EDIT: Apologies, so it wouldn't start, which was due to the older version I was running, but now I'm not getting any data from the weather. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That config variable "debug" can go. If one wants to debug, they should change the debug level globally, we dont have module specific debug switches here.
D'oh! That was a brain-cramp on my part. Fixed! |
Yeah that says you've got 'blank' weather info populating the UI. What version of MM are you using? |
2.32 |
|
||
Log.debug(`[weather.envcanada] ${target} Citypage url: ${forecastFileURL}`); | ||
|
||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just this one intend fix and its ready to be merged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just fixed it 🙂
I also see and error in the console
|
and here is the config I used {
module:"weather",
position:"top_right",
classes:"page2",
config:{
weatherProvider:"envcanada",
siteCode:"s0000004",
provCode:"BC"
}
}, |
yeah, somethings not quite right with the envcanada provider in this PR. but our weatherprovider could also need a better null handling. so far no provider seems to have triggered this altthough some other provider (like openmeteo) COULD also return null if some weathertype is not send or recognized. envcanada doesnt seem to send this info though (and some others also) adding some better null checks in our module seems to be necessary, should we do this here or in another PR? lets see what the PR creator @Crazylegstoo says about the env data |
I think fixing our code should be done outside this PR |
Thanks for raising this weirdness, guys. I've been running this code for weeks in various configurations and have not seen this problem crop up. Except... I updated my config.js today to have 4 instances of the weather module displaying Current weather (using envcanada) for 4 different Canadian cities. Having 3 instances was no problem, but once I added a 4th instance then the same null issue cropped up. It only seems to occur for Current weather - did not arise with multiple instances of Forecast or Daily. This is all VERY anecdotal since I only did a quick test and I cannot explain how null is arising, yet. I'll have to spend some quality time looking at this more closely. Just a heads up that I am leaving on a 2-week camping trip in a couple of days so I may not have anything to share until I get back. If it makes sense to close this PR and start anew, I'm good with that. |
no problem, your 2 week trip time will put this very close to Oct 1, release.. so I think this needs to wait |
As mentioned [here](#3878 (comment)) our weather module needs a bit better handling for null values in the type field. This pr adds this and cleans up the layout a little.
is this provider specific or again a "global" problem of the weather module? I would be happy to get this merged before next release. We should not block this PR with old "global" problems ... |
this (null checks) is global problem of weather module.. MAY also be IN the provider, but the problem I posted was the weather provider returning nulls |
part time old , but also part time how envcanada seems to deliver wind speed:
I guess our code doesnt know how to convert "calm" :-) Maybe @Crazylegstoo can fix it later. And yes, I am too for merging now and have it fix later. Better to have something working instead of nothing... |
Just playing catch up, so many thanks for everyone who looked at this! That 'calm' windspeed value from Environment Canada is a new wrinkle (and pretty dumb, I'd say). I'll put this on my to-do list to look at. |
Earlier in 2025, Environment Canada changed the process to access weather data for Canadian cities. This change was raised in Issue #3822 as a Bug, which is addressed in this Provider update. There are no Magic Mirror UI changes from this update.
The 'old' method to access Environment Canada involved accessing a static URL based on a City identifier which would result in an XML document containing the appropriate weather data.
The 'new' method is a 2 step process. The first step is to access a time-sensitive URL that contains a list of links to various cities that have weather data available. The second step requires finding the correct city in that list based on a City identifier, and then accessing that unique URL to access an XML document containing the appropriate weather data.
The changes made to the envcanada Provider code are solely aimed at using the new 2-step method to access a specified City's weather data. Since the resulting XML document structure has not changed, no other code in envcanada required changes.
Note that a ChangeLog entry is included in this PR.