[Archived][APP][Pro] OpenWeatherMap

I just installed app. It is getting installed but when I want to create a flow I can not choose the app??
I have restarted Homey and reinstalled the app. Same result.
Dont work for me.

Hi, you have to create a device and use this for reading values or use in flows.

Thanks! It works now👍

Hello Anne,

I hope you still receive eMails from this community…
I’m interested in continue app development for this app. Even if it needs some rewrites based on the new API (and perhaps breaking changes). It would be too bad to leave this app unsopported.

So please feel free to transfer the app to my account. I can clone your github version (is it up to date?) to continue.

Bye
Ronny

3 Likes

Nice to hear, Ronny. I like this app a lot!

then you are my beta tester :wink:

I didn’t use this app for a time. After using HA instead of HomeyDash I had no usecase for it.
But a forecast with flow alerts (rain in the next hour) would be nice. So I decides to continue this app and extend the OneAPI with forecast data.

The ‘old’ api for hourly and daily preview still seems to work. The paid API uses another URL. The ‘old’ URL still works. But perhaps its a kind of adjustment period and the old API will discontinued somewhen.
Perhaps the old drivers will be removed and only the OneAPI device will be continued. That will need an addition of forecast devices for teh OneCall API.

My goals for the next time are:

  • Upgrade to SDK V3
  • Add ‘child’ devices for OneCall-Current device. The advantageof the OneCall API is, that the current device is already reading all information with one call. The forecast data can be pushed forward to child devices for hourly/daily forecast. That saves a lot of API calls. You have 1000 calls free a day wiht an API key. So you could add several locations and use a shorter call period.
1 Like

Does anybody know if it will be possible to see the precipitation per day?
What is currently visible in the app is participation per hour.

The ‘old’ OWM API is providing these values. But it’s not yet implemented in the app.

But this API will not be extended in the app. It’s still working, but no longer provided by OWM as free subscription.
Instead, the target is on the new OneCall API which supports hourly and daily forecast (including rain and probability for hour/day). So please give me some time to transfer the app and make some technical upgrades. After this, the app can be extended with new hourly/daily forecast using the OneCall API.

3 Likes

Thanks Ronny that you will work on an update of the app. In the mean time I will keep my local weather station online until the total precipitation will be available via the app.

Okay then, if you insist :laughing:

Hi Ronny,

I have just received your mail and transferred the app to you :+1:

There are some unresolved/unfinished issues in the latest version in the repo… A rewrite would be probably be a good idea anyhow :slight_smile:

3 Likes

Thanks, Anne. Well, the app ist pretty good structured. And I won’t like to destroy as less as possible (breaking changes). So I’ll just bring it to SDK3 and then extend with some missing features (forecast for OneAPI).

PS: If you still kwow some details of missing things, you can send me a list via PM.

3 Likes

Hello to all beta users :wave:
The new major update is on the way!

:arrow_right: The new test version:

First there are many changes for updating to SDK3 - technical details with which I do not want to bore you.
So I go further to the details wich will affect you.

  • The ‘old’ devices using the old API seems to be still working. It seems the API ist still active, but not longer visible at OWM API page (they use different URLs now). So you can still use these devices.
  • The device for the new OneCall API got some updates - new capabilities, more flow trigger and a new pairign dialog. You can still use your existing device, but I would prefer to remove it and add it new. You will have all capabilities in a better order and clean device settings without old entries.
  • The add-device dialog for the OneCall device has a more Homey-like design. In the pairing dialog, you can insert the OWM API key, followed by your city. Leave it blank to use Homeys location (lat/lon). A request interval can be set (default is 5 minutes). All settings can be changed in device settings.
  • You can add several location (devices for current weather). Each device can have it’s own request interval.
  • With a API key you can execute 1000 calls a day. So set your ovreall intervall to a value where you keep below 1000 calls for all devices.

Some visual details from the paiting dialog…

  • The app got a new design:
    grafik
  • And some new device icons.
    grafik
    The first one is the current weather using the OneCall API. Select this entry.
    The other ones are current weather and forecast for the old API - deprecated now, but still existing. They will continue to work, but will be hidden for paiting in future.
  • Insert your API key and City
    grafik
  • Select your City
    grafik

Please try the new version.
If you see errors, missing flow trigger, not working things, please report here with some screenshots, so I can reproduce the issue.
I translated into dutch using Google translator. If you have ideas for a better translation, please give me some improvements.

Next steps will be

  • adding hourly and daily forecast for OnecallAPI
    These will be “child” devices for a location (current weather). The location device will retrieve the data and the hourly/daily details will be pushed to the forecast devices.
2 Likes

Thanks! Looking good, Ronny.
It’s part of the game to migrate unfortunately, but I’m very glad the OpenWeather app is alive again.
The depricated devices seems to work ok now, I have to monitor them.
I will notify you of any Dutch translation thingies.
Cheers

Oh, one thingy, the mobile app doesn’t show all tile value choices so it seems.
EDIT: I see now there’s exactly 12 enum capabilities

Thanks for your test. All suggestions for improvements are welcome.

For a tile item you can only select numeric values, no text or enum values. That’s a default behaviour.

YW! I see now there’s no more than 12 enum capabilities.

A few flows broke, the trigger ID of the triggercard was: ‘measure_rain_change’ (as I remember)
The new value seems to be ‘RainChanged’?

And one flow with triggercard ‘If windstrength in km/h’ changed (don’t remember the exact trigger ID)
The new value seems to be ‘WindStrengthChanged’

The Dutch (Google) translation was pretty accurate.
A few (translation) suggestions:
‘voelt-als temperatuur’ > ‘Gevoelstemperatuur’

and
Triggercard:
Ultraviolette index = Ultraviolet index

and

and

F.i. ‘Windkracht (km/u) werd …’
and
‘Windkracht (Beaufort) werd …’

Cheers

Interesting, that there was a trigger for measure_rain_changed. That was nowhere defined in the app. Perhaps it was auto-generated by Homey for the capability. I added trigger where nothig was already defined.
The “old” trigger from the previous app version were named XxxChanged, so I used this style. This has a disadvantage - each trigger must be defined and triggered for every capability inside the app. But the advantage is, that I can define in the app, when it’s executed.

Example:
All auto generated trigger will be executed on capability change. At this time, some capabilities would be set to the new value and some still have the old value. Conditions would not be accurate if you are checking other device capabilities in the flows.
Using “own” trigger gives the ability to update all capabilities first and trigger flows after that. In that case you can use all capabilities for conditions with their new values.

So it’s not so easy to solve this. I would suggest to use the current flow trigger, even if it needs a flow rebuild. That’s the only way to solve the existing inconsistency of flow execution.
Migrating to OncallAPI will need new flows, too :sweat_smile:

I didn’t think of a screenshot before repairing my flows, so I temporary installed the live version 0.0.20 again :sweat_smile:

.
Oh, and if you can change the date to this format for the Dutch:


No hurries ofcourse

Cheers

Hi Peter,

I checked the code again. And I think it’s a behavior or difference between SDK2 and 3.
The old SDK seems to show auto generated trigger for capabilities. So you could use measure_rain_changed even if it was not defined in the app (like the higher/lower trigger now).
With upgrading to SDK3, this trigger is not generated by Homey but you see the new app defined trigger.
I think we’ll have to live with that. Going to the new devices will unify such things.

About the date…Homey (or its Node.JS version) has no support for language depending time formats. That’s why I only calculate the time for the current timezone and then use a kind of “international” generic layout. In my Webapp its splitted on 2 lines, in the mobile app it all fits in one line?

Hint: all condition cards are broken in the new test version. There a adaption for SDK3 ist still missing…