This is no different on Hubitat than on Windows. When you plug in a USB device, it doesn't just know what the device is. It has to have a driver to know what it is, and what it does. And if the new device doesn't match an existing device, you may have to download a new driver.
In our case with Hubitat, you can either import someone's driver they wrote, or create your own to get this same effect.
So in my non-coder view, I don't expect the hub to automatically "discover what a device is capable of" (and here is probably the more relevant point) "know how to use those capabilities" any more than I would Windows to know what something is.
Technically it is possible for the hub to know what a device is capable of and then support it. When a device is added to the hub (zigbee or zwave) it gets a list of clusters or classes that the device supports so it knows.
However, the issue is with the device manufacturers. They don't all stick to the standards that they shood. For example, one contact sensor I wrote a zigbee driver for reports switches as on/off instead of a contact sensor as open/closed. This would throw the hub off. So you have to create a driver to handle this situation know that this device isn't playing nicely.
There are a lot of devices like this. Some report battery % while some report battery voltage and others may just report "battery low" as an alert.
In your zigbee parse method look at use the "zigbee.getEvent" method. It will parse the description into a known event object that you can just use "sendEvent(evt)" to send off. It will only parse a few of them. If it doesn't parse it then use the "zigbee.parseDescriptionAsMap" and then act on the clusters reported.
The zigbee cluster manual helps you understand the various clusters. They start in chapter 3.
The difference here is that Zigbee specified the app layer of the protocol and all ON/OFF devices will work the same. All light dimmers are the same. All batteries are...OK - Batteries are a mess. But lights, electrical outlets, switches, metering devices, sensors - {temperature, pressure, humidity, CO2 etc}, they are all exactly the same. Over the Air Upgrades - the same.
I beg to differ. There are lots of manufacturers who use non-standard clusters even on "standardized" zigbee 3.0 devices. Creating a need for device-specific drivers. And this isn't unique to Hubitat.
Edit - off course, this digression isn't making your job easier. If I were you, I would use existing community drivers for similar devices as a starting point.
Thank you Bertabcd1234, that's an amazing starting point. Looks like I have to write 48 different drivers for all my devices. This really helps.
I still can't get the finger print to work. Here is my simplest device. It is an outlet with power measurement on both outlets but only one of the outlets can be turned on or off. It has 3 endpoints. Endpoint 1 contains the OTA upgrade cluster, Endpoint 3 the switchable outlet and endpoint 4 the power measurement for the other outlet. ID: F11F //this is the zigbee(802.15.4) short address Manufacturer: Swidget Product Name: Model Number: Insert deviceTypeId: 354 //no idea where this is coming from
manufacturer : //this isn't populated, not sure why, could this be my problem?
idAsInt : 3
inClusters : 0000,0003,0006,0702,0B04
endpointId : 03
profileId : 0104
application :
outClusters :
initialized : true
model : //again, only populated on endpoint 1
Note that Hubitat firmware 2.2.8 introduced the "libraries" feature, which lets you define a small (or large) code snippet that can be inserted into apps or drivers with an #include. See:
If all of your devices should ultimately expose different capabilities to Hubitat, then you may need different drivers for each, but if there is significant overlap between some or all, this will save you some typing. Again, I'm not as versed on Zigbee driver development, but with Z-Wave the parse() method often calls other methods that take care of handling incoming messages from specific "command classes" (roughly like Zigbee clusters), and for lots of Z-Wave devices these work the same--just a matter of having the right ones in the driver. Up to you how you do it either way, though! And I'd definitely second the recommendation to take a look at Hubitat's example drivers above if you haven't already.
I would switch to the "Device" driver (this is the actual name of the driver you can find in the "Type" dropdown on the device page). Then, open "Logs" in a new tab/window and hit "Get Info" on the device page. This will write a fingerprint to the logs that you can copy/paste into your driver verbatim. Whether it may have trouble working without specific parts specified by the device, I don't know...
Perhaps. But you can change the driver to whatever you want. In this case, change it to "Device".
And when you do that, and click "Save", you'll see a "Get Info" button. When that button is clicked, the logs will show the fingerprint for the device .... something like this
Ah, OK, I set the parent device type to device. Then the button appears. I press it, the finger print shows up in the log.
I can now also see all three of my endpoints as children on the devices page.
I'm now screwed. All 48 of my devices will have the exact same endpoint 1, so their finger prints will all be identical. I have to think about this.
What type of devices are these 48 Zigbee devices? Are all 48 devices truly unique in their capabilities? If some are identical, then the same driver can be used. Hard to believe that you'd need to write custom drivers for all of them, unless that are truly custom Zigbee devices that you've built?
I think I should explain what I'm building. I have one insert that is a zigbee radio module that can have different sensor modules attached to the radio module. The insert can go into a number of different host types. For example a host could be an electrical outlet, an on/off switch or a dimmer switch. The daughter boards can sense occupancy, temperature, humidity, pressure, vibration, luminosity, CO2 content, air quality and a few other things.
The insert will reveal different zigbee endpoints depending on what host it is in and what sensing abilities the daughter board gives it. All permutations will have on endpoint 1 the basic cluster and the Over the Air upgrade cluster.
Currently I have 6 hosts and 8 possible sensor combinations. When I use the devices with Amazon Alexa she just discovers the clusters she understands and uses them. Although she has lots of limitations in what zigbee clusters she supports.
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.
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)
