It definitely has standards, but they are at a different level than Z wave standards. It's actually much more similar to Wi-Fi. There's no guarantee at all that two different home automation devices using Wi-Fi will be able to understand each other. The message content is not part of the Wi-Fi protocol standard. Just the transmission format. The same is true for top level Zigbee. It's a message transport protocol, not a message content definition.
Zigbee goes farther than Wi-Fi by providing the profiles, which do standardize the message content. But their use is optional.
Interesting read, but the last comment in that article confuses me. Zigbee 3.0 is supposed to be able to join legacy networks, and legacy devices are supposed to be able to join 3.0 networks. Hereās a Silicon Labs KB quote to that, I believe the Zigbee alliance website makes the same statement.
āZigbee 3.0 has been designed to allow for interoperability between zigbee 3.0 devices and legacy HA and ZLL devices. With proper configuration, ZLL and HA devices can join zigbee 3.0 networks and similarly zigbee 3.0 devices have the functionality to join legacy legacy networks operating with either ZLL or HA networking. This KBA will help you understand the configurations necessary for allowing this.ā
How does this differ from ābackward compatibleā in your post?
Lastly, @veeceeoh, if you want to get started with webCoRE, @ogiewon has done all of us a big favor and posted all the fixes and modifications needed to the webCoRE code, to make it run on Hubitat,
Forgot to post a link to what I was referring. Given below is the fork that can be directly pasted and used in Hubitat. (Credits go to Ogiewon and other who contributed to it.)
Zigbee 3.0 is a big topic with a lot of tiny technical details. Since neither the hubitat hub nor the Xiaomi devices are using zigbee 3.0, I donāt want to hijack this thread. Why donāt you start a new thread to discuss Zigbee 3.0 and Iāll be happy to continue there.
Iāve got two questions. hopefully theyāre both quick!
is there an air-pressure capability? Currently, the driver for the Aqara temp/humidity sensors only report the āTemperature Measurementā abd āRelative Humidity Measurementā but do expose a pressure value on events that get fired off. Iāve managed to update one of the apps i use (the MQTT bridge: [PORT] Hubitat MQTT Bridge) to also use the pressure valueā¦ but it got me thinking as to why the driver only reports 2 of the the devices three capabilities.
is there a āreleasedā event for the aquara buttons when theyāre configured in momentary mode? I see the runIn() call calling ReleaseButton which should fire off a call to getContactResult which should log to the event log a Button was released message, right? I donāt see these āreleasedā messages showing up in the event log for any given button, but i do see the Button was single/double/tripple clicked messages. Thoughts on what i might be doing wrong (is my ReleaseTime value set too low (currently 1 sec?)? Or is there something else that i can do / help with to figure out why release events are not showing?
Sure, but my question is around why other things on the hub canāt see the āreleasedā events.
When the button is in ātoggleā mode, i see a ābutton pressedā and a ābutton releasedā event in the hubitat event log. When the button is in āmomentaryā mode, i only see ābutton was {s/d/t/q} pressedā events, but no ābutton was releasedā eventsā¦ the state of the button is always at some positive integer; it never returns to 0. Is this something that can be done w/ āmomentaryā mode? it looks like runIn() should fire the ReleaseButton functionā¦ but it never does. Is there something iām missing / not configuring correctly?
Not that I'm aware of. Since there is zero developer documentation for Hubitat, my lowest common denominator guess (because I hate to assume) is that things work the same as in SmartThings, until we find out otherwise. And ST doesn't have an atmospheric pressure capability. To know for sure, we have to ask the Habitat folks.
Despite all this, I'd also have to guess that, just as can be done with ST, enterprising individuals can write Apps which look for custom events for triggers or conditions that aren't supported through a capability.
Aha. Would it be possible to publish a list of capabilities supported somewhere? I think thatād take some of the guesswork out of independent developersā work.
Currently we support all the ones ST has implemented with the same commands and parameters ect, we attempt to document notable exceptions (button for one).
Interesting, yes we should have all the capabilities in that list, and youāre correct Pressure Measurement is missing, I swear it used to exist, I had a driver over their that used it.
I also checked our code, we donāt have it eitherā¦, oh well.
One of my two Temp/Humidity sensor dropped offline two days ago. Both were working fine for a couple of weeks then the one decided to take a vacation. Doing the reconnect got him to rejoin the family again but then he dropped out again. Going to delete and repair to see if that will help.
how far away are your Temp/Humidity sensors from the hub?
I was having similar problems with my 3 Temp/Humidity sensors but I moved my hub to the main floor basically in the middle between all 3 and it has been much better (knock on wood).
I think there is a bit of a limited range with all the Xiaomi sensors.
Since neither the hubitat hub nor the Xiaomi devices are using zigbee 3.0, I donāt want to hijack this thread. Why donāt you start a new thread to discuss Zigbee 3.0 and Iāll be happy to continue there.
