location.hsmAlert always returns null (for me), yet the hsmAlert value is available for testing in RM.
Is there any way to get the hsmAlert value in an app or device handler without subscribing to the hsmAlert event?
tag: @bravenel
That's what it appears like to me. You can only get events from hsmAlert, you can't fetch the current status. Not saying that's how it "should" be, just saying I'm seeing the same thing as you, although I can't imagine why you shouldn't be able to do that. But then again, location has always been a special case.
Not all location events have corresponding states that are available, in fact most do not. Location events are just that, events.
So, no, if you want to know the last event value you would have to subscribe to the event, and store it somehow for later reference. This is what RM does, and the value of hsmAlert is only available when it is the last event for that rule. RM puts each trigger event into state, for later reference.
4 Likes
I want to get the hsmAlert event value in a Device Handler, and it always fails with the following error when attempting to subscribe
subscribe() is applicable for argument types: (com.hubitat.hub.domain.Location, java.lang.String, java.lang.String) values: [Arn's Hubitat, hsmAlert, hsmAlertHandler] on line 190 (updated)
Subscribe command
subscribe(location, 'hsmAlert', hsmAlertHandler)
and always works in a simple test app.
I suppose a workaround is subscribing to hsmAlert in an app, then when triggered executing a subscribed device's command passing the hsmAlert value, then storing that value in the device using an updateDataValue. Kind of convoluted but I'm out of ideas.
Is there a better option?
can you gather the previous events
getLocationEventsSince()
I don't believe that drivers can subscribe to anything, only apps can do that. So, you would have to write a service manager app to subscribe to the events and then use that app to send the data to your device. Or, simply use the app to do what you are trying to do.
@Ryan780 is right: you cannot subscribe to events in a driver (they are called Device Handler on some other platform, not this one). It seems that your desire to do so possibly suggests that your overall design idea is flawed. Drivers manage individual devices, and generate events, maintaining the state of device attributes. Apps consume events through subscriptions, and can reference driver attributes, and invoke driver commands. Driver commands may cause the connected device to do things, and/or may change attributes. The logic for an automation resides in an app,
So, reconsider your overall design, and the allocation of responsibilities between app and driver. Even when you have a service manager model, the partitioning should be such that the logic is in the app, not in the driver.
1 Like
Please forgive my misuse of terminology from one platform to another, I also code on the other.
My initial requirement was simply getting the current location.hsmAlert value in a driver, but that does not function.
I never wanted to do a subscribe in a driver, but that appeared to be the most direct route. I've learned that is not an option.
I have it worked out, an app subscribes to the hsmAlert event, then issues a device command to the subscribed devices that stores the value. Since the app already subscribes to hsmAlert it was easy to code. Convoluted, but it'll work.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
