Generating derived weather calculations with the Weather Calculations Binding

Thank you Bill, it ran all night and its working!

Best, Jay

Perfect!

As a side note for others, I’ve uploaded the new version to the marketplace (I think, it seems like the only option is to simply replace the link on the listing.) If anyone needs to upgrade, I think you just uninstall the old version and re-install. Or get it from directly from the download link above.

Best,

Bill

Hey Bill,

I’m seeing the Trend factor being the same during the same binding calc cycle for 2 different states (IL & FL) when it shouldn’t be.

Here’s the config for both, if you want me to try different altitude for each location, I’d be glad to since I’m NOT 100% sure these are accurate.

Hoffman Estate, IL
Altitude = -798
Station Altitude = 231

St. Petersburg, FL
Altitude = 46
Station Altitude = 46

Both places have separate specific weather items for each location.

2022-06-12 03:57:40.051 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Chicago Barometric Pressure Trend via MAP is Storm is coming
2022-06-12 03:57:40.369 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Florida Barometric Pressure Trend via MAP is Storm is coming

2022-06-12 05:57:42.398 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Chicago Barometric Pressure Trend via MAP is Storm is coming
2022-06-12 05:57:42.688 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Florida Barometric Pressure Trend via MAP is Storm is coming

2022-06-12 06:57:43.618 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Chicago Barometric Pressure Trend via MAP is Storm is coming
2022-06-12 06:57:43.795 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Florida Barometric Pressure Trend via MAP is Storm is coming

2022-06-12 07:27:44.323 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Chicago Barometric Pressure Trend via MAP is Storm is coming
2022-06-12 07:27:44.517 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Florida Barometric Pressure Trend via MAP is Storm is coming

2022-06-12 07:57:44.850 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Chicago Barometric Pressure Trend via MAP is Storm is coming
2022-06-12 07:57:45.124 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Florida Barometric Pressure Trend via MAP is Storm is coming

2022-06-12 08:57:46.160 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Chicago Barometric Pressure Trend via MAP is Storm is coming
2022-06-12 08:57:46.449 [INFO ] [org.openhab.core.model.script.WEATHERCALC         ] - Florida Barometric Pressure Trend via MAP is Storm is coming

Best, Jay

Yep, seems I neglected the pressure trend calculation which uses a shared source of data. I’ll fix that tomorrow and get a new version for you to test out.

Sorry about that!

Bill

1 Like

I’ve uploaded a new version (3.2.3) that I think should fix the problem. I’ve only had it running for a few hours, but it /seems/ to be working, if you’d like to try it out.

https://bitbucket.org/hww3/org.openhab.binding.weathercalculations/downloads/

1 Like

Have some updates on the subject of displaying weather forecasts:

After looking around and giving it some thought, I think that the idea of a common schema for forecast data may be a losing proposition. That’s mostly because there’s a wide variation in the data available between different sources and producing a schema that doesn’t omit data from more full-featured forecasts (like WeatherFlow’s) would result in quite a bit of complexity. It’s a shame, but the primary downside is that each widget would need to be customized; something you’d probably want to do anyhow.

I do think that weather flow’s data format would be a strong contender for the common schema, as it’s well thought out and includes all of the data you’d want. :slight_smile:

Now for something you can actually play around with…

I’ve uploaded a new version of the smart weather binding that includes a new thing type: Better Forecast. Create one of these things and configure it with your station ID and an authorization token and you’ll get access to an automatically updated forecast based on your location. The Better Forecast thing also has features for trimming the number of forecasts in order to improve performance. By default, the forecast includes 10 daily and 220+(!) hourly forecasts, so you can cut a lot of data transfer if you don’t need that amount of data. It also “enriches” the forecast and current conditions with some extra fields that make building widgets a bit easier. This includes things like icons for the various conditions (a work in progress) as well as sunrise/sunset calculations.

https://bitbucket.org/hww3/org.openhab.binding.weatherflowsmartweather/downloads/

Once you’ve set a forecast thing up, you can link an item to the enriched forecast data and use this widget to display it in your OpenHAB UI:

https://git.sr.ht/~hww3/org.openhab.binding.weatherflowsmartweather/blob/master/src/main/resources/widgets/weathercard.yaml

This is based on the WeatherCard widget by @RGroll, discussed here:

And it looks like this:

In addition to the weather card widget file that you’ll use to create a new widget in the OpenHAB UI, you will need to add an empty file called “dummy.js” in your config/html directory, but that’s a one-time thing.

The widget does some “magic” that gets around forcing you to create a million items by parsing the JSON data before the widget fills things in. That, plus some of the extra fields the enrichment process contributes made the resulting widget code a lot simpler. Just be careful not to mess with the “onload” line in the widget. I’ve got some additional things I’d like to do (I want to add an option to use WeatherFlow’s weather icons, for example), so I will try to follow up when I have more to report.

As always, comments and suggestions are welcome!

Bill

1 Like

After looking around and giving it some thought, I think that the idea of a common schema for forecast data may be a losing proposition. That’s mostly because there’s a wide variation in the data available between different sources and producing a schema that doesn’t omit data from more full-featured forecasts (like WeatherFlow’s) would result in quite a bit of complexity. It’s a shame, but the primary downside is that each widget would need to be customized; something you’d probably want to do anyhow.

In my opinion “a common schema for forecast data” would need to be, in the first place, rather a sort of the agreement made between weather bindings developers. Forecast sources from different weather providers deliver similar data i. e. weather data (temp, precip, humid, pressure etc.) and also description of the weather together with corresponding icons. The issue is that the same data are often delivered in different ways. If you are non-standard user, it’s fine, because you will rather choose to customize both, data and widget. However, for typical person who just want see forecast for the next 5-7 days with a “complete” widget it is important to have data in a common and consistent format. I would take Kodi as an example, where you have default widget for weather forecast and different providers that you can choose to install depending on the accuracy of data as appropriate to desired location. I could imagine something similar in OH, where you could have a weather widget with forecast available in OH3 from the start and user would just need to install any weather data binding, set the location in OH3 settings and choose weather provider in widget configuration to have it all set and working.

I do think that weather flow’s data format would be a strong contender for the common schema, as it’s well thought out and includes all of the data you’d want.

I agree, the scheme provided by WF is very good.

Once you’ve set a forecast thing up, you can link an item to the enriched forecast data and use this widget to display it in your OpenHAB UI:

Ok, sorry if this is a silly question, but how exactly should I configure forecast thing to have it working with the widget?
I made the thing and created items for each channel.
Now, what do you mean by “linking item to enriched forecast data and use this with the widget”?
As far as I understand the widget itself doesn’t need to be fully configured, but how should I link “enriched forecast” to the widget? Is this something I should put into “Item prefix” or change other setting, or maybe I should change something in the YAML code? Right now I get error as follows:

Hi-

Use the weathercard widget here:

https://git.sr.ht/~hww3/org.openhab.binding.weatherflowsmartweather/blob/master/src/main/resources/widgets/weathercard.yaml

In it’s configuration, there’s a setting for “Forecast Item”. Set that to the item you created above for the “enriched forecast”… I think you’ve called it WeatherFlowForecast_ForecastEnriched.

That should be all you need to do. There is a lot of data available that isn’t displayed. You can customize that if you want, the code is a lot simpler than the original version because all of the data is in the one item and it gets parsed into a javascript object so you can do something like:

=items[props.item].objState.current_conditions

I’ve included an example of the kind of data you can get from the enriched forecast here:

https://git.sr.ht/~hww3/org.openhab.binding.weatherflowsmartweather/tree/master/item/src/main/resources/widgets/forecast_enriched.txt

One side note: I found a bug in the Main UI that was causing the forecast icons to be missing. My fix was accepted a week or two ago and it should be present in the latest snapshot.

1 Like

Yes, I think that in order to be useful, you’d need to account for data that most people wouldn’t care about (but that some might)… yahoo weather probably doesn’t include a lot of the types of data that the weather flow data does. Right now everyone has been tailoring their widgets and such to the specific data source they’re using. Maybe if we got to the point where we had some really good widgets that used the weather flow format, we might convince people to convert their data to the weather flow format.

There are some other weather formats that seem well thought out (the Norwegian meteorology department looks nice), but even the best of those don’t have places for the detail available in the WF format.

Thanks Bill! Amazing work. It didn’t work for me in the first place because I have hade already installed WeatherCard widget with the same UID, so this time I’ve copied YAML to new widget and changed UID and it works.
It seems that enriched forecast provides a lot information. If i find some spare time I would like to build a full screen weather widget with these data. Thanks again for your work!

1 Like

Just to let you know, after 3.3 upgrade of OH, Weather Calculations failing to be installed from marketplace
image

anyway, your manual installation how-to, worked fine … :+1:

No sure what might have gone wrong; was that the only error you got? Did you already have the binding installed when you did the upgrade?

i had it installed manually (updated version 3.2.1), after OH upgrade i was trying to install one from the store 3.2.2 and got the error above, nothing more.

installed 3.2.3 manually after that…

I suspect that the marketplace feature doesn’t know how to deal with upgrading a bundle that’s been manually installed. The marketplace is still a fairly new feature, so they probably haven’t figured out all of the use cases. Glad you were able to get it installed eventually!

thanks to your great manual how to do that (which i would never found out by myself) it’s piece of cake :wink:
only downside is that i needed to set log:level again

maybe consider by default log:level ERROR instead of INFO? as it’s filling up openhab.log with pretty useless informations on every weather change… :wink: or direct it to the event.log instead which makes more sense to me.

Hi-

Yes, I know that with a default logging configuration the binding is pretty verbose. The reason for that is that it makes troubleshooting for new users a lot easier. I think eventually I will be able to turn the noise down a bit. I’m not able to control where the log entries appear, that’s something that would need to be done at the openhab installation level. For now, you can turn it down with

log:set WARN org.openhab.binding.weathercalculations

Also, I’m not sure why you’d lose those settings during an upgrade… I’ve not seen that happen here.

Hello, all!

I just wanted to let everyone know that I’ve uploaded a version of the Weather Calculations binding that has been compiled for openHAB 3.4… no other changes, and I haven’t tested it myself. I’ve also updated the marketplace entry (I think). Feel free to give it a try and let me know if you run into any problems!

https://bitbucket.org/hww3/org.openhab.binding.weathercalculations/downloads/org.openhab.binding.weathercalculations-3.4.1.jar

Thanks, Bill!
Works perfectly. Used the opportunity to switch from .jar files to the Marketplace, no issues there, either.

1 Like

Many thanks for the report… glad to hear it’s working for you!

1 Like