This is handy. Any chance of getting it added to the community store (HACS)?
I donāt know what that isā¦ point me towards it and Iāll check it out.
There was a bug in the core that caused some wacky stuff after changing entity ids and a bug in ZHA that contributed to it as well. Both were fixed in the .96.3 release today.
1 Like
Here it is - Custom Component: HACS
Really handy way of adding and managing custom components (including Lovelace card)
Thanks for the quirks update for those xiaomi buttons. they now both have a quirk applied. butā¦ neither of them are firing anything for zha_event. and they both have unavailable senors like this - https://imgur.com/a/xJSb72s
How can I help fix?
And another odd behaviour that i noticed, I use the xiaomi motion sensors with the lux sensor built in. The lux update is very infrequent, and i believe that they send a lux update when motion is triggered. But i have found that it appears they update the lux AFTER the motion trigger. So for example i have a automation for if motion is triggered and its below 3 lx then turn on the light. But what appears to happen is the motion is tiggered, the lx is still well above 30 from earlier in the day, the lux is then updated to 2 and the automation is never fired (as the lx at the time of the motion was above 3). But it only appears to affect one of my sensors. The others are all fine. i have removed and re-added it with no luck. Its the version with the aq2b quirk (i have a mix of the aq2 and aq2b).
I canāt do anything about the order of reportsā¦ thatās done by the device. As for the buttons, iām Not sure what the issue is. Can you set the log levels to debug for ZHA, zigpy and bellows (if you have husbzb-1) or zigpy-deconz (if you have a deconz based radio) and try again and provide the logs?
I believe this is done.
1 Like
Ok, thought that might be the case. I have set a redundant automation that if the LX goes to below 3 while motion is detected then turn on the light. Should remedy. Iāll have a look at how to set those logs up tomorrow
Legend, thanks mate. Taking forever to update the store, Iāll have a play tomorrow
So I have been experimenting with the Xiaomi Aqara Vibration sensors the past few months and have noticed a few changes between HA .94 and .96. Before the vibration sensors had a binary_sensor for vibration and another sensor for vibration type, e.g. Tilt, Drop, Vibration, etc. Now all I see is just the binary_sensor. Either way, I was not able to rely much on those entity states, but rather I managed my automation by monitoring event type āzha_eventā, filtering for the ādevice_ieeeā number of my device and the ācommandā for the value āTiltā, which turned out pretty reliable. However since upgrading to .96, those particular events are no longer available, and only the binary sensor and battery sensor exist for that device. In trying to update my automation, I have been using the binary sensor, but I find it a bit sensitive, and get some false positives, and itās probably due to the vibration type.
Is there away we can expose the vibration type (Tilt, Drop, etc) through the binary_sensorās attribute? This way if the automation triggers from the state change to āonā, it can query whether it was due to a Tilt/Drop/Vibration, and then act accordingly.
I have 2 of these, and I had only seen the binary sensor for them as I only used them with 95.0 and above. Or if we could see the angle of the sensor would be ideal. My use case is having it on a garage door. If itās flat the door is open, if itās upright the door is shut.
2 Likes
Ok, todays question - how is the meshing of the network managed through the zha integration? I have been using the add devices button, but I see if I selected an entity that can act as a repeater from the drop down there is actually an add devices button down there. Does the main add devices option add to the primary controller only or does it choose whichever repeater node has the best signal?
I have just noticed when adding some buttons last night that some buttons disappeared, and Iām thinking I may have hit my device limit if I have to manage the meshing manually. Or maybe I just didnāt add them properly in the first placeā¦
I have 36 devices on my network, 4 of which are power points and one ZigBee bulb which should be repeaters.
You canāt manage the mesh. It is done automatically at Zigbee network layer.
This is more for Zigbee end devices, specifically Xiaomi ones as those work (stay online) only when connected through specific vendor/model Zigbee routers (most mains powered Zigbee devices are Zigbee routers). When you click the add device button from a device drop down, then only that Zigbee Router would allow new devices to be joined. Doesnāt matter if you join a Zigbee router as it would join the mesh and communicate with any other neighbor, however for Zigbee end devices (all battery powered devices) this means that this specific router would become the Zigbee Parent devices for the newly joined end device. In specific cases, like parent not available, the Zigbee End device may choose another parent, in other words you can influence which device would become parent for the new zigbee end device, however you canāt force it to stay with that parent and zigbee end device may decide to pick another parent device.
The main add devices button opens all Zigbee routers on your network, including the coordinator (hub) for new joins. The joining device will (should) pick the strongest device to perform initial join and in case the new device is a Zigbee router, then it just extends the mesh. In case the newly joined device is a Zigbee End Device, then the device through which it initially joined is going to become its parent device.
Super detailed response, thanks for taking the time. You mention Xiaomi devices specifically, and they are what Iām using (I have one IKEA remote, bulb and dimmer, the rest of my devices are all Xiaomi). So should I just be adding them the usual way, or via the device drop down choosing the closest repeating device?
I understand the issue that if that repeater goes offline they will not re-route via a different repeater either way.
As part of the zha_event with the āTiltā command I had mentioned previoulsy, it had a tilt angle value which represented the amount of angle in degrees which had changed. It was an absolute number, so an open garage door would have a value of 90, and a close would also have a value of 90, so you wouldnāt be able to tell direction. Hopefully there is a way this information can be exposed in a useful manner for this device.
Works a treat, thanks mate
So Ikea remote and dimmer (I assume a wireless dimmer, the round one) are Zigbee end devices, so doesnāt really matter. IKEA Bulb holds xiaomi devices fine, so you can add them the usual way. See Xiaomi & Aqara Devices - Pairing & Keeping them connected - Devices - Hubitat, it just when you have those āxiaomi incompatibleā routers on the network, then you would want to be more careful through which devices it joins the network.
1 Like
@dmulcahey I assume itās safe to go ahead and delete any zha.xyz entities from our entity registry post-0.96, right? They are all unavailable and cluttering things up, so the OCD in me wants to clean them up, but I want to make sure itās not going to break anything first. 
Logs - Debug Log - Pastebin.com
That was from a fresh start up, and then pressing both buttons on the dual switch and the single button. I know there is a lot there, but iām not quite sure how much you actually need.
Iāll take a look. You can also adjust the vibration sensitivity. I think there are posts where I explained how somewhere in this thread. If not, let me know and Iāll post it.