Sigh... Yes, that's what I've been doing but I thought I would use modes for modes (day, evening night perhaps) and use HSM states for the purpose intended, as they cleanly map to alarm system states.
Much as I like HE, I wish it was open source. Not necessarily the underlying OS or whatever customizations they've made to core services and such, but certainly the apps and drivers. I think I'd actually pay MORE for HE if it was a more open system.
Full disclosure I actually started using HSM this past weekend. I use HomeBridge since family uses iOS devices and within HomeBridge there is a Security device that syncs with HSM. I wanted the ability to control things from it so I simply set Home and Away within HSM with a single device so I could "arm" or disarm them. I created a custom app that syncs HSM to modes to alarm system too. I don't use HSM for real situations and alerts other than smoke and water sensors since my alarm system does a great job at the real security.
Stick a virtual button or switch in there not tied to anything.
Yeah, I saw that somewhere. Honestly, unless I'm missing something, the more I look at it I don't see anything useful HSM offers in my scenario. I can mirror the alarm's state in HE with a simple global variable.
Agree with your observation and as mentioned only reason I set it up was to be able to use it from HomeBridge\HomeKit on my iOS devices since its already exposed. HSM is really meant for those without an alarm system but also good for other scenarios to be notified for water leaks, smoke alarms, batteries, etc. That is where I have used it for years.
Personally, I'd never trust a home automation system with those things (except reporting battery status). If my ha system goes down it would be an inconvenience, but would not affect the safety of my family or property. Smoke/fire, water sensors and thermostats, etc. are the exclusive domain of my alarm system.
True but you have the luxury of having the ability to hookup water sensors to your alarm system as example that most don't. So backup for most is HA.
Not so much a luxury, but it does come at a cost. My alarm panel is about $400. But what's the cost in money, time and inconvenience if a leak occurs? Or potential death if a smoke detector goes off and my pets are in imminent danger. I can create some app or rule that works fine 99% of the time but has some edge case that just happens to occur at the worst possible time. Or in a 3rd party app or driver. Or something bad happens and the internet just happens to be out.
My alarm system allows simple automation rules but it's a closed system (more closed than even I would like sometimes). But it's solid, doesn't rely on the internet or the power grid, and is UL certified including firmware updates. No HA system meets that level of QA and reliability, nor would I expect it to at any reasonable price point.
Yeah, and I'm not knocking it (or maybe I am 
). Guess it all depends on your risk tolerance.
@bravenel How can I use hsmAlert, rule as a trigger in rule machine to trigger a RM rule when the descriptionText of the HSM Monitoring Rule has a certain value? For example, I have a Custom HSM Rule (called "DoorAjar") that throws an alert if any door has been left open for more than 5 minutes. I want to trigger a RM Rule when DoorAjar throws an alert. The end goal is to be able to use RM to automatically cancel HSM alerts when all the doors have been closed (and no other alert is outstanding). Any ideas?
I can select to use hsmAlert, rule as a trigger in RM, but I'm not given the option to compare the descriptionText with anything to see what rule triggered the alert??
This needs some attention, as it shouldn't really be trying to convey information in the descriptionText. I need to look into an improvement for this to work the way you want.
No rush, but just letting you know I'm still interested in seeing if this improvement is possible for HSM. Hopefully it's still on your to-do list, which I'm sure is quite long! Thanks!
I'm looking at this now. What would work for you? Perhaps the triggering device name and value could come along with the trigger.
Yes, I think so. That would be the minimum needed for creating RM rules to cancel alerts. Of course, another option would be to specify conditions native to HSM for canceling an alert, but I havenāt thought through that enough to know how hard or complicated that would be.
Oh, also the name of the rule that triggered the alert, if that wasn't already assumed. That way cancel logic can account for multiple rules having a triggering device in common.
Yeah, I figured as much. Not clear how best to do it. The device and event name are easy.
Would it be easier then to just allow the user to specify a condition in each rule that cancels an alert triggered by that rule? Then you wouldn't have to expose anything to RM to achieve the targeted functionality.
Why do you need to cancel the alert? It will alert again without being cancelled.
Obviously, if you set off a siren or started flashing lights, you probably want to stop those. But if all it does is notify you, what difference does it make that it is in the Alert state?
As for adding conditions into HSM Rule to cause various outcomes, I'm not a fan of that. That's exactly what RM is for, because how do you decide what conditions are important? "Your use case is not my use case..."
What I'm thinking of doing is this: An HSM custom rule should include in the event it throws the device and value that caused the alert. I've got a POC of that working already, where device and value show up in RM for %device% and %value%. The other thing is that in RM when you select "rule" as the trigger for HSM Alert, it should offer a list of the HSM Custom Rules, so that you subscribe to one of them.
Yes, this. Plus, without automatic canceling of alerts, my dashboard inevitably ends up reflecting a stale alert status.
Understood and agree. If there's a better way to do it, great!
Sounds perfect!
Download the Hubitat app
