Best news by far that I've heard this week!
I did not think it was possible until @OpenDave pointed out that he had the exact same stuff I did and was working just fine with a GW1000.
I have a lot of changes coming to the driver. Mirco (@anon81541053) pointed out a bunch of areas for improvement (helps to have a real developer look at stuff). Major changes to state/event handling. If I can get my head wrapped around Maps I may even be able to make it a lot smaller and more efficient.
I'll switch to the AmbientEcowitt driver when my GW1000 arrives next week - can't wait. Thanks for all your work on these drivers!
We need to raise awareness about the GW1000 - lots of Hubitat owners hate going to the internet for data.
I guess I could just wait for the boom!!! 
All in good time.
Lighting detector on order... no idea when it will arrive.
I have a very overhauled driver running the paces at the moment. Cut the total code down by ~1/4. Still lots of stuff that could be done, but future work... In any case the major change was that I took @anon81541053's advice and made the part where it handles the variables all based around a switch( variable) and managed to reduce a lot of duplication there. I also reworked the Ecowitt parsing to be in line with his, and created a new parsing for the Ambient API so there was less reliance of some fudge factors between them (since the variable names are almost identical). Finally, I completely reworked the version control and logging levels (he pointed out there is ANOTHER logging level and that I was not following standard versioning).
Hopefully I will feel comfortable enough (no more errors) to post the new drivers tonight (unfortunately the changes also required my reworking the WeatherSensorCloud driver as well).
1 Like
Shouldn't that be LightNing Detector? 
Just thought I would throw some humor into it. Thanks for looking into it.
Nope. I ordered a solar radiation sensor...
Ha! Not sure if I did that or got hit by autocorrect.
@sam.bowden Yup, completely agree. That is why I added it to the community supported drivers page. I should probably go update it to point to the newer version of the drivers @snell is working on.
@snell are you ordering these directly from Ecowitt or have you found them somewhere else? I've tried to order from them before but decided against it when I could not use a credit card or figure out how to pay. I really want a few of their leak sensors but cannot find them on Amazon or anywhere else.
I could not find them either or used on eBay even. I did not check forever, but did check a few trusted sites. So in the end I ordered a Lightning 
sensor and a leak sensor directly from them, paid by Paypal. Unfortunately it is a LONG way off. They sent me an email to confirm my address and the frequency needed... but also indicated that shipping is likely 6 weeks out.
Thanks for the response @snell. That is what I thought would be the case. Shipping all the way from China directly I think.
Yes, that fits with the estimated shipping time unfortunately.
Version 0.6.1 is now posted, this requires WeatherSensorChild 0.6 or higher if you are using child devices.
Big thanks to @anon81541053 for his expertise.
Major changes include:
- Massive rework of how Ecowitt data is handled based on @anon81541053's method.
- Massive rework of how data is processed after being received, based on things I learned from @anon81541053.
- Rework of state/event processing and posting (thus the child change).
- Update to version control to be more in line with semver.
- Update to logging methods to include Trace level logging (beyond Debug), which I had not even known existed.
@snell I am getting 2 battery devices for the WH51. The batteries for the WH31B's are a little suspicious. They have gone from 100 to 75 in one day.
You can add in the WH31B also.
Another strange thing is that when I first open the device page for the WH31B the values on the page show up as the pic below, but as soon as I press Save Preferences it changes to the 2nd pic above.
So there are "reasons" for all of that.
- When you Save Preferences it clears the state variables, but repopulates the version and driver (this is to make sure it knows the current version/driver since those are fixed). If there is a true need, I can make it save the variables across that particular one... but they should get repopulated pretty quick.
- The 75 is intended. These sensors only report a 0 (good) or 1 (bad). But they will almost NEVER be actually at 100%... so I chose to make the "good" value show 75%. Other batteries that report voltage should do a % based on their voltage (although now that I think about it I should probably make it between their "top" and "replace" voltages). The PM reports 0 to 5 I think, so it's % is based on that.
@snell Understood. Appreciate the explanation. However you want to do this is up to you. Would be great for a percent as you said, maybe make it easier to tell what state the battery is in.
Battery is typically a %. 100% or 0%, 75% or 0%... Not sure which is better, but I can switch it easy enough if opinions vary.
Which ever way you decide. If the darn thing doesn't report anymore I guess that would be a 0%!! 
Yup. But I think someone has an app for watching battery devices and making a bigger notice when they are 0 and/or stop reporting. Now that there are child devices that actually report a "normal" battery things like that will work! Woohoo!
