Looking for a weather station that I can query without a web service / app I came across the Weather station WH2650 from Steinberg Systems:
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:
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:
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
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.
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.
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 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
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âŠ)
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.
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
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:
readout of the battery level 0-5
readout of the signal strength
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
support of all the channels the gateway supports: you can bind some of the sensors multiple times
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:
In the name there is nothing with weather station
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.
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:
The RJ45 model of the ipObserver
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.
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.
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
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 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
I had no joy.