Yeah, you’re right; after a full-reset, “Adelaide, Australia” works correctly. I’ve discovered a few quirks though, mostly surrounding the weather APIs, but also with the v2.1.0-b UI.
I think a summary of what I did was; try PWS-fail, try local town location (green lookup)-fail, set time-zone using buttons during startup, try various other location settings-ongoing fail.
Despite lots of rebooting I have only just tried a full-reset. I’m guessing setting the timezone using the buttons during startup hard-codes them, resulting in continued failure to correctly set sunrise/sunset even if the correct data was returned.
So why did the PWS and local towns fail? I’ve been digging around within weather1.py from the repo to determine the source of data, and found the API responses to be quite inconsistent in various situations.
For a start, the PWS data returned by wunderground and openweathermap is from a completely different country! Check the responses for a PWS in my neighborhood:
http://api.wunderground.com/api/YOURAPIKEYHERE/current/conditions/q/pws:ISOUTHAU107.json
http://api.openweathermap.org/data/2.5/weather?q=pws:ISOUTHAU107
I don’t really understand weather1.py, but it looks like it is getting the sunrise/sunset data from openweathermap.
Another quirk is that “Aldgate, Australia” gives a green lookup in the UI, but the wunderground API returns an error:
http://api.wunderground.com/api/YOURAPIKEYHERE/current/conditions/q/Aldgate,%20Austalia.json
The openweathermap response looks reasonable:
http://api.openweathermap.org/data/2.5/weather?q=Aldgate,%20Australia
Choosing “Adelaide, Australia” gives a consistent response across the APIs and UI, but unfortunately the temperature and rainfall is significantly different from where I live.
So I guess I’ve discovered an edge-case. I’ll keep tinkering with it, but my level of understanding of the code is fairly limited at the moment.