Sonoff zigbee PIR reporting 'unavailable'

This is a bit of an odd issue. The setup is HA latest version (2011.???), Sonoff zigbee bridge, Sonoff zigbee PIR, Sonoff zigbee temperature and humidity sensor. I am using the zigbee integration.

Everything works but after about 7 or 8 hours of inactivity, the PIR sensor shows as ‘unavailable’ in HA. It still works though and will trigger. Once it triggers it is reported as '‘detected’ until it flips back to ‘clear’ in HA (ie no motion detected) and after 7 to 8 hrs or so it will start to be reported as ‘unavailable’.

Again, it works as it should but just doesn’t report back to the mother ship.
The temperature/humidity module is working just fine without dropping to ‘unavailable’ but then, unlike the PIR module, it has data flowing at regular intervals.
It almost looks like the PIR goes into low power semi-sleep mode until it is woken up by a motion being deteted. When HA is seeing no activity for a long time it thinks the unit is broken …

I am a bit annoyed with myself as I just ordered 10 more PIR units after testing showed them to work real well. I am hoping that I don’t have to deal with the ‘unavailable’ message on all of these.
I also hope that battery life reports are wrong :frowning:

2 Likes

I am trying to get a better view of zigbee network via ZHA. I wrote some very basic python scripts that others can build on I hope to capture ZHA’s view of the network. My next step is to use a ti zigbee cc2530 with the debugger code flashed to it so drill down into the network from that view. Have a look at some of this first pass code and see if you can finds ways to look into your network and devices. So far, I am still puzzled. I see two different zigbee light bulbs behaving very differently on ZHA network. And some other wall switch devices being unplugged staying online 'as far as ZHA, I think, even though they have been unplugged for hours… and this is a different ‘view’ than I think I see ZHA present to my entities and events views. Maybe similar to what you are seeing.

https://github.com/deepcoder/ha-zha-query-tools

Thanks for the link to you ZHA tools. I will explore this at a later time.
For the time being I am assuming that there is some sort of time-out in HA that says “if you haven’t heard anything in 8 hours then the device must be unavailable”. I do not think it is related to Zigbee but I suppose that the ZIgbee automation could send out the ‘unavailable’ message to HA.
I will do some more digging.
I was sort of hoping that there was some sort of setup parameter somewhere in HA that says -this device will be marked ‘unavailable’ if there was nothing received within x hours. It would be ideal if it could be adjusted on a per entity or device basis.

It doesn’t affect anything (so far) but is just a bit of an annoyance.
I have also set up a polling script in Node-Red to see if I can keep the node available although I doubt it will be that easy to fix this. The required inactivity on the sensor makes it a bit time consuming to troubleshoot.

1 Like

I updated my simple tools a bit, have a look at the ws04.py routine, see if it might give you a starting point.

I do believe that HA sensors do have an attribute that will mark the sensor as ‘unavailable’ after not receiving an update for a period of time, at least for MQTT sensors, which are most of mine. Below is an example that I use, have a look a this link:

# shelly water leak sensor garage 01
  - platform: mqtt
    name: 'Garage Water Leak 01 Status'
    unique_id: "DC:4F:22:76:5A:22-Status"
    expire_after: 3600
    state_topic: "shellies/shellyflood-765A22/sensor/flood"

In the example given, you set the timeout to 3600 seconds or 1 hour ? Does the Shelly sensor report in on a regular basis in less than one hour intervals? I gather that you do not see an ‘unavailable’ message?
The Sonoff temperature and humidity sensor talks to HA quite frequently so it is odd that the PIR only reports when the status changes without talking if things are idle.
I only have the single PIR - it is theoretically possible that it’s “check with the mothership” process is not working right.

I had a look-see at the MQTT documentation and yes, the expire_after is exactly what I see with the Sonoff PIR sensor. I had another look at the ZHA documentation and there is no mention of a timeout that I could find. I suppose it might be accessible via their ‘quirks’ modifications but that is well above my understanding for the moment.

I do need to implement a flood sensor and it sounds like the Shelly unit will be my choice - thanks!

I am sorry to have to clearly spell out my lack of knowledge but …
I copied ws04.py from your github page and put it onto my ubuntu desktop. I opened a terminal window, changed to the Desktop directory and ran “python ws04.py” but with no quotation marks.
The result I get is:
File “ws04.py”, line 151
console.print(“First ZHA data retrieval pass, setting up database”)
^
Any idea what I have done wrong?
edit: the little ‘hat’ sign should be under the ‘t’ in ‘print’

I have found a bunch of reports of devices becoming unavailable. I have enabled all kinds of logging and will see if I can see what actually happens when the device becomes unavailable. I will post updates if I find out anything worthwhile.

In reverse and probably random order to you points :wink:

Probably my poor python skills causing you problem. Here is my brain dump…

make sure you are running via python 3 and not python 2, world is a python transition and not sure where everyone is.

run ‘python3’ with nothing else and may sure you see:

Python 3.8.5 (default, Jul 28 2020, 12:59:40)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

basically some version of 3 should work.

quit()


I think I got a little too fancy with a python library to colorize the output to the screen.

try:

pip3 install rich
pip3 install web-socket-client

then

python3 ws04.py

(fingers crossed, hopeful!)

so far I am pretty happy with the Shelly hardware overall. I have yet to need to rely on the Shelly Flood sensor. But if you have a good wifi system in place, I think it is a good route. That said, this is a perfect use case where lower power long battery life zigbee end devices should shine. After my one test unit from Shelly, I bought a set of additional flood sensors, but have yet to install them.

In the picture below is a report on how often the shelly flood reports it’s battery status. Trying to address a couple of your questions. So, basically the Shelly flood reports it battery status about on average say once a day. So putting a ‘expire_after:’ of less than 86,400 seconds (yes the MQTT unavailable timeout is in seconds) would be unhelpful for the Shelly Flood. My bad for my original example.

I do not thing the availability of the ‘expire_after:’ options for sensors is consistent in HA. MQTT sensors YES, ZHA sensors, I do not think so. SUX!

I struggle with this ‘monitoring’ problem. I have cobbled together a mess of several solutions that monitors whether different sensors are running or not. HA could really do a better top down solution for this. Hoping!!

So, if you can figure out my crappy code ws04.py running, hopefully it will give you a view into your PIR sensors. I have two different PIR sensors that I am testing with ZHA.

In the picture below, I have a Ikea motion sensor and a Aqara motion sensor attached to ZHA. Both, from a back of the envelope standpoint, seem to be working fine. The picture shows that both are attached directly to the coordinator, both are ‘online’, and the Ikea last spoke with the coordinator 119 minutes ago, and the Aquara spoke 24 minutes ago. Both seem correct, as this about about the period since a human as near either. Now, both MAY wake up and talk to the coordinator for other reasons, say battery level or light level or something else. So you need to combine this ZHA web socket view of zigbee sensors with the HA state change and event change info to get a more complete picture. Complicated? Yes!

To your point, of checking in with the mothership, this is why I am trying to collect ZHA info over time with my little python programs. in theory, ws04.py should collect ‘check in’ time info over time, so you can see how often your various zigbee sensors say ‘hello’.

Turns out that both ‘rich’ and web-socket-client were not installed. I installed ‘rich’ without problem but trying to install web-socket-client received a ‘could not find a version that satisfies the requirement web-socket-client’.
Obviously, trying to run ws04.py resulted in an error (module not found error: no module named ‘websocket’)
Oh, yes, running ‘python3’ gets the right reply.
ZHA apparently has a number of logs available. I have (I think) enabled them but so far I have not found a place to view them :frowning:

On a hunch I tried installing websocket-client (without the extra hyphen) and that worked. Unfortunately it resulted in a bunch of errors with the final one being ‘connection refused’.
I am not running SQLlight on this machine … that may be one issue.
The other is this from your git page

HOME_ASSISTANT_IP = "localhost"

Add a Home Assistant Long-Lived Access Token and IP address of your Home Assistant server in the code of each program, variable is:

ACCESS_TOKEN = ''

I have no idea what to do with these but no, I am not running this on the HA machine directly (not sure I want to use my 11 ft pole to touch an experimental program on a production server)