I am noticing an issue that when the below rule is triggered HSM will arm and then 10 seconds later disarm. If I trigger a mode change to away manually the system arms properly and does not disarm. It seems to only happen when mode manager changes to "away" based on presence.
As a total nubie on this subject, why the NOT after your ELSE-IF? Doesn't that make mode away(false) become true?
Look at this message topic. Instead of using modes for arming/disarming, I set up (with help) a rule to arm and disarm based on whether the presence sensors are present or absent, eliminating mode manager entirely from the process. So far, it is being very reliable.
I have had it working for a while, its only recently I have noticed the issue. I am going to delete and re-create the rule and see if it helps.
I wish for you success!
Looks like the issue still exists after re-creating the rule. This last time 5 minutes went by before it disarmed on its own.
This was working, so not sure what changed.
Did you look at the rule I made (with the help of Bruce)? It has been working great since I got it set up.
Also, look to see if you still have some arm/disarm parameters in the HSM that are conflicting with your rule. Once I set up the rule above, I went through and deleted the sections in automatic arming/disarming related to the Modes since the rule is now performing that function.
Thanks for sharing , but I never had anything setup in HSM directly I only triggered HSM arm/disarm with RM based on mode changes. It may be something in a more recent update, I know there was some changes in 2.1.2 with HSM, but nothing that looks like it could cause this issue. For now I will just setup a different rule with presence as you did, but this is something that should be looked into.
What is interesting is I have a rule setup to "arm-home" when mode changes to "bedtime" and that works without issues every time. It seems to be only related to either away mode or 'arm-away', but then its also not consistent. Today away mode was triggered two times and one of the times HSM did not disarm until someone arrived back to trigger a mode change, but the other time it just disarmed 5 minutes later without any mode change.
Indeed this is interesting. I separated the modes from the HSM so I could use modes with the thermostat. Once I did that, the thermostat started behaving properly. Having modes run the thermostat and the HSM seemed to have some conflict. I can't say for sure, but I am relating my observations.
I do not even have my Ecobee's in HE currently so not using modes with thermostats so I doubt that it is conflicting.
There is defiantly inconsistencies and a possible bug with HSM and with arming. For more testing this time I used HSM instead of RM and setup the system to armAway when mode becomes away and disarm for day,morning, etc. modes. What I have found is that if there is no delay added the system will armAway or armHome, but if you look at the following log you can see HSM is actually arming, then disarming and arming again for some reason.
Disarming always seems to work fine though.
If I add any delay, it could 10 seconds or 10 minutes to the arming process, then it fails to arm and I see the following in the logs, now this delay issue could be another problem, because I noticed the logs under my AlarmDecoder app and not HSM.
What does your Mode Manager look like? It may be that something in that setup is working against what you have set in the HSM's automatic arm/disarm settings. Also, what is triggering your away/home mode changes? Do you have presence devices (key fobs, etc.) or are you using the app's Geofencing?
You are not providing enough context information. Show Location Events log.
Do you have any rules or other apps that are telling HSM to do something? It looks as though some external thing is sending a disarm command to HSM in response to either it arming or in response to the mode change.
Whenever HSM initiates some action, you can see "hsmEvent" in the second column. Those entries that are blank in the second column are coming from something else.
Also, show the App Events for HSM for that same period. From gear icon for the app, on the app status page.
The only other rule I have setup is the following, but it is for a different mode and does seem to work properly.
That rule is disarming HSM in the ELSE part of the Conditional Action!
You can tell from the logs that it is starting the delayed arming, but gets immediately disarmed. There's your culprit.
Wow, yeah I guess I missed that so its basically disarming anytime other then the condition I have set. I will change that to an Else-If and setup the correct conditions. Thanks