That would be on me, and I have been pretty busy. I traditionally have done the Hubitat drivers for free (donations only). Zooz just links to them with my permission.
I wish I had more time to test devices and write code for Hubitat. ![]()
That would be on me, and I have been pretty busy. I traditionally have done the Hubitat drivers for free (donations only). Zooz just links to them with my permission.
I wish I had more time to test devices and write code for Hubitat. ![]()
Not on you at all. If Zooz wants to ensure robust sales of their devices to Hubitat users, they need to ensure that all the functionality of those devices is available, and they should invest the funds necessary to ensure that happens. Your time and expertise are valuable, so they should compensate you if your efforts are leading to greater product sales for them.
Thanks for your feedback. We're trying the best we can to allocate resources between platforms to ensure the widest functionality available. We were hoping that with the introduction of Z-Wave JS, the need for custom drivers would decrease since everything should work out of the box (that's how Z-Wave was designed). But if we see increased demand for custom code, we will definitely invest in it, like we had in the past for this and other platforms. It's always about finding the right balance between paying for custom functionality on the platforms we don't own while keeping the price of the devices reasonable giving all other costs we have to take into account
Thanks for your patience in the meantime!
Agnes, Jeff...any word on an driver for this wonderful little device? I really want to use it for monitoring my septic alarm...as noted above, but the existing driver just won't work in my use case. I really need the child device issue to be resolved. Pretty Please?
Scott
We're working with Hubitat directly to make this functionality possible since this is ultimately a platform limitation and it shouldn't require a custom driver. Let's hope we can get the official integration updated as soon as possible. Thank you again for your patience!
This functionality is added to the next build of 2.4.4 which is in beta right now..
Great news! Thanks Bryan.
Scott
@bcopeland -- I see it in the patch notes, but after updating, I still have no child device. I tried changing to device and deleting states, and the reloading the Zen57 driver, followed by a Configure.
Do I need to exclude and rejoin?
Scott
What is the "Input Type" config parameter set to..
If it is set to values 4 through 12 it should have a child device after it is excluded and re-included..
It's set to Dry Contact, I want to say it's 10, but I'll have to dig around. But you answered ... I have to exclude then include. That'll have to wait, as Im not trudging out in the snow and cold and dark to fix it tonight! Lol
Confirmed: the value is 10.
Thanks Bryan
S.
Thanks for finally addressing this, but I have tested it by making sure my Parameter 5 was set to 7, excluding my ZEN58 and reincluding it, and still no child device. I also tried parameter 5 set to 10, and changed Parameter 11 to 1, excluding and reincluding after each change, but no luck. I'm on the current 2.4.4.135
Input Type (Parameter 5) needs to be set to 4 or higher
Input Trigger (#11) needs to be set to 1 (Disabled)
That's at least what will cause the device to send the separate reports.
After you include the device again, double check the settings, it is possible you need to set them back again to the desired values, save, and then possibly run configure to create the child device. This just depends on if the driver loads them from the device at pairing or assumes they are at defaults. (I am just guessing since I did not write this driver and no instructions were provided).
Also, often times the child device will look hidden, make sure you click the > next to the device in the list or look in the child devices tab on the device page.
Which device are you using, ZEN58 or ZEN57?
This is a Zen58. Here are my parameters:
No child device hiding there, and pressing Configure does not create one.
The only thing I can think of, is that the value 10 (dry contact) is different than the rest, since it uses the switch command class it actually sends it on another endpoint. Very annoying for making a custom driver in a platform like this. I just made that setting not available in SmartThings so I didn't have to deal with it. I always test with the contact sensor option.
Other than that @bcopeland or @bertabcd1234 would need to take a look at it.
I do not think I tested it on Hubitat.