Ademco/Honeywell/Vista ESPHome custom component with an esp32/esp8266

You no longer have the error connecting to esphome?

Following @Dilbert66 's instructions, I no longer have the errors, but for some reason still am not able to reconnect.

HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- ESP8266WiFi @ 1.0
|-- ESP8266mDNS @ 1.2
|-- noise-c @ 0.1.6
Compiling .pioenvs/vistaalarm/src/main.cpp.o
Linking .pioenvs/vistaalarm/firmware.elf
RAM:   [=====     ]  48.8% (used 39980 bytes from 81920 bytes)
Flash: [=====     ]  50.9% (used 531139 bytes from 1044464 bytes)
Building .pioenvs/vistaalarm/firmware.bin
esp8266_copy_factory_bin([".pioenvs/vistaalarm/firmware.bin"], [".pioenvs/vistaalarm/firmware.elf"])
esp8266_copy_ota_bin([".pioenvs/vistaalarm/firmware.bin"], [".pioenvs/vistaalarm/firmware.elf"])
========================= [SUCCESS] Took 24.26 seconds =========================
INFO Successfully compiled program.
INFO Connecting to 10.0.63.187
ERROR Connecting to 10.0.63.187:8266 failed: [Errno 111] Connection refused

I seem to have introduced another bug when fixing the compilation on the esp32. It’s crashing again. Works on esp32 but not on esp8266. I’m looking into it.

Edit: Never mind. It wasnt crashing. I had loaded an earlier version. Note, though that an earlier version of today was crashing and was corrected so perhaps that was the one you loaded. Anyhow, I’ve made a couple more ram tweaks so go ahead and re-upload and see if it fixes your issue. If it was crashing, it should go into safe mode and still allow you to upload.

Just to make sure I’m on the right track, I’m using the dev version of the yaml and under the components section, I’ve omitted the ‘web_keypad’ because just a few lines further below it says that it’s only for esp32:

components: [vista_alarm_panel,template_alarm,web_keypad,mg_lib]

I include the line “mg_lib:” as well but it ends up with a lot of errors and doesn’t compile.
When I remove “mg_lib:”, it compiles with no errors, but still results in “error: connection refused”

You don’t need the mg_lib as that’s also just for the esp32. Odd about your connection though. It might be crashing but to know you would need to look at the logs from the serial console. It works ok here but not connected to a panel though as I really only develop on the esp32 nowadays. I only fire up an esp8266 to ensure it compiles. I’ll have to hook one up to a panel to test further.

Edit: I’ve hooked up the esp8266 with the latest dev version and it works fine so far so I’m not sure what the issue is with yours right now.

Are you using MQTT? I was testing with the API enabled which worked fine. I switched to test with MQTT and got some crashes which I’m looking into. I suspect though that we are encountering a memory issue. From what I see, the crashes are related to a stack corruption. I did my best to optimize ram use as best I can but obviously not enough. MQTT uses much more memory than the API connection.

Edit: I see you are using the API from your screen capture since I see it’s using the noise-c lib (which mqtt doesnt load) so it should be working fine. I’ve also tested the original code from the master branch which I haven’t really touched in a while, and it’s also crashing with stack issues (likely due to low memory resources). What this means is that with all the esphome updates, the size of some of the components have started to use a lot more resources than before, limiting what is available for the vista alarm library which also needs a good chunk for various buffers. What I recommend is to update to an ESP32 if you can. It’s a much faster platform with tons more memory and flash storage, as well being dual-core. Any ESP32 will pretty much work and with their cost being pretty cheap, it’s worthwhile. It’s getting very tricky trying to optimize ram use and cannibalize some features just to make it work in the original esp8266. You can even get an ESP32 mini that fits within the same footprint as the wemos d1. I’ve also used the esp32c3 and esp32s3 super minis successfully.

As to your crashes, if you can’t connect , the only way to really know what is going on is to connect to the usb port with a laptop and using a serial monitor look at the log that way.

I do have it booting on the ESP8266 with Howard Chen’s PCBA and entities are showing up in Home Assistant. I’m not getting any status changes though, except for heap and loop time updes. I must have done something wrong in my configuration. I’ll have to go back through it to figure it out.

[18:02:15][C][safe_mode:018]: Safe Mode:
[18:02:15][C][safe_mode:019]:   Boot considered successful after 60 seconds
[18:02:15][C][safe_mode:021]:   Invoke after 10 boot attempts
[18:02:15][C][safe_mode:022]:   Remain in safe mode for 300 seconds
[18:02:15][C][api:140]: API Server:
[18:02:15][C][api:141]:   Address: vista20p.local:6053
[18:02:15][C][api:143]:   Using noise encryption: YES
[18:02:15][C][esphome.ota:073]: Over-The-Air updates:
[18:02:15][C][esphome.ota:074]:   Address: vista20p.local:8266
[18:02:15][C][esphome.ota:075]:   Version: 2
[18:02:15][C][esphome.ota:078]:   Password configured
[18:02:15][C][debug:021]: Debug component:
[18:02:15][C][debug:026]:   Free space on heap 'Heap Free'
[18:02:15][C][debug:026]:     State Class: ''
[18:02:15][C][debug:026]:     Unit of Measurement: 'B'
[18:02:15][C][debug:026]:     Accuracy Decimals: 0
[18:02:15][C][debug:026]:     Icon: 'mdi:counter'
[18:02:15][C][debug:027]:   Largest free heap block 'Heap Max Block'
[18:02:15][C][debug:027]:     State Class: ''
[18:02:15][C][debug:027]:     Unit of Measurement: 'B'
[18:02:15][C][debug:027]:     Accuracy Decimals: 0
[18:02:15][C][debug:027]:     Icon: 'mdi:counter'
[18:02:15][D][debug:035]: ESPHome version 2024.10.2
[18:02:15][D][debug:039]: Free Heap Size: 12736 bytes
[18:02:15][D][debug:041]: Flash Chip: Size=4096kB Speed=40MHz Mode=DOUT
[18:02:15][D][debug:050]: Chip ID: 0x005FC819
[18:02:15][D][debug:051]: SDK Version: 2.2.2-dev(38a443e)
[18:02:15][D][debug:052]: Core Version: 3.1.2
[18:02:15][D][debug:053]: Boot Version=31 Mode=1
[18:02:15][D][debug:054]: CPU Frequency: 80
[18:02:15][D][debug:055]: Flash Chip ID=0x00164054
[18:02:15][D][debug:056]: Reset Reason: External System
[18:02:15][D][debug:057]: Reset Info: External System
[18:04:38][D][sensor:093]: 'Heap Free': Sending state 15848.00000 B with 0 decimals of accuracy
[18:04:38][D][sensor:093]: 'Loop Time': Sending state 303.00000 ms with 0 decimals of accuracy
[18:04:38][D][sensor:093]: 'Heap Max Block': Sending state 7304.00000 B with 0 decimals of accuracy
[18:09:38][D][sensor:093]: 'Heap Free': Sending state 15848.00000 B with 0 decimals of accuracy
[18:09:38][D][sensor:093]: 'Loop Time': Sending state 22.00000 ms with 0 decimals of accuracy
[18:09:38][D][sensor:093]: 'Heap Max Block': Sending state 7304.00000 B with 0 decimals of accuracy
[18:10:10][D][sntp:072]: Synchronized time: 2024-10-26 18:10:10
[18:14:38][D][sensor:093]: 'Heap Free': Sending state 16192.00000 B with 0 decimals of accuracy
[18:14:38][D][sensor:093]: 'Loop Time': Sending state 24.00000 ms with 0 decimals of accuracy
[18:14:38][D][sensor:093]: 'Heap Max Block': Sending state 8880.00000 B with 0 decimals of accuracy
[18:19:38][D][sensor:093]: 'Heap Free': Sending state 16064.00000 B with 0 decimals of accuracy
[18:19:38][D][sensor:093]: 'Loop Time': Sending state 24.00000 ms with 0 decimals of accuracy
[18:19:38][D][sensor:093]: 'Heap Max Block': Sending state 7304.00000 B with 0 decimals of accuracy

I’ve gone wrong somewhere, but I don’t know where. I get nothing on the bus.

  • Using Howard Chen’s PCBA with an ESP8266
  • The config passes validation, compiles, and installs wirelessly to the device.
  • I get 0.6 Ohms from screw terminal to screw terminal; the wires aren’t broken.
  • The green wire is in terminal 6; yellow is in 7. On the PCBA they’re in G and Y.
  • I do get updates in the ESPHome logs; the device is alive and connected.
  • On the Vista 20P, *189 is 1/1/1/1; *190 is 1/1.
  • I have one physical keypad at addr. 16 and everything is in partition 1.
  • I have no expanders, relays, or radios.

Does this rule out everything but the soldering? Is there something I’m not thinking of? What have I missed?


[13:21:47][D][debug:035]: ESPHome version 2024.10.2
[13:21:47][D][debug:039]: Free Heap Size: 14832 bytes
[13:21:47][D][debug:041]: Flash Chip: Size=4096kB Speed=40MHz Mode=DOUT
[13:21:47][D][debug:050]: Chip ID: 0x005FC819
[13:21:47][D][debug:051]: SDK Version: 2.2.2-dev(38a443e)
[13:21:47][D][debug:052]: Core Version: 3.1.2
[13:21:47][D][debug:053]: Boot Version=31 Mode=1
[13:21:47][D][debug:054]: CPU Frequency: 80
[13:21:47][D][debug:055]: Flash Chip ID=0x00164054
[13:21:47][D][debug:056]: Reset Reason: Software/System restart
[13:21:47][D][debug:057]: Reset Info: Software/System restart
[13:21:49][D][api:103]: Accepted 192.168.1.100
[13:21:49][W][component:237]: Component api took a long time for an operation (289 ms).
[13:21:49][W][component:238]: Components should block for at most 30 ms.
[13:21:55][D][api.connection:1446]: Home Assistant 2024.10.3 (192.168.1.100): Connected successfully
[13:22:35][I][safe_mode:041]: Boot seems successful; resetting boot loop counter
[13:24:37][D][sensor:093]: 'Heap Free': Sending state 15680.00000 B with 0 decimals of accuracy
[13:24:37][D][sensor:093]: 'Loop Time': Sending state 20187.00000 ms with 0 decimals of accuracy
[13:24:37][D][sensor:093]: 'Heap Max Block': Sending state 7040.00000 B with 0 decimals of accuracy
[13:24:37][D][sensor:093]: 'Heap Fragmentation': Sending state 24.00000 % with 1 decimals of accuracy

top of config file:

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: "true" # 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

I don’t see anything wrong in the config. Did you have that circuit working before with an older version? Everything points to a connection issue as far as I can tell.

I’m only just starting. It must be a soldering issue. Thanks for the double check.

Yes, green on 6 and yellow on 7. So I can’t figure out why you would have an issue. Perhaps make sure your optocouplers are not inserted backwards…

USB power. It’s gotta be a cold solder joint or something. I’ll solder a second one up and see what happens.

Odd. Anyhow, if you ever want to switch to using an ESP32, you can grab an ESP32 d1 mini which has compatible pinouts to fit on that same pcb. You would then need to use gpio22 for inputrx, gpio21 for inputtx and gpio18 for inputmon in the yaml config as well as setup the board as a wemos_d1_mini32

1 Like

you’re probably right, might just be easier if I picked up at an esp32 board and hooked that up to it.
Will report back once I’m able to make that transition.

edit: Ok, so i ordered a esp32 board, edited my yaml for the esp32 instead of esp8266, and then re-wired the rest of the circuit board to suit the non-isolated simplified version. I compiled, downloaded the .bin and plugged in the esp32 on my machine and flashed with esphome web. Everything went smoothly, not a hiccup.

While still connected to the computer, i connect wirelessly for the log

[17:09:31][I][app:100]: ESPHome version 2024.10.0 compiled on Oct 29 2024, 15:02:05
[17:09:31][C][wifi:600]: WiFi:
[17:09:31][C][wifi:428]:   Local MAC: 08:A6:F7:48:58:5C
[17:09:31][C][wifi:433]:   SSID: [redacted]
[17:09:31][C][wifi:436]:   IP Address: 10.0.63.187
[17:09:31][C][wifi:440]:   BSSID: [redacted]
[17:09:31][C][wifi:441]:   Hostname: 'vistaalarm'
[17:09:31][C][wifi:443]:   Signal strength: -50 dB ▂▄▆█
[17:09:31][C][wifi:447]:   Channel: 1
[17:09:31][C][wifi:448]:   Subnet: 255.255.255.0
[17:09:31][C][wifi:449]:   Gateway: 10.0.63.1
[17:09:31][C][wifi:450]:   DNS1: 0.0.0.0
[17:09:31][C][wifi:451]:   DNS2: 0.0.0.0
[17:09:31][C][logger:185]: Logger:
[17:09:31][C][logger:186]:   Level: DEBUG
[17:09:31][C][logger:188]:   Log Baud Rate: 115200
[17:09:31][C][logger:189]:   Hardware UART: UART0
[17:09:31][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Front Entry'
[17:09:31][C][template_alarm.binary_sensor:032]:   Device Class: 'door'
[17:09:31][C][template_alarm.binary_sensor:032]: Template Alarm Binary Sensor 'Garage Entry'
...
...
...
[17:09:32][C][template_alarm.text_sensor:021]: Template Alarm Sensor 'Beeps (bp_2)'
[17:09:32][C][template.switch:068]: Template Switch 'vistaalarm Connection'
[17:09:32][C][template.switch:070]:   Icon: 'mdi:shield-link-variant'
[17:09:32][C][template.switch:091]:   Restore Mode: disabled 
[17:09:32][C][template.switch:057]:   Optimistic: NO
[17:09:32][C][restart:068]: Restart Switch 'restart_switch'
[17:09:32][C][restart:070]:   Icon: 'mdi:restart'
[17:09:32][C][restart:091]:   Restore Mode: always OFF
[17:09:32][C][safe_mode.switch:068]: Safe Mode Switch 'Safe Mode'
[17:09:32][C][safe_mode.switch:070]:   Icon: 'mdi:restart-alert'
[17:09:32][C][safe_mode.switch:091]:   Restore Mode: always OFF
[17:09:32][C][sntp:048]: SNTP Time:
[17:09:32][C][sntp:049]:   Server 1: '0.pool.ntp.org'
[17:09:32][C][sntp:050]:   Server 2: '1.pool.ntp.org'
[17:09:32][C][sntp:051]:   Server 3: '2.pool.ntp.org'
[17:09:32][C][sntp:052]:   Timezone: 'EST5EDT,M3.2.0,M11.1.0'
[17:09:32][C][mdns:116]: mDNS:
[17:09:32][C][mdns:117]:   Hostname: vistaalarm
[17:09:32][C][safe_mode:018]: Safe Mode:
[17:09:32][C][safe_mode:020]:   Boot considered successful after 60 seconds
[17:09:32][C][safe_mode:021]:   Invoke after 10 boot attempts
[17:09:32][C][safe_mode:023]:   Remain in safe mode for 300 seconds
[17:09:32][C][api:140]: API Server:
[17:09:32][C][api:141]:   Address: 10.0.63.187:6053
[17:09:32][C][api:143]:   Using noise encryption: YES
[17:09:32][C][esphome.ota:073]: Over-The-Air updates:
[17:09:32][C][esphome.ota:074]:   Address: 10.0.63.187:3232
[17:09:32][C][esphome.ota:075]:   Version: 2
[17:09:32][C][esphome.ota:078]:   Password configured
[17:09:32][C][debug:021]: Debug component:
[17:09:32][C][debug:026]:   Free space on heap 'Heap Free'
[17:09:32][C][debug:026]:     State Class: ''
[17:09:32][C][debug:026]:     Unit of Measurement: 'B'
[17:09:32][C][debug:026]:     Accuracy Decimals: 0
[17:09:32][C][debug:026]:     Icon: 'mdi:counter'
[17:09:32][C][debug:027]:   Largest free heap block 'Heap Max Block'
[17:09:32][C][debug:027]:     State Class: ''
[17:09:32][C][debug:027]:     Unit of Measurement: 'B'
[17:09:32][C][debug:027]:     Accuracy Decimals: 0
[17:09:32][C][debug:027]:     Icon: 'mdi:counter'
[17:09:32][D][debug:035]: ESPHome version 2024.10.0
[17:09:32][D][debug:039]: Free Heap Size: 203020 bytes
[17:09:32][D][debug:162]: Flash Chip: Size=4096kB Speed=40MHz Mode=DIO
[17:09:32][D][debug:210]: Chip: Model=ESP32, Features=WIFI_BGN,BLE,BT, Cores=2, Revision=3
[17:09:32][D][debug:218]: ESP-IDF Version: v4.4.2
[17:09:32][D][debug:223]: EFuse MAC: 08:A6:F7:48:58:5C
[17:09:32][D][debug:129]: Reset Reason: Power On Reset
[17:09:32][D][debug:271]: Wakeup Reason: Unknown
[17:10:01][D][vista_alarm:997][cmdQueueTask]: High water stack level:  1672
[17:10:31][D][vista_alarm:997][cmdQueueTask]: High water stack level:  1672

Not sure if the last couple of lines means anything, but otherwise didn’t see any issues in the log. ESPhome shows it as ‘online’. So then I went and plugged it in to the circuit board all connected back up with the alarm panel.

Just to add to the previous edit is that once plugged back into the circuit board, and when i choose to check logs wirelessly, I get this error:

INFO ESPHome 2024.10.2
INFO Reading configuration /config/esphome/vistaalarm.yaml...
INFO Detected timezone 'America/Toronto'
INFO Starting log output from 10.0.63.187 using esphome API
WARNING Can't connect to ESPHome API for vistaalarm @ 10.0.63.187: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='10.0.63.187', port=6053))]: [Errno 113] Connect call failed ('10.0.63.187', 6053) (SocketAPIError)
INFO Trying to connect to vistaalarm @ 10.0.63.187 in the background

In both cases, i’m getting the log “wirelessly”, no?

Slightly off-topic, but is there anything configurable in esphome settings as an environment as a whole that would be banning or preventing the connection?

Not if it connects initially. It could still be crashing but I can’t see why it would as I can’t duplicate the issue. The only way to know for sure is to monitor the serial log from the usb connection on the device and capture it. Any crash, error will show up there before it event connects to wifi. Otherwise, we’re only guessing.

Edit: The “high water stack level” messages are from the secondary core task that runs to capture the bus traffic asynchronously. This way no data will get missed and response to cmds will be instant. Some of the esp32 devices have 2 cores and the second core can be used for this purpose.

What esp32 are you using and what is it set as in the yaml? You can perhaps post an issue and your yaml on my github repository here:

Ok, a whole bunch of things have changed … I’ll try to answer and update as I go along in this post. Sorry for the long write-up!

First, there might be a misunderstanding on my part about logs, but you’ve mentioned a couple times to “monitor the serial log from usb connection” and I thought that was what I was doing when I pasted the outputs in above posts. I tried to google it, but I’m not quite getting it so I would appreciate some more guidance as to how to obtain the logs.

I purchased these from amazon and the yaml is as follows:

esp32: 
  board: nodemcu-32s
  framework: 
    type: arduino
    version: recommended

As I was posting some of those outputs the other day while the device was plugged in only via USB (away fro the circuit board), and I’m not sure what happened, but it looked like an event triggered but the time stamp on it was weird … it was January 1, 1969 or something like that. I remembered when I was working on another ESP project that the time was also wrong and the work-around / solution was to use home assistant as the platform, rather than sntp. So currently this is what’s changed in the yaml which seems to have fixed the connection issue (as odd as it seems???)

time:
 - platform: homeassistant

Next thing, that happened after I plugged the ESP board back into the circuit … it connected fine, but shortly after, there was a whole lot of beeping that occurred in the house. I looked at the keypad and noticed 2 things, the main keypad (with the wireless) showed “CHECK 100 RF” or something like that, and the secondary keypad went blank aside from just showing “OC” on the screen. Googling this, it means ‘open circuit’ and something went wrong with the wireless module and hence the second keypad lost wireless connection. I also noticed that all my wireless motion sensors on the second floor are also not triggering.

I unplugged my wiring hot-mess (and noticed I goofed on a few connections) and reset everything from the keypad. The second keypad is now back, but the wireless motion sensors are all still not in service (i.e., they don’t trip when I walk in front of them and there’s no message on of the triggering on the keypad).

After fixing the wiring, I plugged everything back in without triggering any further problems. I wonder if I might have fried/killed something when the circuit board had a couple of wrong connections??

As I’m looking through home assistant, I see a slew of new vista alarm sensors, but they all show as “unknown” or “unavailable”. However, the moment I trip a sensor (i.e. open a door, walk in front of motion sensor) the status changes to on/off and their status will update automatically/correctly. I go around the house triggering all the sensors to give it a proper status, but is this correct behaviour? Some things can’t be triggered like motion sensors/door contacts, so how do those update? Anyhow, something later triggers and causes all the sensors all to revert back to “unknown” or “unavailable”.

Appreciate the help and patience!

I doubt you broke anything as the bus is pretty resilient but you might have confused the panel with your connection issue. A bad ground can cause all kinds of noise to show up on the bus and cause errors on the panel. You can try and reset errors by entering your disarm code + 1 a few times. You can also reset the panel but unplugging it from power and then replugging it (ensure the battery is also disconnected). This should also reset the RF base in case it got confused as well. As to the sensor updates, those should update to a default state on startup. It sounds like there might be a config issue on your yaml. If you can post it either here or on my github page (remove any sensitive info first) and I can look at it.

Edit: I forgot to clarify the difference in getting the logs from usb vs the esphome wifi interface. When you connect to your device via the esphome dashboard, you will only see the data it shows you after it’s booted, initialized and connected to wifi. You won’t see any errors that can occur before that. To truly see what is going on , you need to have your pc physically connected to the usb port of the esp, and then when you select to view the logs from esphome, select the option 2 or 3 to view the logs from usb. The easiest way really is to use google chrome or chromium (wont’ work with other browsers) and go to url : https://web.esphome.io and click connect, select the usb port and you should see logs. To capture logs from the beginning, after you connect, press the reset button on the esp (or click “reset device” on the web form) and view the logs. Once you get what you want, you can click on “download logs”. Voila!

I did try all the things you suggested with disarming with code+1 a few times and unplugging without much luck.

I think I figured out the sensor updates, it’s because I still had the line “publish_initial_state: true” under each zone. I commented those out and it’s all working correctly now. I can probably work through yaml bits with the odd pointer here and there :slight_smile:

Will report back if/when the wireless sensors are sorted …

Hmm, interesting. Someone else mentioned about the “publish_initial_state” issue causing the unknown statuses but I could not duplicate the issue. Odd since the back end code already takes care of doing an initial publish.

Weird about your sensors. Not sure what the issue is with those. If some of your wireless sensors work, that means your RF base is communication fine.

Edit: Ok, I did find the issue with the publish_initial_state and have corrected it on dev. I had no pushed a change to git