Migrate openweathermap to timeseries

Setup, Configuration and Use Migration
1

With the latest release “timeseries” was introduced and it was also mentioned that this will greatly simplify openweathermap by reducing the amount of items that need to be created.

This is also mentioned in the binding doc here One Call API Weather and Forecast

but looking at Channel Group Ids it seems that still the huge amount of items like “forecastToday, forecastTomorrow, forecastDay2, … forecastDay16” are needed?

So, my questions are

  • Can I already reduce the items from many (“forecastToday, forecastTomorrow, forecastDay2, … forecastDay16” ) to one and how would I do that?
  • Does the openweathermap-widget already support that?
  • How do I migrate my old items to timeseries and how do I have to adapt the widget then?

TIA
Stefan

2 Likes
2

I’m not sure if this is true in any way :slight_smile: as the forecast data is not fixed:

@ 10:00 temp_plus3h = 21.2 °C
@ 11:00 temp_plus2h = 21.0 °C
@ 12:00 temp_plus1h = 21.1 °C
3

Maybe this is only coming soon?

image
image2730×244 51.8 KB

4

My point is, the data can be written as timeseries, but will have to be rewritten once the data is updated.

5

I don’t know if they are needed but I would expect them to remain separate Channels until OH 5 since removing them would be a significant breaking change.

There also appears to be a new property on the one call API Thing for strategy that needs to be set to forecast. Perhaps you need to recreate the Thing to access that strategy property?

Based on what I’ve read I think the answer is yes. I never used forecast info so I’ve not tried it myself yet.

Probably not. It’s going to expect the forecast info to be in separate Items since UI widgets do not have access to persisted data.

I imagine you’d configure the strategy to forecast. Once that is done you’d just have one ForecastTemperature Item. As the binding updates the forecast, it will populate the predicted temperatures into Persistence. As the time passes and a “future” entry in persistence arrives, the ForecastTemperature Item will be updated. This makes less sense in this use case then it makes in cases like energy prices which get posted and updated at midnight and don’t change until the next day. The weather forecast is constantly being update and always into the future. Now is represented by different Items.

I don’t see any way you will be able to use these saved values in a widget directly. You’ll still need the separate Items to drive the widget. Instead of those Items getting their states from the binding, I imagine that you’d need a rule that queries the main Item’s future states and updates them accordingly.

6

Ok, thanks for clarifying that. This is actually a pity because the main, well only, way I use the binding is with the widget and if we cannot access timeseries in widgets this actually doesn’t improve a lot at least for that binding.

@florian-h05 Have you heard about anything that we would be able to access items of type timeseries in a widget?

7

First of all, it’s important to note that I only supported time series support for the OneCall forecast Thing.

Set forecastHours and forecastDays both to 0 in the Thing config and those channels won’t be created. (This is also in the binding docs.)

We (me and @laursen) decided to keep the current defaults so that those channels are automatically created for new Things as usual and more importantly, for Things defined in .things files are not removed if the forecastDays etc are not manually set.

Delete your (hundreds of) old forecast Items, set forecastDays etc to 0 and create new items for the new channels. The new time-series enables channels will be added to existing Things because I provided Thing upgrade instruction, no need to recreate a Thing.

Exactly. Time series are enables by using the forecast persistence strategy for the Items which receive TimeSeries from the binding. For time series support, there is no configuration needed on the Thing level. The binding only send the time series to the channel, what happens with that time series is up to openHAB core.

Well, currently this is my only use case as well, but once we integrated our heating into KNX and time series handling in rules has been improved (this means basically improving the PersistenceExtensions to retrieve future values from persistence), I will use the forecast data to plan heating.

No I haven’t, but I’ve already thought about that.
To access the forecast data, widgets would need access to persistence, which would theoretically possible, but require several requests to the server for the weather widget: temperature, precipitation, icon id etc.
Implementing persistence access for widgets is possible I think, but some work.

Personally I will create a rule to create a JSONDB on the server, store that in a string Item and use that JSON for the widget. Once I’m finished with the rule (the rule is actually the simple part, just some JS code) and the updated widget, I can post them on the marketplace, I guess others will have a use case for them.

2 Likes
8

This already works. I did a test with InMemory persistence, which now also works correctly in 4.1.1: