I am trying to set up a notification if my alarm panel reports an error, but I don't see an option to do so through the Notifications app. Rule machine is able to see all the attributes (see below) -- is there a workaround to capture the attribute "Error_Partition_0" ?
1 Like
+1 from me.
I need a way to trigger notifications from the inbuilt app without misusing the standard āpresenceā attribute for this purpose.
Example: a custom alarm attribute firing an event when a water shut-off valve didnāt close. Or a door opener didnāt close the garage door.
Not without using Rule Machine or a custom app for part of that workaround, in which case I'd say you might as well use Rule Machine for the whole thing. (An alternative that would also work is modifying the driver to use a "standard"/capability attribute for this.)
The built-in Notifications app does not support custom attributes, just the set of "standard" attributes provided in the UI. This would be an interesting feature request, but in the meantime, one of the above will have to do.
That is an error in the driver, as "TEXT" is indeed not a supported type for an attribute. Perhaps the driver author meant "STRING". That will need to be addressed in the driver, whether by you, the original developer, or someone else.
It may be worth to check for updates of whatever driver you're using or read through the forum thread where developers usually post about their code to see if anyone else has had as similar issue or if the author has already addressed the problem.
2 Likes
Change line 58 in the driver's code to have "string" instead of "text" and try testing it out. Think that should do it.
@dcaton1220 I submitted an issue for this on the project. Is it safe to change directly or wait for an update and upgrade through Hubitat Package Manager?
You can certainly change the code on your own hub yourself; any future HPM updates will just overwrite that (as would a repair with the current/"bad" code if you do that for some reason). There is also no guarantee that an author will update their code, or any timeline for when it may happen if it does, though most authors are fairly responsive. (Some authors also prefer the forum over GitHub or vice versa, so if there's a thread here, you may wish to read that too.)
So, basically, up to you. 
Personally, I'd change lines 58-61 in the driver myself since they all have the same problem and it sounds like you want to use this now, but that's all your choice.
1 Like
I apologize for not being more active here, but I've been away most of the summer, and won't return home for another week. I do have some code updates to release, but there's no alarm system here so I can't test anything until I return.
I'll look into any issues that were posted on GitHub and try to get something out soon as I get an opportunity after I return. I did fix some data type issues that could cause problems, and a few other minor things. It's hard to test this stuff unless my wife is out of the house for a while though. She's not a big fan of me setting the alarm off 
As others have said, any future HPM updates will overwrite any changes you've made, but you can always save your changes and apply them again, if need be (hopefully not).
2 Likes
I appreciate the guidance. I've made the change and it is recognized in Rule Machine.
you might as well use Rule Machine for the whole thing
When I try to set up the Notification from Rule Machine, I don't think it's actually reading the attribute:
In this case the value of the attribute (Error_Partition_0) is DISARM_FAILED: Invalid usercode
Not sure what I'm doing wrong
Even if rule machine picks up the attribute it wont work till the type is correct.
I assume this is because you think the UI is displaying the wrong values? If so, device, event, value, and time refer to the last trigger event, but you need an actual trigger event for them to update. Manually running this rule actions will not do this, and the UI will often report surprising (to users) values for one or more of these variables for that reason. (Notably, it will not "retroactively" read anything from any devices that happen to be used in triggers; again, you need an actual event, and then it should refer to those values.) The now variable is an exception--it is always the current time--and is likely the value you actually see displayed in the current value.
That being said, there also appears to be something odd with how your trigger event is displaying. I'm not sure where that null is coming from at the end. There was a UI oddity that prompted for a value in some (all?) cases in the past when it shouldn't have (it doesn't make sense; any value is literally any value and shouldn't require you to provide a value), though it still worked correctly--which I thought was supposed to be fixed. "Changed" might work instead if this doesn't, though that depends on what the driver does (i.e., forcing state changes or not for subsequent events with the same value) and what you really want.
The type has been fixed (the rule is able to be created).
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
