HSM issue

📢 Feedback
1

Issue: When Configure automatic arm/disarmSetting is set for Arm-Away with Away mode with an Away exit delay time coded

  • then the HSMmode is set to Away and HSM Arm State is already armedAway or armingAway

  • the system always reissues an armAway request creating an additional armingAway event

This also occurs with other modes/armstates when a delay is set for the respective arm state.

Suggested resolution: Do not reissue armAway request when system state is armedAway or armingAway state, but do change the mode.

Reproducible: Yes, 100%

2

Is there a downside? I mean, there are actually two events, but you are asking to suppress one. Seems like others (and of course I'm thinking HubConnect and HSM in an upcoming release) would want to know about Events, period.

let me flesh that out a bit :slight_smile:

HubConnect will be needing to exchange SHM and HSM states.. without seeing all the events, would it be accurate?

3

I'm using arm states beginning with "arming" to issue TTS exit messages. When the system event is issued for "armingAway" and there is an exit delay it correcty triggers the exit delay message.

(I like modes to follow the Arm State) Next my Modefix app, notices HSM state is armingAway, sets the Mode to Away when it is not Away, triggering another armingAway event and a second TTS message. Please note the reArm is also issued if the arm state is armedAway.

I've mitigated the duplicate message by using checking the last 2 events and not "speaking" when certain conditions are matched. There are timing issues that make this workaround, rather painful to figure out, but easy to code once understood.

I have no idea how this impacts HubConnect. I do not use it and have no idea if it sends all HE arm state events.

4

Wait... You have HSM armAway when mode changes to away and mode of Away being set when HSM is set to armedAway? Isn't that a circular function? Wouldn't the problem be solved if you only had one controlling the other?

5

If coded to not react when system is already in requested state or mode, No.

My code fixing Mode when arm state changes, is coded so it does not set the mode when it is correctly set.

Simply asking same for arm state when setting it from Mode.

Should be a very simple bit of logic, assuming for Away (not the most sophisticated way to do this but it's easy to read)

if (location.currentState("hsmStatus") =='armedAway'||
    location.currentState("hsmStatus") == 'armingAway')
    {}
 else
   sendLocationEvent(name: "hsmSetArm", value: "armAway")
6

But that would only happen with armedAway because of the exit delay, right? The system isn't actually in armedAway yet. For example, if you're in armedHome, issuing another armHome doesn't actually do anything. You'd have to check for Armed Away or armed delay. I know there were changes in this area to get setups with multiple keypads to work correctly when arming from one of them. @mike.maxwell was working that I know. Maybe he can shed some light.

7

I'm using my own converted version of ST SHM Delay and a Mitch Pond converted DH.

No issues other than my initial request, and I've mitigated it with some code assuming it may never be fixed.