For all you blizzard guys. Ecowitt has a LDS01 snow shield 3D print file for free on there website.
2 Likes
Proposed fixes and improvements
The Groovy drivers with fixes and improvements are in the repository bellow for appreciation.
https://github.com/esimioni/temp-ecowitt-hubitat
@sburke781 , I didn't want to send a Pull Request before explaining the rational here.
I can do it if/when you are comfortable, or if you prefer, you can grab the files and update directly on your GitHub repository.
My Environment:
- WS90 weather station
- WH40H rain gauge
- WH51 soil moisture sensor (2)
- GW2000B Gateway (with built-in Indoor Temp/RH/Pressure sensors)
Main Issues
1) CPU Usage
- Checking at
Logs -> Devicetab I have noticed that Ecowitt devices were by far the top CPU consumers. - The WS90 and GW2000B devices combined were responsible for 45%+ of the CPU time of all drivers! And I have more than 100 Zigbee devices, 5 Ecobees, plus some other LAN devices.
2) WH40/WH40H wouldn't be recognized as separate sensor
- All attributes from the WH40H were being sent to the WS90 device on HE, as a result, on every data reporting event, the Rainfall Piezo values would be updated, then replaced right after by the WH40H ones or vice-versa.
This was creating lots of unnecessary events/data updates on the hub, which also get sent to my Node-RED via Maker API, spreading unnecessary processing.
3) Unreliable Battery readings on WS90
- Due to problem #2 above, the battery reading from the WH40H was being applied to the WS90.
- The capacitor/solar battery was being reported as "battery" overwriting the AA/backup battery reading which was overwritten by the WH40H reading
- Apparently the parameters on the HTTP request can sometimes come with different order, so the last processed value would prevail.
Improvements / Fixes
1) WH40/WH40H as a separate device
- This fixes most of the mentioned issues!
2) Separate solar battery and backup battery readings (WS90)
- If a sensor reports solar battery, it will now fill different driver attributes (states) so you can use both. No more overwriting/unpredictable behavior.
- Diver preference to enable/disable solar battery reporting.
Since it changes a lot during the day, you can save some attribute changing by disabling these reports, if you don't need them.
Normally we shouldn't care about the solar battery, it should just work. If there is a problem, it will start using the backup batteries and one could notice the problem from there. - Removed
capacitorVoltageattribute, it was a duplicated information frombatterySolarOrg.
3) Option to suppress rain data
- You can save some more processing by disabling events you might not be interested in.
In case you have a separate rain sensor, you might want to disable rain data ingestion for the WS90.
3) Option to suppress runtime / latest update / dateutc on Gateway
- These attributes were, of course, updating every minute (or at your defined interval), and honestly I don't see any use for them. In any case, it is an option on this version of the driver.
5) Log improvements
- Using Closures to avoid String interpolation for log levels that are not active.
6) Code/performance improvements
- Reordered
casestatements on the mainswitches to avoid (as much as possible) regex matching. - On every data ingestion the driver was checking if it was on the latest available version
I just commented this code, a more clever strategy could be used, but it is a bit complex for me and I didn't want to spend too much time just to understand it. - Added a preference to enable/disable
Wind Compasscalculation, all other calculated attributes were already configurable. This was the only "mandatory". - Removed try/catch from the
parse()method. On exception, it was suppressing the line number. The hub handles it better
- Removed some unused conversion methods.
- Added some
TODOson parts of the code that could receive future improvements. - Some other improvements that I don't remember
The drivers are quite complex (for me), it took me a lot of time and testing to apply the changes.
I don't understand some parts of the code and there are some unused stuff like methods / local vars that are probably leftovers from previous versions. I couldn't help myself in doing some cleanup here and there
I did my best not to mess up with the functionality, but I can't guarantee it 100% as I don't have every device type. It is working well for me so far.
I also tried not to change existing behavior without the user explicitly changing a preference for that.
3 Likes
yes the percentage is high but you also need to look at the top percentage. here in my case the top 2 are indeed weather stations but if you notice the total is on 2.5% .. so not really an issue so about 20 percent of the 2.5 percent equal about .5 percent total
2 Likes
Wow, thanks for taking the time to work through all those changes @eduardo . I will need to read through your notes on more detail and let you know what I think.
3 Likes
Just chiming in. Mine only uses 0.3% of busy and has a state size of 1406 and is in 30th place in my list of apps when reverse sorted by %busy. I have the GW2000B, WS 90, 7 - WH31 Temp/Humidity sensors, and 3 WH51 Soil Moisture sensors.
My top two items are dashboards that are on my wall mounted tablets. The Ecowitt feeds one of those dashboard.
2 Likes
Hi All I'm after a bit of help with the available Attributes. I want to use Rain attributes to control the amount of watering that is done, which I think I'm OK with. The other thing I want to do is setup an app to advise when it starts raining so that the household can check that the rain isn't coming in through any open windows. I have senses on any window that is susceptible so have that part covered. In the 'Weather Station' device attributes I can see several 'Rain' items (see screenshot). However when selecting from the attributes in an App there is one called 'Raining' which is not showing in list in the device attributes. When selected in the App the value is showing as 'Null'? I thinkig that this currently isn't being collected in the Driver Code. Is this correct? If I can't select 'Rain' what can I use to notify that it has started raining, & then what do I use to know when it has stopped? Thanks in advance for any help
Probably rainEvent, but I’m not sure if that increases as accumulation is happening or once it has stopped. rainTotal will increase, so you could look for a change in that to trigger a “raining” indication.
1 Like
If it is like the display on the EcoWitt dashboard rainEvent would be an accumulation as it is happening, potentially over midnight.
@greghoward1962 - You could probably use either rainEvent as @SmartHomePrimer suggests, or the rainRate. Probably worth considering how sensitive the sensor is, as well as other factors that could influence rain coming in after it has started, like wind direction.
1 Like
Very good point. If wind is blowing rain in a window, that could be quite a lot of water before the sensor indicates anything.
My rain guage is the cup style, so I know mine would not indicate quick enough to prevent damage. I have no experience with the haptic style, so maybe they’re faster at indicating “raining”.
1 Like
I remember there was a conversation somewhere, likely here on the Community, where people were discussing a similar issue, likely relating to whether to raise an awning. I think the consensus was that more sensitive water sensing pads of some kind were a better option to detect the beginning of a rain event. Not sure whether EcoWitt sell anything like that.
1 Like
I guess I use 'Rain Event' & then to turn it off I can use that it hasn't increased for maybe 30 minutes??
That said, @greghoward1962 , not to say not to try out using your weather station and seeing how it works for you. Different setups work for different people.
Depends on how you plan for it to work. I would simply turn a switch on when it is increasing, resulting in a warning / notification of some kind, if the window is open.
Might need to leave you to it, got stuff on this afternoon.
OK when you get time, its a work inprogress. It hasn't rained here since about 10pm last night, 'Rain Event' was showing 1.3mm at around 7.30am & is still hasn't changed. Rain Hourly is currently 0. So maybe that can be used to turn it off??
Is there a way to find out how quickly the Attributes react? I would have thought that 'Rain Event' would have reset after purhaps an hour?
Can you help (or advise where I can get help) with how in Rule Machine to get a trigger for if say the 'Rain Event' attribute increases or decreases?
Thanks again for any help & for getting the driver back on track
1 Like
I believe i added a raining attribute in the last couple of years. just checked I did. but that attribute is only present and reported for ws90 wittboy
1 Like
EDIT - You are likely right.. and I did not read your post closely enough.... (Was watching the Men's Final of the Aus Open Tennis).... I'll need to check it when I get a chance to see what is the best attribute to use and how best to detect the rain.
1 Like
I have 2 on order
I've been getting alerts via the Ecowitt app & trying to line it up in Hubitat. I'm a bit lost as to what's happening?
Send me a PM with some of the warnings and I will see what I can work out for you.
