I already asked about the cheap Xiaomi button in the compatible devices thread but didn't want to spam the thread anymore.
The current state is that I can pair the button and get it working (rudimentary) with a jury-rigged device driver. But, as mentioned by another user, the device becomes inactive after a while and needs to be paired again. Something that I didn't encounter with ST.
anyone else working on this?
I read that the xiaomi devices have a check-in delay that exceeds the time out for Hubitat. Hopefully it can be lengthened.
If the delay timeout cannot be lengthened for all devices, maybe it should be possible to override the timeout in the device driver.
Zigbee devices are supposed to poll their controller every minute, even sleepy ones, or they get kicked off the network (after a grace period of a few minutes). There is a settable parameter in the controller for how long they have, and we will adjust this upwards to see if it helps. Suffice it to say that the Xiaomi devices may not be conforming to the zigbee spec.
I’ve got a couple of the heat/moisture sensors from xiaomi that don’t seem to work. I’ll keep playing with them. They do just run off a watch battery so it’s unsurprising they might have exceeded the specs to increase their battery life.
This post gives some details on the sensors, it's from the incompatible devices thread.
I will have to investigate if any of the Xiaomi devices support commands to the Poll Control Cluster (0x20) (doubtful), but I'm reading that there are two Poll Intervals - Long and Short, as well as a Fast Poll Mode, and also a Check-in Interval.
As I understand it, the purpose of the poll intervals is for the parent (controller) to determine how to handle timeouts on messages that have been buffered and waiting to send to an end device. The check-in interval sets how often a Poll Control Cluster server (on the controller) sends a check-in command to determine if any devices need to change to Fast Poll Mode for frequent polling to retrieve data from the parent.
I've searched through several of the revisions of the ZigBee Cluster Library Specification documents, however, and don't see anything about a 1 minute polling interval. I do see other defaults, though - from ZCL document 075123, rev 5:
Now if Xiaomi devices are polling my Hubitat controller at a frequency of less than 7.68 seconds, I have no way of knowing, because that information is not passed on to me through logs or any other means. However, I do know all of the Xiami devices I have paired with the Hubitat hub stay connected and continue to send attribute reports well past the 7.68-second mark, and also the 1-minute mark. So I suspect those timeouts are likely not the cause of the devices' paired connection being dropped.
All Xiaomi battery-powered devices send a type of "check-in" report that includes battery voltage data (amongst other data) 50 or 60 minutes after pairing, depending on which type (Xiaomi Aqara or "original" Xiaomi, respectively) and every 50/60 minutes thereafter. What I see in the Hubitat logs is that attribute reports cease shortly before that first "check-in" report.
Regardless of the cause, there is absolutely no way for me to troubleshoot the drop of connection, because I have zero information passed on by the Hubitat hub with regards to the log of the pairing process and any polling / check-in communication. All I have to work with is attribute reports passed on by the main parse() function in a device driver, and that doesn't help.
I specifically purchased the Hubitat hub based on your encouragement to do so here, and also a statement by Check Schwer here that you try to do "minimal filtering of messages" coming to the Hubitat hub.
So I've come here ready to create Xiaomi device drivers reworked specifically for the Hubitat.
But if these devices, which I have had zero problems keeping connected to a SmartThings v2 hub for months, can't stay connected to the Hubitat, then I am completely at your mercy on the first step of working with you (as you encouraged) to get them working with Hubitat hub.
I did some more reading, and I have found a reference to the ZHA 1.2 recommendation that end devices poll their parent every 60 seconds.
A couple problems here with that, however:
First, that recommendation is based on the assumption the end device expects to receive occasional commands or reports from the parent. Not all devices operate that way, and by all accounts, Xioami devices in particular have no reason to expect any commands or reports from the coordinator beyond the pairing process. Even the Texas Instruments Q&A article I link to above states that the 60 second recommendation shouldn't be treated as a rule set in stone:
Section 5.3.4 (End Device Parameters) also briefly mentions polling, saying that 'an end device that is designed to receive data should poll its parent every 60 seconds', which seems to contradict the 7.5 seconds, but that same table (Table 5.4) also contains a 'Value' field for that parameter, which says 'Set by stack profile', so the Stack Profile section (5.2 as quoted above) takes precedence here.
An informal interpretation of all this would be that your end device should operate in one of a few poll intervals depending on what’s going on:
Their example is based on the SE (Smart Energy) specification, but I think their conclusion in that last sentence also applies in this case.
The second problem is that an end device not polling the coordinator every minute should not be a reason to completely drop its connection. I have read that if devices are unable to get a MAC acknowledgment from its parent, it can enter orphan status and start a rejoin process. So again I think the timeout that's occurring with Xiaomi devices paired to the Hubitat hub is not directly related to the 60 second polling interval.
Also, after searching, I don't believe dropping of the Xiaomi devices' connection relates to the check-in interval I mentioned in my previous post. From this Q&A article (again, on TI's website), I read:
If you are using the Poll Control Cluster in HA1.2, there is an additional element named "Check In." This is really an Application layer interval where an end device (Poll Control Server) contacts another node, the Poll Control Client, which does not have to be its parent (and usually is not the parent). The point of this particular check in is to see if there is information waiting at the Client, which can reside there for much longer than if it had been sent "normally" through the parent.
I'm quite sure not all or none of the Xiaomi devices include Poll Control Cluster support, so the polling check-in timeout wouldn't apply.
Regardless, I have emailed support regarding the dropped connection issue.
Thank you for all the effort you are putting into this!
has anyone opened up one of these Xiaomi buttons and see if you can hard wire them to a device?
looking to turn my old non smart roomba vacuum in to a smart one. Would have preferred a zwave device but for the price zigbee will do the job.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
