search

Dilbert66 / esphome-vistaECP

This is an implementation of an ESPHOME custom component and ESP Library to interface directly to a Safewatch/Honeywell/Ademco Vista 15/20 alarm system using the ECP interface and very inexpensive ESP8266/ESP32 modules .
GNU Lesser General Public License v2.1
124 stars 21 forks source link

Updated ESPhome to 2021.9.0 and zones lost supervision #55

Closed AlexandreUSA closed 2 years ago

AlexandreUSA commented 2 years ago

Last night, I updated ESPhome to 2021.9.0 from 2021.8.2. After a minute or so, my vista 21IP keypads went into bunch of errors. I had to unplug my vistaalarm system to go back to normal. Anyone else got into some trouble while updating to ESPhome 2021.9?

Lot of messages with error code 354 [Comm Fail (log only)] or 383 [Supervision Auxiliary Wire Zone]. All related to zone 9 to 14 (extander)

003 E354 Z107 P0

009 E382 Z009 P1

I restarted the VistaAlarm system today and no more errors on the keypads. However, I still have this log entry in the vistaalarm log:

[13:57:06][D][text_sensor:015]: 'vistaalarm Lrr Msg': Sending state '382: Loss of supervision RPM zone 10'

Do we have an issue here with the latest ESPhome release?

Dilbert66 commented 2 years ago

Are you using the virtual expander or is this extender a physical extender on the panel? When using a virtual expander and you restart, the panel will error since it is not getting a response from the ESP so will generate errors. You clear errors as usual by entering your accesscode then 1 twice.

AlexandreUSA commented 2 years ago

It is a physical extender. No change in my vistaalarm.yaml. I could not clear the errors either using the access code twize.

substitutions:
  systemName: "vistaalarm"
  accessCode: !secret access_code #Only comes into effect if needed for arming and quickarm is not set
  keypadAddr: "19" #set this to an unused keypad address slot. Make sure to enable it in  your vista panel programming

  #esp32 pins:
  rxPin: "22" #GPIO pin to use for data receive (yellow line) 
  txPin: "21" #GPIO pin to use for data transmit (green line)
  monitorPin: "18" #GPIO pin to use for monitoring module traffic such as RF or Expanders . Set to -1 to disable

  # module addresses:
  # 07 4229 zone expander  zones 9-16
  # 08 4229 zone expander zones 17-24
  # 09 4229 zone expander zones 25-32
  # 10 4229 zone expander zones 33-40
  # 11 4229 zone expander zones 41 48
  # 12 4204 relay module  
  # 13 4204 relay module
  # 14 4204 relay module
  # 15 4204 relay module
  expanderAddr1: "0" # 1st zone expander emulator (4229) address to use . Set to 0 to disable. 
  expanderAddr2: "0" # 2nd expander emulator address to use . Set to 0 to disable. 

  relayAddr1: "0" # relay module emulation (4204) addresses. Set to 0 to disable
  relayAddr2: "0"
  relayAddr3: "0"
  relayAddr4: "0"
AlexandreUSA commented 2 years ago

I should add that the message [D][text_sensor:015]: 'vistaalarm Lrr Msg': Sending state '382: Loss of supervision RPM zone 10 is gone. I did arm, disarm the system and it got replaced with the latest LRR message. [D][text_sensor:015]: 'vistaalarm Lrr Msg': Sending state '441: Armed STAY user 3 Restored'

I think I am good now but I have no idea why the system did not like the update last night and why I had to unplug it.

Dilbert66 commented 2 years ago

Are you using the latest dev version of the code? I assume you are. The only thing that I can think of is that some spurious data got sent on the bus (or the line was held high) by the ESP during the update that created interference on the system while the panel was talking to one of the extenders so generated the error. I've never seen the issue but I will do some testing with my logic analyzer to monitor the bus during an update to see if I can spot any such problem.

AlexandreUSA commented 2 years ago

Yes, I am using the latest dev version of the code. I could not recreate the issue. I did reinstall the firmware on the ESP32 again to see and all seems fine. I will keep monitoring but so far so good.