Plugin changes arm mode on restart of HS3

[The Profit]

[spud]

no it's not intended, could you provide some debug logs?

[The Profit]

no it's not intended, could you provide some debug logs?

Spud, I have attached the debug log. This issue only happens when the alarm is already set to "Arm Stay" and then a restart of HS3 is performed. If the alarm is not set then it doesn't have this issue.
I am using the latest version of the Envisalink DSC plugin 3.0.0.38

Let me know if you need anything else.

[spud]

hmm, this is weird....

the plugin initializes at 7:11:04 and the panel correctly sends a "Armed Stay" message status (PartitionArmed 11), but then one minute later (7:12:01) it says one zone has been unbypassed and resend the arming status as "Armed away" (PartitionArmed 10)

it may be a bug in the EnvisaLink but I can't replicate it on my system, and the one minute delay is strange.

Anything special with your system?

[The Profit]

hmm, this is weird....

the plugin initializes at 7:11:04 and the panel correctly sends a "Armed Stay" message status (PartitionArmed 11), but then one minute later (7:12:01) it says one zone has been unbypassed and resend the arming status as "Armed away" (PartitionArmed 10)

it may be a bug in the EnvisaLink but I can't replicate it on my system, and the one minute delay is strange.

Anything special with your system?

Spud, I don't know what you would consider "special with a system", however,I don't believe mine is different than any other system.
I have two keypads, one upstairs wired to the panel and a second wireless (but powered) keypad downstairs, all window/door sensors are wireless and then two wireless motion sensors, 1864 DSC panel with wireless transceiver. I have one partition setup. I haven't had any issues with false alarms or errors from the system that generate from sensor signal loss.
Is there a way to figure out which zone unbypassed? Maybe I could think about what could be a problem with that specific device? I don't see any values changing in the bypass devices....
I am definitely able to repeat it every time. If I don't want to repeat it however, I do disable the Envisalink plugin before I restart HS3 and it doesn't change it to "arm away". If it was a problem with the envisalink, wouldn't it still set it to arm away with the plugin disabled?

[The Profit]

hmm, this is weird....



the plugin initializes at 7:11:04 and the panel correctly sends a "Armed Stay" message status (PartitionArmed 11), but then one minute later (7:12:01) it says one zone has been unbypassed and resend the arming status as "Armed away" (PartitionArmed 10)



it may be a bug in the EnvisaLink but I can't replicate it on my system, and the one minute delay is strange.



Anything special with your system?

[spud]

I have no idea what could be causing this...
Do you have EVL3 or EVL4? If EVL3 do you have firmware 1.12.182.or later?

To know which zones are bypassed you can try to force the panel to send a "Bypassed Zones Bitfield Dump" message by sending a "Send Keystroke String" event action with the following command: "*1#"

From EnvisaLink TPI doc:

[The Profit]

I have no idea what could be causing this...

Do you have EVL3 or EVL4? If EVL3 do you have firmware 1.12.182.or later?



To know which zones are bypassed you can try to force the panel to send a "Bypassed Zones Bitfield Dump" message by sending a "Send Keystroke String" event action with the following command: "*1#"



From EnvisaLink TPI doc:

[julietalpha]

[The Profit]

hmm, this is weird....



the plugin initializes at 7:11:04 and the panel correctly sends a "Armed Stay" message status (PartitionArmed 11), but then one minute later (7:12:01) it says one zone has been unbypassed and resend the arming status as "Armed away" (PartitionArmed 10)



it may be a bug in the EnvisaLink but I can't replicate it on my system, and the one minute delay is strange.



Anything special with your system?

[spud]

Before reporting to eyezon, I have a few questions:

1. Could you untick the "Create additional devices for zone bypass status" checkbox in the Config page, and then do the test again. Do you still have the same problem? Could you send me the debug log.

2. When the problem happens does it actually change the arm mode on your system, or is it just the plugin that reports incorrectly that the system is armed in away mode?

[The Profit]

Before reporting to eyezon, I have a few questions:

1. Could you untick the "Create additional devices for zone bypass status" checkbox in the Config page, and then do the test again. Do you still have the same problem? Could you send me the debug log.

Ok, I turned on the debug log, then unticked "Create additional devices for zone bypass status" then armed the alarm to "Arm Stay", then shut down and restarted HS3. The system didn't change the arm state at all. Then I ticked the "Create additional devices for zone bypass status" and performed the same test again and it did change the arm state to "Arm Away". (See attached debug log.)

2. When the problem happens does it actually change the arm mode on your system, or is it just the plugin that reports incorrectly that the system is armed in away mode?

Yes, it changes the system arm state, not just the devices in HS3. I hear the system keypad beep and the screen changes from Arm Stay to Arm Away. The plugin will also update the devices when the alarm state changes as well.

Thanks for your help on this Spud!

[spud]

The problem was that the plugin sends a "*1#" command at startup to force the panel to send back the bypass status of all zones. It turns out that this command make the system to switch from Armed stay to Armed away when the system is armed.

So in version 3.0.0.39 available here, the plugin only sends this command if the system is disarmed

Thanks for reporting this bug!

[Guest]

Not sure if this is considered the same bug and corrected in .39, but I experienced the same thing but caused by a socket error in attempted communication with the envisalink forcing a reconnect this morning:

Dec-26 12:48:53 AM Event Event Trigger "Security Alarm Armed"
Dec-26 12:48:53 AM EnvisaLink INFO Alarm status change: Armed Stay
Dec-26 12:48:50 AM EnvisaLink INFO Zone (multiple of these zone status lines)
Dec-26 12:48:50 AM EnvisaLink INFO Reconnection OK
Dec-26 12:48:50 AM EnvisaLink INFO Trying to reconnect to: xxx.xxx.xxx.xxx
Dec-26 12:48:39 AM EnvisaLink INFO Connection Lost, will try to reconnect in 10 seconds
Dec-26 12:48:39 AM EnvisaLink ERROR Receiver::Run() A socket error has occured: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Dec-26 12:48:39 AM EnvisaLink INFO Reconnection OK
Dec-26 12:48:39 AM EnvisaLink INFO Trying to reconnect to: xxx.xxx.xxx.xxx
Dec-26 12:48:28 AM EnvisaLink INFO Connection Lost, will try to reconnect in 10 seconds
Dec-26 12:48:28 AM EnvisaLink ERROR Receiver::Run() A socket error has occured: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Upon finding this thread I upgraded to .39, but thought I would post here in case this is a different code path with the same issue.

Edit to Add:
Just noticed the profits other thread on socket errors. Since he experienced the socket error after upgrading and didn't have his arm mode switch I am going to guess that the fix is effective for this as well.