I found the easiest way (for me) to handle this was with atomicState, tried state but was surprised when it did not work as expected. Likely due to state not being saved to app ends and atomicState is instant update. Looking at the hsmStatus queue worked but due to multiple armingAway events I was forced to use time on the compare. Decided to use atomicState instead.
Sample code
def alarmStatusHandler(evt)
{
def theAlarm = evt.value as String //curent alarm state
def lastAlarm = atomicState?.hsmstate
atomicState.hsmstate=theAlarm
then to dump the dup armingAway/Night/Home events
if (theAlarm == lastAlarm)
return false
Okay - I get it. My setup isn't working because I'm not actively using HSM. I thought HSM had its own internal settings for away, home, night as ST does but I see that was a bad assumption. Within ST I also don't use SHM but I can still set the SHM status to away, home, and stay. I was trying to do the same here. At least now I know what I need to do. For what it's worth seems to me you would want to have a generic capability to set HSM to away even if you don't have any sensor tied to this mode. Anyway, i understand your design language now and I will adapt my app accordingly.
One person sets "Arm Away" and it shows on the panel. Second person arrives home and sees this set. Tells them the intent of the first person who left. Another perhaps more practical use is if a third party app reads the status of Arm Away that Hubitat doesn't know about. The more practical scenario is for future expansion of HSM use - allowing the intent to be implemented even before the practical application is active. All that said, I get why you did what you did and I'm not even asking it to change. I just found it confusing that it was different than what I expected from how ST works. I know there isn't any love there but my app has to play nice with both and I bounce back and forth so when I find random inconsistencies like this it confuses me. Thanks again for giving me some of your precious time on this. I know how busy you are. I now have what I need to fix my HousePanel app.
Good idea. I don't have any sensor paired to my Hubitat hub. I'm only doing this to support other users of my app that do. All my sensors are still on the ST side. I will try using a few virtual sensors to see if that makes it work.
Sure enough - once I added a virtual contact everything started working as it should. The arming works and reading the status even works. Thanks all for your help with this.
I can think of one scenario, albeit probably one that won't occur frequently. That would be for those running multiple hubs, with HSM running on each remote. It would be useful to have one of the hubs act as a central HSM arming/disarming point without having to use virtual devices. Again, it's probably not going to be that common of a need, outside of my own, of course.
Remoting the devices certainly works and I suspect that's how most people will probably do it once HSM support is released. That said, there is a benefit from processing at the edge too. Having standalone HSM's running on multiple hubs allows one to create unique security partitions with zoned alarming, yet still having centralized control in one place. This is exactly how I'm doing it now in my rental property (in which I also live in). One hub manages security for common areas, the other for the apartment in which I live. i.e. I don't want sirens blaring in the common areas if my DW decides to do laundry in the middle of the night because she cannot sleep and forgets to disarm the system.
Like I said, probably not going to be a common use case but its too early to tell right now.
Even so, you'd have to show a use case where having an arm state for which there were no sensors and no alerts makes any sense. It's sort of pointless except in some contrived abstraction view. It does nothing.
Not so if there exists the possibility of also setting the alert state programmatically. The remote HSM partitions could then trigger alerts on a device-less central HSM and indicate which remote partition was triggered.
As I said I’m probably unique right now. I have a workaround planned for this in the next HubConnect release so I wouldn’t worry about it.
