Zone status does not update to latest state after a connection lost

[goldriver2]

I upgraded from the old envisalink integration to this new envisalink_new integration because I had issues where if there was a network failure, EVL reboot or communication issues opened door sensor were not showing their real state after the connection was re-established, the status was only updated if these zones were physically closed and re-opened.

Is the new integration supposed to reload and set the latest EVL status for each zone after any connection lost ?

I have 2 dog trap doors that are almost always open except if there is no one at home, actually, while working on the DscServer issue I found out that at every rebbot of the DscServer or the EVL or the integration their status was showing closed in the devices entities. I don't suspect the problem is with the DscServer since my Homeseer system does reflet the correct state as soon as the connection is back.

[ufodone]

Both the stock envisalink integration and this one should always reflect the current zone status. There may be a small delay on Honeywell system but DSC should update in near realtime.

Homeseer updating correctly doesn't necessarily rule out DscServer. E.g., for whatever reason it could only send updates to one of the connected clients in this situation.

It sounds like you are able to reproduce this so debug logs would help track it down. I would also try and reproduce without DscServer in the equation to help narrow down the issue.

[goldriver2]

Here are the exact steps I have been doing my tests

The tests I have been doing are, enable disable integration, start stop dscserver, reboot EVL. concentrating ont door Zone20 (porte chien ha) and 25 (porte chien s-s) as they are the only ones I can keep open (it is -20 degres where I am now)

A) With envisalink_new connected to EVL:

1- Disable Enable to EVL ; all devices report correct state after plugin restarted
2- Reboot EVL with envisalink_new connected to EVL; correct state reported after reboot of EVL

B) With envisalink_new connected to DscServer (only envisalink, no homeseer) Zone 20 and 25 Open:

These are the entities and EVL status before starting testing

Activated debug

1- Disable Enable envisalink_new connected to DscServer; WRONG state of devices , they arre ALL Closed at startup and will only change if open/closed

open/closed the 2 doors manually to set back HA status to reality

2- Stop / Start DscServer with Only envisalink_new connected to DscServer;correct state of devices

3- with envisalink_new connected to DscServer, reboot EVL; WRONG state of devices , they arre ALL Closed at startup and will only change if open/closed

My question to you then, can you explain to me how EVL is working, is it standing there waiting for client to request status of zone OR is it pushing status whenever there is a change ? does it automatically resend a complete state of all zones on a regular basis ? Is DscServer supposed to pushed status when a client connects and then send any changes ?

With the attached log can you guide me on what to ask Mike to check on DscServer to fix this ?

home-assistant.log

[ufodone]

I only had a quick look at the log so far but it looks like the issue is that DscServer is sending unsolicited zone timer dump updates (615). Generally these are only sent by the DSC when requested via a 008 command. envisalink_new should never be requesting them.

The contents of the 615 look wrong as well. The first one shows no zones open. The second one shows zones 20 and 25 open. The last one shows no zones open. I haven't figured out when these update come yet based on the sequence of steps you posted but if zone 20 is never physically closed, then I would never expect a 615 update indicating the zone is closed.

My suggestion at this point for DscServer is:

1. Don't send 615 updates unless requested by a 008 command.
2. Check to make sure that the zone status sent in the 615 updates are accurate.

[goldriver2]

 The multiple 615 you see have been generated at each stop/restart of the DscServer, I just look at the log and it only send it when the server restart, since doing the test no more 615 have been sent. Should it be or not sent at server startup ? Just forced a 615 by restarting DscServer and all zones does report accordingly to the EVL web page, I suppose that the ones where it shows no zone are open are due to the fact I might have reboot EVL and dscserver reconnected while EVL was not completely reset ??? De : ufodone ***@***.***> Envoyé : 2 mars 2024 11:17 À : ufodone/envisalink_new ***@***.***> Cc : bruno lalongé ***@***.***>; Author ***@***.***> Objet : Re: [ufodone/envisalink_new] Zone status does not update to latest state after a connection lost (Discussion #101) I only had a quick look at the log so far but it looks like the issue is that DscServer is sending unsolicited zone timer dump updates (615). Generally these are only sent by the DSC when requested via a 008 command. envisalink_new should never be requesting them. The contents of the 615 look wrong as well. The first one shows no zones open. The second one shows zones 20 and 25 open. The last one shows no zones open. I haven't figured out when these update come yet based on the sequence of steps you posted but if zone 20 is never physically closed, then I would never expect a 615 update indicating the zone is closed. My suggestion at this point for DscServer is: 1. Don't send 615 updates unless requested by a 008 command. 2. Check to make sure that the zone status sent in the 615 updates are accurate. — Reply to this email directly, view it on GitHub<#101 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABXBTSPDZLLQTP56TTCM7XTYWH3O3AVCNFSM6AAAAABECQ647SVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DMNJSG4ZDK>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[goldriver2]

The multiple 615 you see have been generated at each stop/restart of the DscServer, I just look at the log and it only send it when the server restart, since doing the test no more 615 have been sent. Just forced a 615 by restarting DscServer and all zones does report accordingly to the EVL web page, I suppose that the ones where it shows no zone are open are due to the fact I might have reboot EVL and dscserver reconnect while EVL was not completely reset ??? (I was able to reproduce it but when I catch the log only one zone

[ufodone]

DscServer sending a 615 isn't, by itself, a problem. It's not what the real EVL will do but the integration will handle it fine..

What appears to be causing your problem is that the contents of the 615 are indicating that no zones are open even though they are. The log has three "sections" that presumably represent each case where you restarted something. In all cases, the integration receives a 609 for zone 20 which indicates it is open. The 615s follow the 609 in each case. The 615 sent for the second section looks correct in that it indicates zones 20 and 25 are open. However, for the first and third section, the 615 indicates that no zones are open and this is what is resulting in your zones appeared closed when they aren't.

The DSC EVLs will send discrete updates in realtime for each zone and it will also send one for each zone when you initially connect. A 609 indicates a zone is open, a 610 indicates a zone has been restored (e.g. is closed), etc. A 615 contains the current state of ALL zones in a single update. What is happening is the DscServer sends all the 609/610/etc at startup but then follows it up with a 615 but the contents of the 615 are wrong and don't reflect what it just told us (via the 609/610 updates).

[goldriver2]

DscServer was updated to 5.9.6.3 and the 615 issue where open zones were not reporting FFFF is resolved. It's been running for the last 24 hours and everything seems fine.

Thanks for your guidance on this problem, I can now address my needs to connect more than one automation system to my Envisalink 3.