Fine Offset Weather Station Binding: Discussion

[sihui]

@miwok

WS90

Fine Offset Weather Station Binding: Discussion

With the knowledge I have today, I would decide to buy the WS90 and then choose a suitable gateway + display according to the compatibility matrix. And then look for a cheap bundle. Especially when it comes to controlling devices based on weather conditions, the advantage here is that it can detect even the smallest amounts of rain.

@miwok

GW2000

Fine Offset Weather Station Binding: Discussion

Thanks Andreas, Teaching an old dog new tricks is hard. I rebuilt my test Pi again just to be sure it was not me. Compiled the new java. It connected as expected and provided a second Device on my iPhone device list -proxy. I can’t select it to get to the next screen. The direct one works but I ca’t get the Proxy to show data. This is the proxy output: bill@Discovery:~ $ java Proxy Try to discover on /192.168.0.255:46000 Found device ‘GW2000C-WIFIB04B V2.1.7’ at 192.168.0.80:45000 via…

Fine Offset Weather Station Binding: Discussion

Hi Andreas, Woo Hoo it all works. Thank you so much. I don’t know how you can do this long distance but I really appreciate your skills. Regards Bill

[spuerlue]

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.

[the-ninth (Robert)]

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.

[laursen (Jacob Laursen)]

See:

[fineoffsetweatherstation] Fix QuantityType for rain-rate

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

[the-ninth (Robert)]

@laursen

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

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?

[laursen (Jacob Laursen)]

@the-ninth

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:

Checking if upgrade instructions were provided for all OH 4 PRs

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.

[the-ninth (Robert)]

@laursen

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.

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.

[neuling10]

Hi,
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

[Seaside]

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

[moody_blue (Hugo)]

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).

[JankKeks]

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

@executeCommand(CMD_READ_RAIN): received

FFFF5700290E000010000000001100000000120000000013000000000D00000F0064880001007A017B00D3

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

21:57:01.248 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item ‘Wetterstation_Ecowitt_Niederschlagsmenge_aktuelle_Stunde’ updated to 10 mm

[Stephan-Prem]

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,
Stephan

[sticki (Jörg)]

Hello,
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
Jörg

[saxxing]

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

[Andy2003 (Andreas Berger)]

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.

[Andy2003 (Andreas Berger)]

FFFF5700290E000010000000001100000000120000000013000000000D00000F0064880001007A017B00D3

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

[Andy2003 (Andreas Berger)]

please also provide trace logs

[saxxing]

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

[Andy2003 (Andreas Berger)]

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?

[Andy2003 (Andreas Berger)]

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)