Initial Connection Failed

[jn3va]

After I upload the code I get the following message, the last line repeats as it tries to connect INFO Reading configuration /config/esphome/vistaalarm.yaml... INFO Starting log output from 192.168.1.184 using esphome API INFO Connecting to 192.168.1.184:6053 (192.168.1.184) WARNING Initial connection failed. The ESP might not be connected to WiFi yet (Error connecting to 192.168.1.184: [Errno 113] No route to host). Re-Trying in 1 seconds WARNING Initial connection failed. The ESP might not be connected to WiFi yet (Error connecting to 192.168.1.184: [Errno 113] ...

I'm using an ESP32, but I was having this same issue on an ESP8266 yesterday. On both devices I can upload a different ESPHome config and have confirmed those configs work and can get on the Wifi, I can see debug activity in the log etc, So the boards seem ok.

When I upload the VistaAlarm config the board is not able to get on WiFi afterward When I ran this with the ESP8266, it was able to run for a short time, created the devices/entities that represented the alarm zones but then lost connection. I'm thinking the board is crashing. I switched to the ESP32 in case that 8266 was bad,

For the ESP32, I'm currently just running the board off of the USB power, no connection to the alarm system. Yesterday I had the 8266 connected to the alarm. Will the code run if there is no connection to D1 an D2 or might that be causing the crash? I want to wait to reconnect to the alarm until I am sure its running the code; but wondering if maybe I had a bad connection on one of the RBYG wires yesterday with the 8266.

My Vista uses mostly wireless sensors, so I have zones going up to 29 in my YAML file. Any known issues with a large number of sensors? The only other confi I made in the yaml was to set the relays and expanders to 0 to disable.

Signal strength is -55bD I've set a static IP (in the yaml and on my router for the device MAC) Set power_save_mode: none

Any ideas what to look at next? Thanks!! Joe

VistaAlarm-ESP_yaml.txt

[Dilbert66]

It's possible there is too much traffic being sent from the esp due to the amount of zones you have. I have seen something similar and that was the case. Here's a couple things you can try:

Set debug to 0 here: 
VistaECP->debug=0;

 Comment out these lines:
   # VistaECP->onLine1DisplayChange([&](std::string msg) {
     #   id(l1).publish_state(msg); 
    #});  
  #  VistaECP->onLine2DisplayChange([&](std::string msg) {
    #    id(l2).publish_state(msg); 
    #}); 

Also set this line to INFO

level: DEBUG -> level: INFO

[Dilbert66]

When you say crash, are you seeing reboot messages in the serial log on the console? These would explain better. You won't see the crash logs on the esphome logs, only on the backend serial.

Yes, the code will run if not connected to the panel but you wont' see any traffic as nothing is coming in.

[jn3va]

Thanks so much for responding!

When I tried the ESP8266 on Sunday I changed logger level to VERY_VERBOSE The log showed a lot of basic status activity (like executing through a loop) but then it just stopped and the connection failed messages started. At one point there was what a series or rows of Hex codes, which I assumed was a stack dump, then a reboot. I was not able to do the OTA flash once the connection failed messages started. I had to power cycle the board, but had the same result: eventually, it stopped responding to ESPHome and would not OTA update. At that point, I assumed the board had an issue and switched to the ESP32. With the ESP32 I can't get it to run at all - I'm not seeing it even get as far as creating the text_sensors in HAAS.

I saw in a separate debug post where you mentioned you were running yours on ESP8266 instead of a 32, so I'll re-flash an ESP8266 and try it again tonight and change the log level to INFO and post the file.

[Dilbert66]

The code should run on either esp8266 or esp32 (with the proper device selected in the yaml). Odd that you can't reflash. Try updating the code with the alarm system connection disconnected physically ( or toggle the "vistaalarm connection" to off in the esphome component in home assistant so that it won't affect the update. You should be able to connect to the chip fine then. Otherwise, there is something else going on. You can try loading the chip via direct usb connection if the ota doesnt work.

[jn3va]

No luck so far. I tried 2 ESP32 boards and an ESP8266. I have ESPHome loaded in Haas, and OS, HAAS and ESPHome are all at the latest versions.

My typical process is to use the wizard to create a basic image and upload that via USB – I call this the “stub” an example yaml is in vistaalarm-esp8266-stub.yaml After the stub is added the board shows up under integrations, I click configure, enter the API password and its added! Then I replace the stub code in the yaml with your VistaAlarm code and use OTA to upload : see vistaalarm-esp8266-v20p.yaml

After the OTA update, the 8266 connected and creates 40 entities, but then something happens and the board stops responding.

I have a command line install of ESPHome on my PC so I can connect the boards to USB there and see the serial output and isolate it from any HAAS system issue. I've also used Putty to connect to the USB and watch the results.

The serial/console logs activity for a while but stops at the same point each time I power-cycle de board “now=30001”

From the log: [19:59:17][VV][scheduler:152]: Running interval 'update' with interval=8 last_execution=29989 (now=30001)

Can you take a look at the yaml and console log files and see if anything jumps out as a cause?

I’m going to try again later this week

Thanks! Joe

VistaAlarm-esp8266-stub_yaml.txt VistaAlarm-ESP8266-v20p_yaml.txt

esphome_vistaAlarm_ESP8266_console_log.txt

[Dilbert66]

Ok, I can't see anything in the logs that shows a reboot or crash. The loop is running but its not processing anything anymore as if the interrupts stopped executing. Your logs are also a bit too verbose in this case. Switch from very_verbose to debug otherwise it creates way too much traffic. Secondly, we can reduce the loop update interval from 8ms to 16ms using this line in vistaalarm.h (around line 196 in setup(): set_update_interval(16);

Try these and then post another sample of your logs and we can see what else is going.

Edit: you shouldnt have to change the update interval but I just added it in case but it does run best at 8ms to ensure that no cmd response is delayed on the bus.

[jn3va]

Alain what version of ESPHome are you using?

I have not been able to get this to work yet. Trying to research the problem I'm seeing various ESPHome forum references to some WiFi issues with the more recent versions of ESPHome, so was considering trying to use a previous version. I'm also ordering a new board to give that a try just in case I'm working with a bad batch. The strange thing is that if I load just the basics (just enough to get ESPHome on Wifi and have it managed by the HaaS ESPHome add-in) it works (can ping, OTA etc.), but after I load the VistaAlarm code, it can't get past the Wifi connection - that's what's leading me to think there is some ESPHome bug. I've tried ESPHome 1.16.2 and 1.17.1 (latest). I also had an ESP8266 running all day yesterday and it would crash and reboot about every 20 minutes.

And for the yaml... all these are 0 if I don't have these board added correct?

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 was 12 13 14 15 relayAddr2: "0" relayAddr3: "0" relayAddr4: "0"

Thank you!!

[Dilbert66]

Currently i'm running 1.16.2. Yes, setting all to zero is correct for the expander and relay options. Did you also make sure that you set the logger to DEBUG and not verbose? That will cause issues if you don't. I don't get why you are having so many issues with wifi otherwise. Never had problems or heard of others having issues.

Edit: installed 1.17.1 and works fine with this version as well.

[jn3va]

Yes DEBUG level logger. Since I've used the same ESPHome version, I'm thinking its a board issue. I have several other ESP32 and ESP8266 (but different brand/source) running ESPHOME with no problems. As soon as I get a new board I'll try again. Thank you sir!

[Dilbert66]

The code does tax the board a bit due to the amount of interrupts so perhaps it's a power issue. I have not measured the current use so can't say for sure. The only issue I had with some clone boards is some of the 5volt regulators are under powered and would burn up which is why I use an external 3.3 volt regulator and feed to the 3.3 volt input. You would see WDT reboots I would think though. It is odd. How are you powering the board?

[Dilbert66]

Just for testing, can you reduce the amount of zones you have configured to half that. I guess 20? See if that makes any difference. I have not tested with so many zones. I can't see why it would cause an issue but can't hurt to try.

edit: I added a bunch of zones up to about 40 and see no issues so far.

[jn3va]

I tried cutting down the zones to just 10 but still no change. Noting in the code that might be assuming there will always be a Zone 1 is there? My system is all wireless sensors so the zones started in the double digits. I'm supposed to get 8266 from Amazon tonight so I'll try again this weekend if I can find the time.

[jdev-homeauto]

Hi all! I wanted to preface my comments below by saying how awesome it is that this project exists, and watching it evolve has been amazing. Developers rarely get the praise for their considerable efforts, so I just wanted to say thanks for creating this ...!

I also have a similar loss of functionality shortly after boot on my system with the current code. I notice that if I revert back to commit 9314ea89f53e4f6b3846d019e6e5185c1ccad91a, my D1 Mini Pro boots and runs without stopping, but with the current version I get what looks like a crash within a few seconds (10-20?) of booting. I can still ping the device and open a TCP connection to port 6053, but I don't get any response ("Timeout while waiting for message response!" error in the Logs section of my esphome server web interface). My alarm panel is an ADT Safewatch Pro 3000 (based on a Honeywell Vista 20p WA3001-5.4?), and I also have all wireless zones, starting at 9 (I presume zones 1-8 are defined as null zones in the panel, but I haven't delved into the programming).

[Dilbert66]

Tks for the kind words! This project is just a fun thing for me to do as a challenge and as a learning tool into embedded development.
It's great debugging stuff with knowledgeable users and it really helps make the code more robust. I think you're hitting on a possible bug in the code so let's find it. It's great that you found a commit that seems to work better and that helps narrow down the issue. There is one line of code that has the potential to cause issues and which was added after the commit you noted. So comment out this line in vistaalarm.h (around line 460) // while(vista.keybusConnected && vista.sendPending()) vista.handle();

[Dilbert66]

Also, if possible can you also upload the logs which show the crash? It's either a WDT reboot or a code error.

Unfortunately, I don't have a wireless expander for this old vista system I have so I can't fully test for it so it's possible I'm missing something. My main system is a dsc. I got this vista for playing around with but its lacking in peripherals.

[Dilbert66]

I've pushed an updated version that addresses the issue with the while loop. Hopefully that's the fix for your issue.

[jdev-homeauto]

Thanks for making the change so quickly ...! I gave it a go with mixed results, so it's probably something my panel is doing or a config I have messed up. I set up a separate installation on a A-Z Delivery Dev Kit C V4 ESP32, and before the while loop fix, it too launched and then hung, but after it seems to keep running indefinitely. On my D1 Mini Pro that is actually connected to my panel, I'm still getting the same boot and then unresponsive state. I'm not sure if I'm capturing anything that is useful but I'm attaching to it via the USB-to-serial interface on it and copying that output. I do have an FTDI board I can plug in, but my setup is kind of challenging to access so the USB interface is my go-to. If you have recommendations on how to better identify what the board is doing, I'd be happy to give it a shot. I would swap in the ESP32 board for the D1, but unfortunately the ESP32 board doesn't have an antenna (the antennas I got came with u.FL pigtails that weren't exactly high quality and I can't attach them to the board) and the location is out of range without an antenna.

Anyway, the VistaTest.log.txt file shows the output I get on the USB-to-serial interface on the D1 Mini Pro, and at the very end, it just hangs that way for >2 minutes with no change. Is there a longer time I should wait to see if the watchdog fires off a reboot?

Thanks for taking the time to take a look at this!

VistaTest.log.txt VistaTest8266.yaml.txt

[Dilbert66]

I can't see any reboot messages in the log so can't say for sure. I've created a code branch called "test" and pushed a modified version with some lines removed for testing. https://github.com/Dilbert66/esphome-vistaECP/tree/test

you only need the file "vistaalarm.h" as that was the only one changed. Both of you guys can try it and let me know if it fixes the issues you are having.

[Dilbert66]

I've also pushed a potential fix to master that does fix an issue with the esp hanging while trying to clear the send buffer. This might be related to differences in how fast some panels respond to key send events ie. send an f6. I can't confirm since I would need to see analyzer traces of the bus of the affected systems to do that.

Anyhow, I added a timeout on the initial send loop to ensure the process will not keep trying more than 2ms to avoid wdt reboots or hangs. This issue would occur also if an esp implementation had a faulty or missing tx circuit.

[jn3va]

You are the man! The change worked great. The ESP32 is talking to HaaS and showing the entities for the alarm zones! I'm going to let it run to make sure the board is stable and will work on connecting to the alarm panel this week. Thank you for all your help. And I want to echo jdev-homeauto's comment - this is an awesome project, very cool. Thanks for creating this!

[Dilbert66]

Awesome! Glad you got it working. Tks again for helping debug the issue.

[jdev-homeauto]

Awesome, thanks for the quick response and for addressing my issue! Based on your comment above, I re-examined my wiring and it turns out that I had in fact mis-wired my optoisolator (I put the green line on pin 6, not pin 4). I'll get that corrected hopefully tomorrow, but my board is also running without freezing now. Impressive that you can handle an error condition that normally shouldn't happen.

Thanks again!

[Dilbert66]

The issue was related to me rushing to fix one issue and causing another! The bane of programmers! lol Glad we sorted it out. Well, working on this prompted me to finish a couple other things that needed to be updated. The mqtt sketch and the panel card. Everything pushed to master now.