Security Mode / Security System bemusement

Background information: There is a one to one relationship between the Security Mode in a Location and the STHM security status. Less obviously, when the Security Mode changes the armAway, armStay or disarm command is called for any device in the Location with the securitySystem capability (I don’t know by what, it just happens). Basically it allows the Security Mode to be used to arm and disarm third party security systems.

I have a driver based device with the securitySystem capability plus three momentary buttons. All it does is track the Security Mode automatically, and the buttons allow me to manually set the Security Mode via Rules.

This was working perfectly until the last week or two. Now a glitch has appeared:

  • In the evening I set the Location Mode by a Rule. This works.
  • Setting the Location Mode arms the Security Mode by a Rule. This presumably works because …
  • Changing the Security Mode arms STHM automatically. This works. However …
  • Changing the Security Mode should arm my virtual device. This has stopped working. Pressing my buttons no longer seems to work either. However …
  • If I use STHM to disarm and rearm sanity is restored. My device is updated and things start working normally again.

The similar sequence for disarming in the morning works fine.

I haven’t attempted any deeper diagnostics yet. I thought I’d see if anyone else has spotted anything odd going on.


I just tried switching the Location Mode manually while watching my Edge driver logs. The first change, which would have changed the Security Mode to Armed(Stay) did not result in any activity. All further changes behaved as expected with the Edge driver logging the command being called. It is like something somewhere had fallen asleep.

1 Like

I saw the same when toggling STHM directly - the first change failed to trigger the driver, while subsequent changes worked. I guess we should expect some bugs considering we’re exploiting undocumented behavior?

1 Like

Perhaps, though I am not sure if we are exploiting undocumented behaviour or the undocumented behaviour is exploiting us. The annoying thing is that it was working so nicely, and then suddenly it wasn’t.

I’ve always considered the ‘security system’ stuff and the old ‘alarm system’ stuff to be alongside ‘device health’ as ‘things it is incorrectly assumed that the users know all about as it would be ridiculous not to have told them’.

1 Like

It is probably significant that after my noodling in the afternoon things worked as intended last night, but tonight it was back to being odd.

I’ve been seeing quite unreliable behavior from the securitySystem capability as well. I have a security system driver that looks for the arm/disarm commands from STHM but they seem to be received only sporadically. Using the mobile app to manually change STHM state to arm or disarm seems to trigger it more reliably, but if STHM arm state is changed via automation routine (based on location presence), it’s unreliable.


I just wanted to note on this thread that over the last few days my securitySystem device has resumed tracking the Security Mode reliably.

I shall also note that it is a new device on a new Location on a different shard.