Inexplicable 'Unknown/Unavailable' Status After Alarm State Change

[j3tang]

Whenever the alarm status changes, something is causing it to go into ‘unknown’ or ‘unavailable’ states.

While in ‘disarmed’ state, when I leave the house, it becomes ‘armed_away’, or vice versa when I return home. In HA, I have an automation that notifies me of the changes of the alarm state and so in the example below, on returning home while being away it will go from ‘armed_away’ → ‘disarmed’ → ‘unknown’ → ‘disarmed’

The view from my phone as HA notifies of state changes:

Below is the log from ESPHOME where while it was in the armed_away state being disarmed. You'll also see I walked in front of a couple of wireless motion sensors. However, I don't recall at what point I triggered those motion sensors -- before or after the "unknown" state.

alarmLog.txt

Below is a copy of the vistaalarm.yaml, with a few small bits like wifi, disarm code, etc. removed.

vistaalarm.yaml.txt

I'll also add into here the issue about the status of all the sensors flipping to open and back to closed. I have a door contact that's part of the alarm system which when opened will trigger an automation in HA to send a notification to me every time. It did not trigger in the event above, but seems to happen almost every time when the alarm status changes. This is just a hunch, but it feels like what's happening when the system goes into this unknown/unavailable state, it also causes the contacts of the system to the ‘open’ state before switching back to what the true state of it is (closed or otherwise).

[Dilbert66]

I had a good look at your log and I do not see any disconnection or invalid statuses being sent. Very clean log, no noise. Maybe there's a hardware issue somewhere that's intermittent but this log doesnt show any issues at this time. A couple notes about your yaml config. You can remove the autopopulate: entry. That was only a test I was doing and should not have been pushed. It doesnt work right because of how ESPHome works. It's deactivated anyhow.

Secondly, you might want to consider adding the "auiaddr" entry. It is used to poll the panel for sensor close events when detected. It will allow the esp and ha to detect closure events almost immediately instead of depending on the TTL timeout. You can use address 1 or 2 as they should already be active on your system.

auiaddr: "2" #AUI address from program field *189 to use for zone status queries. Ensure it is not assigned to a real touch keypad.

[Dilbert66]

You can also post a log of the system going from disarmed to armed to see if any issues occur there.

[j3tang]

Did the arming sequence and this time I see that the door contact mentioned above that gets the notification when it opens, did occur. The corresponding arming log is here for review: alarmLog_armedaway.txt

During the countdown after being armed, at "May Exit Now 11" the wireless motion sensor (zone 11) was triggered even though there wasn't anyone there. Then at "May Exit Now 10" it happens again but this time with zone 10 and 11 triggering. Then at "May Exit Now 9", zones 9, 10 and 11 are triggered ... the pattern continues down to when it counts down to 1 and all zones from Zone 11 down to Zone 1 all gets sent. And yes, I have 11 zones on the alarm system so all 11 of them are triggered. That must be why I'm getting that notification about the door contact being open.

Ok, but there's more!

After I recorded that portion of the log, I disarmed the system while I was sitting at my desk posting this. I thought it was odd that I didn't see any "unknown" / "unavailable" state updates. So I walked out of my room and triggered some motion sensors (zones 9 & 10) and I immediately got notification on my phone about an alarm status change that went from the disarmed state that it was originally in, to unknown, and then back to disarmed. So it seems like after an arm/disarm status, the first time afterwards you trigger a sensor (motion or door contact) it will cause this unknown state to occur.

Part 2 of the ESPHOME log is here for review: alarmLog_armedaway_part2.txt

There's a line that looks like it's sending an empty state. Is that what's causing the "unknown" status? [09:43:26][D][text_sensor:064]: 'Zone Status (zs)': Sending state ''

The chronology of things in terms of the notifications can be seen here:

[j3tang]

I had a good look at your log and I do not see any disconnection or invalid statuses being sent. Very clean log, no noise. Maybe there's a hardware issue somewhere that's intermittent but this log doesnt show any issues at this time. A couple notes about your yaml config. You can remove the autopopulate: entry. That was only a test I was doing and should not have been pushed. It doesnt work right because of how ESPHome works. It's deactivated anyhow.

Secondly, you might want to consider adding the "auiaddr" entry. It is used to poll the panel for sensor close events when detected. It will allow the esp and ha to detect closure events almost immediately instead of depending on the TTL timeout. You can use address 1 or 2 as they should already be active on your system.

auiaddr: "2" #AUI address from program field *189 to use for zone status queries. Ensure it is not assigned to a real touch keypad.

Thanks for reviewing, I've removed the auto populate and added the auiaddr entry, uploaded and everything seems ok. Upon installing new .yaml, it said something along the lines that it couldn't reconnect and will attempt to continue to try in the background, but almost immediately it connected back.

I think I felt a bead of sweat beginning to form on my forehead the moment I saw that it couldn't connect ...

And just to continue the notification updates, after the install of the edited yaml, the system went into 'unavailable' state and then back to 'disarmed', which is what it was prior to the uploading the edited yaml. After that, when I left my seat and triggered a motion sensor (the first time after the status change), it also went into 'unavailable' and then back to 'disarmed'.

[Dilbert66]

ahhhhh, ok. I see the issue! When your panel is counting down the exit delay, the esp code sees the count down timer as a zone instead of a time left sequence and turns the zone on . I have to adjust the logic to ignore those! That's an odd one.

[Dilbert66]

Ok, here's the scoop! There was 2 different things going on with your system. First, the incorrect zone changes. That was due to the code bug which was picking the count down as a faulted zone. That should be fixed now in the new code I've just pushed to dev. The second thing is the fact that you are monitoring the partitions status which can have various states such as armed_home, armed_away, disarmed and unavailable. "disarmed" is when the system is ready to be armed as there are no open zones. "unavailable" is when there is a zone open such as a motion sensor which means the system is not ready/unavailable to be armed. Some people didnt like me sending "unavailable" so I started sending "not_ready" instead which is seen different in some HA panels. Anyhow, when you see unavailble or not_ready, it means there is a zone open so you can't arm. That's all. Nothing to concerned. That's why when you triggered the motion sensor, the system state went to unavaible. Anyhow, try the latest code and see how it goes.

[j3tang]

Ok, here's the scoop! There was 2 different things going on with your system. First, the incorrect zone changes. That was due to the code bug which was picking the count down as a faulted zone. That should be fixed now in the new code I've just pushed to dev. The second thing is the fact that you are monitoring the partitions status which can have various states such as armed_home, armed_away, disarmed and unavailable. "disarmed" is when the system is ready to be armed as there are no open zones. "unavailable" is when there is a zone open such as a motion sensor which means the system is not ready/unavailable to be armed. Some people didnt like me sending "unavailable" so I started sending "not_ready" instead which is seen different in some HA panels. Anyhow, when you see unavailble or not_ready, it means there is a zone open so you can't arm. That's all. Nothing to concerned. That's why when you triggered the motion sensor, the system state went to unavaible. Anyhow, try the latest code and see how it goes.

I'm a little confused by the 'unavailable' part. I understand the purpose of it, but does this mean every time I walk in front of a motion sensor or open a door, it will cause it to go into 'unavailable'? Because the 'unavailable' does not happen throughout the day as I'm walking around the house. It only happens when switching between disarmed and the various armed states.

edit: I went out and just got home a moment ago, but probably since then you've updated the code and so now I am noticing a little bit different behaviour. From the first 10 minutes of observation, it seems when triggering wired motion sensors or opening doors (since they are also wired contacts) it does not go into 'unavailable'. However, when triggering the wireless motion sensors it will go into 'unavailable' state and then return back to 'disarm' so it looks like only a wireless motion sensor issue? The concern though is that when that happens, it looks like it opens up all the zones. I have an HA automation that captures when zones are triggered. Screenshot below indicates that when that 'unavailable' state occurs, it does it for all zones instantaneously.

Also somewhat strange is that the Shed Door that gets the notification about when it opens, I didn't get that notification even though you can see in the image below that the shed door got "opened".

Also wanted to throw in there that I don't think I've ever seen the system go into 'not_ready'. I think that would make sense rather than 'unavailable', but also at the same time, it shouldn't change the alarm's various armed states. Is it possible for me to monitor a different entity that won't get triggered every time it goes into 'unavailable'?

[Dilbert66]

All zone you show me above were because of the bug. As to the unavailable, again I don't see any issue in the log as to arming or disarming making it go to unavailable state. Only the panel ready status will do that. I'm not sure what you expect here? The system status is describing the status of the panel exactly. You can perhaps write a condition in your panel that if it says "unavailable " to assume it's still disarmed.

[Dilbert66]

Again, only one zone would cause the unavailable, not all zones. If you see all zones showing then there is still a bug somewhere, either in my code or your script so I would need to see new logs again to see what's going on. I can't guess as my system is different than yours. I dont' have count downs, etc..

Edit: The wireless sensors should bevave the same as the wired but then again, it's the panel that dictates what that sensor will be, not my code. If the panel thinks there is an open zone, it's sends out the not-ready flag.

[Dilbert66]

Perhaps, you might want to show the code that displays the panel above so I can understand what you are doing to process the sensors.

[j3tang]

All zone you show me above were because of the bug. As to the unavailable, again I don't see any issue in the log as to arming or disarming making it go to unavailable state. Only the panel ready status will do that. I'm not sure what you expect here? The system status is describing the status of the panel exactly. You can perhaps write a condition in your panel that if it says "unavailable " to assume it's still disarmed.

Oh, so all the sensors opening in that image means I'm not using the new code yet? You mentioned in your previous post to try out the new code. Does that just mean hit "install" on the esphome device and it will download or does the fact that you updated your code already mean that it's live for everyone's use already?

Yes, I will give that a go and see if I can ommit certain status' so that it doesn't provide a notification every time it changes.

[Dilbert66]

Yes, sorry I should have clarified, you need to hit install and it will grab the new code and program it to the esp.

[j3tang]

OK, I did an 'install' and it looks like the reason for all the zones opening up at the same time has to do with my wireless motion sensors possibly?

What you're seeing at the beginning of the log below is me walking towards the stairs on the main floor triggering a couple of wired motion sensors (zone 5 & 6). What you don't see though is me reaching the upstairs to trigger the wireless motion sensors because it looks like it disconnects and the esp reboots. When it completes the reboot, it resets all the zone sensors to when it connects back to esphome and hence the screenshot showing everything getting reset at 12:11

So the log doesn't capture the wireless motion sensors getting tripped, but it looks like I can reproduce it every time I trip a wireless motion sensor.

alarmLog_WirelessMotionTrip.txt

[j3tang]

Perhaps, you might want to show the code that displays the panel above so I can understand what you are doing to process the sensors.

The markdown code for the above screenshot is adapted from this post. Rather than listing automations, etc. it just identifies the zone that is triggered.

[Dilbert66]

Interesting.. Definitively looks to be related to the rf sensor code and it would definitively cause the sensor resets. Can you add this line to your config and re-install:

 rfseriallookup: ""

There's definitively another bug somewhere for it to crash like that. I'm trying to duplicate the issue but can't do it so far. I see from your other logs that it doesnt always crash on all rf sensors so doesnt make sense yet. Looks like it's the rear motion sensor causing it.

[j3tang]

Interesting.. Definitively looks to be related to the rf sensor code and it would definitively cause the sensor resets. Can you add this line to your config and re-install:

 rfseriallookup: ""

There's definitively another bug somewhere for it to crash like that. I'm trying to duplicate the issue but can't do it so far. I see from your other logs that it doesnt always crash on all rf sensors so doesnt make sense yet. Looks like it's the rear motion sensor causing it.

I think it looks like it's the rear sensor causing it only because that's the last one that gets tripped right before I go up the stairs to the wireless ones. You can see that the wireless upstairs ones never register because I think that's what's causing the issue.

I put in the line you recommended and can confirm that it no longer causes any crashes, and I can actually see the wireless motion sensor trip (without it causing crashes).

rfseriallookup: ""

In my yaml configuration I posted above, I actually had the serial number, partition and zone numbers in there, but commented out. Maybe it's time to put them back in .....

# rfseriallookup: "0321880:1:9,0826586:1:10,0302053:1:11"

Everyone in the house is at home, so I won't try to test the alarm state changes, but so far everything seems to be running smoothly. I'll report back once I get a chance to test the alarm state changes.

[Dilbert66]

I'll look to see why it was crashing on yours. It wasnt on mine with no line but who knows. I'll add some checks. Glad we figured it out. Awesome. Logs do help!