Ok, I went out to do the groceries, and came back home, and now a whole lot of the zigbee devices have doubles of the sensors, but only in the ZHA config tab. In the integrations tab they are all fine. Looking through the logs i see -
Error doing job: Exception in callback <function async_track_state_change..state_change_listener at 0xaa4c27c8>
and then the detail is:
Error doing job: Exception in callback <function async_track_state_change..state_change_listener at 0xaa4c27c8>
Traceback (most recent call last):
File “uvloop/cbhandles.pyx”, line 68, in uvloop.loop.Handle._run
File “/usr/src/homeassistant/homeassistant/helpers/event.py”, line 85, in state_change_listener
event.data.get(‘new_state’))
File “/usr/src/homeassistant/homeassistant/core.py”, line 342, in async_run_job
target(*args)
File “/usr/src/homeassistant/homeassistant/helpers/event.py”, line 158, in state_for_cancel_listener
if not async_check_same_func(entity, from_state, to_state):
File “/usr/src/homeassistant/homeassistant/components/automation/state.py”, line 99, in
lambda _, _2, to_state: to_state.state == to_s.state,
AttributeError: ‘NoneType’ object has no attribute ‘state’
Everything appears to be functioning fine though. Just providing some feedback if there is an issue others may be having
EDIT: after a reboot the entities have gone back to single sensors
I don’t recognize the error from the log file. But the double sensors and the unresponsiveness, yes… For me the solution… since like 6 hours now… was to do a firmware update.
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.
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?
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
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.
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.
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.
@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.
