I don't understand why all of the boolean debug statements are false. I'd expect them all to be true.
I think I noticed this same thing a while back and wasn't 100% sure what's going on (someone more familiar with the inner workings of the platform might have to chime in; my guess is that these, for whatever reasons, are not references to the same object). What I usually do instead is something like this:
settings["myDeviceList"].any { it.deviceId == evt.deviceId}
...or, in other words, comparing the deviceId property instead of the actual DeviceWrapper or DeviceWrapperList objects (maybe one of these isn't really one of those types and that's what's causing this).
1 Like
Thanks! That makes sense that we're probably not comparing references to the same object. This is what I ended up with:
settings.humidistats.any{it.deviceId == evt.deviceId}
Is there any benefit to using the string key syntax over the object attribute?
I'd guess nothing significant, if any difference at all; I just have a personal preference for the String key notation since I find it less awkward when I'm building a key name with dynamic components that way, though even then either could work.
And as you might know, even just the setting name itself could work since setting names all get elevated to properties anyway (e.g., just humidistats.any { ... } in your case), but I always feel better about using settings if there's any chance performance matters where I'm using it since this might at least save Groovy from needing to use some "missing property" magic that makes this "elevation" happen. That is pure speculation on my part since I have no idea how Hubitat actually implements this--just the easiest possibility I know of, with also no additional knowledge of whether the interpreter/compiler might be able to see any of this ahead of time and optimize it to be the same anyway. 
(Anyone know for sure? The only tradeoff seems like just a tad more typing to me.)
1 Like
