Multiple Disarm sent to monitoring center when vistaECP enabled

[jn3va]

My alarm company called because my panel has been sending multiple arm and disarm events (2 arms and 8 disarms), when there should be only 1 each. (attached screenshot). Red highlighted section happens when VistaECP is enabled. Blue is expected/normal.

They had me do a re-load and reprogram of my panel thinking something had gotten corrupted in the panel programming. I had to disable the VistaECP in order for them to be able to download into the panel.

I left the VistaECP disabled and all was normal for 24 hours, so I started thinking maybe the ECP was causing the multiple events. I re-enabled the VistaECP and the multiple arm and disarm event reports came back (see attachment).

Have you heard of anything like this? I'm using a version of the VistaECP from March 2022; so I'm due for an update, but before I do I wanted to check if you've seen or heard of this before?

This is a Vista 21 IP panel. I'm using wiring option 1 (preferred) I have 5800 series wireless devices so I have additional pin and MONITORTX uncommented.

Thanks! Joe

[Dilbert66]

I've seen weird activity like that due to a bad ground connection between the esp and the panel (black wire). It's either that or another bad connection or bad component. Can you view the esphome logs while this is happening?

[jn3va]

Ground looks (visually) like its connected fine, but I can check with a meter tomorrow. Nothing in the ESPHome Logs. Bold Entries correspond to the timestamps in the logs from the monitoring center.

2024-10-25 14:11:28,181 INFO 200 GET /devices (0.0.0.0) 11.92ms 2024-10-25 14:16:28,171 INFO 200 GET /devices (0.0.0.0) 5.28ms 2024-10-25 14:21:28,172 INFO 200 GET /devices (0.0.0.0) 6.42ms 2024-10-25 14:26:28,174 INFO 200 GET /devices (0.0.0.0) 5.28ms 2024-10-25 14:31:28,167 INFO 200 GET /devices (0.0.0.0) 1.80ms 2024-10-25 14:36:28,171 INFO 200 GET /devices (0.0.0.0) 4.31ms 2024-10-25 14:41:28,189 INFO 200 GET /devices (0.0.0.0) 8.00ms 2024-10-25 14:46:28,166 INFO 200 GET /devices (0.0.0.0) 2.01ms 2024-10-25 14:51:28,166 INFO 200 GET /devices (0.0.0.0) 1.19ms

The YAML looks like its set for Debug level, but is that to the USB UART? Is there something I need to set to have it log to the ESPHome Log?

logger: baud_rate: 115200 level: DEBUG

UPDATE: Just realized that the ESPHome integration was not enabled for Debug logging. I've turned that on and will repeat the test arming/disarming and grabbing the logs (from ESPHome as well as the device at the console) tomorrow.

[Dilbert66]

You should be able to connect to the esp via the esphome dashboard using wifi to view the logs. If you can't connect to it then you have an issue with the esp so might want to replace it.

Edit: if you were able to re-upload a new config, then the esp should be ok. You should be able to see it from the esphome integration also. If you can't then there is definitively an issue with the chip.

[jn3va]

I was able to reproduce and capture the logs. I did 2 sets of test to reproduce and confirm.

The Excel file is an export from the alarm central monitoring system with both tests. Rows 5-9 are the second test; rows 11-50 show the first test. For the first test - alarm arming at 14:57:32 and disarming at 14:58:09 with many arming signals being sent. There was only one disarm sent this time. Yesterday there was many disarming signals... and one or only a couple arming.

The ESP log 01 (TXT file) shows the first test - the Arming Stay commands repeating between 14:57:32 until I disarm at 14:58:09 e.g. [14:57:32][D][text_sensor:067]: 'esp_vista Lrr Msg': Sending state '441: Armed STAY user 0'

I did a second test and saw similar results - but not spamming the monitoring center as much. The second test has 3 arming events sent (rows 7,8,9) and 2 disarming (rows 5 & 6)

In the ESP log _02 the arming and disarming events are at 15:24:14 Armed 14:24:15 Armed 15:24:16 Armed 15:26:57 opened the door (FAULT 11 GARAGE) entered disarm code 15:27:01 disarmed 15:27:24 disarmed 15:27:27 Armed Stay user 2 (thats the disarm code at the panel) Restored 15:27:30 Armed Stay user 2 (thats the disarm code at the panel) Restored

These latter 2 (Restored) messages line up better by the timestamps with the alarm log.

I see a 3rd one of these "Restored" messages at 15:27:50 (but the central monitoring only has 3 in their report)

LocationActivity_20241026.xlsx logs_esp_v20p_logs_01.txt logs_esp_v20p_logs_02.txt

[Dilbert66]

Awesome. Tks for the logs. Can you set lrrsupervisor to false. It almost looks like there is a conflict with a real long range radio device.

[jn3va]

With lrrsupervisor set to false I don't get any of the sensor data reporting. I've attached the log from the compile/update and what is logged when running.

There were a couple warnings (lines 31-48) but no errors.
When running it shows the state of the display at the keypad, but then reports an unknown component took too long

e.g.

[08:55:51][I][INFO:688]: Prompt: DISARMED [08:55:51][I][INFO:689]: Prompt: Ready to Arm
[08:55:51][I][INFO:690]: Beeps: 0

[08:55:51][D][text_sensor:064]: 'esp_vista Lrr Msg': Sending state '' [08:55:51][W][component:237]: Component took a long time for an operation (137 ms). [08:55:51][W][component:238]: Components should block for at most 30 ms.

So seems like I need the supervisor to get the data for sensor states etc. Does your supervisor send something back into the ECP? Is there a way for it to be read only? I like having the ability to control the arm and disarm, but would rather have the ability to read the states and lose the control if needed. Or maybe a section of code I can comment out to test?

I'm thinking my next step will be to update to your latest code. Any other ideas before i take that step? logs_esp_v20p_compile_supervisor_false.txt logs_esp_v20p_run_logs_supervisor_false.txt

Thanks!! Joe

[jn3va]

I set the lrrsupervisor back to true and recompiled and I'm still getting the same result (component took too long and no sensor data). I was re-reading your docs and noticed you mentioned a deprecation... so assuming maybe that is the cause.

This library is designed around the "external components" feature of ESPHome The previous version of this library was using the older "custom components" feature which is being deprecated.

So I'm going to pull the latest and start over tomorrow when I have the whole day to work on it.

logs_esp_v20p_run_logs_supervisor_true.txt

[Dilbert66]

No, you do not need the lrr for sensor states. It's only there for extra detail such as armed, disarmed but there are other specific fields in the yaml that do capture and display that data. I should clarify, that it only displays the messages and so it's safe to have on ONLY if you do not already have an existing physical LRR device as they would confilict. One thing I noticed is that you are getting a lot of checksum errors (those are the data packets with 77 in the 12th field). That means you have bad wiring or a bad connection to the panel. The error with component took too long are ok and normal. It's just some extra warnings that esphome added a while back. Also note that you will only see sensor updates when something changes or every 5 or 10 minutes when the esphome refreshes it's updates.

[jn3va]

Thanks Alain! - I'll check it out Monday. I checked all connections were tight and checked continuity on the wires and everything seemed fine.

I wanted to make sure I understand a couple things:

you will only see sensor updates when something changes or every 5 or 10 minutes when the esphome refreshes it's updates

I've been running this for a couple years and I did not see it take 5-10 minutes lag for sensor changes to come through. If I opened a door it was fairly quick - maybe 5 seconds before it showed up in HomeAssistant. Sounds like I see them quickly if a change but they refresh regardless every 5-10 mins?

I noticed is that you are getting a lot of checksum errors (those are the data packets with 77 in the 12th field).

For the 77 checksum error... Do you think that is the VistaECP with a bad connection and its not reading the signal correctly, or could someting else be generating those - possibly the 5800 wireless receiver reporting the errors? Almost all of my sensors are wireless, so I can see there being collisions sending data to the receiver; and I will occasionally get "Check 90" LongRangeRadio communication errors on the keypad that I have to clear manually. I have never been able to fully figure the Check-90 out - its very random. Sometimes it will be multiples per day, other times weeks or months in between. The alarm company tech support says its "normal" issues with the IP communication and probably wifi, EM interference from something (maybe the nearby airport). I suspected it was maybe the alarm monitoring servers going off-line for maintenance, but now I'm wondering if maybe there is interference and the 77 checksum has always been there.

[Dilbert66]

Sorry for the confusion... The 5 to 10 minute refresh cycle is unrelated to panel activity. It's just esphome re-updating ha with the current value of the sensors.

As to the checksums, that is usually related to bus signal errors. Then again, you are running a really old version of the firmware and I have made quite a few changes since then to improve data handling so could be that. The check 90 comm errors are also related to connectivity or signal errors due to the panel not receiving the f9 responses from the esp correctly.

[jn3va]

I'm setting up the new version. You made some awesome changes :-) In the YAML - Can I have both the binary and the text sensors? I previously had text, so wanted to keep those since I have some automatons defined that use them.

I only have one partition, no relays and no expanders so I assume I just remove those from the YAML (e.g. rdy_2, trble_2, ln1_2, ln2_2 etc.

Mainly I'm asking about the zone & sensors section; I've left items like kaypadaddr2, relayaddr_ etc set at "0"

For the text sensors: Is this the correct format (no space between the number and word messages? Or if a space needed? (Documentation has a space but I think that will cause an error so I removed the space.)

• platform: template name: "$name Front Door" id_code: z10messages

[Dilbert66]

Sure, you can use text sensors for the zones like before.. The id code should be z<zonenumber. so it should be

id_code: z10

or simply:

id: z10

As to the partition 2 fields, yes, you can remove them.

[jn3va]

Thanks! I tried to compile, but its throwing errors on these lines from the YAML. Says they are invalid options and check indentation.

input mode control

invert_mon: "true" invert_rx: "true" invert_tx: "true" input_mode_rx: INPUT input_mode_mon: INPUT

autopopulate: true # auto populate seen active zones

Looks like these exist in the VistaAlarm.yaml under the original project but not in the esphome-components project. I commented them out and uploaded, so mostly this one is an FDA for updating the YAML on Git.

[Dilbert66]

You need to point to the "dev" branch of the git source as those features are new there.

external_components:
  - source: github://Dilbert66/esphome-components@dev 

[jn3va]

I'm getting compile errors

INFO ESPHome 2024.10.2 INFO Reading configuration /config/esphome/esp_v20p.yaml... INFO Detected timezone 'America/New_York' INFO Generating C++ source... INFO Compiling app... Processing esp_vista (board: nodemcu-32s; framework: arduino; platform: platformio/espressif32@5.4.0)

HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash

• toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5 Dependency Graph |-- WiFi @ 2.0.0 |-- ESPmDNS @ 2.0.0 |-- Update @ 2.0.0 |-- noise-c @ 0.1.6 Compiling .pioenvs/esp_vista/src/main.cpp.o /config/esphome/esp_v20p.yaml: In lambda function: /config/esphome/esp_v20p.yaml:709:14: error: 'vista' was not declared in this scope return vista.keybusConnected; ^~~~~ /config/esphome/esp_v20p.yaml:709:14: note: suggested alternative: In file included from src/esphome.h:60, from src/main.cpp:3: src/esphome/components/vista_alarm_panel/vistaalarm.h:56:15: note: 'esphome::alarm_panel::vista' extern Vista vista; ^~~~~ /config/esphome/esp_v20p.yaml: In lambda function: /config/esphome/esp_v20p.yaml:715:7: error: 'disconnectVista' was not declared in this scope disconnectVista(); ^ ~~~ *** [.pioenvs/esp_vista/src/main.cpp.o] Error 1 ========================== [FAILED] Took 5.62 seconds ==========================

[jn3va]

I downloaded the components locally, changed the YAML to use the local non-Git version and commented out those few lines (invert_mod, invert_rx etc.) for now.

That throws a ton of errors during the linking stake and exits with an error.

Logs here is you wanted them.
logs_esp_v20p_local_component_failed_linking.txt

logs_esp_v20p_failed_compile_GIT.txt

[Dilbert66]

in your yaml change "return vista.keybusconnected" to "return $panelId->connected();"

Remove, the line and associated section where it has "disconnectVista" in your yaml

This is all like in the example yaml from dev.

[Dilbert66]

Try doing a clean also. I suspect you have some errant old code hanging around in the build directory

[jn3va]

I pulled a brand new yaml and repopulated it fresh, but I was using the one from master and not dev. I just pulled the dev and will compare line by line and try again. Thanks!!

[jn3va]

Getting closer but still errors -

I updated to the dev yaml file I removed the optional button section

When I compiled it threw errors about the web component (see logs_esp_v20p_failed_compile_dev.txt)

I commented that section of the YAML out (attached) and tried again - this time a different compile error. (see logs_esp_v20p_failed_compile_2_dev.txt)

Just for kicks, I tried to compile again but got a completely different errors each time. see logs_esp_v20p_failed_compile_3_dev.txt see logs_esp_v20p_failed_compile_4_dev.txt

I'm done for the day - my night to cook. I'll pick this up later tonight if time, or tomorrow. Thanks! for your help! (and awesome work on this project!!)

Compile Error Logs logs_esp_v20p_failed_compile_dev.txt logs_esp_v20p_failed_compile_2_dev.txt logs_esp_v20p_failed_compile_3_dev.txt logs_esp_v20p_failed_compile_4_dev.txt

Current YAML esp_v.yaml.txt

[Dilbert66]

Ok, the first compile error was due to a bad file I had on the repository that I fixed a few minutes ago. The other errors you are getting, well, I have no clue whats going on there. Looks like your GCC compiler in your esphome instance can't handle the compile. It is some weirrrrrrrd stuff. Never seen it. What platform is your HA running on ? I don't know if your running out of resources or what... You can maybe try restarting the ESPHOME add on and see if that fixes it. The issue is definitively related to your ESPHOME build environment (docker addon)

Anyhow, a swell mystery for sure. Whats for dinner! Bon appetit!

[jn3va]

Partially working!

Compile issue - I think there must have been some old files, libraries etc. in ESPHome that were getting mixed in with the new. I used my original ESPHome device, yaml file name, API key etc. trying to preserve the old name to not break automations. I think it was compiling using some of the old local components as well as the new GIT linked components. That was causing the linker to exit with an error. I created a new ESPHome device with a unique name and yaml file. I did reuse the IP and the API key and after that I was able to get it to compile and link and its running now... but it is not reporting any of the sensor states.

It does see the keypad output and reports that correctly for lines 1 and 2. Also good news - the alarm monitoring so far is not getting multiple arm and disarms reported from my panel any longer!

sensor states - I opened and closed the basement door, and unlocked and locked the basement door - the panel lines 1 & 2 show these changes (_zones log file) lines 213-301 but the binary sensors never change state and I don't see any indication in the esp log output with the "O" or "C" like the old version. Any ideas on this one?

Unlocked door = Fault 13 (line 213) Open Door = Fault 15 (line 242) Closed door (line 383) locked lock (line 301)

One setting I was not sure about and did not change in the YAML is auiaddr: "2"

*189 shows below when I review.
AUI 1 2 5 6 00

I don't have any touch screen keypads. Do I need to change this to 0 in the YAML? or to 2 in *189? Or do I have something incorrect with the binary sensor zone definitions in the YAML?

logs_espvista21_zones.txt

espvista21.yaml.txt

[jn3va]

I unplugged the panel and the AC status changed so it is reading, reporting some binary sensors correctly.

On the rfseriallookup: line I have them defined as 7 digits. e.g. 0447462:2:10 All my sensors start with an A e.g. A044 7462 Could the A be needed?

[Dilbert66]

if You want to use text sensors for the zones (show o/c), you need to setup the zxx id's in the text sensor section, not in the binary_section. Right now you have them as binary sensors which only show on/off. As to the sensor I'ds, you should not have an A as the system wants a decimal serial number. I don't have any here so can't confirm the numbers. I just created the code using someone elses test results.

It's also ok to leave the AUI as 1 or 2 as the system emulates a keypad to get extra data.

[Dilbert66]

Can you recompile again. There was an issue yesterday that prevented the esp from loading the zones correctly.

[jn3va]

I recompiled but no change. The first time I saw it pulled in changes for 2 cpp files. No change in sensor states. I tried a "Clean Build Files" in ESPHome so it would pull everything down and recompile; but still no change.

I'm OK using binary sensors. I've changed the ESP device name, so I need to touch all the automations anyway. All good - and using the binary sensors I think will give a better experience with HA since it has defined icons for the on/off states.

[jn3va]

It's also ok to leave the AUI as 1 or 2 as the system emulates a keypad to get extra data. What should *189 have in it? It sounds like that it needed for this to get the zone status. I'm not familiar with 189 so not sure what it should look like. Normally the top line is just description, so I assume its telling you that addresses 1,2,5 & 6 are options. When I use #189 (show value of field 189) it beeps, shows 01 05 00 then 3 beeps. I tried setting the address to "5" in YAML but no change.

[Dilbert66]

For 189 depending on your panel type, you can have either 2 or 4 AUI's. You might as well enable both 1 and 2 so enter, 1,1 for assigning address 1 to partition 1 and address 2 to partition 1. you can enter 0, 0 for the last two if it accepts it. You don't need this to get the zone status. This is an extra function I added to be able to immediately get the close status of a zone. Normally for the build in panel zones, you need to wait up to the TTL time (30 seconds default) to determine a zone is closed. With the AUI keypad function, i can query the panel for the zone status. It's not a requrirement. Just a nice to have.

[Dilbert66]

Ahhh. Ok, I see the issue. You missed one change. Use template_alarm. You need to use "template_alarm" instead of "template" for all alarm fields. That is custom code. Look at the example fields in the yaml.

# zone id code = z+zone number
  - platform: template_alarm   <-------------- here
    name: "Workshop Fire"
    device_class: smoke
    id: z2
    publish_initial_state: true   

[jn3va]

Good eye on the template_alarm. Sorry I missed that! That fixed it. Sensors report when there is a change now.
But many still say "Unknown" I assume that will refresh over time but its been about 15 minutes and any that I did not trip manually (like opening and closing a door) still say unknown. I'll keep monitoring... Its not a huge issue, but I have glass-break and fire sensors that might not update since there won't be a change in state for those - hopefully! :-)

Before I fixed template_alarm everything looked "normal" and showed "Closed" or "Clear" so maybe the publish_initial_state is not working or was removed in this version. I noticed the YAML does not have that in the example on DEV version (but did on the MAIN)

DEV

• platform: template_alarm id: z1
  name: "Front door z1" device_class: door

main

• platform: template name: "Front door (z1)" device_class: door id_code: z1 publish_initial_state: true

====== I also dug up some documents and watched a couple you-tubes... My alarm company uses AUI 2 for remove access and for something called tuxedo - I think that is mobile app integration back to the panel (I don't subscribe to that - don't need to thanks to YOU! :-) but they have AUI 2 configured for remote by default). Might be something to mention in the YAML comment or maybe use 5 instead to avoid conflicts

For enabling AUI 5 - I saw 01 05 00 when I checked field 189. What the panel was actually showing me was 01 then 05 then 00 then 00 for AUIs 1, 2, 5, & 6 (I just did not realize since the last two were both 00). So I had to reprogram it so #5 is active. You might want to have people use 5 instead of 2 in case anyone else has something similar set up with their monitoring company. To program it to use 5 (or 6): On the keypad press #180 to see the current values (e.g. 01, 05, 00, 00). Then press 189 and enter 1 5 1 0. This will enable AUI address 5 for partition 1. If you had wanted to enable address 6 instead you'd enter 189 1 5 0 1

[Dilbert66]

I have an older panel so my program 189 only supports 2 aui so there is no address 5 availabe so I can't suggest that to others. The programming is different then on yours. If you enable 5, then go ahead and use that in the yaml also. Also the publish initial state is done in the background with template_alarm so you don't need to add it. Which sensors say unknown? Everything should be initialized on startup.

[jn3va]

All of the sensors still say unknown, with the exception of doors that have been opened. Anything I should check or try?

[Dilbert66]

I'm at a loss as i can't duplicate the issue here. The system is set to publish all values on startup. Can you post your updated yaml so we can have a look?

[Dilbert66]

You can perhaps try and refresh the esphome record on HA for this device to make sure the field names and id's are re-synced.

[jn3va]

I removed the "publish_initial_state: true" from the YAML and recompiled. All is working 100% now! States no longer show unknown and states change withing a second or two of a zone change. Thanks again for your help and the awesome work on this project.

Since this is the DEV branch. Is there anything I should watch for in terms of changes. Something I should subscribe to or monitor on Git so know know when you make changes; before I update the device in ESPHome monthly... just in case :-)

[Dilbert66]

Glad you got it working ! Not sure why the publish initial state was causing the issue for you? I'll test that out. It should not have mattered as it's done from the python init code by default.

As to the dev branch changes, if things are working ok, I would suggest you change the "refresh: 10m" option under external_components to "refresh: never" and only change to 10m when you actually want to update it. With refresh never, it will not fetch update changes on its own unless you tell it to. Safer that way in case I publish changes that can break things which I've been known to do occasionally :)

[Dilbert66]

Ok, I did find the issue with the publish_initial_state and have corrected it. I had missed pushing a change to dev.

[jn3va]

Awesome - thanks again for your help troubleshooting and getting updated!