Zigbee Drivers starting point

The fingerprint is just used to pick the best-match driver when pairing. You can always manually change the driver afterwards (just like you did now to temporarily switch to the "Device" driver). It is, of course, a better end-user experience if the driver matches as-is, but if the fingerprints are truly the exact same, I don't know what else you could do.

Except...what kind of devices are these? I saw "Swidget" above somewhere, so I don't know if that's what you're talking about, but if all the devices are laregly the same except for a capability or two (and they have a lot in common otherwise), you could do a parent/child thing--the parent device handles all Zigbee communication, but child/component devices can expose the relevant capabilities to Hubitat, which you can dynamically create/remove (and use different drivers for, with different capabilities) as needed.

On the Z-Wave side, one example of this is HomeSeer's Flex Sensor. The parent driver handles temperature readings, which is all the device supports as-is. Optionally, the user can connect either a light/LED sensor or a water sensor, and the parent driver will create either a switch (read-only, to indicate whether the LED is on or off) or water/moisture sensor child device for use with those components, if needed.

2 Likes

Is there a way for me to dynamically add or remove capabilities? I see that all zigbee endpoints are listed as Component Devices but they all inherit their parents Device Type. My endpoints are all going to be very different. The first endpoint will just be OTA upgrade. Another might be only power reading, another ON/OFF, another will have different sensor readings.

unfortunately not for the primary parent device.
you can however dynamically create/remove various child devices which could then have different capabilities.

OK - that works beautifully. I have 15 zigbee endpoints (component devices), they are all different and never change. All that changes is which endpoints are enabled (revealed to the network)

I think there is a misunderstanding somewhere here; devices (parent devices) can create a child device of any type. Hubitat has lots of "component" drivers built in, which I'd recommended starting with for ease of use and because they should cover most uses, but you could also write your own if needed. Hubitat's example drivers contain examples of how parent/component communication works with the built-in drivers if that is helpful to see.

Can you point me at an example of a driver that supports multiple child devices? Or do I write multiple drivers for the child devices and just have them match on the fingerprint?

You don't necessarily have to write a driver for child devices; Hubitat has lots of drivers built in that are meant to be used as child devices for specific types. These are the "Generic Component..." drivers. So, if you need a child switch, "Generic Component Switch" would be one you can use. You can write your own if you want to or if you have specific needs that these don't address; the advantage of the built-in ones is that end users don't need to install more drivers (and you don't need to write one).

In a "parent" driver, you can create as many child devices as you need. The addChildDevice() method works the same for creating one child as it does for multiple child devices--you just do it multiple times. :slight_smile: Elsewhere, you can use getChildDevice() (or getChildDevices() if needed) to get a reference to whatever specific child device you need. You will, of course, need some way to identify which child you want; generally, something in the DNI would be most helpful. (One convention I've seen is to append a number or unique identifier to the parent device ID. DNIs must be unique across all devices on the platform, not just ones you create personally.)

I'm not sure Hubitat has any published examples of drivers with multiple children, but the idea isn't too dissimilar from the single-child examples they have like the Generic Component Parent Demo driver they published. However, if you want a practical example, here are two real drivers I wrote:

Both of these use Hubitat's built-in component drivers for all child devices. I'm not saying they're the perfect examples of everything (although with the exception of some odd behavior I think that Zigbee device exhibits, I think they follow good practices...looks like I might want to verify Z-Wave Supervision on that first driver, though). But hopefully they are helpful for examples!

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.