ufodone / envisalink_new

A modernized version of the Home Assistant envisalink integration available through HACS.
MIT License
61 stars 6 forks source link

Failure to Setup Integration (Failed setup, will retry) #138

Open ChipSkylark37 opened 1 week ago

ChipSkylark37 commented 1 week ago

Hello,

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

Steps tried:

Other Notes:

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 commented 1 week ago

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 commented 2 days ago

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 commented 21 hours ago

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.