Fine Offset Weather Station Binding: Discussion

Hello Community,

Looking for a weather station that I can query without a web service / app I came across the Weather station WH2650 from Steinberg Systems:

WH2650

My purchase decision was driven primarily by this blog post.

However, after installing the product, I could not access a URL on the gateway to read the weather data as described in the blog post.

With some research I found out that this product is produced by the company Fine Offeset from China as a whitelabel solution and is sold under different names worldwide.
After I found the data exchange protocol on one of the resellers pages, I created a binding which is directly able to query the gateway and provide its data in OpenHAB.

UPDATE 29.08.2022:

If you come across this thread for information to help you make a weather station purchase decision, here’s some insight:

Some weather stations (e.g. with displays) have a customized firmware which cannot be read with this binding, here you need to use the IPObserver binding as an alternative.
Since a specific command must be supported to read additional sensor data, I assume that all weather stations that support such sensors should be compatible with this binding.
Such additional sensors are e.g.:

  • WH34 - External temperature sensor
  • WH35 - Leaf wetness sensor
  • WH40 - Rainfall sensor
  • WH41 - Outdoor air quality sensor
  • WH45 - Air quality sensor
  • WH51 - Soil moisture sensor
  • WH55 - Water leak detection sensor
  • WH57 - Lightning detection sensor

Another indication that the weather station could be compatible with this binding is the aspect that the weather station can be used with the WSView app or the WSView Plus app.

Known weather stations not compatible with this binding:

UPDATE 22.12.2022:

If your gateway does not support reading out live-data, a second gateway can be used to read out the sensors for openHAB.
This approach has been tested by a community member.

1 Like

As long the PR is not merged, you can access the binding via the marketplace

1 Like

That is some serious FineOffset black magic @Andy2003 ! I didn’t even know you could poll the GW on port 45000 but I guess that is what the app does.

Tried the jar against my GW1000 + weatherstation, three soil sensors and an air quality sensor and:

  1. Auto Discovery is great, however I am getting the following error (and hence missing channels) for my Air Quality sensor (WH41)
2022-03-13 15:48:04.154 [WARN ] [nal.handler.FineOffsetGatewayHandler] - cannot create channel for PM2.5 Air Quality Sensor Channel 1
2022-03-13 15:48:04.154 [WARN ] [nal.handler.FineOffsetGatewayHandler] - cannot create channel for Air Quality Channel 1
  1. I see each sensor also becomes a Thing in the inbox and is the equivalent of the sensors page in the app in that is shows signal and battery for that sensor, however when I add them, they stay as Offline and do not update. In the trace I see entries for all channels I am not using as registering (WH51_CH4/5/6/7/8) and the odd disabled but none of the ones I am expecting appear in that trace. (i.e WH51_CH1 / 2 / 3 my 3 soil sensors)

I am running the jar against Openhab 3.1, not sure this should make too much of a difference.

  1. Auto Discovery is great, however I am getting the following error (and hence missing channels) for my Air Quality sensor (WH41)
2022-03-13 15:48:04.154 [WARN ] [nal.handler.FineOffsetGatewayHandler] - cannot create channel for PM2.5 Air Quality Sensor Channel 1
2022-03-13 15:48:04.154 [WARN ] [nal.handler.FineOffsetGatewayHandler] - cannot create channel for Air Quality Channel 1

That is great! I was not able parse these sensors the right way, so I could not setup the channel type correctly. So this is somehow an expected behavior.

@NicGray Can you do me a favor and provide me with the complete trace log, especially the one from the executeCommand.

Additionally give me a screenshot of your WS View-App so I see how the data correlates to the one displayed in the App.

  1. I see each sensor also becomes a Thing in the inbox and is the equivalent of the sensors page in the app in that is shows signal and battery for that sensor, however when I add them, they stay as Offline and do not update. In the trace I see entries for all channels I am not using as registering (WH51_CH4/5/6/7/8) and the odd disabled but none of the ones I am expecting appear in that trace. (i.e WH51_CH1 / 2 / 3 my 3 soil sensors)

Hopefully I can fix this as well with the trace data that you provide!

I just tried to run the add-on with the 3.1 and it worked without any problems with my setup.

I had to blow some dust about to give you some juicy figures
 also I think the AQI values in the WS View might be derived off the pm2.5 values that the sensor sends but am not sure


2022-03-13 19:20:59.823 [TRACE] [ervice.FineOfssetGatewayQueryService] - executeCommand(CMD_GW1000_LIVEDATA): received: FFFF27004C0100F106440827EE0927EE0200D707540A00000B00000C0000150000000016000217002A00F04D00092C242E35302919000A0E000010000A11000A12000015621300002B4D0D00078D
2022-03-13 19:20:59.824 [WARN ] [nal.handler.FineOffsetGatewayHandler] - cannot create channel for PM2.5 Air Quality Sensor Channel 1
2022-03-13 19:20:59.825 [WARN ] [nal.handler.FineOffsetGatewayHandler] - cannot create channel for Air Quality Channel 1

2022-03-13 19:21:29.833 [TRACE] [ervice.FineOfssetGatewayQueryService] - executeCommand(CMD_GW1000_LIVEDATA): received: FFFF27004C0100F106440827EE0927EE0200D707540A01570B00010C0005150000000016000217002A04384D000E2C242E35302919000A0E000010000A11000A12000015621300002B4D0D00073C
2022-03-13 19:21:29.835 [WARN ] [nal.handler.FineOffsetGatewayHandler] - cannot create channel for PM2.5 Air Quality Sensor Channel 1
2022-03-13 19:21:29.835 [WARN ] [nal.handler.FineOffsetGatewayHandler] - cannot create channel for Air Quality Channel 1


and here is the trace data from the sensors

2022-03-13 19:39:17.628 [TRACE] [ervice.FineOfssetGatewayQueryService] - executeCommand(CMD_READ_SENSOR_ID_NEW): received: FFFF3C014D00000000CD000401FFFFFFFFFF0002FFFFFFFFFF000
3FFFFFFFF1F0005FFFFFFFF000006FFFFFFFF000007FFFFFFFF000008FFFFFFFF000009FFFFFFFF00000AFFFFFFFF00000BFFFFFFFF00000CFFFFFFFF00000DFFFFFFFF00000E000111D60D040F000112080D0410000111C
50D0411FFFFFFFF1F0012FFFFFFFF1F0013FFFFFFFF1F0014FFFFFFFF1F0015FFFFFFFF1F00160000C4E7060417FFFFFFFE0F0018FFFFFFFE0F0019FFFFFFFE0F001AFFFFFFFF0F001BFFFFFFFF0F001CFFFFFFFF0F001DF
FFFFFFF0F001EFFFFFFFF0F001FFFFFFFFFFF0020FFFFFFFFFF0021FFFFFFFFFF0022FFFFFFFFFF0023FFFFFFFFFF0024FFFFFFFFFF0025FFFFFFFFFF0026FFFFFFFFFF0027FFFFFFFF0F0028FFFFFFFFFF0029FFFFFFFFF
F002AFFFFFFFFFF002BFFFFFFFFFF002CFFFFFFFFFF002DFFFFFFFFFF002EFFFFFFFFFF002FFFFFFFFFFF0005
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - executeCommand(CMD_READ_SSSS): received: FFFF300B0001622E486427009F
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH68 = registering
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH80 = registering
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH40 = registering
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH26 = registering
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH31_CH1 = registering
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH31_CH2 = registering
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH31_CH3 = registering
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH31_CH4 = registering
2022-03-13 19:39:17.637 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH31_CH5 = registering
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH31_CH6 = registering
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH31_CH7 = registering
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH31_CH8 = registering
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH51_CH4 = registering
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH51_CH5 = registering
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH51_CH6 = registering
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH51_CH7 = registering
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH51_CH8 = registering
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH41_CH2 = disabled
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH41_CH3 = disabled
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH41_CH4 = disabled
2022-03-13 19:39:17.638 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH57 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH55_CH1 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH55_CH2 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH55_CH3 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH55_CH4 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH34_CH1 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH34_CH2 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH34_CH3 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH34_CH4 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH34_CH5 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH34_CH6 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH34_CH7 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH34_CH8 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH45 = registering
2022-03-13 19:39:17.639 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH35_CH1 = registering
2022-03-13 19:39:17.640 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH35_CH2 = registering
2022-03-13 19:39:17.640 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH35_CH3 = registering
2022-03-13 19:39:17.640 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH35_CH4 = registering
2022-03-13 19:39:17.640 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH35_CH5 = registering
2022-03-13 19:39:17.640 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH35_CH6 = registering
2022-03-13 19:39:17.640 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH35_CH7 = registering
2022-03-13 19:39:17.640 [TRACE] [ervice.FineOfssetGatewayQueryService] - sensor WH35_CH8 = registering

@NicGray I fixed all your issues, please test the latest build.
You need to remove all sensors and let them be rediscovered by the plugin.

Looks good! The only feedback I would have is that I believe the Signal Strength is sent as an integer 0-4 which matches the 4 bars you see in the app, but I get the value as “excellent” which sort of makes it hard to run a rule on as I don’t know what the lower values are (I can assume
)

Such a binding already exists. See here

IpObserver - Bindings | openHAB

In the photo you posted, that box is an ip observer unit and the binding has two methods to fetch the data:

  1. Via scraping the livedata webpage.
  2. Via capturing the data sent to weather underground.

The signal strength is set as a number between 0-4. It is only the UI that displays the number as text. This comes from the correct tagging of the channel.

I looked at the IpObserver add-on, however it did not work for my configuration.

  1. my gateway has no livedata webpage that I can scrap. I think this is b/c of the current firmware version of the gateway 1.6.8
  2. capturing the data sent to weather underground is no option since I want to use offline mode. This means that all outgoing traffic from the gateway is blocked by a firewall. So no communication from the gateway to OpenHAB should be possible, only vice versa.

The implementation of my plugin also has the following advantages over the IpObserver:

  1. readout of the battery level 0-5
  2. readout of the signal strength
  3. support of many additional sensors, e.g.
    • WH35 Leaf wetness sensor
    • WH40 Rainfall sensor
    • WH41 Outdoor air quality sensor
    • WH45 Air quality sensor
    • WH51 Soil moisture sensor
    • WH55 Water leak detection sensor
    • WH57 Lightning detection sensor
  4. support of all the channels the gateway supports: you can bind some of the sensors multiple times
  5. Discovery via broadcast and not via a full network scan as it’s done in the IpObserver add-on

In general, the approach taken by this plugin is much more robust, since here the gateway’s protocol is interpreted correctly. No scraping of a web page is required, whose format may change due to firmware updates.

You mis understand how it works. It works fully 100% offline, local and at 15 seconds between packets that get pushed to the binding. I run mine fully blocked by firewall with that method it works great and it also supports the soil moisture sensors as I have a user that is requesting I add the channels at the moment.

If you have found another way that is great news and I will have to check out the PR when I have some spare time.

Yes, I agree that I didn’t directly recognize the part about the self-hosted “weather underground” server.
However, I also had problems identifying the “IpObserver” add-on as the correct plugin for my weather station. This is due to the following reasons:

  1. In the name there is nothing with weather station
  2. Due to the distribution strategy of “Fine Offset” every reseller can name his products as he likes. As a result, one company has named its gateway “IP observer”, but there are countless other names for the same product. In my case WH2650.
  3. The lack of product images has made it even more difficult to identify the add-on as the right one

Nevertheless, I have now written the plugin and am making it available to the community. I think by directly using the data exchange protocol I can get more data points than with the “IpObserver” add-on.

I agree with you on most of what you have written and wish to say thanks for your contribution and the binding clearly has a lot of hard work in it from what I have seen so far.

I had similar thoughts and the reason I did not go with the name Fine Offset for the binding name was that at the time it was written, the binding did not work with all weather stations made by Fine Offset and the majority of the different brands had thankfully kept the name Ip Observer on all the units and manuals referred to them as this.

I’m interested to know if this one works with:

  1. The RJ45 model of the ipObserver
  2. The wifi screens that come with WH2900 and various other looking screens which probably are all the same internally and just a cosmetic change.

Agree, however since we do not own the copyright for the images we need to obtain permission from the copyright holders to use them on the website. Have you done this? The pictures wont get approved unless we have permission.

Thank you for the contribution and your probably right as it looks to be a good way to do it. I like that the discovery is not doing a dumb scan of all IP.

Here I can only guess, since I do not own these devices. But I would be very surprised if these devices used a different protocol. Everything that is compatible with the “WS View” app should also be usable with this binding.

Good point, I removed all the images I had downloaded and replaced them with an image where I am the copyright holder. I also removed the protocol definition (PDF) and used a direct link instead.

I found also a nice overview of the different brands selling Fine Offset devices: MUST READ - Fine Offset Clone Models,sensor compatibility,firmware + other info

Oooh, nice. I have the Froggit WH2600 Pro which should be identical to this. Will try it out sometime during the weekend. I am currently using an ESP8266 as a server to which the station pushes the data (can be configured in the app) and that then forwards everything to OH. Which works just fine for me. But if I can get rid of the extra server even better.

Hi Andy,

Thank you very much for that!
I have the Froggit WH2600 Pro Wifi station with an extra WH45 sensor. Currently I am using an external script to collect the data and transmitting it to openhab via MQTT. This works flawless.

However, when I saw your post I decided to try your binding. Unfortunately after setting up the bridge, I only get this in the log every time the station is queried (switched to TRACE):

2022-03-15 19:07:57.548 [TRACE] [ervice.FineOffsetGatewayQueryService] - executeCommand(CMD_GW1000_LIVEDATA): received: FFFF2700510100DA06270827E90927E902005E07460A001D0B00000C0000150000000016000217001900140E0000100000110021120000002113000005850D00007000D52C00210057001F00520214021406C6
2022-03-15 19:07:57.550 [WARN ] [ervice.FineOffsetGatewayQueryService] - failed to get measurand 0x70

Im am currently running openHAB 3.3.0.M2

Any idea what might be wrong?

Thanks & regards,
Matt

I’m interested to know if this one works with:
The RJ45 model of the ipObserver

I gave this a try last night - I have an “Aercus Weather Sleuth” which has an Ethernet (wired) base station. Unfortunately it does not appear to have the same command port as the WiFi modules listed above (on TCP45000), but also tried a few others listed in the doco/other places (TCP46000, 49123, 5000,2999) with no joy either. I did try a nmap port scan to see if I could pick up any other open ports, but other than bringing the poor base station to its knees and locking it up :slight_smile: I had no joy.

Be interested to know if anyone else manages to get a Ethernet based ‘Fine Offset’ working, and what port they use, but for now, I will continue to use the “IP Observer” binding, which has been rock-solid to date, after I changed from ‘Screen Scrape’ mode to using the ‘Server’ mode.

I was keen to help test this new binding, to see if it overcame a limitation of the Protocol (not the IP Observer binding itself) where a number of items are not reported via the ‘Wunderground’ protocol, such as battery level, however I guess if this command port doesn’t exist, no amount of hacking will sort the issue :slight_smile:

Cheers