Generating derived weather calculations with the Weather Calculations Binding

It’s actually surprisingly hard to make versions for a particular milestone release. I think the 4.1 release is almost here, so I’ve prepared a version for that:

http://bill.welliver.org/dist/openhab/org.openhab.binding.weathercalculations-4.1.0.jar

Hello, I currently getting this warning

2024-03-26 00:00:00.009 [WARN ] [s.handler.WeatherCalculationsHandler] - Bucket tipper future already exists. Cancelling it.

I am on OH4.2M1

current stable is 4.1.2, maybe the binding is not yet updated for 4.2?

I don’t generally make public builds for milestones, as they tend to be moving targets. Often a version from the previous stable release will work for at least a few milestones, until dependency versions get changed, at which point the previous build won’t load anymore.

This message probably indicates that the binding was reloaded or that you’ve possibly got multiple copies of the binding installed. The binding handles the situation, but it lets you know that something unusual is possibly happening.

1 Like

will this addon be part of the marketplace? as now on 4.2 it got again purged out so my calculations not working again … :face_holding_back_tears:

Hi-

4.2 was just released a few hours ago, and preparing a new version for the marketplace is a manual process that I haven’t started yet. It may be a few days before it’s available for 4.2. I’ll reply here when it’s uploaded.

Bill

1 Like

Good to know, I will defer the update to 4.2 for a while, then.

Thank you for all you do, Bill!

Hi!

I’ve recompiled this binding for 4.2.0 and uploaded it. I’ve also updated the “marketplace” entry, so that it should show up for 4.2 users. Please have a look and let me know if you discover any problems (I haven’t yet upgraded to 4.2!)

Bill

1 Like

thank you,
calculations works :+1:
not sure if this is related to OH4.2 (probably) because I’m getting more errors like this from WeatherUndeground binding as well :thinking:

2024-07-11 09:07:50.706 [WARN ] [ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '27.79 hPa' of item WC_VaporPressure with form

at '%s %unit%': Conversion = 'u'

removing %unit% from item definition removed the error. Not sure if we are now not supposed to be using it :wink:

@hww3 would it be possible that WC items could use “unit” definition from OH?

Seems like now they arent

Number:Length           WC_RainToday            "Rain Today [%s]"             <none>          (gWeatherCalc)  {channel="weathercalculations:weathercalculations:myWeather:rainfallToday", unit="mm"}

still shows meters, am I doing something wrong, or it’s not possible yet?

Hi-

I think both of the problems you mentioned happen outside of the binding itself. The binding returns values with units of measurement attached and then depending on the system of measurement you’ve set or the item display configuration, openhab will convert the value as necessary.

For example, here’s what the binding does at the start of each day to update rainfall totals:

 this.updateState(WeatherCalculationsBindingConstants.CHANNEL_RAINFALL_YESTERDAY,
                new QuantityType<>(new BigDecimal(rainFallYesterday.doubleValue())
                        .setScale(RAIN_DECIMAL_DIGITS, RAIN_ROUNDING).doubleValue(), CENTI(SIUnits.METRE)));

In my UIs, I get a value displayed in inches, because I’m set to use “Imperial” units.

Digression: calling it the “Imperial” system is actually incorrect, in the US we use the “US Customary” system of units, which actually differs from the “Imperial” system used in the UK. There are differences in the units that were modified here or there post-1776: primarily those involving volume (the British pint is bigger than the US pint, for example). There are also some differences in avoirdupois measurements (short ton vs long ton). So yes, things are even more of a mess for those not using SI units for everything than it might seem on the face.

Having said all of that, I think ultimately the answer to your question probably lies somewhere in the workings of the UoM system. From a quick read of the documentation, what you’re doing looks reasonable. Something is obviously making conversions, because as the code snippet above shows, we’re working with cm internally for that particular channel. Perhaps this is a bug? Most likely, you need to restart openhab to get it to notice the change (I had to do this to cause unit metadata added to an item to take effect here).

Interesting. To my knowledge the customary units for rainfall are either “mm” or “inch”.
Never heard someone use “cm”.

“mm” is especially nice since the number is the same for “liters per square meter”, often used by meteorologists.

To be honest, I don’t recall the reason cm ended up being used (suspect it may have been related to the measurement a rain gauge was using. The UoM system, thankfully, converts to the units users actually want. Hopefully, you can get the right units out… let me know if that’s not the case, and I’ll try to raise the issue with the openhab core folks.

On my weather station the rain is in cm as well. Don’t know why.
I use mm.

To be honest, I don’t use the rain function with the weather calculations. I only record the cumulative sum of rainfall and derive the daily/weekly/whatever amount from there.

But I do wonder about the units as well. My system is set up “imperial”, so I record windspeed in mph. That’s what the item says, too.
But the Weather Calculations Thing shows this:

Item that provides the current wind speed in meters per second

Does that mean that OH converts that from mph to m/s or are things like my windchill off?
I suppose it’s the former, since my heat indices are correct, and my temperature is in F, but the binding still shows:

Item that provides the current temperature in ºC

I suppose that’s just hardcoded in?

The binding uses SI units internally to perform all calculations. If the items you’re providing as input don’t provide Unit of Measure (UoM), then the values have to be in the units in the description. If the item provides a unit of measure with each value, then the binding can request that openhab convert it automatically. Otherwise, the binding has to assume that temperatures, for example, are in degrees C.

It works the same way for values that are generated by this binding: they all have units of measure attached where appropriate. These values can then be converted to whatever unit you might wish: inches or mm or cm or whatever. It’s all handled automatically for you by the UoM subsystem.

1 Like

so after a while it looks like it’s measuring now in mm as per my item definition. So it either needed OH restart or new recalculation maybe?

I need to verify if it is doing correctly so, I’ll set two items which one of them will be original units and other will be conversioned to mm and will get back to you :wink:

I played around with this a bit over the other day and it does seem that a restart of openhab is required for the UIs to reflect the data. When you’re doing this programmatically in code (say, in a rule or binding), it happens immediately because you’re directly calling the UoM system.

Based on my testing, the values are correct based on the units included in the value returned to the UI and the API.

thank you Bill!
I can confirm it displays correct milimetres vs. original meters after a while from changing it in the files (i assume with next readings) and indeed after OH everything is as well calculated in selected units

1 Like