@snell Yes it shows humidity1 and humidity2, temp1 and temp2 for the WH31B's. Not sure what you mean by child devices option? Are you talking about creating a virtual device for each?
No. If you use the new AmbientEcowittWeather driver, there is now an option for child devices to be generated.
So the main device would still show everything exactly as it is today, but you would also get child devices automatically added to it that show the values specifically reported for each of them. So, based on yours (at least from above) you would see at least 4 child devices:
"Indoor Station" (basically the base station)
"Outdoor Station" (your WS-2902)
"Sensor1" (should be the 1st WH31B)
"Sensor2" (should be the 2nd WH31B)
The benefit is things like temperature and humidity (and any other reported value) are set on each child device. So if you want them in the dashboard or Rules, it makes it easier because you can just select the child device to provide that specifically (instead of making a workaround because of the normal temp1 or humidity1 reporting).
I see version .99 of AmbientWeather as a driver. Wrong one?
Sorry, it was mentioned above, but the AmbientEcowittWeather.groovy is a whole new driver attempt (I wanted to make it clear it supported Ecowitt now).
For the child devices to work properly you also need to load the child device driver:
If you do not want the child devices, you do not need the second driver and with the option disabled in the Preferences it should act just like the 0.99 AmbientWeather.
@snell Sorry I must have missed it somewhere, a lot of posts to read. I have the driver loaded but my senior moments are getting the best of me. I see no child devices.
Huh... Ok, things to check (the thorough list in case anyone sees this in the future):
- The AmbientEcowittWeather.groovy driver has been added to your Drivers Code list.
- The WeatherSensorChild.groovy driver has been added to your Drivers Code list.
- The virtual device you use has AmbientEcowittWeather selected in the Type dropdown for the device.
- The "Enable Child Devices?" Preference is enabled and you have saved preferences.
- A refresh has occurred (or you manually select the Refresh command).
- You have refreshed the webpage for the virtual device (usually F5 in your browser, or the reload/refresh button provided). Child devices (and state variables, or new preferences if the driver is updated) are not automatically added to an already-open device display.
You should see the child devices added in the Device Details section as Component Devices.
If they do not show up... Please turn on the Debug Logging level, perform a refresh, and shoot me a capture of what the Logs show.
As a note for this feature (again, for general understanding), disabling the Child devices preference will automatically delete any child devices once the Preferences are saved. Plus they can be removed individually without problem, the driver will automatically re-add them on the next refresh. However, removing the child devices will obviously cause issues with any Rules made to use them.
This is not listed under USER types. Just AmbientWeather and WeatherSensorChild
@snell OK, I copied the drivers from your links above and recreated them and deleted the old drivers I had. Now there is a child device option!! They are coming in great. Sorry for the doh moment.
@snell I do have one other question. I went in to create an event for the WH51. In actions I selected custom attribute and picked the WH51 from the list. In the attribute dropdown it still has all the attributes from the pws instead of the WH51. Is that correct?
If you are using one of the "standard" attributes like temperature, humidity, pressure, or whatnot, you can select the standard attribute without it being a custom one (this is one of the benefits of the child devices).
Unfortunately, the custom attribute list is based on the attributes provided by the driver NOT by which ones the device is actually using (or had sent an event for). There is no way to dynamically select attributes in the driver/for the device (it is a part of the design of Hubitat), so I cannot correct for this as I had to make sure the main driver and the child driver supported every possible attribute that every sensor could report. The "proper" method of a whole bunch of individual child drivers (one for EACH sensor type) would be excessive for me and difficult for people to use.
Understood. I will not use the custom attribute and select from the standard list. Thanks
Don't get me wrong... you can use the Custom Attribute if you want... it just is a long list and easier to make mistakes with. If it is something simple like temperature or humidity, or what not I would recommend the "normal" attributes.
I understand. I will use the standard unless the custom ones are needed. Great Driver BTW. Been waiting for a way to do this so now the WAF factor is good.
Got my GW1000, PM2.5, and a soil sensor today. Initial setup went smoothly and all the basics are working. I think I might edit the comments in the next rev of the AmbientEcowittWeather driver to spell out the setup instructions a bit so people do not need to hunt through this thread, but overall it was not too bad.
It has highlighted one thing though... I need to come up with a different naming scheme for the child sensors in this driver. I had a lot of changes I wanted to make in this one anyways so now I have something else to do in the next few evenings.
Ok, the child naming problem should now be cleared up. You can remove the existing child devices if you want, new devices will be automatically generated. I apologize for the problem this might cause for any current work you already made using the names, but it was needed to make sure that names going forward were unique.
Version 0.04 is now posted as well as an updated WeatherSensorChild (0.05).
@snell Any progress on the battery status for the WH31B's? Reading 0 on both CH1 and CH2.
Also doesn't the GW1000 have a barometric value along with the temp and humidity?
I am on the latest version for both drivers. Versions are different below.
Also I have this for the CH2 WH31B.
- Version : 0.02
- temperature : 75.2
- Driver : WeatherSensorChild
- humidity : 36
- battery : 0
And this for the CH1 WH31B.
- Version : 0.05
- temperature : 75.2
- Driver : WeatherSensorChild
- humidity : 37
- battery : 0
Can you enable debug logging and send me a shot of that, at least any lines where the batteries are being reported?
I will check into the barometric sensor. The GW1000 does have one but my bet is the value it is returning is getting overwritten by the outdoor sensor, as I do not have a specific separate data point for it.
Now that I have my own GW1000, I am noting some changes I need to start working on to try to make things better for those owners without muddling things for the existing Ambient API users.
I'm a happy Ambient Weather 2902A user and use the API driver provided by Mr. Snell to tie it into my Hubitat Elevation for home automation tasks. As a point of interest, how are you using the GW1000 and associated sensors? How do you tie them to the 2902A and where is the GW1000 located?
Having just gotten a GW1000... It was remarkably easy.
- Installed their app "WS View" onto my smartphone.
- Plugged in the GW1000 to a USB power supply.
- Added the GW1000 "Configure New Device", then select the GW1000 image, then follow through the process which includes getting it on your Wi-Fi.
From there, you can check the live data in the app. The GW1000 will automatically recognize the signals from the WS2902A and does not interfere with it's normal reporting to it's display/station. You can also check the status of additional sensors you might also add (I added a PM2.5 and a soil sensor just to try them out).
Here you go. Both State variables now read .05 for version. Don't know how CH2 changed from .02 to .05 by itself but who knows.