Net.WebService GetData() problem after Raspberry Pi update

Good morning,

As I periodically do, I checked for updates for my Raspberry Pi this morning. Seeing these seemed to be an update (see here: https://www.raspberrypi.org/downloads/) I went thru the process of using Putty to connect to my Pi and then go thru the update.

Everything appeared to work fine, and it boots and HG Loads.

However, I am getting an error with the Weather Widget now - its reported that it cannot find “sys” in a string - but after some troubleshooting, appears that this command in the Weather program (both the “standard” and my updated version):

var weatherData = Net.WebService(webserviceurl_conditions).GetData();

is no longer returning any data, so when the rest of the program tries to parse the results it ends up with the missing sys error.

If you add this line:
Program.Notify("weatherData = " + weatherData);

to the weather program right after the line above, and then under Maintenence options turn on Event History you can see that weatherData is nil - it should be a list of data returned from the OpenWeatherMap API call.

I’m not sure if perhaps the Net.WebService on the pi was not started / enabled after the update, or if something in the update changed / broke how that is supposed to work. But I’m hoping someone here may have an answer (or even a suggestion).

Thanks :)

Might be worth posting this in the relevant Github. Not sure if you will get a response though.For anyone having this problem and using this source as sunrise/sunset for automations you’ll experience difficulties.

I posted a new issue over on GitHub

For those that wish weather the jkutils open weather available from the package manager does still work. I use to run both it and the WU as past experiances showed me you couldn’t relie on a single weather pull.
Once Genie updated to the OW I stopped using the jkutils program. I fired it back up yesterday and is still reporting however temperature is off by a few °C for my location.

Over on GitHub, Gene looked into it and found the issue to be the certificate on the OpenWeatherMap side expired. You can see the details here

Since some like yourself rely on weather data in their automation setups it may be worth coding a backup pull for when certificates fail in the future. I’m sure this won’t be the last time we experiance a SSL certificate expire.

Just for others who are experiencing a similar issue, this issue relates to the OpenWeather program that comes as standard with HG, in current release 1.3 v7. Obviously it doesn’t affect the HGBE Edition as it doesn’t use OW.

According to Gene the OW security certs expired on 30 May which would tie in with the last valid call HG made to OW so users of OW may now need to wait until OW update their security certs.

OK, I can confirm that the work around (which is what it is right, not a fix - that will hopefully come from OpenWeatherMap when they do something to update their certificate) posted on GitHub here will allow the weather program and widget to work again:

Folks in case your puzzled at what fix @soxfan1966 is referring to here is the solution I posted in HG GitHub

You could use this as a workaround but ensure you take an image of your install SD card before editing security stores. This solution comes with a health warning.

cd /etc
ls -al ca-certificates.conf*
sudo cp ca-certificates.conf ca-certificates.conf.BAK
ls -al ca-certificates.conf*
sudo nano ca-certificates.conf

Edit

“AddTrust_External_Root.crt” to “!AddTrust_External_Root.crt”
sudo update-ca-certificates

Thanks, I thought I had included a link to the GitHub post.

It’s important to be clear what solution worked when editing security certs. Incorrectly modified certs can play havoc with an install.

You don’t need to disable security certificates to get OW working. Just change the pull from https to http.
A try catch bit of code added to the HG OW so when the https pull fails it uses the http pull.

The workaround I provided relates to OpenWeather and the strict SSL connection. All other aspects of HG will function as normal.