HSM Custom Rule Bugs?

[Pineview]

New to Hubitat, I apologize in advance if these are newbie mistakes or assumptions. On HE C-8 I’m using HSM to monitor 7 water sensors and 7 smoke/CO detectors throughout my home. All text and light alerts are working fine. I also have a Zooz ZSE19 Multisiren which is working perfectly in HSM for water and smoke/CO alerts and in Rule Machine.

BUG 1: I created an HSM Custom Rule to monitor a contact sensor connected to my basement sump pump alarm. All text and light alerts work fine. I added the Zooz ZSE19 as a siren alert but it doesn’t work. All other alerts work except the siren. I checked my HE log file and whenever the siren is supposed to turn on in the HSM custom rule ‘Sump Pump’ I see this orange warn entry: Ignoring 'on' command because Switch On Action Setting is set to 'Do Nothing'. I tried removing this HSM custom rule then creating again but same results. When adding siren I select Siren & Strobe, same as everywhere else I’ve used it without issue. I observed when re-creating the HSM custom rule, after selecting the siren, the value displayed for Siren Alerts was ‘115, 105, 114, 101, 110 => Zooz Siren’. This seemed buggy to me so I removed the siren from HSM custom rule, added it back in and it displayed the normal ‘siren and strobe => Zooz Siren’ but still not working. I also tried creating a few other HSM Custom Rules using other sensors and the siren doesn’t work for any custom rule I create in HSM with same log error noted above. It works everywhere else in HE including HSM standard monitoring, just not in HSM custom rules.

BUG 2: My workaround fix to get the siren working for my sump pump alarm was to create a rule in Rule Machine that’s triggered by [HSM Alert Reports: Rule, HSM Custom Rule: Sump Pump]. If I understand correctly this should only trigger in Rule Machine when my HSM custom rule ‘Sump Pump’ goes into Alert mode (alarm activated). I’m also using another rule to turn off the siren when I cancel the HSM custom rule alert, that’s triggered by [HSM Alert Reports: cancelRuleAlerts, HSM Custom Rule: Sump Pump]. This is actually working fine with only one issue: Any other HSM custom rules I create also trigger my sump pump siren, via [HSM Alert Reports: Rule, HSM Custom Rule: Sump Pump]. So, rather than this trigger/variable being specific to my HSM custom rule named ‘Sump Pump’ it’s instead triggered by any and all HSM custom rule alerts. If this is how it’s supposed to work then why does Rule Machine provide a dropdown to choose which HSM Custom Rule?

Other than these hiccups I’m really enjoying my new HE C-8! Great design, great product, and the Hubitat community is fantastic. Former ST user for many years so configuring devices and automations/rules on my computer rather than phone is a gift, thank you.

[bravenel]

@Pineview

I see this orange warn entry: Ignoring 'on' command because Switch On Action Setting is set to 'Do Nothing'.

Please show a screenshot of this log entry. On the far left, does it say dev:nnn (where nnn is some number). If so, this is an issue with the siren device. That is not a message generated by HSM Rule.

See what happens if you give the siren an on command from its device page.

[Pineview]

I sincerely appreciate your fast reply. Per your advice I did further testing and screen shots of my log file are below. Yes those are dev:44 alerts from the siren but if I understand correctly the error msg it's sending HE is because HSM Custom Rules is not sending the proper 'Turn On' command to the siren. If you look at my log screen shots for manually turning on the siren from its device page and HSM Water Monitoring successfully turning on the siren the device works and reports to HE 'Alarm is Both' and 'Switch is On'. It's only when my HSM Custom Rule 'Sump Pump' attempts to turn on the siren and fails that the siren reports back to HE 'Switch On Action Setting is Set To Do Nothing'. Today I tested 7 water sensors and 7 smoke co detectors and HSM turned the siren on every time. It's definitely an issue specific to HSM Custom Rules. I'm uncertain how to view HSM application log entries, would that provide more clues? Is there any chance this could be due to DB corruption in my hub? Thanks again for your time and help!

Siren Device Page Test - Works Here:

HSM Water Monitoring - Works Here:

HSM Custom Rule 'Sump Pump' - Not Working:

[bravenel]

I'm not familiar with the Zooz siren device. Please show where the siren setup portion of HSM Rule.

[Pineview]

The driver for the Zooz S2 Multisiren ZSE19 is an official Hubitat driver named 'Zoos S2 Multisiren'.

Device Page Screen Shots:

HSM Custom Rule Screen Shots:

[bravenel]

So with both siren and strobe selected, HSM Rule will send an on() command to the device.

You don't have the device Preferences set properly.

Shouldn't that be set to "Turn On Siren"?

[coreystup]

@bravenel

with both siren and strobe selected, HSM Rule will send an on() command to the device.

I don't have this device, but HSM switching the device "on" when both options are configured as the alert action in HSM doesn't seem obvious to me. I would think HSM would do each action ticked individually regardless of what the "switch on" preferences were set to on the device itself.

[Pineview]

So, I changed the device preference Switch On Action from 'Do Nothing [Default]' to 'Turn On Siren' as suggested. I am very happy to report the siren now works properly in my HSM custom rule 'Sump Pump'. I also tested and confirmed it still works in HSM Water and Smoke CO, Machine Rules, and manually. THANK YOU so much! After exclusion from ST but before inclusion to HE I did a factory reset on the siren so Switch On Action should have been set at factory default, hence 'Do Nothing [Default]'. With that said it was obviously not the correct setting for Hubitat. It still baffles me as to why it worked everywhere else except HSM Custom Rules but I will get over it lol. I can't thank you enough for your quick reply, expertise, time and help!

[bravenel]

@coreystup

HSM switching the device "on" when both options are configured as the alert action in HSM doesn't seem obvious to me

This is how these devices are intended to work. They have commands siren(), strobe() and on(). It makes no sense to select strobe for a siren device that doesn't have a strobe light.

[coreystup]

@bravenel

They have commands siren(), strobe() and on(). It makes no sense to select strobe for a siren device that doesn't have a strobe light.

I follow that, my point was the UI elements in HSM having both options that if ticked individually they would do siren() or strobe() commands. But if both are ticked they do on(). Maybe its just me, but that seems completely unintuitive.

[bravenel]

@coreystup

having both options that if ticked individually they would do siren() or strobe() commands.

That's what the driver does with on().

@coreystup

Maybe its just me, but that seems completely unintuitive.

This was how these drivers were designed, and correspond to device level commands. Why send two commands when one will do?

[coreystup]

My point was the HSM UI is confusing, not any comment on the driver design or efficiceny of sending multiple commands or not.

If selecting both siren and strobe won't actually do a siren and strobe but instead is dependent on what setting is on the device, then perhaps the UI should just say "execute switchon", and then I would know to set the actual action up on the device page itself.

I realize the HSM UI won't change and this is just the way it works - 'because', but just making my own confusion known. The OP had a similar confusion.

[bravenel]

@coreystup

If selecting both siren and strobe won't actually do a siren and strobe but instead is dependent on what setting is on the device,

Actually, HSM Rule should be sending a both() command in this case. Per the capability definition: Driver Capability List | Hubitat Documentation for capability.alarm.

We will put that fix in. I think at the time HSM Rule was originally implement (5 years ago), on() was the way this was done, and our drivers treat on() as both().

As for should two commands be sent instead of one, we will just have to disagree about that. The capability wants both() sent, not two separate commands.