Decided to debug the RF Sensor driver (@sburke781 )... My WittBoy is a WS90b and console is HP2560, and it reports two battery attributes:
wh90batt - voltage of the AA batteries
ws90cap_volt - voltage of the capacitor battery (solar charged)
Seems like there are two issues with the RF Sensor driver:
wh90batt is being treated as type 0 (boolean) instead of type 1 (voltage). It should be handled the same case as wh80batt, right?
ws90cat_volt overwrites the battery. This attribute should probably be ignored, logged only, or driver needs a second battery reading (and second set of voltage min/max)?
When I moved the wh90batt case to group with the wh80batt case (in attributeUpdate), and comment out the ws90cat_volt case, then the battery reporting appears to work correctly.
Thanks for digging into this @xcguy. I'll take a look at this when I get some time, not sure when that may be. Would I be right in thinking that with the changes you made to your own copy of the driver that it is working for you now? Or are you still having issues? Just wanting to work out whether I need to look at it sooner.
I don't actually own a Wittboy myself, so if you could turn on debug logging and send me a PM with a copy of the data feed, that would be a great help.
If you could also send through a copy of the updated driver, that would also be appreciated, even though the changes you described seem relatively straight forward to reproduce.
I have tried to start a new habit and logged an issue in the GitHub repository as well.
The changes do fix the battery reporting for ws90, with the caveat that the user has to update the RF Sensor preferences to use some empty and full values appropriate for 3 volts. I don't have a good suggestion on 3 volt values, as it appears lithium batteries will have a different voltage range than alkaline (and NiMH) batteries.
On a related note, I noticed in the debug messages that the ws90 is reporting it's firmware version (attribute ws90_ver = '132' which is 1.3.2). Would be nice to see the firmware version reflected in the RF sensor attributes.
@sburke781 I've been meaning to ask this for a couple of weeks; would it be possible to get some more informative Dashboard tiles and detailed data?
I'm missing some of the data and info I got from Netatmo that I used in automations. eg recorded max temp for the day etc. It was really nice having a Dashboard tile with detailed info for each gauge / function. eg Netamo
I do need to get back to the tiles for (now) a few reasons... so I may look at these... I can't promise when I will get a chance to look at this... Feel free to "build-your-own"...
No u have done a great job! I have enough other apps or device code to maintain (or the computers and networks and wifi infrastructure in 5 locations) to keep me busy enough. Sigh first world problems. Current task configuring a new qnap nas and backing evrrything up off an aging drobo that is no longer supported before it dies.
Thanks again for providing the updated code and notes on the Wittboy battery readings @xcguy . It's starting to make more sense now, and goes back to some issues we had with battery reporting when some people starting using a Wittboy, including @njanda. I can see from my comments back on the 5th Feb that I was in fact worried about the ws90cap_volt trumping other battery readings, and I was in fact right It's also interesting that my older weather station reports just a single reading as a boolean....
Anyway, like I said it is making more sense now. I think I might take a little longer and add some of your suggestions for:
Recording the ws90cap_volt value - I think I will store it as a separate attribute reading for now. I'd want to do a bit more thinking before considering a separate battery device
Storing the firmware version - This should be simple enough to do, like the stationtype attribute logic in the gateway driver
EDIT: Actually, looking at the firmware version again, this could be a little problematic. I may still end up recording it, but I'm not sure I will be able to record it as 1.3.2 from a value of 132. If they ever reach a 2-digit value for any of the three parts I'm not sure how they would expect to parse it... I may just record 132 instead. Will think about it some more. Shame they didn't adopt the same apporach as mine with includes a formatted version number, e.g. stationtype = GW1000_V1.7.5
I can't say when I will get to finalising the changes, hopefully sometime over the weekend.
@sburke781 I've updated the pull request with changes I made to support the solar battery and firmware version. I've been running with those changes for this past week. Tried to follow the previous conventions/minimal updates, but feel free to use/toss what you think is best. My updated repo: GitHub - xcguy/ecowitt: Hubitat Ecowitt Gateway Integration
At a glance that all looks really good, I think I'll end up keeping most of it, great work.
One thing I was thinking about doing differently was the firmware, but want to check something. Can you (or anyone else with a Wittboy) please turn on trace level logging and check the logs for the next data feed to see if there is both a stationtype with a version number included, plus a ws90_ver or ws80_ver entry as well. If there is only ever one or the other, my inclination is to store them in the same firmware attribute already present on the Gateway device, but I just want to make sure it makes sense to do it that way.
I probably need to do a little more research on how it is connected to the LAN as well, if there is a gateway device in the middle, then it probably makes sense to store the new firmware version on the sensor device in HE.
Looks like you received the min/max temps from Netatmo...? If I read the app code correctly. EcoWitt must calculate that on their side when displaying the dashboard, it is not sent from the gateway. Not that it means it can't be done, just that I will need to find the most appropriate way to implement it.
It's all good, I was actually expecting you needed to do it as well, so was just going to steal your code But not to worry, will definitely be possible, and a nice feature to have.
A couple of things that sprung to mind are
Handling min's / max's and if the temp drops lower in the evening, etc. Not sure how weather bureau's tend to handle these situations...
I am expecting to do a nightly reset, but again, not sure how this would be commonly handled, so will need some investigation. Plus I would need to handle if any scheduled reset of the min/max does no occur
Might do some digging around others who have integrated these in other platforms to see how they might handle something like this.
I can see now it does still require a gateway. So will just need someone to confirm the data points sent through to make sure there are different versions, one for the gateway and one for the weather station.
