Hi there, I have an Ecowitt rain sensor WH40 connected to GW1000.
But the channel for Rain-total does not show up
I used to use the HTTP listener binding - where this was available, and in fact it is the only value I use for the device, as i don’t like the weekly and monthly totals, and prefer a rolling last 7 days and last 30 day value, that I calculate from the value stored in persistence DB.
Another quirk, is that when it polls the gateway, there seems to be a limit on number of sensors, and then next poll gets the rest, and the available channels will flip with each poll - like below - although this doesn’t seem to cause any issues with operation.
The channel rain-total is missing - I am running 3.4 M6 - does anybody know if it should be there?
To be clear, the page updates like below, without any input from me - I set the poll to 5 seconds to capture
Sometimes there are problems when multiple clients are connected to the gateway. Is it possible that other apps are querying the data? Please provide the trace logs of the binding, so I can help you further.
So I started again, and removed Gateway, and also an entry in another app. When I added it to OpenHAB again, the appearing and disappearing channels were resolved.
However the Rain-Total that I am looking for is still not there.
And the CMD_READ_RAINDATA return structure, makes it quite clear, that it doesn’t send the RainTotal out.
Out of interest why is CMD_READ_RAINDATA using 0x57 in my log, rather than the defined 0x34?
So I think i will maintain my own lifetime rain total - it looked to be of length 4 so the same range as Year, is only 9.9m, and we had locally a record 2.5m in the last year.
Thanks not only for your original contribution, but also continued support in this forum, which in itself becomes a repository of info helpful to others.
Using an Ambient IPObserver WH2682B (running v2.0.4) as a gateway.
Pressure is shown correctly as
But on my items it’s not scaled correctly.
Is there a simple method to scale this value?
Feel free to mention me if you need a comment on the ipObserver binding. That binding is best left to talking to the ipObserver units which is why it was named that way. There are two versions of it, a hardwired network rj45 version and a newer wifi version. These to my knowledge do not support the ecowitt protocol, or at the least the rj45 does not support it. There is no value in adding functionality that already exists in the Fine Offset binding to another binding, that only places strain on volunteers that could better use the time writting whole new bindings that do different tasks.
The GW1100 and ipobserver boxes can both be purchased separately for around USD$30 - 50. Since the RF link to the outdoor units is 1 way with no security, you can use as many of them at the same time, including the other screens and wifi gateways. You could use the ipObserver, Fine offset and also the weatherundergroundupdatereciever bindings for 3 different ways to get your weather station data all at the same time locally without a cloud or internet connection, not that you would, but choice is good to have.
If buying again, I would probably look into this binding because I value the soil sensors that the ecowitt system allows that does not work with the older ipObserver units. I do not know of another way to get soil sensors that work in openHAB for the same price. To use them you would need to use the GW1100 and this binding.
Thanks for that! Now that I know how it will work, I’m actually very happy with the prospect of having both the GW1100 and the LCD display - it’s a really nice live display to have in the living room, and the GW1100 + FineOffset binding will do everything I want in terms of openHAB integration. Knowing what I know now, the only thing I would do differently would be to order the GW1100 as well as the LCD display in my initial order, rather than paying a separate shipping fee. It would be nice if the LCD display could speak the same language as the GW1100 to save the need for the extra piece of hardware, but that’s a very minor complaint.
The new GW1100 is in place, and it’s brilliant! Everything (or almost everything) is now working through the FineOffset binding. I’ve noticed a couple of things which I think might (?) be issues with the FineOffset binding, but none of these are deal-breakers, and all are at least as good as what I was getting with the ipObserver, as well as allowing me to access things like lightning which I couldn’t get through that binding.
Here are the issues I’ve observed since hooking up the GW1100 and migrating everything over to the FineOffset binding:
rain-rate is defined in the Binding guide as Number:VolumetricFlowRate, however I don’t believe that’s correct. I don’t think openHAB actually includes a Number form which matches rain rate measurement, because that should be in length per unit of time (e.g. mm/hr): that isn’t the same as volume per unit of time (e.g. l/hr) which is what volumetric flow rate is, but since it’s always “per hour”, I think the choice made by ipObserver to define rain rate as Number:Length is correct. I’ve typed my linked item as Number, and that is giving me mm/hr (which is what I want), but that is not a QuantityType and wouldn’t handle a change in units being reported.
A few parameters are displayed in WSView Plus and on the webpage when I access the GW1100 directly, but are not showing up as channels in the FineOffset weather station thing:
Feels Like/Heat Index
Wind chill
Outdoor dew point
According to the binding documentation, these channels should be supported, but they aren’t appearing. Any suggestions as to how to get them to show up?
Thanks again for this excellent binding - I’m so excited to have top quality weather data being fed in real-time into openHAB.
Since 1 mm / m² is equal to 1L, the chosen quantity type is correct. In the end, it is a volume per time. The unit for Number:Length (e.g. mm) would not represent the rain rate correctly.
This issue was already discussed in:
See also:
If your gateway is not reporting the values, the binding cannot show them.
Thanks for that! My trace output is as follows - it seems different from the trace output in that other thread, but I suspect you’re right about it being calculated in the web interface but not reported in the data stream:
I’ve already got it calculating an approximated dewpoint using the approximated (simpler) formula on How do I calculate dew point? … but if I’m going to be keeping on using a calculation, I should probably do it with a more complete formula.
I disagree with you that the rate of rainfall is correctly represented as volume per time, but I suppose it is equally wrong as length (without a per-time component integrated) - L/hr (instead of mm/hr) includes an incorrect multiplier of 1 m², whereas mm includes an incorrect multiplier of 1 hr - it’s just a question of which incorrect dimension we choose to multiply the correct units by. Unless/until openHAB expands the number category to include a rate-of-precipitation option (mm/hr or in/hr), the dimensionless approach will do the job, and is no less correct than any of the other options (either the Length approach used by ipObserver, or the VolumetricFlow used by FO).
Thank you again for the amazing work on this binding - I’m off to code up an accurate dewpoint calculation!
If anyone needs it, this rule appears to be an accurate one for converting temp (°C) and RH to dewpoint:
rule "calculate outside dewpoint"
when
Item Outside_Temperature changed or
Item Outside_Humidity changed
then
val a = 17.625
val b = 243.04
val rh = 1.0*(Outside_Humidity.state as Number)
val tempC = (Outside_Temperature.state as QuantityType<Number>).toBigDecimal
val alphaTRH = Math::log(rh/100) + (a * tempC)/(b + tempC)
val dewpoint = (b * alphaTRH) / (a - alphaTRH)
Outside_Dewpoint.postUpdate(dewpoint)
end
@Andy2003
I have my Pressure Items configured similar to yours, but I’m still trying to understand why the pressure is displayed x10.
Many raw values from the gateway are multiplied by 10 and the binding must be scaling and adding units.
For instance, temperature is received as 230 and changed by the binding to 23.0 °C
So shouldn’t the binding also be dividing the pressure value by 10? Or do I just need to add a transformation to the Item?
Here is the log of CM_GW1000_LIVEDATA with the following Openhab events
16:32:01.423 [TRACE] [service.FineOffsetGatewayQueryService] - executeCommand(CMD_GW1000_LIVEDATA): received: FFFF2700450100D5062808272D0927B902003E07620A00320B000E0C001415000005D216000117001A008D223C1900610E0000100045110045120000025313000002530D004546
16:32:01.472 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WeatherStation_RelativePressure' changed from 10172 hPa to 10169 hPa
16:32:01.474 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WeatherStation_OutdoorTemperature' changed from 6.3 °C to 6.2 °C
16:32:01.475 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WS_OutdoorTemperature' changed from 6.3 °C to 6.2 °C
16:32:01.477 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WeatherStation_HumidityOutside' changed from 97 % to 98 %
16:32:01.478 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WS_HumidityOutside' changed from 97 % to 98 %
16:32:01.480 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WeatherStation_WindDirection' changed from 54 ° to 50 °
16:32:01.481 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WeatherStation_WindSpeed' changed from 8.64 km/h to 5.04 km/h
16:32:01.483 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WeatherStation_GustSpeed' changed from 11.16 km/h to 7.2 km/h
16:32:01.484 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WeatherStation_LightIntensity' changed from 166 lx to 149 lx
I believe the pressure should be logged as
Item ‘WeatherStation_RelativePressure’ changed from 1017.2 hPa to 1016.9 hPa
but I could easily be wrong since my understanding is limited.
