OK, this has happened a few weeks in a row now. I think it started with 2.1.8, but am not 100% sure.
- I have water sensors setup in HSM
- When the maids come, I always DISARM the smoke/water alarming because they get sloppy/carried away with the mopping
- The last two weeks, maids start mopping and sure enough - I get sirens blaring, water valves closing, etc.
Is this a known issue @bravenel or something new?
Here's a test from the system events. It isn't aq flase alarm, per se, as one of the water sensord was indeed wet. But what is new is alarming even though it shows as DISARMED on the HSM app...
How did you do the disarmAll? Why is there another disarm event 1 second later? What sequence of steps did you do?
1 Like
Good thought/question.
I disarm it with an RM rule (below). The second one might be coming in through HubConnect though. I'll try turning off HSM sync in HubConnect tomorrow and see if that part goes away.
I bet that is the issue... Thanks @bravenel.
1 Like
Well, it happened again.
This time, though, when the maids got there I double checked that HSM said it was disarmed - and it showed as "all Monitoring Disarmed". So I thought I was good.
But as soon as they start mopping the leak alarm went off, sent my pushover message, and closed my water valve.
I give up at this point. I'll just remove the leak sensor stuff out of HSM and implement my own logic. Annoying, as this had been in service for many months and worked correctly prior to either the 2.1.7 or 2.1.8 update... Currently running 2.1.8, FWIW.
Remember above where I asked where the second "disarm" was coming from? This is what is causing this. Having a rule send "disarm" has the side affect of re-arming water and smoke. Did you track down where that was coming from? The reason it behaves this way is that there is no explicit "arm water" command. Water is automatically armed in all cases except for "disarm all".
Argh. OK. Who would have thought disarm = arm? 
I never found where the second/other disarm was coming from. I originally thought it was coming from HubConnect, but I turned off HSM sync in there. So must be somewhere else.
I guess I need to look harder. Thanks for re-iterating what you already told me...
When you mentioned it the 1st time it didn't register that would re-arm the water part. I thought it was more of a "that's weird, where is that coming from" question.
So as with most things, PEBCAK.
2 Likes
I know. The concept here was that water and smoke should be armed all of the time, and not accidentally overlooked when arming the system. So only "Disarm All" disarms them, and everything else arms them.
I'll look at the possibility that 'disarm' after 'disarm all' becomes a no-op.
I'll find the rogue "disarm" sooner or later.
I have one RM that sends a Disarm All on maid code use - that has been there forever. The "new" part is the additional "disarm", which obviously is a problem. I don't remember ever setting that up anywhere, but - well it is happening, so I must have (even if unintentional).
1 Like
I'm putting in a fix for this. It will simply ignore disarm if already seen Disarm All. This fix will be in an upcoming hot fix for 2.1.9.
1 Like
Thanks Bruce!
Side note - I think I found it. When I added keypads to my system (which I subsequently got mad at and smashed in the middle of the night - lol) I setup HSM to arm/disarm based on mode.
When the maids put in their code the mode changes from away to home thus triggering an HSM disarm.
But the maid code is also what sends the Disarm All in my RM rule... So it was a timing thing. I guess putting a 10s delay on the Disarm All (or something like that) would have made it come in last.
Mystery solved (well probably - still need to test it to confirm when I get home, but I'm 99% sure that was it).
1 Like
BTW, this is not something new or that changed in HSM. It's been this way all along. But, I don't see any harm in disregarding a "disarm" command that comes when the system is "disarmAll". The HSM UI knows how to handle this, and doesn't even offer a "disarm" button if the system is "disarmAll". Only from RM could this problem arise.
1 Like
Understood, and agree. It was setting up the disarm by mode that trumped my RM rule Disarm All. User change, not system change. 
The only thing I would add, though, is the HSM UI shows the state incorrectly in this Disarm All then Disarm case. It shows all monitoring as disabled on the "Apps" page, and if you go in HSM details it shows smoke/water alerting disabled too. Which it obviously is not,
That's why I was so flummoxed. As I specifically went in HSM to verify it was off (and it said it was) before the maids got to the mopping.
1 Like
The status shown on the Apps page is not a very reliable thing. For one, the Apps page is static. For two, it could be that the setting of that status happens from the HSM UI. I'll look into that issue also, although it will become somewhat moot with the change to how disarm command from RM is handled.
2 Likes
This issue was fixed in latest hot fix release for 2.1.9.
1 Like
Thanks Bruce! As always, very much appreciated.
