[New Binding] Ambient Weather WS-1400IP weather station

I think you might need to add more information, like what version you are on and an extract from your openhab.log

1 Like

That happens when there is an issue with the jar. Re download it and unzip it to the addons folder. Perhaps antivirus has changed the file so keep an eye open for messages when you download and open the zip. Another thing to try would be to clean the cache or rename the jar file to force the framework to look at the newly downloaded copy as slightly different. I see it happen when doing testing probably 1in 300 times I change a jar.

1 Like

Thanks for that hint. Seems I was the lucky one out of 300.

For the records, I use OpenHAB 3.2.0M2 installed via apt on Armbian 21.02.1 Buster on a NanoPI Neo.
The logs did not reveal any additional information except for that Handler missing error - not even when switched to trace (which I may have done incorrectly though). And the docs just state “The handler cannot be initialized because the responsible binding is not available or started.”.

Now I have the effect, that only some channels work, all others are shown as NULL. However, those values shown seem to be correct. From the logs I see that the values are received correctly. I had the items created automatically by ticking them in the semantic model UI.


18:39:47.112 [TRACE] [ipobserver.internal.IpObserverHandler] - Update received:tempf=61.0&humidity=96&dewptf=59.9&windchillf=61.0&winddir=331&windspeedmph=0.67&windgustmph=1.12&rainin=0.000&dailyrainin=0.130&weeklyrainin=0.130&monthlyrainin=0.142&yearlyrainin=30.350&solarradiation=0.00&UV=0&indoortempf=71.1&indoorhumidity=73&baromin=30.035&lowbatt=0&dateutc=now&softwaretype=WH2650A_V1.6.8&action=updateraw&realtime=1&rtfreq=5
18:39:47.134 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element tempf, value is 61.0
18:39:47.153 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'WeatherStation_LastUpdatedTime' changed from 2021-09-15T18:39:26.122618+0000 to 2021-09-15T18:39:47.125811+0000
18:39:47.176 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element UV, value is 0
18:39:47.189 [TRACE] [ipobserver.internal.IpObserverHandler] - UNKNOWN element rtfreq, value is 5
18:39:47.200 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element windspeedmph, value is 0.67
18:39:47.212 [TRACE] [ipobserver.internal.IpObserverHandler] - UNKNOWN element realtime, value is 1
18:39:47.224 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'WeatherStation_OutdoorTemperature' changed from 16.22222222222222 °C to 16.11111111111111 °C
18:39:47.227 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element yearlyrainin, value is 30.350
18:39:47.241 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element dewptf, value is 59.9
18:39:47.257 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element indoorhumidity, value is 73
18:39:47.264 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element rainin, value is 0.000
18:39:47.271 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element windchillf, value is 61.0
18:39:47.282 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element winddir, value is 331
18:39:47.289 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element monthlyrainin, value is 0.142
18:39:47.296 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element dailyrainin, value is 0.130
18:39:47.303 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element windgustmph, value is 1.12
18:39:47.311 [TRACE] [ipobserver.internal.IpObserverHandler] - UNKNOWN element dateutc, value is now
18:39:47.318 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element solarradiation, value is 0.00
18:39:47.325 [TRACE] [ipobserver.internal.IpObserverHandler] - UNKNOWN element softwaretype, value is WH2650A_V1.6.8
18:39:47.333 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element baromin, value is 30.035
18:39:47.340 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element lowbatt, value is 0
18:39:47.347 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element indoortempf, value is 71.1
18:39:47.354 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element humidity, value is 96
18:39:47.361 [TRACE] [ipobserver.internal.IpObserverHandler] - UNKNOWN element action, value is updateraw
18:39:47.368 [TRACE] [ipobserver.internal.IpObserverHandler] - Found element weeklyrainin, value is 0.130

Image of the items created automatically:
… can’t add it here, new members can only add one media item per post…

Image of two of the items created automatically:

Just give it some time as it won’t update the channels unless the value has actually changed. The issue is the channels were not linked when the value first came through. No rain means it won’t update till there is, I will look into this but nothing to worry about for now just be patient and all will work.

Thank you @matt1 . Out of curiosity: Is that a general OH conceptional issue or specific for this binding? I am thinking of things now, which almost never change their state like “Battery low”, which probably won’t change until the batteries become empty.

Just this binding and I consider it a bug on the to fix list. If you reboot or pause and unpause the thing it will probably work. I suspect it is just when you add a new thing and all the channels are unlinked when the first packet is processed.

1 Like

I can confirm that most items have updated their state now. Thank you @matt1 for providing this binding!

Hi Matt - Thanks for this new version of the binding, and I can happily report that it works well with the Aercus WeatherSleuth. From what I can see, everything matches up OK with the LiveData page on the IP Observer itself.
If I understand the above discussions correctly , it is configured to receive updates from the IP observer, not ‘scrape’ the data. Just in case, thing config is:

UID: ipobserver:weatherstation:3ead6a4dc7
label: Weather Station
thingTypeUID: ipobserver:weatherstation
  pollTime: 20
  password: *****
  address: *****
  id: *****
  autoReboot: 5000

The only thing that I am seeing, is that the date/time is incorrect on the IP Observer live status page (some time in the year 2105 !!), and the Rain Totals seem to ‘rollover’ at weird times (e.g. ‘today’s rain’ may reset mid-afternoon). This is not specific to the data in OpenHAB, but also in the live view.

I have had a look for NTP packets etc, and if “Fine Offset” did ever get around to supporting NTP, my Aercus unit certainly isn’t requesting NTP sync’s. (Firmware version 2.2.8).

Where the binding comes into play, is that according to the following post (Different brand, but same engine under the hood) Ambient ObserverIP list of bugs/known issues (Reply #4), it seems that the unit time is set via a timestamp in the response from Wunderground server.

Given I have the OpenHAB binding set to emulate the Wunderground server, is the binding currently developed to return this timestamp, and if not, it is possible for the binding to return this in future? If the latter, I’m happy to raise a specific issue, and try provide any other details I can help with, along with testing. I will take a random guess that this timestamp is UTC, as the offset is configured on the IP observer.


Yes that may be possible in the future, but currently the changes are not merged into the main project as there is a whole new binding possibly coming that may make this one obsolete. For now either connect it to the real WU site to set your clock and then disconnect it, or perhaps you can give it the wrong timezone to trick it. Maybe update firmware.

You can always turn on the debug logs if you want to know if it is scraping or getting updated pushed.

Hi Matt - Cheers for the reply. Before I posted the above, I had already upgraded the Weather Station to the latest Firmware that Aercus have available (2.2.8)… However your suggestion re the temporary change for the suggestion to set the weather station to update wundergound was a good work around…

What I have found through some experimentation with that approach is:

  • The time did update as expected from Wunderground, and then I could set it back to update the binding
  • Contrary to my expectations, the unit does appear to have a RTC in it, so the work-around is persistent across reboot’s/power cycles (The posts on the WX forums were predominantly for older units, which I guess didn’t have RTC’s in them)
  • What the root cause for original my issue probably was, was the actual upgrade of the firmware a few weeks ago, which I now believe ‘bricked’ the RTC value, waiting for it to be set from the first wunderground ‘reply timestamp’

So it’s all good, and I guess the only benefit for updating the binding (aside to avoid the above workaround, which is not really that big deal) would be to maintain time synchronisation if the RTC drifts over the longer term. So I agree, its probably not worth considering if there is a new binding around the corner.

Thanks again for your help.

hi Skinah!
Has something changed with the units?
it’s raining here and i was wondering why openHAB tells me it was 0.01 mm but that can’t be true…
so i connected to the WS with “WS View” where it says 6.6 mm for today.
i took a look in the logs where i got this:

2021-11-13 23:13:47.562 [TRACE] [pobserver.internal.IpObserverHandler] - Found element dailyrainin, value is 0.260

as far as i understand 0.260 is inch/h

but the binding (?) shows me m/h instead of mm/h:

2021-11-13 23:12:14.793 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WS_RainToday' changed from 0.0064008 m to 0.006604 m

should i transform m > mm or is there something i am missing?
has this always been this way?

Not sure if you have changed something but I do set my units in my items file…

Number:Length Ecowitt_Rain_Today "Rain Today [%.1f mm]" (gPersist4) { channel = "ipobserver:weatherstation:e1803acdd2:rainToday" }

Sorry only just saw your post, if you have worked it out already please post the solution. But in reply…
It should be automatic as the binding has UOM support. It should read what the units are set to and then adjusts internally automatically for you. You can get it to display in any unit you wish via metadata in the UI or in textual files as @NicGray posted an example (thanks).

Check if you have openHAB set to SETTINGS>REGIONAL SETTINGS> tick SHOW ADVANCED and check the box for metric. Also go into the settings for the ipobserver and set it to also show metric…
If you are using the PUSH method of the binding by giving an id and password then the data always comes into the binding via imperial values, if you are using the SCRAPING method then its possible your settings page is not getting scraped correctly when the binding first starts.

@matt1 can you shed light on your comment about creating a whole new binding? I am currently using Home Assistant (Ecowitt Integration) to pull all the values and send them to openhab via mqtt. The main reason for this is that I need the soil and pm2.5 sensor values which the ipObserver does not currently decode.

It may help to quote my post, but I will guess your wanting to know about this binding which is under the review process here and a JAR file is linked in the first post if you wish to try it out. The readme.md file is the documentation and should answer your questions if it has the channels your after…

[wundergroundupdatereceiver] Initial contribution by danieldemus · Pull Request #10105 · openhab/openhab-addons (github.com)

I just submitted earlier today, my own PR for the changes to the ipobserver binding to support the push method, if it is accepted then I would be happy to add new channels. It may be deemed that the changes should not be merged due to the above binding being the preferred way forward, then I do not want to waste time coding anything further until that is decided.

If you do try the above binding, it would be great to hear if both bindings can run at the same time or if they conflict. Worse case you would just need to press the pause button on the ipobserver things to stop them listening on the port 8080 server whilst you try out the new binding. They may both work at the same time, I have not tried it but they both work the same way and you wont need to change the settings in the weather stations controls/app.

I would not be surprised if the jar gets you going already and you can stop the Home Assistant to MQTT method your doing now.

So my issue with the Weather Underground Receiver is that it looks like it only handles a single Soil Moisture channel. Ecowitt (FineOffset) allows multiple sensors to be added and I use 6 Soil Sensors to help make my Irrigation system smarter. Selfishly I just want a FineOffset / Ecowitt binding but obviously that’s a bit of work for you that you may not want to maintain. Also not sure how much demand there is for it.

With regards to both bindings running at the same time, can you not run both Things just on different ports?

Wait for it to be merged and then make a request or bounty to have the extra channels added. I have never tried it so I do not know the in depth details on it so best you give it a try as it is possible for some bindings to offer the same channels multiple times. The system info binding is one, you can have multiple disk stats that change depending on how many disks your server has installed. Extra CPU graphs depending on how many cpu cores etc…

Correct too much work, its better to have a generic capture all binding and since multiple weather stations send the weather underground standard packets, then it makes sense to create one binding that talks this protocol.

I feel that would not get approved, best to keep using the same server on the default port and keep things simple and easy to maintain. There are other ways that could be considered, but does it not work? Have you tried it? lets not talk about something which may work fine and there is no issue.

What weather station model and soil sensors do you have? How long do the batteries last for? I may be interested in adding some to my setup if they work and are cheap.

Sorry, I was getting mixed up with the Home Assistant Integration which allows you to specify which port to listen on.

I have the Ecowitt GW1101 (ECOWITT Welcome to Ecowitt!) which is an outdoor unit, and the indoor “ipobserver” unit it connects to that can upload the stats. I then use the WH51 soil sensors which go about a year on a rechargeable AA battery. Not sure where you live but frequency must match and they sell out of Amazon here in Australia. Paid $15 for each Soil Sensor.

I have used your binding previously and it does bring in the values just not coded to pass them on.

2021-12-22 20:08:17.093 [TRACE] [pobserver.internal.IpObserverHandler] - Update received:tempf=75.0&humidity=78&dewptf=67.8&windchillf=75.0&winddir=178&windspeedmph=0.00&windgustmph=0.00&rainin=0.000&dailyrainin=0.000&weeklyrainin=0.228&monthlyrainin=1.866&yearlyrainin=22.516&solarradiation=0.00&UV=0&indoortempf=78.4&indoorhumidity=68&baromin=29.881&AqPM2.5=2.0&soilmoisture2=25&soilmoisture3=89&lowbatt=0&dateutc=now&softwaretype=GW1000_V1.6.8&action=updateraw&realtime=1&rtfreq=5
2021-12-22 20:08:17.095 [TRACE] [pobserver.internal.IpObserverHandler] - UNKNOWN element soilmoisture3, value is 89
2021-12-22 20:08:17.095 [TRACE] [pobserver.internal.IpObserverHandler] - UNKNOWN element soilmoisture2, value is 25

I’ll wait to see what the outcome of the 2 binding is, but having Home Assistant publish all sensors into MQTT isn’t a bad way to hedge your bets that someone has made a binding for a piece of tech you own.

ooohhh. i missed your response o_O
i have configured all the items via mainUI (as i didn’t know how to do it correcty via config files. is there a wiki?)

i’m not using most of the “new” openHAB3 stuff and haven’t really used metadata until now so i’m not sure how i should use metadata. :neutral_face:

okay, checked metric now. (“m” = meters should be metric already)?

it’s metric already (although i cant find any settings on the device to change anything…):

i have set id and password, so i guess i use the PUSH method?

i’m still on openHAB 3.1 and have manually installed org.openhab.binding.ipobserver-3.2.0-SNAPSHOT.jar, should i remove the binding before upgrading openHAB and then install via openHAB UI?