[Archived][APP][Pro] OpenWeatherMap

Apps
62

For anyone still on Homey V1, the alpha version has been confirmed to work with V1.

DM me your Athom id (mailadres) and I will add it to the alpha version in the store so it becomes available to you as well.

63

Hi Anne,

Since the latest update, 0.0.15, the sunset variable hour value is zero. Thats a bit odd :wink:

64

Tsss… I am not aware of changing anything🤔 I shouldn’t have added it in the first place, it’s included in the standard Homey ‘date and time’ variables…

Although with the app you can use sunrise/sunset times for any location, but who needs that I wonder…

65

I noticed after update 0.0.15. Maybe it was there already before this version.
I will use the Homey standard variables

66

Thanks for reporting by the way.

I will fix it and publish it with some cosmetic changes to the Readme (removing references to the V1 version). Maybe in the coming two weeks or so.

1 Like
67

I can be a bit more specific now: the first digit is missing. F.i. the sunset value should be 21:25 but it is 1:25 in the app.

68

Hi Cor,

I can easily fix it, however at the moment I am not doing anything with Homey development, I am spending my time on other things. Perhaps when the memory leak is fixed and Homey becomes somewhat more usable again I’ll pick it up.

At the moment it is not on my list of priorities, sorry.

69

Hi Cor,

I have fixed the sunrise/sunset date format. The update can be downloaded from github right now (https://github.com/abaretta/nu.baretta.openweathermap), and will appear in the app store when approved by Athom.

Note that I do not appreciate the way you tried to drag me into the discussion on the Homeydash thread.

I understand that you want the bug to be fixed, and obviously it is annoying when the sunrise/sunset dates are incorrect in the dashboard, but please realize that I spend time on this completely voluntarily, I have tonnes of other things to do which are generally more rewarding than working on Homey apps.

Suggesting to remove the OWM app as a sort of a ‘threat’ is not very, let’s say, supportive. If you don’t like the app, just uninstall it and be done with it. If you do like it and need something done, a bit of positive feedback goes much further.

2 Likes
70

Thanks Anne.

I have taken notice of your remarks. My posts could have been more diplomatic. Sorry for that.
I do like the app :+1:

71

No worries :+1:

The fact that the dates did not (do not) display properly in Homeydash is certainly relevant.

Weird thing is that when I looked at Homeydash the sunrise/sunset values were correct. It seems the builtin values were used instead of the OWM values.

Also, with the OWM app you can add several different locations. In all cases the sunset/sunrise variables will have the same name (albeit in the context of different devices). I don’t know how Homey decides on which one to use as the ‘main’ sunrise/sunset value. I am surprised it doesn’t just stick to the builtin values :thinking:

72

Latest update shows the time correct. Thanks Anne

73

Hi, i installed the app today. It looks like the 16d forecast isnt working anymore, because this feature is no more a free feature? But this was the best way to look of the max and min temp of next day?

74

Does somebody knows the Update-Intervall of Daily/Current Conditions?

75

I thought 2 minutes

76

Thanks.

77

The app polls OWM every 10 minutes, however the data in the OWM current table is only updated every 30 minutes.

Also note that the data may be up to two hours ‘old’.

1 Like
78

Mmm, that would be a shame, but seeing what happened with the weather underground API not surprising perhaps.

The 16 day view still works for me, we’ll see.

It seems they have added a 4 hour table as well, and the UV data is now freely available again it seems. I’ll have a look at the 4 hour table (at some point :grimacing:).

79

Hello Anne,

at first thank you for creating this app :+1:

I tried to create a weather warning (for open windows) using this app.

The flow reacts now on cloudy weather conditions, not on rainy ones.
Is it possible, that the app don’t set the tag to the current value?

Screenshot_20190609-132537_Homey
Screenshot_20190609-132537_Homey.jpg540×1140 145 KB

Do you use these conditions from OWM-API?
OWM%20conditions
So the tag is filled with the detailed description (like “light rain”)? The condition instead is filled with the main description (like “rain”)?
So if I test the flow, I can use the main description as weather conditions for tests (Thunderstorm, Drizzle, Rain, Snow, Clear, Clouds)?

I also have a feature request for your app - for using it for precipitation alerts.
It would be nice if the app could provide a new trigger for changing between “no precipitation” and “precipitation”. So the condition precipitation should combind all precipitation-conditions like rain, drizzle, thunderstorm…
That would make it much easier to create flows for alerts. Now each condition must be checked in the flow and because only 3 OR-statements are allowed in the app, I have to create more than one flow for this…and much more to check the windows state in addition.
It would be nice if you could check if it’s possible.

Thanks and greetings
Ronny

80

Hi Ronny,

To be honest, I don’t think the OWM data is sufficiently accurate for your use case unless you don’t mind getting rain through the open windows every now and then.

I think the weather predictions are OK, about as accurate as most other sources (I guess). However, the detailed location based information in the ‘current weather’ table is not very accurate at all in my experience. I only use the app to warn me if frost is predicted in the next 24 hours, I don’t use the ‘current weather’ data at all.

The limited accuracy is the reason I only used the main condition code categories in the app. The more specific codes are like adding digits behind the comma when the accuracy of the number before the comma is questionable (by the same token, displaying the temperature in hundreds of degrees Celsius doesn’t make sense either, it suggests an accuracy which is completely unrealistic).

I don’t know what’s going on with the tag, I would need to look into that.

81

Hi Anne,

I know the prediction is inaccurate and only a approach. But the last week it was exciting close to the real weather.
The main condition is detailled enough for the app consitions. The details are too much for flows. If needed they can be printet with the tag. Your implementation is really helpful (details for the tag, main for condition).
It would be great if the main conditions could be used in conditions.
I just tested if it could be useful to remember of open windows if weather is getting rainy.
I followed some other OWM values, but the main condition seems to be the best way to handle it. All others are too detailed (e.g. rain in mm).

So I just wanted to inform you, that the condition don’t seem to work. I would be heappy if you could fix it :slight_smile:

Please ask if I can help with testing something.
Btw… what value must be set for testing the flow with conditions?

Screenshot_20190610-201813_Homey
Screenshot_20190610-201813_Homey.jpg540×1140 35.5 KB

Is “rain” (like OWM-API) the correct value instead of “Rainy” like shown in the condition , right? That was confusing before reading the OWM-API :thinking::innocent:

Thank you for your time and your help
Ronny