HSM Intrusion

Hi all,

I searched for this, and I found a few related topics, but I'd just like to clarify my understanding...

I have an LED strip in my Hallway. When the Hallway motion sensor is triggered, the LED is currently set to either Green (HSM disarmed, most probably by Presence) or Red (HSM Armed Away, possibly because Presence didn't detect home-coming, so I have a Ring keypad I can use to Disarm)

I'd like to add a third option, where the LED shows Orange (to indicate HSM Intrusion whilst I was away). However I cannot see that checking for HSM Intrusion is an option. All the other HSM states are possible, but not Intrusion, it seems.

Is my understanding correct? If so, this seems like an omission - surely you'd want to be informed of any Intrusion during your absence?

I realise I can set a variable on HSM Intrusion alert, and then set my LED based on that, but that seems like an unnecessary step

Keith

Is that not what this does?

The biggest piece of information I see missing from your question is where you're looking to see this, notably, what app. The above answer provides a Rule Machine trigger that will capture this event. If you're not looking to trigger a rule based on this event (or you aren't using RM at all), you'll have to do something a bit more creative (it's not available as a condition per se, presumably because it's just an event and the HSM status itself still remains armed, etc. as it was before), but there are ways to ultimately make it do what you want.

But it depends on where you're looking and how you want to do it. :smiley:

2 Likes

No, not at all. As I mentioned in my original post, my trigger is the Hallway motion sensor detecting movement, not the changing of HSM status. This rule is triggered by someone entering or leaving the house - you cannot enter or leave the property without going through the Hallway.

I'm not so much interested in when people leave the house, rather when they return. At this time they will enter the Hallway, they will trigger the Hallway motion sensor, and then at that point I want to indicate to whoever is in the Hallway what the current status of HSM is. I do this by flashing an LED strip in the Hallway with a specific colour:

Green: HSM is Disarmed. This usually happens automatically because HE detects the Presence of myself or my wife returning to the property

Red: HSM is Armed. This most likely happens because HE does not detect the Presence of myself or my wife. Presence is a bit suspect as we all know, and I don't want to set off the alarm if it's not been automatically disarmed. For this situation I have a Ring keypad linked to HSM, and I can then manually Disarm HSM via the keypad code (at which point the LED turns green)

What I want to add is a third colour:

Orange: HSM Intrusion has been triggered whilst we have been away. This would override the Green/Red indicator because obviously I'm very interested to know if HSM has been triggered, so that I can check out what happened.

I'm using RM5 to query HSM status as condition in an IF/THEN conditional, once my rule has been triggered by the Hallway motion sensor

This works fine for most of the HSM status types, (including the ones I use for my Green/Red indications) but HSM Intrusion is not available for selection, as you can see from the above screen shot.

This seems strange to me. This is not an event at the time the rule runs, because the HSM Intrusion could have occurred hours, days or even weeks ago (depending on how long I've been away). It's a status - HSM Intrusion was triggered - just like the other statuses that are available for query in the drop-down list. All the other HSM statuses here (for example HSM Armed Away) are also not (in this context) an event, because, again, this could have happened days ago. It's the current status of HSM, available to be queried

As I said, I know I could capture the event of HSM Intrusion, and set at variable at that time, and then use this variable to set the colour of my LED strip at a later time when I return home. However, IMHO, it should be possible to query the status of HSM at this later time, to find out if HSM has been triggered since it was last set Armed Away, but that's not currently possible.

I understand what you're asking; @bravenel would be the one to ask about both HSM and RM, but again my assumption is that "HSM Status" in this context refers to the armed/disarmed state of the HSM system itself, which is separate from any intrusion alerts, so it would need to be a different "capability" rather than fall under this one. But I don't think that exists, possibly because it's not clear to me that existence of an un-cleared HSM intrusion exists at all as a state exposed outside the app (just an event). The app clearly does keeps track, of this, at least internally, so perhaps this could be exposed in some other way, or maybe there's another method I'm not thinking of.

In the meantime, there are some workarounds you might be able to use, some of which it seems you may be aware of (capturing the event and then setting a variable, resetting the variable in response to something else, etc.. or perhaps using a virtual switch as a "light" to turn on in HSM for intrusion and then checking that switch state elsewhere).

1 Like

HSM is acting here like an alarm system (albeit one with more capability than most). Every other alarm system I've ever used indicates on the control panel in some way (via lights or display) that it's been triggered. I guess I just assumed (rightly or wrongly) that HSM would provide the same capability.

As you said, there are other ways I can handle this, so it's not a big issue. But it would be a nice addition if @bravenel is feeling generous :wink:

If you open HSM, it does indicate that it's been triggered. That's its 'control panel'. Beyond that, there are numerous ways to display this. It will turn on a switch, turn on a light, send a notification.... How many ways do you need?

It sends an event. You do whatever you want with that event.

But I can't query that from within a rule...

I don't want to react to the event at the time, I want to query the status later...

It just seems odd to me that in an automation hub, I can't automatically query that a built-in app has been triggered. But anyway, many ways around it

Thanks

Trigger on the event and set a Hub Variable. There are no means to "query" apps. What you are seeking is a different design for how apps and the hub work, but there is a totally simple solution to what you need.

But I can query HSM to see if it's in the Armed Away state (and all other states, except being triggered) even though the event that put HSM into that state might have happened weeks earlier. It's not necessary for me to update a variable when I set HSM to Armed Away, and then query the variable later if I want to find out the status

Anyway, as you say, there are other ways to attack this problem, so let's end the discussion here

Not while there is an open misunderstanding about what's going on...

What you are referring to with "query HSM" is not a query of HSM at all, but of the value of a specific system 'location variable' that reflects the status of HSM. The states reflected in that variable are set by HSM:

  • "Armed Away"
  • "Armed Home"
  • "Armed Night"
  • "Delayed Arming Away"
  • "Delayed Arming Home"
  • "Delayed Arming Night"
  • "Disarmed"
  • "All Disarmed"

Triggered is not one of those states, it's an event. HSM can generate a dozen different events. Events are momentary in nature, and may cause the state of an object to change. This location variable that records HSM Status above is not related to HSM being triggered, although obviously HSM must be in an armed state before such an event will occur.

The hub is an event driven system, where events are used to cause state changes. Pretty much any event in the hub can be used in RM to 'capture' an event in order to set a state. States in turn can be queried. Each of the possible HSM events can be captured in this manner, should there be a need to record that event for whatever reason. HSM events are not captured to a system location variable because more than one can occur and be relevant to a given use case (e.g. water and smoke). It is entirely up to the user to decide which of these events should be captured into a state object (variable or device) so as to be queryable as needed.

I'm not misunderstanding, merely questioning the semantics

Earlier you said

so the implication is that this "state" is being stored somewhere within HSM, and thus could presumably be returned from an RM query, much as the other states you mention are

  • "Armed Away"
  • "Armed Home"
  • "Armed Night"
  • "Delayed Arming Away"
  • "Delayed Arming Home"
  • "Delayed Arming Night"
  • "Disarmed"
  • "All Disarmed"
  • "Was Triggered"

I don't see that this is any different than the other states that I can query, and I don't see that it fundamentally breaks the concept that

An event (intrusion, leak, smoke, etc) has caused HSM to enter the state "Was Triggered", in much the same way that an event (pressing a button, setting mode to Away, detecting a non-presence, etc) cause HSM to enter the state "Armed Away".

I don't need to know what event caused HSM to enter the state "Armed Away", only that it did so. Likewise, I don't need to know what event caused HSM to enter the state "Was Triggered", only that it did so. If I want more info on either of these situations, I can check the logs, or write another Rule or something.

But clearly you don't agree, and you're the one in charge :wink:

Thanks for the discussion :+1:

Apps have all sorts of internal states, but there is no hub mechanism to query them. Apps can send events, command devices and some set location variables. HSM sets the HSM status location variable as described above.

The easiest way to do this is to use a virtual switch to capture the Triggered event. HSM can turn on that switch under its Lights options. Then whatever you want to know can be found out by querying that switch’s state. HSM would even turn off the switch when the Alert is cleared.

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.