+1 to this question!
If you’ll forgive me for delving into a long, speculative diatribe… I’ve observed in working on my own SmartApps that these Jasco/GE dimmers respond to setLevel() by immediately turning on (if previously off) and ramping to the specified level. This is as expected, I think, but it also makes me suspicious that whatever code it is that executes behind the scenes in the “Hello, Home” Set Dimmer action is not calling setLevel() directly - since the goal would generally not be to turn set all dim levels to the specified dim level AND turn everything on. So the hello,home dimmer thing must be doing something more indirect, or trying to, at least.
Does anyone happen know what might be getting done inside that hello,home smartapp? My hope is that there might turn out to be some other method to call like setLevelButDontTurnOn() … though I’m guessing it’s not implemented like that since I don’t think the capability supports any such thing.
Instead, my guess (total speculation) is that what’s happening is that ST is internally maintaining some state that “caches” whatever the “current dim level when on” should be for all known dimmers, and (in principle) then intercepting on() calls and instead calling setLeve(cached_level) to shoot to that level whenever someone later calls on(). This latter approach would have the downside of not working well if someone tapped the physical switch, though, so I could be wrong.
Anyway – enough speculation. If there’s currently no good answer, I’d be willing to help try to build some workaround solutions, as these are common dimmers (incl. at my house ) … but I’m new enough to ST development that I’d like some reassurance from others that this isn’t already a solved problem (or known to be unsolvable somehow).