Auto Arm loop

[champson]

Hi Adam,  I have seen an interesting effect of using the auto-arm function.   I had the auto-arm value set to true for one group, and it seemed to be working fine.   One evening, my wife tried to disarm the group using a key that was disabled.  This caused the alarm to sound, and since I had no siren connected, it was left in the alarm state overnight.
When I went to disarm it in the morning, I noticed that it was not possible to disarm, as immediately the group was auto-armed.   The event log may be seen below:

78. 12:05:35 Mon 12.10.2020 Key #1, linked to champson disarmed.
79. 12:05:35 Mon 12.10.2020 Group 1. Garage auto armed. SMS
80. 12:05:35 Mon 12.10.2020 Group 1. Garage disarmed.
81. 12:05:44 Mon 12.10.2020 Key #1, linked to champson disarmed.
82. 12:05:44 Mon 12.10.2020 Group 1. Garage disarmed.
83. 12:05:44 Mon 12.10.2020 Group 1. Garage auto armed. SMS
84. 12:05:58 Mon 12.10.2020 Group 1. Garage armed.
85. 12:06:14 Mon 12.10.2020 Key #1, linked to champson disarmed.
86. 12:06:14 Mon 12.10.2020 Group 1. Garage disarmed.
87. 12:06:15 Mon 12.10.2020 Group 1. Garage auto armed. SMS
88. 12:06:22 Mon 12.10.2020 Key #1, linked to champson disarmed.
89. 12:06:22 Mon 12.10.2020 Group 1. Garage disarmed.
90. 12:06:22 Mon 12.10.2020 Group 1. Garage auto armed. SMS
91. 12:06:27 Mon 12.10.2020 Key #1, linked to champson disarmed.
92. 12:06:27 Mon 12.10.2020 Group 1. Garage disarmed.
93. 12:06:28 Mon 12.10.2020 Group 1. Garage auto armed. SMS
94. 12:06:41 Mon 12.10.2020 Group 1. Garage armed.

My phone is full up of auto-arm messages :)
Cheers,
Charlie.

[vysocan]

Hello Charlie,

the auto arm is checking for last PIR state timestamp in all zones of the group. So let me understand if there is really a bug. If you do not trip any zone in that auto arm group how did you get to authentication unit? Or do you have authentication unit outside of group perimeter?

But still there is probably room for adding a check not to auto arm group that is in alarm state.

Adam

[champson]

The strange thing is that I don't seem able to disarm the group.  You can see from the log entries that as soon as I authenticate a key to disarm the system, it is immediately armed again.  Shouldn't the disarm event set the group to unarmed and reset the auto-arm timer?

[vysocan]

The key disarm the group. But the auto arm is calculated from zones belonging to this group. That is if no zone is tripped, then the group does not know that it should not do auto arm right after you disarm.

That's why I've asked you, that you have authentication unit covered by zone.

[vysocan]

Responsible code in ohs_th_service.h

// Group auto arm
    for (uint8_t groupNum=0; groupNum < ALARM_GROUPS ; groupNum++){
      if (GET_CONF_GROUP_ENABLED(conf.group[groupNum]) && GET_CONF_GROUP_AUTO_ARM(conf.group[groupNum])) {
        tempTime = 0;
        // List through zones
        for (uint8_t zoneNum=0; zoneNum < ALARM_ZONES ; zoneNum++){
          if (GET_CONF_ZONE_ENABLED(conf.zone[zoneNum]) && GET_CONF_ZONE_GROUP(conf.zone[zoneNum])==groupNum){
            // Get latest PIR
            if (zone[zoneNum].lastPIR > tempTime) {
              tempTime = zone[zoneNum].lastPIR;
            }
          }
        }
        // Group has at least one zone && time has passed
        if ((tempTime != 0) && ((tempTime + (conf.autoArm * SECONDS_PER_MINUTE)) <= timeNow)) {
          // Only if group not armed or arming
          if ((!GET_GROUP_ARMED(group[groupNum].setting)) && (group[groupNum].armDelay == 0)) {
            tmpLog[0] = 'G'; tmpLog[1] = 'A'; tmpLog[2] = groupNum; pushToLog(tmpLog, 3);
            armGroup(groupNum, DUMMY_NO_VALUE, armAway, 0);
          }
        }
      }
    }

[champson]

OK I see now.  The movement detector in this zone has the sensitivity turned down currently, so probably there is no alarm condition.  I need to connect up the reed switch for the door entry, which I haven't done yet, and I guess once I do this it won't be in a condition where it can auto-arm.

[vysocan]

Yes, this gateway behavior expects that authentication unit is "guarded" by zone. It should be true for even for not auto armed groups.

I have another idea,I think about new logical unit called "door" or "entry" unit. It would be hardware of authentication unit that would not be inside any zone, plus a relay( or solid state relay), and extra iButton probe or switch. When you place one iButton outside of property and second inside, one can with iButton from outside control the relay to allow the door (relay) to open for some defined period of time. And same can be possible from inside. It might be useful for fence gate, or maybe for shed.
Basically an authentication unit that is not "guarded" by zone, that will force all zones in a  group to update the PIR timestamp.  Just an idea for now.

[champson]

Hi Adam,
I did some testing this morning.  I set a delay multiplyer of 1x for the entry contacts and PIR.   This should have resulted in the system alarm occuring after 20 seconds,  but actually I saw the same as before, where the group authentication node just beeps and flashes red continually.
I have turned debug on and captured the following.


ch>
ch> debug on

Debug ON.
ch>
ch> RS485: 2048, 8-16
RS485: 0, from 1, ctrl 0, length 11, Data: 4B, 69, 0, 1, 74, 8F, 74, 1, 0, 0, D0,
Received Key, node index: 2
Check key for group: 0, type: armed away
Key matched: 3
RS485 send cmd: 10 to address: 1
RS485 send cmd: 15 to address: 1
RS485 send cmd: 12 to address: 1
RS485 send cmd: 12 to address: 1

ch> RS485: 2048, 8-3
RS485: 0, from 1, ctrl 1, length 2, Data:
RS485: 2048, 8-12
RS485: 0, from 1, ctrl 0, length 7, Data: 53, 54, 0, 53, 6B, 48, 41,

ch>
ch>
ch> Radio from: 2, RSSI: -95, Data: 53, 54, 0, 23, 5B, 9A, 41,
Radio from: 2, RSSI: -95, Data: 43, 2,
Modem alive check: OK.
RS485: 2048, 8-16
RS485: 0, from 1, ctrl 0, length 11, Data: 4B, 69, 0, 1, 74, 8F, 74, 1, 0, 0, D0,
Received Key, node index: 2
Check key for group: 0, type: armed away
Key matched: 3
RS485 send cmd: 16 to address: 1

Here is the log.  After 3 minutes I gave up and disarmed the group.  No system alarm raised still.
92. 12:26:18 Fri 30.10.2020 Key #4, linked to Spare keys armed away.
93. 12:26:34 Fri 30.10.2020 Group 1. Garage armed.
94. 12:26:48 Fri 30.10.2020 Zone 3 Grg Slide Open alarm.
95. 12:26:59 Fri 30.10.2020 Zone 1 Garage PIR alarm.
<< 3 minutes waiting....>>
96. 12:29:56 Fri 30.10.2020 Key #4, linked to Spare keys disarmed.
97. 12:29:56 Fri 30.10.2020 Group 1. Garage disarmed.

Maybe I have misunderstood somthing.

[vysocan]

I will look into it. From first glance this sequence:
RS485 send cmd: 10 to address: 1
RS485 send cmd: 15 to address: 1
RS485 send cmd: 12 to address: 1
RS485 send cmd: 12 to address: 1
seems wrong, it should be:
RS485 send cmd: 10 to address: 1
RS485 send cmd: 15 to address: 1
RS485 send cmd: 12 to address: 1
RS485 send cmd: 11 to address: 1

Command 11 is Alarm state.

Do you remember the 20s delay between:
RS485 send cmd: 12 to address: 1
and
RS485 send cmd: 12 to address: 1
?

Adam

[champson]

Sorry I couldn't see, as the laptop was running the debug console in a cupboard :)

[vysocan]

No problem, already found the bug and just pushed a fix. Small integer overflow.

Please try the fix.

[champson]

Thanks Adam, I will try tomorrow morning.  I also noticed that my RTC battery is showing as 0.0v.  Strange, perhaps it has fallen out.  I will check this also.

[vysocan]

RTC battery voltage is measured every (65536/4) seconds. Since this measurement drains the battery more then the RTC itself.

[champson]

Strange, I just updated to the latest code and took the chance to measure the battery with a DVM.  It's showing 3.12 volts, but when inserted it still shows 0v on the web interface.  I have noticed this in the past, but it also seemed to correct itself.

[champson]

Thanks Adam, this works great now!

[vysocan]

That is great, thanks!

For RTC battery check after 5 hours.

Also I've noticed you have very week signal from the radio unit. RSSi - 95 is almost absolute minimum, if I remember well -103 or -108. Good signal is around -85. Try, for example, to redirect the antenna, so they are parallel.

[champson]

Ah yes, that's my fault.  I haven't yet soldered the coil antenna on the wireless remote node :)  Thanks for reminding me.  The wireless node is for the second group of zones, which I will move on to next week hopefully.  

[vysocan]

FIY, Just checked again, RTC battery is measured 1 minute after start, then again every ~5 hours.

[champson]

It's strange; now it's been up for over 6 hours but still reading zero.  I wonder if it is becuase I have temporarily removed the external 12v backup battery.  It seems to be showing that battery is OK, even though it's not connected.  

[vysocan]

The PSU is not that smart, it signals only when battery is bellow 11V. It is not able to sense its peesence until AC is turned off. Gateway just display the state eeported.

Do you have the RTC inserted correctly?