Looking for some help with this issue that I just noticed.
I have been looking to activate some actions based on hub HSM status. Simply put i want to turn things down when we leave the house and set the system to Armed/Away, then return some of those same items to their previous state when we get home. A great example of this would be fans as they don't cool houses but people right.
I have some rules already written to do this but they only work part of the time. The reason they only work part of the time is because of some weird states coming from HSM. The simplest way to put it is that I have a pretty standard rule that shuts everything down when HSM reports the Armed/Away state and then saves some device states to hub variables. The rule actually works great, but it is getting triggered by Armed/Away state when the hub is set to Armed/Away and when Disarmed is triggered from the Hubitat UI. Based on timing it looks like when Disarmed is submitted it first submits a Armed/Away, and then is immediately followed by Disarmed. The hub effectively executes the Away action first (a second time) and then sets the hub variables to the off state. This means the end result is nothing returns to it's previous state. I hope that make sense.
What is really strange is so far this only seems to occur from the Hubitat UI. If I use my Ring keypad it seems to work fine.
I just thought of one more idea which is to remove and reinstall HSM, so we will see what that yields, I have had that fix a few issues in the past, but this is strange. Does anyone else have any ideas
So i went through and setup HSM Again and it is still occurring. This is what the logs show.
Thos show exactly what I am talking about. That rule should only be triggered by the Armed/Away state.
I just added a delay step now where it has to stay in Armed/Away for 3 seconds to see if that will help.
The delay added to validate the state of Armed/Away seems to have done the trick, but i don't think this should be needed.
@bcopeland or @gopher.ny
I have wanted to make sure there was nothing wonky with my prod setup so I created a quick test on my dev hub. It experienced the exact same thing.
HSM was never installed on that hub and it only has a virtual contact sensor and Virtual motion sensor setup in it for the intrusion detection.
You need to show us screenshots of the rule in question and the HSM setup page.
Here is the rule now. It includes a delay now that is a work around.
I don't thin the rule is the problem as HSM can be sending the Armed/ Away event right before the Disarmed event. That was the point of doing it on the Dev hub I have.
Yeah, I can reproduce the behavior. I will look into finding a fix for it.
@bravenel
Even what i thought was going to be a work around i am seeing filures. It looks like my rule i attached above is also triggering when the hub goes into ArmingAway as well as ArmedAway. This is also triggering a similar condition where the automation isn't working right.
Is this goign to be a 2.3.3.x udpate, or do you think it will make it into one of the minor releases for the current build.
So just to explain my last post here is a screen shot of the rule's execution in the Log. Looks like it triggered the rule when it went to Arming Away.
Here is the rule
I also noticed that when i clicked on the Armed/Away button from HSM to go into Armed/Away it would cycle through the delay and then restart the count down.
Similar to the preivous test i replicated it on my Dev hub and the rule ran twice. Once when in the ARMING state and then once when Armed.
It looks like RM is treaking Arming and Armed states the same.
Please show the Event Subscriptions for the rule from the App Status page (gear icon).
The new firmware 2.3.2.138 does seem to have fixed the first issue with a Armed/Away event being sent just prior to Disarmed when the diarmed button is pressed.
The issue with RM Rules triggering on any state change for HSM still seems to be a issue. Here are some screen shots to show how the rule is setup to confirm the issue is still occuring along with the logging.
I will look into this...
It has the wrong subscription for the Required Expression, and there is one other problem as well. Looking into a fix for these.
1 Like
Thanks for the update. I am glad to hear it has been identified
There will be a fix for this in the next release. I've been testing with a rule just like yours. I did notice one thing: If HSM has a delay in arming Away, which evidently you had or were testing with (HSM Status armingAway), that event should (and now does) cause the Required Expression to become false, thus not triggering on the subsequent armedAway event. This rule would only trigger without a delay in arming Away. It does not (in latest version) fire on any other HSM Status event, and any other HSM Status event will make the Required Expression go false. Sound right?
1 Like
So the delay was added after I started this thread to deal with "Disarm" button action triggering both a Armed/Away and Disarmed event. That was fixed in the most recently release so thank you.
If I am reading what you said right I think you are pointing out a logic issue with my rule. Simply put my Regular expression and trigger combination would never work becuase the "arming away" event would trigger it to be false. ie i would never go from Disarmed to Armed/Away with the delay. Not exactly the intended result i was looking for, but that does sound like how it sould work.
I will go back to removing the delay and look forward to the fix to the subscription for required expression.
Easy fix: Just add armingAway to the Required Expression. So it's
HSM status is Disarmed OR HSM status is ArmingAway
Then it won't go false when the armingAway event happens.
2 Likes
