Fine Offset Weather Station Binding: Discussion

1 Like

Hi @Br3Ak3R
i’ve got the same issue with my Waldbeck Huygens weather station.
Did you manage to solve this problem?

I would be grateful for any hint.

Good evening!

An observation that could maybe help others with a similar problem. When I created the items in OH 3.4.0 the rain rate item was created as “Number:VolumetricFlowRate” with unit “l/min”. However it seems that the channel of the weather station thing delivers “mm/h”. For some reason that still worked in OH 3.4.0, but in OH 4.0.1 I got the following error in the log files:

2023-08-06 20:23:54.483 [WARN ] [penhab.core.library.items.NumberItem] - Failed to update item 'Weather_Station_Rain_Rate' because '0 mm/h' could not be converted to the item unit 'l/min'

I then changed the item type to plain “Number” and set the unit meta data to “mm/h”. With that change it works again, no more error in the log files.


You might have to recreate your Thing if created in the UI. After that it should be Number:Speed.

1 Like

Thanks! In my case the channel in the Thing is already “Number:Speed”, but the item was still “Number:VolumetricFlowRate”. Maybe the OH upgrade to 4.0.1 changed the type of the channel and that is what then caused the incompatibility with the previously created item?

If your Thing is file-based, then yes, the item type of the channel was automatically updated.

However, that PR was merged before the update instructions were added for making it possible to migrate channels of managed Things, and I don’t think it was retrofitted:

So if you have managed Things (created from the UI), it shouldn’t have happened automatically. Not because we didn’t want that, but simply because it wasn’t possible at the time. :slight_smile:

Hmmm, my Thing was created via the UI and still was updated somehow. I have never used file-based configuration, everything in my system is created via the UI. :thinking:

is anyone getting correct values ​​from the “rain-hour” channel? I get the constant value “10mm”
I’m using OH3.4.5 and a GW2000. On Ecowitt, I get correct values for hourly rainfall

Just bought a ecowit wittboy, very nice to see that there is a binding and lots of Oh:ers already using it :+1:

I have several soil moisture sensors (ecowitt WH51). Humidity report is ok but low battery is not. Using ecowitt web ui I can see when the battery is low but this info does not flow to openHAB (lowBattery item is always off).

I’ve got the same Problem with GW1100. I had a look into the GW Rain Response and it seems like the Input string is correct

So something strange happens while parsing. Unfortunately I don’t have a debug environment, so someone else needs to look into it. Result:

Hello everyone,
i have been a litte bit lost in all the informations …

I want a weather station with indoor monitor and a compatibility with the binding.
So i’m landing by the ecowitt HP2551 with the ws69 sensor (Amazon).

Is the HP2551 compatible by itself, or do i need a gateway extra to connect with the binding/internet ?
Did anyone knows the sending rate of the values ?
Had anyone an experience with the battery lifetime (monitor/outdoor sensor) ?

thx a lot,

I have the Wittboy with the WH90 sensor.
Everything works nice and it was integrated in OH 4 within a few minutes.
But unfortunately all the piezo-rain-… items are 0,0 … all other values are working fine.
I saw above that this was an issue and has been solved … so am I the only one with this issue? What can I do?
Kind Regards

Hi all, can anyone help me with the WH45 air quality sensor? I have an EcoWitt WittBoy GW2001(gateway GW2000+ 7in1 sensor WS90) and it detects all the various sensors correctly. In OpenHab, however, among the various channels available, I miss all those related to WH45 (I also tried version 4.1 snapshot). Does anyone have any suggestions? Thanks in advance to everyone

Please provide the trace log of the plugin so I can take a look at the issue. Also give me details about the expected but missing values.


The value reported for rain_hour (0x0F, 2 bytes) is hex 0064 = dec 100, wich is converted to 10.0 mm

please also provide trace logs

After enabling logging in TRACE mode for binding I read every 15s:

16:42:43.531 [TRACE] [service.FineOffsetGatewayQueryService] - executeCommand(CMD_READ_RAIN): send request: FFFF57035A
16:42:43.538 [TRACE] [service.FineOffsetGatewayQueryService] - executeCommand(CMD_READ_RAIN): received: FFFF57003B8000008300000001840000010985000005B98600001D1781000C870064006400640064006400640064006400640064880000007A027B019D
16:42:59.625 [TRACE] [service.FineOffsetGatewayQueryService] - executeCommand(CMD_GW1000_LIVEDATA): send request: FFFF27032A
16:42:59.636 [TRACE] [service.FineOffsetGatewayQueryService] - executeCommand(CMD_GW1000_LIVEDATA): received: FFFF2700540100CA063E0826EC0926EC02007A074C0A002F0B001F0C0023150000032016000017001A0086225558005A00620000000661654A5AF1601B1900266300884B7000CE3F001D00240016001E041A037B0695
16:42:59.646 [WARN ] [internal.service.FineOffsetDataParser] - failed to get measurand 0x4b

As mentioned from the three screenshots you can see that the GW2000A Gateway is correctly detected (as well as all the connected sensors) and also the WH45 sensor is detected and is available as a thing. In the channels of the GW2000A, however, none of the measurements of WH45 appear (neither temperature, nor humidity, nor CO2, …).
Let me know if I can be helpful in carrying out other useful tests to solve the problem.
Thank you very much

Thank you for providing the details, I have found the problem:

There was a protocol update 1.6.3 that changed the length of the TF_USRX (soil or water temperature sensor) from 4 bytes to 3 bytes.

In the binding I have implemented the use of 2 bytes, so that is wrong anyway. This also explains why the binding does not read the WH45 data, because the reading stops after the wrong value (the warning message you see in the logs).

So now I need your help: can you please tell me the values that the WS-View Plus app is showing at a certain point of time and provide the corresponding trace log, so I can try to interpret everything correctly?

I found the rule how to interpret this value:

  • the 1st 2 bytes is the temperature (value * 0.1 °C)
  • the 3rd byte is the battery voltage (value * 0.02 V)