Announcement

Collapse
No announcement yet.

Plugin changes arm mode on restart of HS3

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Plugin changes arm mode on restart of HS3

    HS3 3.0.0.500 &HSTouch Designer 3.0.71 with 782 Devices, 479 Events
    Plugin's:
    BLBackup, BLOccupied, BLShutdown, EasyTrigger, Ecobee,
    EnvisaLink DSC, PHLocation, Pushover, SONOS, Blue Iris, UltraRachio3,
    weatherXML, Jon00 Alexa Helper, Network Monitor, Z-Wave 3.0.1.252

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

    Comment


    • #3
      Originally posted by spud View Post
      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.
      Attached Files
      HS3 3.0.0.500 &HSTouch Designer 3.0.71 with 782 Devices, 479 Events
      Plugin's:
      BLBackup, BLOccupied, BLShutdown, EasyTrigger, Ecobee,
      EnvisaLink DSC, PHLocation, Pushover, SONOS, Blue Iris, UltraRachio3,
      weatherXML, Jon00 Alexa Helper, Network Monitor, Z-Wave 3.0.1.252

      Comment


      • #4
        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?

        Comment


        • #5
          Originally posted by spud View Post
          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?
          HS3 3.0.0.500 &HSTouch Designer 3.0.71 with 782 Devices, 479 Events
          Plugin's:
          BLBackup, BLOccupied, BLShutdown, EasyTrigger, Ecobee,
          EnvisaLink DSC, PHLocation, Pushover, SONOS, Blue Iris, UltraRachio3,
          weatherXML, Jon00 Alexa Helper, Network Monitor, Z-Wave 3.0.1.252

          Comment


          • #6
            Originally posted by spud View Post
            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?
            HS3 3.0.0.500 &HSTouch Designer 3.0.71 with 782 Devices, 479 Events
            Plugin's:
            BLBackup, BLOccupied, BLShutdown, EasyTrigger, Ecobee,
            EnvisaLink DSC, PHLocation, Pushover, SONOS, Blue Iris, UltraRachio3,
            weatherXML, Jon00 Alexa Helper, Network Monitor, Z-Wave 3.0.1.252

            Comment


            • #7
              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:

              Comment


              • #8
                Originally posted by spud View Post
                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:
                HS3 3.0.0.500 &HSTouch Designer 3.0.71 with 782 Devices, 479 Events
                Plugin's:
                BLBackup, BLOccupied, BLShutdown, EasyTrigger, Ecobee,
                EnvisaLink DSC, PHLocation, Pushover, SONOS, Blue Iris, UltraRachio3,
                weatherXML, Jon00 Alexa Helper, Network Monitor, Z-Wave 3.0.1.252

                Comment


                • #9

                  Comment


                  • #10
                    Originally posted by spud View Post
                    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?
                    HS3 3.0.0.500 &HSTouch Designer 3.0.71 with 782 Devices, 479 Events
                    Plugin's:
                    BLBackup, BLOccupied, BLShutdown, EasyTrigger, Ecobee,
                    EnvisaLink DSC, PHLocation, Pushover, SONOS, Blue Iris, UltraRachio3,
                    weatherXML, Jon00 Alexa Helper, Network Monitor, Z-Wave 3.0.1.252

                    Comment


                    • #11
                      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?

                      Comment


                      • #12
                        Originally posted by spud View Post
                        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.)

                        Originally posted by spud View Post
                        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!
                        Attached Files
                        HS3 3.0.0.500 &HSTouch Designer 3.0.71 with 782 Devices, 479 Events
                        Plugin's:
                        BLBackup, BLOccupied, BLShutdown, EasyTrigger, Ecobee,
                        EnvisaLink DSC, PHLocation, Pushover, SONOS, Blue Iris, UltraRachio3,
                        weatherXML, Jon00 Alexa Helper, Network Monitor, Z-Wave 3.0.1.252

                        Comment


                        • #13
                          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!

                          Comment


                          • #14
                            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.
                            Last edited by Erich; December 26th, 2017, 03:33 PM.

                            Comment

                            Working...
                            X