Yes, there are only four attributes that show because they are only ones that report any value, but in the device properties itself for any integration or other app that is reading all of the possible capabilities and attributes of the device, they are seeing all of them, and in some cases where those attributes are null, then it’s reporting them as being a zero value in the case of air quality zero means excellent.
My gut-feel would be it would be possible, but could be a bit of a task to accomplish, without having really dug into the code to find out.
I certainly get the desire to do it, I can understand how presenting devices more accurately across the system and externally would be a better setup.
I believe the driver will be locked because it is a child / component device (can't remember which it is or which would cause it). So effectively it is set by the parent device that creates it, rather than the user having the option to change it.
There is a mixture of issues (I think) that can come about from the current setup. The device/driver having the capabilities at all can mean devices appear for selection in HE regardless of the attributes that are populated, so reducing the attributes listed / populated is not the only issue or solution.
1 Like
I was thinking this too, but I have other components/child devices that I can change the drivers, such as my Tessie for Tesla app. I did actually switch the isComponent value to false on one of the child devices, and that still didn’t allow me to swap it out, so there must be something else on the back end that is making it read only
Yeah, I'm pretty sure there is something in the way the device is created / setup that stops it, just can't remember what.
In general, in terms of what you requested, I'd be happy to consider it, just not sure when I would get a chance to look at it. Happy for you or anyone else to play around with it.
My only real concern or suspicion about why it was developed the way it is, is that there may be too many permutations of capability combinations, i.e. sensors that just do temperature, just do humidity, do humidity and temperature, do humidity, temperature and air quality, etc. Off the top of my head, one option worth considering may be to create library code for the base capabilities and then produce "aggregate" drivers for the different combinations needed. But that could become complex to maintain.
1 Like
@dJOS - Been meaning to mention, you may want to look at this for your aggregate values. Obviously still not combined into the one device, but it might buy me some time 
1 Like
It’s here on row 763 in the parent driver where the child device driver is specified upon creation. It also specifies “isComponent” here, so that’s why I was thinking changing that value would make it editable. My thought is that this section would need to be modified with the ability to assign different child drivers based on type of component being added, but that would take some work. I would be happy to be able to just swap out the standard child device driver for my own, so I’ll keep fiddling around to see if I can make it editable. (I’m hip but not groovy, so my chances of figuring out are fairly slim.) If you get time to look at it further, great, thanks, but it’s really not a critical issue.
1 Like
Yeah, that's all that looks different compared to the Logitech Harmony driver I use, which produces child devices where the driver can be adjusted. Hmmm....
Cheers, I’ll take a look.
1 Like
also you may save on attrib definitions. but they are not getting updated everytime like you say.. they only get updated if values come in.. on the flipside you would have a much larger code base to have all kinds of different drivers.
1 Like
if you want to delete it. it happens automatically. just pull the battery out of the sensor and do a re-sync and the devices will disappear.
2 Likes
Smaller than I thought it would be.
Now for the fun part, mounting it somewhere. 
WS85 pics
2 Likes
I'm wondering which models of gateway are compatible? The GW2000 is the only one that indicates LAN -- is this correct? The GW2000 could be connected to hubitat locally while GW1100 and 1200 would be via cloud?
Thanks!
No, GW1100 and 1200 are also fine, they can connect locally to your HE hub to send the sensor data. One of the differences is that these two connect via Wi-Fi, whereas the GW2000 has the option of a wired ethernet connection, plus PoE.
Some of the EcoWitt displays can also send data locally I believe, taking the place of a Gateway.
2 Likes
@sburke781
Just letting you know, that I recently purchased a Wittboy Weather Station and am now using your gateway driver to feed data to my Hubitat C8 which I use for webCoRE, Tile Builder/dashboards. Your driver works extremely well and without issue. Thank you!
6 Likes
Unless something has changed, the GW2000 is the only one that has an ethernet port for a wired connection. The GW1000 and 1200's are Wi-Fi only, they all work equally well with these awesome drivers. As @sburke781 mentioned some of the displays also have the ability to data locally as well.
I will add that I previously had a 1200 and after about a year in use it started having problems staying connected to the Wi-Fi, I have only heard of one other person with this same issue, so certainly not a widespread problem, but something that could crop up down the road. Ecowitt can be a deep rabbit hole to journey down, but it's a fun journey!
1 Like
A little stuck here - Following sburke871 instructions found here GitHub - sburke781/ecowitt: Hubitat Ecowitt Gateway Integration
Installed the app. It found the gateway with no issue. Added 4 soil sensors. (didn't need to hit the add device button; it automatically added them.
Updated app to version V1.3.1
Found the page to register devices under Device ID. All 4 sensors show battery and signal levels.
I set up the custom data feed to HE but none of the devices are showing up in HE after the gateway updates.
The device status shows sensor sync pending.
Tried using the MAC and IP address.
What did I miss?
need to put in server ip and make sure to assign a fixed ip to your hub via dhcp so it doesnt change.
it should be a local ip normally 192.x.x.x.
also did you install the drivers in hubitat.. you first install them in driver code either manually or through package manager.. then you still must add the base hubitat device through add device.. and configure it.. before it will pull in the children.. show us the base device configuration page in hubitat.
looks to me like you are missing these steps as you dont mention them.
2 Likes
I suspect you may have got the drivers installed fine if you are seeing the sensors sync pending, but doesn't hurt to confirm a few details like @kahn-hubitat suggested. Some screenshots of the device details page would help.
In addition to using the IP instead of hubitat.local, if only temporarily, I would also suggest keeping an eye on the Live Logs page in HE to see if you see any logs / errors appearing, including hub-level logs (not just those linked to the gateway device). This may reveal if the data feed is getting through to the HE hub but not finding it's way to the gateway device.
Hopefully it is a simple as an IP / config issue.
2 Likes
Not see anything in any of the logs
