For all those with lights going into “unavailable” state, enable debug logging for
zigpybellowszigpy_deconzhomeassistant.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
NWKaddress and Light’s entity_id, for example in my case nwk is0xae8eand entity_id islight.dwn_garage_entrance_2. Filterhome-assistant.loglikeegrep '(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?