Could it be that with the last update of the app the temperature is not correct anymore? I see a difference for exact the same location of more than 3 degrees.
My weather station and pervious app: +0,7 degrees
New app: +3,27 degrees
What devices are you using? Current weather (the “old” one) or forecast?
After the update of the app I have added a new device: Current Weather.
Since a few months I compare the temperature of Open Weather with my local weather station. (Davis Weather Station). Before the update of the app, it was more or less in line.
After the update I see a difference of more than 3 degrees.
You took the correct city in pairing dialog? Perhaps there are differences in the lat/lon values depending you are using Homey location and city location or the location from the geocoding API is less accurate. You can compare the lat/lon in device settings.
The you can check the API call (new OnecallAPI) using this lat/lon values:
http://api.openweathermap.org/data/2.5/onecall?lat=…&lon=…&units=metric&lang=de&mode=json&APPID=YourKey
You can re-add the device without a city. Then Homey location is used with some more decimal places in lat/lon. Perhaps that makes a difference.
I have deleted the devices and added them again. Result in temperature is as follow:
- My local weather station: 2 degrees
- Open Weather (New): 4,06 degrees
- Open Weather (Old): 3,61 degrees
I checked the lat/lon values. These are the same.
Could you please check against the API (the linek above)?
Please insert the lat/lon and the API key and insert it in your browser.
You will get a result like this an there you can check the API result:
That’s the data from OWM. If the OncallAPI give different temperature, then it depends on the API, not on the app 
I get the same temperature as in the new Open Weather device I have added.
The strange thing still is the difference between my local weather station and Open Weather. The temperature was always in line but since the new API/App not anymore.
The temperature gap in the morning is big but during the morning/afternoon the gap is less big.
Hm, I would like to help, but if the API ist presenting a “wrong” value I can’t do much…
At OWM it’s not documented, where the data comes from. I thought, the current data should be the same independent of the used API. But who knows, perhaps OWM would like to get some people on the subscription.
Thanks for the answers. I will monitor the coming days the differences.
A new test version is available (0.1.1):
- flow conditions should be ok now.
- some translations fixes (thanks Peter).
- Added hourly forecast.
Some hints for hourly forecast:
- this device is a “child” device for the current weather device. So you can select a hour period and the “parent”. The current weather device will poll the API and update every child device.
- The hourly forercast is for the next full hour. Please check the date/time entry in device sensor view. Independent of thid hourly period, the values are updated instantly. So you will get trigger based on changed values if the forecast is changing within this hour.
- select “0” as period for current forecast (this hour)
- select “1” as period for forecast starting with the next full hour.
3 Likes
Hi Ronny, thanks for all the work and your views.
The 1h ahead device installed well.
Now, this device has 13 enum capabilities, and n# 13 (Windforce Beaufort), is slightly visible in the device ‘Status Indicator’ selection view.
After quite a few hit and miss, I was able to select it 
(setting a smaller phone font did not help, the table row height seems fixed):
I’m sure it’s an Homey app design (no scroll enabled) for that screen. I will inform at Athom about this.
Cheers
Hi Peter,
yes, that’s a Homey App issue. It seems for me a list with fixed row hight, too.
On my phone with a hgher resolution and some longer german words it seems to be ok.
There shoule be the “none” entry be visibe, too. But I have a fixed bar of android buttons. Have you them configured to hover?
To compare: the longer word is still visible in a line.
But I have textsize on position 2 from 8 possible settings. Really small. Perhaps that’s a reason why the date/time is not shown correctly in your example.
I’ve seen a error with the hourly forecast icon. It’s set wrong on pairing. A new testversion is online.
So best would be to delete the forecast device and ceate it new. Then it should have the correct icon with sun and clock.
Thanks, of course the resolution is a factor, didn’t realize.
The bottom bar can be hidden as I just discovered, and now the 13th capability is shown, still “None” is out of range.
This is all of my screen now:
.
Now I’m waiting on Athom’s reply
Check!
Oh I made a mistake earlier with the flowcard translations.
Windspeed (km/h) = Windsnelheid (km/u)
Other findings:
-
Tile 1h forecast install:
If you set forecast time to 0 hours during install, there will be no data loaded.
If you set forecast time to 1 hour, data gets loaded.
If you set the forecast time back to 0, then it halts.
If you set it back to 1 or up again, it only starts updating after an app restart. -
Current weather per 5min.
The time of “Forecasted time” is correct, but sunrise/sunset seems to be at UTC instead of local time.
At my location the timezone is +1GMT and both timestamps are an hour early.
I have already helped with the translation of some apps into German. So far, I didn’t recognized any app that the units were translated into local language.
The international unit for speed according to the international system of units SI is m/s. km/h is based on the unit m/s. km/h is therefore an international unit.
Thanks, that is fixed with the test version 0.1.3
The problem with the time I will check later. Perhaps the new API is providing UTC timestamps instead of local timestamps. I just copied the logik from the old devices but it doesn’t seem to fit.
1 Like
That’s wrong for the old devices, too. I think it depends on the Homeys firmware update last year where Homey internally started to use only UTC. I have to correct it for all devices of OWM app.
Update:
The sunrise/sunset should be in local timezone now.
Testversion: 0.1.4
1 Like
Hi Dirk, thanks! You’re right, before I never really noticed it appearantly.
My focus was on the description though.
Windforce = Windkracht
Windspeed = Windsnelheid
