Weather map not updating

I have obtained the API key from OpenweatherMap . And I configured it in HomeGenie in the weather widget.
Still, the data won’t update at all.

The data is completely nonsensical for my location - it never, ever, snows here, for example. The widget displays “waiting for data”. I have my location setup in configure/maintenance. I have restarted the service, rebooted the Pi, all to no avail.

What am I missing ?

I also have an API key but I don’t believe my data has updated in months. My belief is the data request or the returned data has changed and the widget will require an update OR the API no longer works. I haven’t looked into it since I don’t use my HG interface unless I’m changing something so I’m not the right person to help with fixing it.

It updated overnight. Guess I wasn’t waiting long enough.
I’m getting temperature in celsius, which is what I want.
But the times are still in US style 12 hour (AM/PM).
They are only in US style for the weather widget. For my X10 device widgets, times are properly in 24 hour format.

OW is working perfectly here. In the Programs>Open Weather>Options section make sure you choose the correct update interval, say 60 minutes.

In Maintenance>User Interface make sure those settings match your local preferences, 12 or 24 hour and Celsius or Fahrenheit. It’s all very straightforward.

I have set my preferences in Maintenance>User Interface to 24 hour and celsius already. I thought I had mentioned that, but it looks like I hadn’t.

The temperature correctly shows in celsius. But the time still shows with AM/PM, ie. 12 hour format. It shows 12 hour time format only for the weather widget. The time for all the X10 widgets is in 24 hour format, as expected.

As to the update interval, it was left to the default 30 minutes. I tried to change it to 15 minutes using the up/down arrows, then exiting the weather widget. But it didn’t get saved. Turns out the value set using those arrows is not saved. But using the slider bar immediately to the right does cause it to be saved immediately. So, I was able to change it to 15 minutes. Even after restarting, the time is still in 12 hour format in the widget, though.

Another really weird thing is that it shows the wrong update time/date at the bottom of the weather widget. Right now, it says Friday, January 7, 2022 8:02:02 PM. Whereas it’s currently still January 6 after 8pm as I type. So, it’s 24 hours ahead somehow. The time on the machine using the “date” command is correct, as is the time zone.

[email protected]:~ $ date
Thu 06 Jan 2022 08:14:53 PM PST

The time you see at the bottom of the OW widget represents the last time OW was updated. Change the interval setting to 60 and make sure it’s correctly saved. If you make too many calls to OW in a 24 hour period you may experience problems. Read up on OW from their website and recommended settings

I know the date/time at the bottom is the time of the last update. It’s just weird that that time was 1 day ahead yesterday. As of right now, it’s no longer one day ahead. It appears to be updating every 15 minutes as I told it to. However, the update time is still in 12 hour (AM/PM) format, as are the sunrise/sunset times. I don’t think the problem is about too many requests.

FYI, when I look at the UI from my phone instead of PC, at the same time, here is what I get.

The widget says celsius, but the temperature is 55.5 which is clearly a number in fahrenheit, not celsius. 55 celsius is close to the hottest outdoor temperature ever recorded on earth !

All times in the weather widget are in 12 hour format, still. Interestingly, the times in the other widgets (X10) are in 12 hour format also, whereas they are in 24 hour format when I look from my PC.

I’m using Firefox on both my phone (Note 20 Ultra) and PC (Windows 10 based).

I think there is something seriously hosed. I see at least 3 bugs .

  1. with Firefox on both PC and phone, weather widget times are in 12 hour format instead of 24 hour

  2. with Firefox on phone, weather widgets temperature value is in fahrenheit, but listed with a celsius unit. Ie. nonsensical

  3. with Firefox on phone, X10 widgets times are in 12 hour format instead of 24 hour

Are you using a different browser ? Do you see a different behavior on phone and computer ?

I suggest you firstly check the HG logs for any errors and if it shows up nothing reinstall HG from fresh again. You may well have somehow corrupted the HG config files. Be careful that your HG backup files don’t carry forward any config file errors to a fresh install. To avoid this you might want to rebuild your HG configuration around the fresh install instead of importing potential errors to the fresh install.

There’s not many users left checking in here. I do from time to time. The authors GitHub would be the place to post potential bugs but I wouldn’t hold my breath for a speedy reply :joy:

Looks like there is a workaround for these 2 bugs on the phone.

  1. Go to configure/maintenance/user interface.
  2. toggle temperature to fahrenheit
  3. toggle temperature back to celsius
  4. toggle date to 12 hour
  5. toggle date back to 24 hour

At that point, behavior is identical on the phone vs desktop, ie. temperatures are all correct, in celsius. And times are all in 24 hour format, except in the weather widget.

It looks like HomeGenie is storing some configuration for the time and temperature units locally in the browser, probably in cookies, even though there is only one global setting in the admin UI.
Each browser can have different settings for time/units, despite the admin having a single possible value stored. I would say this is a problem with the design :frowning:

The issue with the 24 hour time setting not being honored in the weather widget seems like a more systematic bug.

I’m sure if you dig a little deeper into the code you’ll get a better idea what is going on. I’ve made some suggestions so it’s up to you how you proceed from here.

Seems to work for me in Santa Ynez.

I just looked into my widget and it turns out that the driving app was disabled for some reason. I enabled it and it updated right away. FWIW, I’m using the jkutils-openweatherdata app. The one called openweathermap doesn’t work (complains about a string error). I don’t need it, so not looking into the issue but wanted to confirm that when the program is enabled it does seem to work. :rofl:

Where did you get that jkutils-openweatherdata app ?
I only see two apps under “Weather and environment” : “basic thermostat” and “OpenweatherMap”.
I have been using OpenweatherMap . I didn’t get any string error, just major problems with the data date/time and temperature.

jkutils was a standard package in the past. I don’t think it’s installed by default anymore, but it is likely in the library of apps in the HG download manager. I haven’t looked recently so that’s an assumption. I’d also recommend checking the old forum links as I know it should be there assuming file links were saved with the forum backup.

Where is the HG download manager in the user interface ? I really can’t figure out this program at all.

I found it - it was called “Package manager” , not download manager. No wonder my google searches came up empty.

I was able to configure it correctly, and add its widget, which now updates and shows the current temperature in celsius. The time is shown only in terms of “last check” and “last update”, and displayed in a 10 digit format - looks like a Unix epoch. No information about sunrise/sunset.
No forecast either. It works, but it really doesn’t look like a very useful widget :frowning:
At least it works, except for the “0° undefined” part. I’m not sure what’s supposed to be there.

Fwiw, i searched google for “homegenie download manager” and the first two links were to useful HG pages. The second had information on the package manager and how to use it.

The interface is self explanatory and includes comments on the tool/page.

As for the utility, that’s something you’d have to ask the author or update yourself. All the code related to HG is open source so you can modify it as you like to make it your own. Obviously if you release it back to the public its common practice to leave references to the original author.