I have this portion of code amongst other scripts, etc. associated with home security in a separate “package” that’s pulled into the main config through ‘includes’.
From the disarm state, I’m able to arm to any of the 3 other armed states. However, from the armed states, I am unable to ‘disarm’ though. Nothing in the system logs suggests there’s anything wrong with the yaml, my secrets file does indeed have a matching entry for the actual 4 digit code, is there anything wrong you can spot?
edit: I should also add that when I go into developer tools and then actions and use the following, it does work properly:
action: esphome.vistaalarm_alarm_disarm
data:
code: "my 4 digit code"
partition: 1
edit: in regards to the publish_initial_state, should I be putting that line back in for each zone?
The service works fine for disarm. The issue has something to do with how HA handles variables from secrets files I believe. It’s nothing I can really offer help with as I don’t use ha that way.
As to the publish_initial_state, no, you do not need to add it back. It’s done in the background already.
Thanks for that, it confirms I’m not going crazy!
Everything at the moment seems to be working like it did prior to me trying to update. I managed to get the wireless motion sensors back up and running by going to all the sensors themselves and popping the batteries out and then back in. Not sure why this did it, but a full shutdown of the system by unplugging AC and battery didn’t do it.
Again, thanks for all the help and creating/maintaining this component!
edit::ok, another quick question! now that the system has been online for good amount of time, I notice that it does tend to lose connection every so often but would reconnect almost immediately. I’m not 100% sure, but I think the below is one of those instances where it may have disconnected?
[13:59:13][W][component:237]: Component vista_alarm_panel took a long time for an operation (125 ms).
[13:59:13][W][component:238]: Components should block for at most 30 ms.
I can see that it will be in the ‘disarmed’ state and then for a short moment go to ‘unavailable’ or ‘unknown’ (and I’m not sure why it could be one or the other), and then once reconnected it would go back to being ‘disarmed’. is there a way to avoid the state change for these brief disconnects, aside from my end with the wifi?
I’m still not getting anything on the bus. Something’s wrong and I must be overlooking it. I bought these ESP32s and soldered one to howardchen3’s PCBA. I’m using USB for power. The soldering came out well this time I don’t think that’s the issue.
I’m sure I’m missing something easy. I’d appreciate any help getting pointed in the right direction.
#for documentation see project at https://github.com/Dilbert66/esphome-VistaECP
substitutions:
name: "vista20p" #unique network name, system name
friendlyName: "Vista 20P Alarm" #used as the friendly name of your application in HomeAssistant
panelId: "Vista20P" #used as the service variable name.
accesscode: !secret access_code
vista_alarm_panel:
id: $panelId
accesscode: $accesscode #Only comes into effect if needed for arming and quickarm is not set
maxzones: "48" #maximum amount of zones that your panel supports
maxpartitions: "1" #maximum amount of partitions that your panel supports
# Enroll your RF serial devices here. Format: serial#:loop#:zone# Each record is comma separated.
# For most devices loop1 is used such as 5800pir, other devices such as 5816 will use loop2. Please refer to your
# RF device programming (*56 program) to see what loop and zones are assigned to your RF devices.
# You can refer to the pdf link below for more details on loop numbers
# https://advancedsecurityllc.com/wp-content/uploads/5800%20Wireless%20Device%20List.pdf
#
# Note: These entries are used to identify and report immediate open/close/battery
# activities directly from your RF devices, bypassing the panel. This is beneficial
# since the panel only reports open events to the keypads. The firmware will work fine
# without these entries except you will have a delay of TTL milliseconds before
# the report of closed zones.
### I don't think I have this
#rfseriallookup: "0019994:2:66,0818433:4:22,0123456:1:55,0399512:1:17" # serial1:loop#:zone1,serial2:loop#:zone2
defaultpartition: "1" #set to your main partition
vistadebuglevel: "3" #component debug level for messages
#assign a new virtual keypad address to each active partition using programs *190 - *196
#and enter it below. For unused partitions, use 0 as the keypad address.
keypadaddr1: "17" #partition 1 virtual keyapd
keypadaddr2: "0" #partition 2 virtual keypad. set to 0 to disable
keypadaddr3: "0" #partition 3 virtual keypad. set to 0 to disable
auiaddr: "2" #AUI address from program field *189 to use for zone status queries. Ensure it is not assigned to a real keypad.
##esp32
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
###input mode control
invert_mon: "true"
invert_rx: "true"
invert_tx: "true"
input_mode_rx: INPUT
input_mode_mon: INPUT
##esp8266
#rxpin: "5" #GPIO pin to use for data receive (yellow line)
#txpin: "4" #GPIO pin to use for data transmit (green line)
#monitorpin: "14" #GPIO pin to use for monitoring module traffic such as RF or Expanders . Set to -1 to disable
#note for the vista128 and vista250, the expanderaddr and relayaddr addresses must be 0
# 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"
ttl: "30000" # time to live in ms for zone/fire status before expiring;
quickarm: "false"
lrrsupervisor: "false" # set to true if we don't have an LRR monitoring supervisor we can emulate one to get the statuses
clean_build: "false" #default is false. only set to true if getting duplication errors in linking step. Once you compile, reset it back to false.
esp32:
board: nodemcu-32s
framework:
type: arduino
version: recommended
#esp8266:
# board: nodemcuv2
# framework:
# version: recommended
#location of alarm panel code. You can use the github release version or
#copy the code to directory "my_components" in your main esphome directory
# see here for more info: https://esphome.io/components/external_components
external_components:
- source: github://Dilbert66/esphome-components@dev #uncomment to use github repository
#- source: my_components #uncomment to use local directory
components: [vista_alarm_panel,template_alarm,web_keypad,mg_lib]
refresh: 10min
## web keypad component
## each included files will be downloaded automatically and compiled within the flash.
## there will be no need for internet access when running.
#For www.js build details and source: https://github.com/Dilbert66/esphome-webserver-custom/tree/keypad
#Component source: https://github.com/Dilbert66/esphome-components/tree/keypad/components/web_keypad
### Note: this is an ESP32 only component. The esp8266 does not support the resources needed.
#mg_lib:
#web_keypad:
# port: 80
# partitions: 1 # a keypad will be shown for each partition
# log: false
# auth: #this section is optional. Enable if you need authentication/encryption
# username: test
# password: test
# encryption: true #set true to use AES256HMAC encryption/auth for sent keys and returned LCD messages
# #set to false to use Digest authentication - no encryption
# config_url: https://dilbert66.github.io/config_files/config_vista.yml
# js_url: https://dilbert66.github.io/js_files/www.js
# ## If you prefer to use locally hosted compile time files comment two lines above and uncomment below
# #config_local: ./config_vista.yml
# #js_local: ./www.js
#
# ## custom function call to send keypresses if other than dsc/vista components are used. Parmeters are a string keys and int partition
# service_lambda: |-
# $panelId->alarm_keypress_partition(keys,partition);
#you can remove/disable this section if you don't want your panel time updated automatically.
interval:
- interval: 7200s
then:
- lambda: |-
$panelId->set_panel_time();
esphome:
name: $name
friendly_name: $friendlyName
###Example of how to set the panel time from the esp time on bootup
# #on_boot:
# priority: 600
# then:
# - lambda: |-
# $panelId->set_panel_time();
# output sympols to output.map for debugging. you can remove if not needed
platformio_options:
build_flags:
- "-Wl,-Map,output.map"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "$name"
password: !secret wifi_password
logger:
baud_rate: 115200
level: debug
api:
encryption:
key: !secret encryption_key
#to use mqtt disable the api: section above. This enables you to use esphome with
#non homeassistant systems
#modify the mqtt section to your needs
#See: https://esphome.io/components/mqtt.html
#mqtt:
#broker: 192.168.2.175
#port: 1883
#username: mqttuser
#password: mqttuser
#discovery_prefix: "homeassistant"
#topic_prefix: $name
safe_mode:
ota:
platform: esphome
password: !secret ota_password
#on_begin: #disabled due to bug in esphome
#switch.turn_off: connection_status_switch
time:
- platform: sntp
########################################################################
# Edit binary and text sensors below to suit your alarm setup.
# You can safely add or remove any sensor as needed.
# The id code is entered using the "id:" tag. Alternatively you can
# add the id code in round brackets at the end of the sensor name: eg. (z1)
binary_sensor:
### zone sensors ###
# open/close status for each zone
# zone id code = z+zone number
- platform: template_alarm
id: z1
name: "Fire"
device_class: door
- platform: template_alarm
id: z2
name: "Front door"
device_class: door
- platform: template_alarm
id: z3
name: "Kitchen and Family Room"
device_class: door
- platform: template_alarm
id: z4
name: "Living Room and Office Windows"
device_class: window
- platform: template_alarm
id: z5
name: "Kathryn and Guest Windows"
device_class: window
- platform: template_alarm
id: z6
name: "Master Bedroom"
device_class: window
- platform: template_alarm
id: z7
name: "Garage"
device_class: window
- platform: template_alarm
id: z8
name: "Unknown"
device_class: window
- platform: template_alarm
id: z10
name: "Entryway Motion"
device_class: motion
### you can also add fields to show fault statuses of other devices you have. The id will be 1 + device address.
###relay addresses are 12/13/14/15
# - platform: template_alarm
# id: z112
# name: "check relay 12"
# device_class: problem
###zone expander device addresses are 07/08/09/10/11
# - platform: template_alarm
# id: z108
# name: "check expander 08"
# device_class: problem
###comm device address such as Alarmnet/LRR is 03
# - platform: template_alarm
# id: z103
# name: "check comm device"
# device_class: problem
### non zone sensors ###
### partition ready status
### ready id code = rdy_ + partition number
- platform: template_alarm
id: rdy_1
name: "Ready partiton 1"
###Partition 2 example
# - platform: template_alarm
# id: rdy_2
# name: "Ready partition 2"
### partition/panel trouble status
### trouble id code = trbl_ + partition number
- platform: template_alarm
id: trbl_1
name: "Trouble Partition 1"
device_class: problem
###Partition 2 example
# - platform: template_alarm
# id: trbl_2
# name: "Trouble partition 2"
# device_class: problem
### bypass zones active status
### bypass id code = byp_ + partition number
- platform: template_alarm
id: byp_1
name: "Bypass Partition 1"
###Partition 2 example
# - platform: template_alarm
# id: byp_2
# name: "Bypass partition 2"
### armed away status
### armed away id code = arma_ + partition number
- platform: template_alarm
name: "Away Partition 1"
###Partition 2 example
# - platform: template_alarm
# id: arma_2
# name: "Away partition 2"
### armed status
### armed id code = arm_ + partition number
- platform: template_alarm
id: arm_1
name: "Armed Partition 1"
###Partition 2 example
# - platform: template_alarm
# id: arma_1
# name: "Armed partition 2"
### armed stay status
### armed stay id code = arms_ + partition number
- platform: template_alarm
id: arms_1
name: "Stay Partition 1"
###Partition 2 example
# - platform: template_alarm
# id: arms_2
# name: "Stay partition 2"
### armed instant status
### armed instant id code = armi_ + partition number
- platform: template_alarm
id: armi_1
name: "Instant Partition 1"
###Partition 2 example
# - platform: template_alarm
# id: armi_2
# name: "Instant partition 2"
### armed night status
### armed night id code = armn_ + partition number
- platform: template_alarm
id: armn_1
name: "Night Partition 1"
###Partition 2 example
# - platform: template_alarm
# id: armi_2
# name: "Instant partition 2"
### ac status
### ac id code = (ac)
- platform: template_alarm
id: ac
name: "AC Status"
device_class: plug
### chime status
### chime id code = chm_ + partition number
- platform: template_alarm
id: chm_1
name: "Chime Partition 1"
###Partition 2 example
# - platform: template_alarm
# id: chm_2
# name: "Chime partition 2"
### alarm status
### alarm id code = alm_ + partition number
- platform: template_alarm
id: alm_1
name: "Alarm Partition 1"
###Partition 2 example
# - platform: template_alarm
# id: alm_2
# name: "Alarm partition 2"
### battery status
### battery id code = bat
- platform: template_alarm
id: bat
name: "Battery Status"
device_class: problem
### fire alarm status
### fire alarm id code = fire_ + partition number
- platform: template_alarm
id: fire_1
name: "Fire Partition 1"
device_class: smoke
###Partition 2 example
# - platform: template_alarm
# id: fire_2
# name: "Fire partition 2"
# device_class: smoke
### relay status
### relay id code = r + address + channel
- platform: template_alarm
id: r121
name: "Relay1"
- platform: template_alarm
id: r122
name: "Relay2"
#### text sensors ####
text_sensor:
###alternative zone status as a text sensor. Values: O=open, B=bypass,T=trbl or check,A=alarm
### zone id code = z+zone number
- platform: template_alarm
id: z1s_messages
name: "Front door zone z1"
### system status messages
### system status id code = ss_ + partition number
- platform: template_alarm
id: ss_1
name: "System Status Partition 1"
icon: "mdi:shield"
###Partition 2 example
# - platform: template_alarm
# id: ss_2
# name: "System Status partition 2"
# icon: "mdi:shield"
### long range radio messages
### lrr id code = lrr
# - platform: template_alarm
# id: lrr
# name: "Lrr Msg"
# icon: "mdi:alert-box"
### RF zone messages
### RF id code = rf
# - platform: template_alarm
# id: rf
# name: "RF Msg"
# icon: "mdi:alert-box"
### virtual lcd keypad line1 and line2 messages for each partition
### partition line1 id code = ln1_ + partition number
### partition line2 id code = ln2_ + partition number
### partition 1
- platform: template_alarm
id: ln1_1
name: "Line1 Partition 1"
- platform: template_alarm
id: ln2_1
name: "Line2 Partition 1"
### partition 2
# - platform: template_alarm
# name: "Line1 partition 2"
# id: ln1_2
# - platform: template_alarm
# name: "Line2 partition 2"
# id: ln2_2
### zone status messages bypas/open/alarm
### zone status id code = zs
- platform: template_alarm
id: zs
name: "Zone Status"
### system beeps
### beeps id code = bp_ + partition number
- platform: template_alarm
id: bp_1
name: "Beeps Partition 1"
###Partition 2 example
# - platform: template_alarm
# name: "Beeps partition 2"
# id: bp_2
###optional cmd button example. Send any keypad keys
#button:
# - platform: template_alarm
# name: Gate Button
# id: gate1
# icon: "mdi:emoticon-outline"
# on_press:
# - lambda: |-
# $panelId->alarm_keypress_partition("${accesscode}#701",1);
# - platform: gpio #example use of pin d8 as a zone trigger port for the emulated zone expander
# pin: D8
# id: pind8
# device_class: window
# on_press: #zone,on/off
# - lambda: |-
# $panelId->setZoneFault(17,1);
# on_release:
# - lambda: |-
# $panelId->setZoneFault(17,0);
# end of panel sensor setup - no need to edit anything below.
##############################################################################
switch:
- platform: template
name: "$name Connection"
id: connection_status_switch
restore_mode: DISABLED
lambda: |-
return $panelId->connected();
icon: "mdi:shield-link-variant"
turn_on_action:
- switch.toggle: restart_switch
turn_off_action:
- lambda: |-
$panelId->stop();
- platform: restart
id: restart_switch
- platform: safe_mode
name: "Safe Mode"
debug:
update_interval: 300s
sensor:
- platform: debug
free:
name: "Heap Free"
block:
name: "Heap Max Block"
loop_time:
name: "Loop Time"
#fragmentation: #esp8266 only
# name: "Heap Fragmentation"
INFO ESPHome 2024.10.3
INFO Reading configuration /config/vista20p.yaml...
INFO Detected timezone 'America/Los_Angeles'
INFO Starting log output from 192.168.1.28 using esphome API
INFO Successfully connected to vista20p @ 192.168.1.28 in 0.224s
INFO Successful handshake with vista20p @ 192.168.1.28 in 0.078s
[15:33:16][I][app:100]: ESPHome version 2024.10.3 compiled on Nov 9 2024, 15:31:25
[15:33:16][C][wifi:600]: WiFi:
[15:33:16][C][wifi:428]: Local MAC: D8:13:2A:2E:C8:50
[15:33:16][C][wifi:433]: SSID: 'Schlinternet24'[redacted]
[15:33:16][C][wifi:436]: IP Address: 192.168.1.28
[15:33:16][C][wifi:440]: BSSID: D4:5D:64:E9:61:91[redacted]
[15:33:16][C][wifi:441]: Hostname: 'vista20p'
[15:33:16][C][wifi:443]: Signal strength: -72 dB ▂▄▆█
[15:33:16][C][wifi:447]: Channel: 11
[15:33:16][C][wifi:448]: Subnet: 255.255.255.0
[15:33:17][C][wifi:449]: Gateway: 192.168.1.1
[15:33:17][C][wifi:450]: DNS1: 192.168.1.1
[15:33:17][C][wifi:451]: DNS2: 0.0.0.0
[15:33:17][C][logger:185]: Logger:
[15:33:17][C][logger:186]: Level: DEBUG
[15:33:17][C][logger:188]: Log Baud Rate: 115200
[15:33:17][C][logger:189]: Hardware UART: UART0
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Fire'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'door'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Front door'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'door'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Kitchen and Family Room'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'door'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Living Room and Office Windows'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'window'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Kathryn and Guest Windows'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'window'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Master Bedroom'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'window'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Garage'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'window'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Unknown'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'window'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Entryway Motion'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'motion'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Ready partiton 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Trouble Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'problem'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Bypass Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Away Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Armed Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Stay Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Instant Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Night Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'AC Status'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'plug'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Chime Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Alarm Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Battery Status'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'problem'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Fire Partition 1'
[15:33:17][C][template_alarm.binary_sensor:032]: Device Class: 'smoke'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Relay1'
[15:33:17][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Relay2'
[15:33:17][C][template_alarm.text_sensor:021]: Template Alarm Sensor 'Front door zone z1'
[15:33:17][C][template_alarm.text_sensor:021]: Template Alarm Sensor 'System Status Partition 1'
[15:33:17][C][template_alarm.text_sensor:021]: Icon: 'mdi:shield'
[15:33:17][C][template_alarm.text_sensor:021]: Template Alarm Sensor 'Line1 Partition 1'
[15:33:17][C][template_alarm.text_sensor:021]: Template Alarm Sensor 'Line2 Partition 1'
[15:33:17][C][template_alarm.text_sensor:021]: Template Alarm Sensor 'Zone Status'
[15:33:17][C][template_alarm.text_sensor:021]: Template Alarm Sensor 'Beeps Partition 1'
[15:33:17][C][template.switch:068]: Template Switch 'vista20p Connection'
[15:33:17][C][template.switch:070]: Icon: 'mdi:shield-link-variant'
[15:33:17][C][template.switch:091]: Restore Mode: disabled
[15:33:17][C][template.switch:057]: Optimistic: NO
[15:33:17][C][restart:068]: Restart Switch 'restart_switch'
[15:33:17][C][restart:070]: Icon: 'mdi:restart'
[15:33:17][C][restart:091]: Restore Mode: always OFF
[15:33:17][C][safe_mode.switch:068]: Safe Mode Switch 'Safe Mode'
[15:33:17][C][safe_mode.switch:070]: Icon: 'mdi:restart-alert'
[15:33:17][C][safe_mode.switch:091]: Restore Mode: always OFF
[15:33:17][C][sntp:048]: SNTP Time:
[15:33:17][C][sntp:049]: Server 1: '0.pool.ntp.org'
[15:33:17][C][sntp:050]: Server 2: '1.pool.ntp.org'
[15:33:17][C][sntp:051]: Server 3: '2.pool.ntp.org'
[15:33:17][C][sntp:052]: Timezone: 'PST8PDT,M3.2.0,M11.1.0'
[15:33:17][C][mdns:116]: mDNS:
[15:33:17][C][mdns:117]: Hostname: vista20p
[15:33:17][C][esphome.ota:073]: Over-The-Air updates:
[15:33:17][C][esphome.ota:074]: Address: vista20p.local:3232
[15:33:17][C][esphome.ota:075]: Version: 2
[15:33:17][C][esphome.ota:078]: Password configured
[15:33:17][C][safe_mode:018]: Safe Mode:
[15:33:17][C][safe_mode:020]: Boot considered successful after 60 seconds
[15:33:17][C][safe_mode:021]: Invoke after 10 boot attempts
[15:33:17][C][safe_mode:023]: Remain in safe mode for 300 seconds
[15:33:17][C][api:140]: API Server:
[15:33:17][C][api:141]: Address: vista20p.local:6053
[15:33:17][C][api:143]: Using noise encryption: YES
[15:33:17][C][debug:021]: Debug component:
[15:33:17][C][debug:026]: Free space on heap 'Heap Free'
[15:33:17][C][debug:026]: State Class: ''
[15:33:17][C][debug:026]: Unit of Measurement: 'B'
[15:33:17][C][debug:026]: Accuracy Decimals: 0
[15:33:17][C][debug:026]: Icon: 'mdi:counter'
[15:33:17][C][debug:027]: Largest free heap block 'Heap Max Block'
[15:33:17][C][debug:027]: State Class: ''
[15:33:17][C][debug:027]: Unit of Measurement: 'B'
[15:33:17][C][debug:027]: Accuracy Decimals: 0
[15:33:17][C][debug:027]: Icon: 'mdi:counter'
[15:33:17][D][debug:035]: ESPHome version 2024.10.3
[15:33:17][D][debug:039]: Free Heap Size: 207072 bytes
[15:33:17][D][debug:162]: Flash Chip: Size=4096kB Speed=40MHz Mode=DIO
[15:33:17][D][debug:210]: Chip: Model=ESP32, Features=WIFI_BGN,BLE,BT, Cores=2, Revision=3
[15:33:17][D][debug:218]: ESP-IDF Version: v4.4.2
[15:33:17][D][debug:223]: EFuse MAC: D8:13:2A:2E:C8:50
[15:33:17][D][debug:129]: Reset Reason: Software Reset CPU
[15:33:17][D][debug:271]: Wakeup Reason: Unknown
[15:33:43][D][vista_alarm:982][cmdQueueTask]: High water stack level: 1572
[15:34:13][D][vista_alarm:982][cmdQueueTask]: High water stack level: 1572
[15:34:43][D][vista_alarm:982][cmdQueueTask]: High water stack level: 1572
[15:35:13][D][vista_alarm:982][cmdQueueTask]: High water stack level: 1572
[15:35:43][D][vista_alarm:982][cmdQueueTask]: High water stack level: 1572
Yeah. I knew I was going to be embarrassed by the answer. I was so focused on figuring out ESPHome I didn’t check the hardware. Thank you for pointing that out!
Not sure why you are getting those disconnects. Could be a number of things, wifi connections, reboots, etc. The warnings about vista_alarm_panel took a long time can be ignored. That’ s normal. No issues there. Just a result of some warnings that the esphome devs added to just annoy people …
The only way to know for sure is to monitor the device via the serial usb connection. You can do that using the esphome dashboard or web.esphome.io
Now that I think about it, I did remember seeing a few watchdog timeouts when using the async polling for the esp32. FYI, with some esp32’s having 2 cores, it is very convenient to use the second core for time sensitive tasks such as polling the panel bus. To do this, I implement a separate task that runs asynchronously and removes any delay in cmd responses. This task, sometimes can cause a watchdog timeout/reboot which should not be happening as I am feeding the wd, but there might be a process somewhere that is causing issues. Anyhow, I’ve added a yaml config to control if that task is used or not. To see if it fixes your issue, set it to false as shown below:
#enable use of second esp32 core for async polling of panel data. default: true
use_async_polling: false
With the help of rwoldberg and his esphome logs, I was able to add the ability to update the time on the panel using the AUI protocol (touch keypads). The new code is on “dev” branch. You can call the set_panel_time() service from HA or use an ESPHOME interval section to do it automatically. Example:
The time will be synced with the ESP time as configured in the “time:” section.
The AUI protocol is also used to capture zone open/close events immediately avoiding having to use the TTL delay to determine if a zone is closed.
To use this, you need to set the auiaddress in the yaml to an active aui device address (1,2,5 or 6) and make sure it’s not assigned to another device if possible. See the yaml example for more info.
Apologies for the long absence and lack of update but I did give the ‘use_async_polling’ a try and still currently have it in in the code. Seems like it may be helping? I don’t seem to get the random unknown status from the system anymore.
What it hasn’t resolved though is that whenever the alarm status changes, something is still causing it to go into ‘unknown’ or ‘unavailable’ states. So here’s an example of what I mean:
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 I will see that it will go from ‘armed_away’ → ‘disarmed’ → ‘unknown’ → ‘disarmed’
I saved a log of when this happened and was about to post it, but can you advise if there’s anything I need to filter out because I’m assuming the disarm code is probably hidden somewhere in there?
Lastly, I also want to add that the shed in my backyard also has a door contact (which is part of the Vista alarm system) and an automation in HA will send a notification to me whenever the door opens every time. Not evident in the above example, but happens almost every time is that when the alarm status changes, I also receive a notification indicating that the shed door is also open (which I know isn’t).
I get the feeling that whenever that status change happens and causes the ‘unknown’ states, it may also be causing all the contacts of the system to go from ‘closed’ to ‘open’, before switching back to what the true state of it is. It’s just that the Shed door gives me a notification and so that’s easy for me to pick up.
Thanks for making it this far down into my post and sorry for the long winded writeup!
That’s very odd behaviour there and I can’t guess as to what it can be. I can’t duplicate it especially since my setup is different. Can you open an issue on my github page and post esphome console logs and your yaml config? Make sure you remove any personal info such as codes or names. I have to see esphome logs to be able to determine what’s going on with the sensor sequence. The disarm code will be in the F6 lines so anywhere you see F6, you can blank those out.
I think I see a line that starts with F6 that resembles the disarm code, but I also see a lot of other F6 lines too … they don’t seem to occur at the same time code as when I entered the code, so I assume it’s not related to the disarm code. Leave those lines in for you to review?
edit:: I left them in and I’ve submitted the issue, thanks again for looking at this!
Ok, i’ve fixed a bug in the code that was generating invalid zone faults. I’ve also explained the issue with why your system goes to unavailable when a zone is faulted (motion sensor, etc). It means the system is not ready to be armed.
FYI, you can apply filters either in HA or in ESPHome to change the sensor values to whatever you want. For instance, if you don’t like getting the “not_ready” value when the system can’t be armed due to an open sensor, you can apply filters. For example, here is a filter added to the partition status in the esphome yaml config that forces the “not_ready” value to become “disarmed” when sent to HA. This is useful since the HA Alarm panel integration doesn’t support the “not_ready” flag as it only recognizes “unavailable”, armed, disarmed, etc. Some people find it confusing when they see “unavailable” showing and assume there is something wrong with the sensor. So with this filter, you can send it whatever it likes. FYI, the platform: vista_alarm_panel is new (I integrated the sensor/template alarm logic into one component), but template_alarm or template should also work as usual.
Hi - I was just about to update my running system and noticed that the master version of VistaAlarm.yaml has these entries which the compiler does not like:
Does this mean I should no longer be using the master branch for esphome-components, even when I’m using the master branch for esphome-vistaECP? Or is this an oversight?
I’m currently downloading the contents of the esphome-components directories and manually adding them to my esphome config directory since I like to have a local copy of the code.
whups, yes, I have to correct that. Those entries are only for the “dev” branch, which I do recommend you use anyhow. I will update the master branch soon.
Ok, i’ve corrected the master branch yaml config.
I just got the latest dev branch installed on an ESP32 with the PCB board, and it works great! Thanks to @kschlichter for the photos so I could confirm I got the right board and soldered it correctly to the PCB.
I decided to set use_async_polling: true to see if I get any performance improvements. I haven’t noticed anything yet, but then again I was doing okay with the 8266 board so I wasn’t expecting any changes.
The auiaddr feature is new to me - I checked #189 on my Vista-20P and it already has “01” for 1, 2, 5, and 6, so I presume that means my panel is configured to allow AUI keypads on all 4 addresses. So I kept the auiaddr variable set at “2”, since I do not have a real-life AUI keypad. Does the AUI keypad get more information that is not available via the regular keypad? I was kind of hoping that while my system is in armed state that I could see the wired motion sensors but that doesn’t appear to be the case.
Thanks again for the continued improvements on the software!
The AUI code is designed to immediately capture close events. Without it, the code has to wait for the TTL timeout to expire before knowing a zone is closed since the panel never sends close events to the lcd keypad. The aui code does that by actively talking to the keypad when it sees an F2 event message. As to seeing events during an armed state, that will only happen if you have your system armed home and your inside sensors are not part of the outside perimeter normally. To know for sure if your system is using the AUI code, I would need to see logs. The important cmds are the F2 and F6. If you want to open up an issue on my github page, and post logs with your system in armed state and with your motion sensors being triggered, I will be able to see if things are working as they should.
As to the use_async_polling, true is best as it used a background task to capture all panel data and is not impacted by other components or delays on the ESP.
Thanks. I’ve uploaded some logs of my system in Arm Stay. It appears the F2 and F6 messages are showing up in the logs, but the actual zone is not showing any open/close.
