I'm trying to recognize which of multiple-selected devices was the one to trigger a handler. In preferences I have an input called 'switch B' which allows multiple switches to be selected. A subscription to switch B activates an event handler. In that event handler I can log two things:
"settings.switch B[0]" -- which is the name of the first selected device from preferences.
"evt.device" -- which is the name of the device that triggered the event handler.
When activating the first-selected switch of switch B, both of the above appear identical in the log. But when compared in a truth statement, they are false. That is keeping me from using it in an IF statement. Why are these two things not the same?
A snippet of code with the pertinent syntax from the switch B handler:
Thanks for the quick response! I see, I think, that I was using the whole wrapper. I'm still getting my head around that concept.
Your first solution worked. That's just comparing strings, I guess.
I thought the second solution of using the id would be even cleaner, but that one didn't work for me. Are both of those integers?
log.trace "evt.device.idAsLong: ${getObjectClassName(evt.device.idAsLong)}" // Long
log.trace "settings.input1.idAsLong: ${getObjectClassName(settings.input1.idAsLong)}" // Long
You probably know why there are both; I don't. (Maybe something ST did, too?) I do know (and it's why I remember the difference) that this once this took me quite long to figure out my problem when trying to retrieve values from a map based on a key that I thought was a number but wasn't...
I feel like the last option from @bravenel might be best (...device?.id). I take it the '?' converts it to a string. The earlier option (...toLong) will work, too, but only with numeric values, I suspect. I guess I'm going to have to settle on approach and try to stay consistent!
No, that prevents throwing a NPE if evt.device is null. In this particular context of RM, that was a possibility, so the ? protects against that.
It's an unusual case that you'd need to check for this at all, that is, to verify event device against a setting. Usually what you'd do instead is just use a different handler, so that by context you knew a priori what setting to use, or what to do with the event device without needing this test. So think about whether you are overloading a particular subscription/handler. Your app should know at the time it is initialized exactly what to expect from events without need to test like this.
Oh, I see. It's the '.' 'evt.deviceid' is Long, 'evt.device.id' is String. One is a class and the other is an attribute of a different class, I guess.
Good point about the questioning the overall approach, Bruce. It does seem a bit klunky. I'd like to develop a variable:value map where some of the variables are device-specific and updated upon event. But I don't know how many of a particular device I will have until after the preferences are set. I was thinking the handler could check against the settings to know which position on the list was triggering the event - then that would be the variable it updates. The handler activates via subscription to the group. I'm not sure how I would separate those subscriptions to activate different handlers if I don't know how many there will be up front. I'll have to think on it - maybe an each loop of some sort.
In the spirit of your point, though, I think I will consider creating custom drivers that track the variables I am interested in and maintain them with the device. I may be stuck with the same problem as I'll still build the master map (of numerous disparate devices and variables) in the app. But worth a try.
Thanks for the link, @tomw! I keep seeing people comment on how generic groovy is different from Hubitat app code groovy. But I think I'm going to have to at least learn the format & syntax.
Groovy is Groovy. There are a few caveats about working in the Hubitat environment, for example certain libraries aren't allowed for import and the Groovy version itself is old so some newer language features aren't available.
But you can generally use online references for Groovy and even many/most Java-specific ones as a reference for Hubitat development.
(Maybe something ST did, too?) I do know (and it's why I remember the difference) that this once this took me quite long to figure out my problem when trying to retrieve values from a map based on a key that I thought was a number but wasn't...
