For all those with lights going into “unavailable” state, enable debug logging for
zigpy
bellows
zigpy_deconz
homeassistant.components.zha
and do the following tests:
-
While light is “unavailable”, go to Configuration -> ZHA -> Pick the light from the Device Picker -> Select “OnOff Cluster (type: In)” -> select “On_Off (id:0x0000)” attribute of the selected cluster and click on “Get Zigbee Attribute”. Do you get a value or do you get
None
-
From Configuration -> ZHA -> pick the light from the device picker and note device
NWK
address and Light’s entity_id, for example in my case nwk is0xae8e
and entity_id islight.dwn_garage_entrance_2
. Filterhome-assistant.log
likeegrep '(0xae8e|light.dwn_garage_entrance_2)
home-assistant.log >filtered-log.txt`
THe filtered log is still going to be noisy, but what are you looking for is:
- light being polled every hour
- whether the poll is successful or not
here’s an example of my log. It was noisy and lines might not be next to each other. In my case there were a few other lines and these three lines of interest:
2019-08-09 00:08:33 DEBUG (MainThread) [custom_components.zha.entity] light.dwn_garage_entrance_2: polling current state
2019-08-09 00:08:33 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xae8e, <EmberApsFrame profileId=260 clusterId=6 sourceEndpoint=3 destinationEndpoint=3 options=320 groupId=0 sequence=74>, 74, b'\x00J\x00\x00\x00')
2019-08-09 00:08:33 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, <EmberApsFrame profileId=260 clusterId=6 sourceEndpoint=3 destinationEndpoint=3 options=0 groupId=0 sequence=152>, 255, -88, 0xae8e, 255, 255, b'\x08J\x01\x00\x00\x00\x10\x00']
the 1st line tells you that light.dwn_garage_entrance_2
entity is being polled by ZHA. During polling, ZHA will try to read On_Off
cluster (cluster id: 6), LevelControl
cluster (cluster id: 8) and maybe Color
cluster (cluster id: 768)
The 2nd line EmberOutgoingMessageType.OUTGOING_DIRECT
this is the request being sent to the light. In that line you should see:
- NWK address of the light – 0xae8e
-
clusterId=6
– On_Off cluster being polled - Data bytes:
b'\x08J\x01\x00\x00\x00\x10\x00'
for those familiar with python bytes representation, note the 2nd byteJ
– that is transaction sequence number and it should be the same in the response.
The third line EmberIncomingMessageType.INCOMING_UNICAST
is incoming traffic and make sure it matches NWK address 0xae8e
and clusterId=6
. And in the response bytes – b'\x08J\x01\x00\x00\x00\x10\x00'
the 2nd byte (represented by J
) is the transaction seq # and it should be exactly the same as in outgoing requests data bytes
So all of you should see polling current state
and EmberOutgoingMessageType.OUTGOING_DIRECT
log lines and either you should get a response INCOMING_UNICAST
usually very shortly after a request or a DeliveryError [0xae8e:<endpoint id may vary here>:0x0006]
. The delivery error message is going to be somewhere between 6 and 36 seconds later after the requests. You are not going to get delivery error immediately.
If you get DeliveryErrors with matching NWK and 0x0006, then the light is off the network. Either physically off or fell off the network.
Another question, with the affected lights, are they powered on all time or are they controlled by physical switches as well?
Also, filter the log for No such device
– grep 'No such device' home-assistant.log
do you get any hits?