Failure to Setup Integration (Failed setup, will retry)

[ChipSkylark37]

Hello,

Coming from built-in integration and unable to get the integration loaded properly. Any help is greatly appreciated.

Steps tried:

• Install from HACS (found in store vs adding custom repository)
• Rename envisalink to envisalink_new in YAML
• Reboot HA
• See logs regarding failure to setup, but 'configure' looks to have brought over all settings
• Comment out envisalink_new in YAML, reboot, more log failures.

Other Notes:

• This is the latest available firmware for the device (non sidekick / LTE)
• The EVL has been rebooted from the Web GUI (192.168.1.250)
• I can access the Web GUI of the Alarm Panel without issues
• I also use Hubitat, which does integrate in with Envisalink for use with HSM and Alerting / Notifications. Is it possible these two cannot co-exist? The CORE integration worked fine with Hubitat.

Debug Log Below:

2024-09-01 11:49:32.958 DEBUG (MainThread) [custom_components.envisalink_new] Created EnvisalinkController for Home (host=192.168.1.250 port=4025 discovery=(None, 80))
2024-09-01 11:49:32.958 INFO (MainThread) [custom_components.envisalink_new] Start envisalink
2024-09-01 11:49:33.011 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.alarm_panel] Discovered Envisalink 4: HONEYWELL
2024-09-01 11:49:33.012 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.alarm_panel] Firmware Version: '01.05.203A' / MAC address: '001c2a0173f9'
2024-09-01 11:49:33.012 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command processing task started.
2024-09-01 11:49:33.012 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Starting read loop.
2024-09-01 11:49:33.012 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Started to connect to Envisalink... at 192.168.1.250:4025
2024-09-01 11:49:33.014 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Connection Successful!
2024-09-01 11:49:33.014 INFO (MainThread) [custom_components.envisalink_new] Connected to the envisalink device
2024-09-01 11:49:33.014 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL
2024-09-01 11:49:33.014 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Caught unexpected exception: ConnectionResetError(104, 'Connection reset by peer')
2024-09-01 11:49:33.014 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Cleaning up from disconnection with server.
2024-09-01 11:49:33.014 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Exception while closing connection: [Errno 104] Connection reset by peer
2024-09-01 11:49:33.014 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Reconnection attempt in 30s
2024-09-01 11:49:33.014 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command processor woke up.
2024-09-01 11:49:33.014 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.alarm_panel] Disconnecting from the envisalink...
2024-09-01 11:49:33.014 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Cleaning up from disconnection with server.
2024-09-01 11:49:33.014 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] An event loop was given to us- we will shutdown when that event loop shuts down.

[ufodone]

This line:

2024-09-01 11:49:33.014 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Caught unexpected exception: ConnectionResetError(104, 'Connection reset by peer')

is triggered by the EVL closing the connection that HA has to it. The EVL only allows a single connection to it so this error is most often caused by something else already having a connection. I don't know anything about the Hubitat version but if it also connects on port 4025 then this could be the culprit. However, that would have also been the case with the stock envisalink integration. To eliminate this as a possibility, you could try to shutdown or disable the Hubitat setup and then startup HA to see if that resolves the issue.

I've also seen cases where people have ended up with multiple envisalink_new devices configured in HA for the same physical EVL device. Can you confirm that you only see a single device in Settings->Devices & services->envisalink_new?

And just to confirm, you don't have any envisalink configuration left in your configuration.yaml, right? You said you renamed it which is the right thing to do but this error could also be caused by having the stock integration also trying to connect to the EVL.

[ChipSkylark37]

Interesting, that did "resolve" the issue.

I think this is actually timing out to an update that was done, as it seemingly only occurred after an update to either Hubitat, or HomeAssistant where the OEM envisalink integration stopped working. I didn't think they were correlated initially because I run updates on a somewhat frequent basis and didn't see anything in the changelogs on either platform.

However, I've always had both configured and polling so its definitely odd.

Hubitat, although I'm sure how it integrates (their documentation says telnet) was used for notifications (Arm, Disarm, Panic, etc) whereas HomeAsisstant was used primarily to allow me to have quick action buttons to Arm / Disarm from my Dashboards / Watch / Phone.

It makes sense then that the new envisalink is also experiencing the same issue, but that still begs the question of 1. which one broke it and 2. why did it break all of a sudden when both had been happily co-existing for years now.

I have checked the Settings > Devices & Services and only see single entries there. Though they are 'unavailable' because when I rebooted HomeAssistant, it looks like the Hubitat took the connection. If I reboot the Hubitat, HomeAssistant takes back over and starts working.

And no, I removed the 'enivsalink' configuration from the YAML by renaming it.

I think I may open an issue on both Hubitat and HomeAssistant forums to see if anyone else has come across this, though I dont think the OEM integration is too widely used.

Appreciate the response and validation on those other few pieces.

[ufodone]

This integration and the stock HA one have always connected to port 4025 on the EVL devices and the EVL devices themselves have only ever supported a single concurrent connection to that port for the several years I've been using mine. So it is a bit of a mystery how this used to work for you and why it suddenly stopped.

If you do get stuck, I know there are people using things like AlarmServer and DscServer.jar to solve this issue. If you search through the old issues here you'll find some info on that. I've never used either of them myself but others have had success.

[bassdr]

I also just started using this and also did not have success with the automation process. I commented out everything in configuration.yaml in case I want to go back to the old setup, and started the setup from scratch in the UI, forcing the ids to match my old setup to avoid breaking all automations.

I guess at this point we could just add a note in the readme warning users that it might not work?

[ChipSkylark37]

Since disabling the integration with Hubitat, the connection from HomeAssistsnt has been 98% reliable. Randomly however I get the same errors that it cannot access and will retry. Rebooting HA doesn't fix it, but rebooting the EVL itself does, at least for some time.

I don't have anything else connecting to the EVL - Are there any other logs I can look at to help diagnose it? The EVL doesn't appear to have any logs and their support forums are nearly all but abandoned.

[ufodone]

When you get those errors and it attempts to reconnect, will it ever recover on its own or does it always require you to reboot the EVL? And how frequently does this occur (once a day, one a week, one a month, etc.)?

Are you able to turn debug logging on and attach some logs from around the time when it disconnects? I don't know if it will reveal any additional details but it's worth a shot.

[ChipSkylark37]

No, it will never recover on it's own and show as "Unavailable" with a little question mark on my HA homepage.

I had it break around 4-5 days ago and waited to see if it would come back on its own, it didnt. Rebooting HA restored access however.

During that time, I was still getting notifications about the system being Armed / Disarmed through HA (I have an automation setup for this), which is odd because the actual Alarm Panel in HA was showing as unavailable.

It seems infrequent that it breaks and I cant really understand why since I've not changed anything and only have the following setup:

1. Direct notifications from the Envisalink to the EVL Mobile App on iOS
2. HA Integration using this Integration

[ufodone]

The fact that you're still getting arm/disarm notifications in HA would indicate that it is connecting and authenticating but then getting disconnected again and repeating this loop. Debug logs from when this happens would likely be very helpful to narrowing down what's going on.

Are you seeing any errors or warnings in the logs when this starts happening?