Thats what Im saying Shoutout to all new users, use xiaomi with tradfri outlets 
1 Like
Simplest way for sure for consistency.
There is a very thing I'm very curious though.
The driver code is the same the only difference is the radio repeater itself. One uses Nortek Radio the other whatever radio they have built in. There is no Xiaomi changes on HW side.
So the question is why does this middle man is able to get the correct information from the Xiaomi devices and than send it to the Nortek Radio. More doing it in a bilateral way.
Yes, but with no other outlets, because xiaomi will fail, my wife loves the ST v2 for the coffee maker... no, I can't use a Tradfri, she will kill me... so I had to create a second mesh for xiaomi.
Good question, but I was using xiaomi without any repeaters and it worked.... so the Nortek stick is not the problem.
So what's the problem?
Saying to me that's because they are not 1.2 is rather vague.
Because if it is not the Xiaomi HW as it works through the outlets and in most cases directly to the HE.
Is not the code. It does work for many users.
If as you suggest is not the Nortek Radio.
It is not for sure the all party go IKEA outlet.
I think this is the best answer
1 Like
That's exactly what I mention above...
I think most of us are looking towards Xiaomi as their devices are cheap, look good, and, for most of us, reliable. But are there any companies offering comparable devices (that are officially supported) for a similar price ?
Nope
1 Like
One thing to keep in mind, If all you want to do is run Xiaomi devices with your hub along the Tradfri outlets and no other Zigbee repeaters you may be OK, but if you have any repeaters not specifically known to be Xiaomi compatible within radio range (like Iris SmartPlugs or just about all the common Zigbee HA 1.2 repeaters) you have to take care to make sure that your Xiaomi's don't join the network through them... because they will, happily, for an hour or two... and then because of the incompatible check-in timings they will get evicted by whatever incompatible router they may have joined. And because of an additional incompatibility in the re-join process they will become orphaned. It leads to a flaky and frustrating experience until you figure out what is going on.
You can work around this by selectively powering down incompatible routers (at least the ones in radio range) when you join your Xiaomi's, but you need to keep an eye on them should you have a power failure or any other scenario where they could be prompted to join an incompatible parent router.
1 Like
The problem is most certainly the Xiaomi devices (or their firmware, I guess). They don't follow the standard ZHA method of asking to rejoin the ZigBee network if they've been "asleep" for too long. The problem is precisely that they aren't ZHA 1.2 You've indicated multiple times that you understand this problem, but you keep repeating the question, so perhaps this part wasn't clear. Because they don't properly ask to rejoin, a standard ZHA 1.2 contoller or routing device generally won't let it back on. This is "solved" on SmartThings, Hubitat (they made modifications to their ZigBee implementation very early on), modified Home Assistant ZHA, and other places by increasing this "timeout" so that the Xiaomi devices don't need to ask to rejoin at all. Hubitat can control what their hub does, but they can't control what third-party repeaters do, many of which do not have this long of a "timeout." I'm not sure exactly what the ZigBee spec calls for, but experience shows that this varies from device to device, and it's something the manufacturer decides. Hubitat can't control that--but they did the best they could with their own hub. 
I hadn't heard of the Aqara devices being ZigBee 3.0. Is there more information on this somewhere? If so, if they are truly standard, they should fall back to ZHA 1.2 and work with Hubitat--and any router--without problem. But the bulk of Xiaomi devices out now are likely older models that do still suffer from the "rejoin" problem on standard controllers. Maybe someone can test a 3.0 device to see if it works without extra effort.
1 Like
Tried a Xiaomo button with a Tradri switch in-between the hub and the button. Fell off the network and stopped responding. Not worth the $5 difference in the SmartThings button.
They show up on the list of certified products of the ZigBee alliance. You need to the search by the Mft (Lumi).
This is the part I'm struggling with on the standards there is no reference to time limits for end devices unless I saw on the wrong place. https://www.zigbee.org/download/standard-zigbee-home-automation/
As far I understood it's the definitions of the Zack stack that defines the time limits for which it it accepts connections and responses.
Taking that in consideration if you tell me that's it's the current custom baked stack implementation that is not very tolerant to some Xiaomi devices. It's ok.
However that's different than saying that is not 1.2 compliant.
So far I have heard a lot of people saying here that they are not 1.2 compliant but not one single person was able to pinpoint exactly where they are not complaint.
For Example as per standard xyz the end device needs to report at this specific intervals.
Not questioning what you are saying, truly not, what I'm saying is for me the information that has been shared is still not enough. I need more details to be convinced. Just that.
The Tradfri switch? I don't think there is an IKEA switch. You mean outlet?
1 Like
Yes, you knew what I meant.
Thanks.
Did both fall off?
Only the button stopped functioning.
It was less than 24 hours.
I received it as a trial from a friend.
So I'm glad he let me borrow it.
I have a ST door contact that is sometimes temperamental, doesnt mean I wont buy another, some devices have hiccups. But my xiaomi door contacts are rock solid and farther away from repeaters
1 Like
I am not endorsing, nor defending Xiaomi devices in any way, but there is one facet to consider for anyone who has experienced issues with Zigbee devices "dropping off" or failing to report events. For reasons unknown, the HE Zigbee stack will just stop communicating with random devices nor will it send out route discovery requests to try to reestablish communications. That behavior has been verified with Zigbee packet captures.
What is not known yet is what causes it to occur. Clearly its not affecting everyone, however it is also possible that in many cases, random device disconnections are being falsely attributed to "mesh issues", i.e. having smart bulbs, inteference, defective device, etc., as those are all known causes. However, now it is known there is at least one other factor involved.
I have also identified a fairly reliably test and recovery procedure that works for Zigbee outlets. It's quite simple. If the following procedure restores connectivity to your plug, chances are you're experiencing the same bug as I am.
- Open the device page for the unresponsive plug. Veritfy that it is not controllable.
- In a seperate browser tab, go to Zigbee Settings and disable Zigbee (choose disable, click update)
- Wait 5-10 seconds after the page loads confirming Zigbee is offline.
- Enable Zigbee (choose enable, click update)
- Wait about 5 seconds after the page loads confirming that Zigbee is back online.
- Go back to the device browser tab, and try controlling the device. Click on/off (or off/on if the device is currently turned on). If the plug doesn't respond within a couple seconds try again. The plug should become responsive again within 2-3 cycles.
I have also confirmed this will temporarily restore reporting for end devices that connect to an affected plug. The only way to know which end devices are routing through a specific router is to map your mesh.
Hopefully support can get this figured out. Perhaps a fix for this issue will help those with using Xiaomi devices.
4 Likes
