I do agree that it would be "nicer" if the system would error out to let you know that call isn't going to do anything.
1 Like
Probably. That would make sense.
I just tried with (location,handler) and it still subscribed to nothing.
Your guess is as good as mine.
We'll have to wait for the all knowing @chuck.schwer to lay down the truth...I guess.
2 Likes
LOL That is even weirder. I believe that works in ST... Oh well. I guess we need Bruce, Chuck, or Mike to chime in and demystify this.
Scratch that...my apologies. It helps when you spell your handler method correctly in your subscribe. hehe 
2 Likes
There is currently no way to subscribe to all events of a device. We discovered this recently and have a ticket open to get it added.
2 Likes
Thanks for clarifying Chuck!
Did this get added or still an open ticket ?
1 Like
I think it must have been added because I can get all events for a specified Hubitat device in Node-RED.
That's coming via Maker API though so Hubitat might have coded that behaviour I'll try and see...
True.
You know, I'm not sure it was ever added. I never remembered to check after this discussion... I don't remember seeing it in any release notes, but something like that might not make it to that list anyway.
There are times it would be very handy, though, so I hope that they do add it...
@JasonJoel I guess I'm not completely off-base in what I was looking for.
I tried:
subscribe(lock, lockHandler)
And got slapped in the log with this:
error groovy.lang.MissingPropertyException: No such property: options for class: com.hubitat.hub.executor.AppExecutor on line 84 (updated)
Btw, where are you finding all the "complete" documentation? All I'm finding is "partial" pages, "todo" lists, and "Nothing found"--and nothing that helps me sort out what the valid parms are, etc. As in, I have no clue what to put for the "what to subscribe to" string nor a clue where to find that information.
Related to this: Noob - Trying to tweak "Schlage Lock Events"
Thanks
1 Like
I think that is the only documentation. Well that, plus what people post on the forums.
Typically if someone asks a question to hubitat, and it is one of the to-do items, they will answer the forum post AND update that part of the official documentation.
That saisd, subscribe is documented, though.
https://docs.hubitat.com/index.php?title=App_Object#subscribe
My guess is you want this form from below:
void subscribe(DeviceWrapper device, String handlerMethod, Map options = null)` (Since 2.2.1)
Which would look something like this in use:
subscribe(nameOfAValidDevice, handleDeviceEvent, ["filterEvents": false])
### `subscribe`
Subscribe to events sent from a device, app or location.
Signature
`void subscribe(InstalledAppWrapper app, handlerMethod)`
`void subscribe(Location location, handlerMethod)`
`void subscribe(DeviceWrapper device, String handlerMethod, Map options = null)` (Since 2.2.1)
`void subscribe(DeviceWrapperList devices, String handlerMethod, Map options = null)` (Since 2.2.1)
`void subscribe(DeviceWrapper device, String attributeName, handlerMethod, Map options = null)`
`void subscribe(DeviceWrapperList devices, String attributeName, handlerMethod, Map options = null)`
`void subscribe(Location location, String attributeName, handlerMethod, Map options = null)`
Parameters
app - Installed App to subscribe to.
location - Location to subscribe to.
device - Device to subscribe to.
handlerMethod - The method to run when an event is received.
attributeName - The name of the attribute to subscribe to.
options - Optional values to configure the subscribe. Possible values:
*filterEvents* - Used for device subscriptions. Set to false to receive all events, defaults to true and events that do not have a changed value will not be processed.I found that documention.
It seems odd that the device handler is a string value in that one case vs a "handler method".
But, also, what I'm missing is documentation on the valid values that can be used for "String attributeName".
I've been programming for 40+ years, so the basic concepts aren't an issue. There are just a lot of blanks to be filled in.
I guess I can try adding an empty/null value for "Map Options" (but the code example I had omitted that entirely, which is why I tried what I did).
Based on your comments here, it sounded like they might not have gotten that format working (the "all events" one)?
1 Like
There is no handler method "type" so it can't be anything but a string - and since a method in a user app can be named anything there is no list that can be provided for this. It is just the name of the method you created in your app you want called when a device event comes in.
Any attribute that exists on a device can be used. There is no finite list, which is why you won't find one. A device handler can add an infinite # of attributes named whatever they want, there is no singular list... Now, there are obviously commonly used attributes - switch, level, etc.
I believe they did, actually - the example/format I quoted above that does not specify any attribute.
This one subscribes to a specific attribute on the specified device:
void subscribe(DeviceWrapper device, String attributeName, handlerMethod, Map options = null)
This one subscribes to all attributes on the specified device (I believe - I didn't try it):
void subscribe(DeviceWrapper device, String handlerMethod, Map options = null)
So again, using this as a fictitious example:
subscribe(nameOfAValidDevice, handleDeviceEvent, ["filterEvents": false])
- nameOfAValidDeivce = any device on your hub
- handleDeviceEvent = the name of the method you create in your user app that you want to be passed the device event when a new event comes in via the subscription
- ["filterEvents": false] = options map specifying to not deduplicate the events before sending them to the handler - aka send them all. The option map portion is optional.
At this point if that doesn't help get you in the right direction I would suggest you find a couple of existing/working user apps and look at how they use the subscribe. It may help clarify it for you seeing an actual working example.
1 Like
I'm give those a try again.
I thought that's what I had "subscribe(lock, lockHandler)" omitting the optional options) when I got the error, so that's why I asked.
And, I'm assuming the "handler" is more like a "void routine(event evt)" -- if it's truly a string, that's an entirely different animal ("nameofmyroutine") which would be unexpected--but that's what it says.
I feel like I'm saying the same thing over and over. But one more try 
.
Yes. It is the name of a method in the app. The name is a string (as names typically are). What is specified there is the method that will be called when there is an event for an attribute that was subscribed to.
You aren't directly calling the method in a subscribe function, so it has to be a string... Just like runIn, or any other async or scheduled call, it needs to know what to run when it is time to do something - but it isn't directly calling it right now.
So for this:
subscribe(nameOfAValidDevice, handleDeviceEvent, ["filterEvents": false])
You would have to have a method like this in your app that would get called when an event comes in for that subscription:
def handleDeviceEvent(evt) {
// Do stuff in here with the event
}
If you look at the older function calls, they got it right--I believe it is a typo in the documentation where they removed "attributeName" but forgot to remove the "string" before it.
This is a string:
string myString = "text in my string"
subscribe(myDevice, myString)
-- or: subscribe(myDevice, "text in my string")
@bcopeland You might want to look at the documentation for the "subscribe" function. It kinda looks like there's a typo in the two new forms of that call (accidentally left "string" in there).
3 Likes
