I’d like to add a new method to the DeviceWrapper class because it’d be an easier way to accomplish what I’d like to do. As an old-school Java guy my first instinct was to create a wrapper or extension of the physicalgraph.app.DeviceWrapper class but then I remembered I was working in groovy and could extend the meta class with the capability I wanted. It turns out that neither of these approaches seems to work in SmartThings. The documentation is kind of schizophrenic as at one point it mentions
The Groovy programming language offers a powerful feature called Metaprogramming that (among other things) allows for Groovy programs to be written in a way that methods can be created dynamically at run time.
All that sounds perfect until I read later that getMetaClass() is considered a restricted method. Is there some magic trick to injecting new methods without using that? I’m a little out of my depth here.
I have my living room lights set to come on bright for 5 minutes when we arrive home late at night
I have a nightlight that turns the lights on low for 10 minutes when there’s motion in the living room.
I feel like the right resolution of those two things would that the light stays on bright for 5 and then low for another 5, but that isn’t very easy to accomplish.
My idea would be to add a method to the device somehow that does something like “setToLevelForMinutes” that would effectively keep a stack of those methods, and revert the light back to its previous state when everything has happened. That way I can keep a bunch of complexity in the device object and can really simplify my other scripting.
Still it’s proving really elusive. I tried last night to see if I could create a better version of the Dimmer Switch device but i can’t find a way to issue zwave commands from a timer call back.
Currently I think a parent-child app might make the most sense. I could have some ugly code in the parent app that handles the timer behavior and have really simple calls in the child apps
I’d rather do it myself so I understand how it works and so when I do hit the limit of what it’s capable of I won’t have trouble extending it.
Where would I find the smart lighting app - i see plenty references to it, but i can’t actually figure out where it is? Might be a good reference to at least see how that works
Ahh yes I’ve played with that one. Didn’t realize “Smart Lights” and “Smart Lighting” were the same.
I used that before for a kitchen nightlight to turn the lights on low when they detect motion. Unfortunately if i then go to the switch and bring the lights up brighter it doesn’t cancel the operation and plunges me into darkness when the motion stops.
That was the closest to my needs that I’ve found, but I ran into a wall when I couldn’t find the source code for it to do my own modifications. It doesn’t seem to exist as a SmartApp template? Do I have to go somewhere else to find it?
Sounds like you are looking for something more complex that what you originally stated. I think the use of state or atomicstate in your smartapp might be able to get you what you are looking for, but with out knowing what you are actually trying to accomplish i’m not entirely sure.
Well i’m trying not to write out my entire use case because it’s not super relevant to the discussion of extending the object model.
Consider the following design goals:
Two different triggers should be able to set the brightness to different levels for different periods of time and for any given point in time the light will be at the brighter of those triggers. So if the nightlight set it to 25% for 10 minutes and the door to 80% for 3 minutes and both trigger at the same time then i expect it to go to 80% for 3 minutes and then 25% for 7 minutes.
After it’s done with any scheduled operation then it should revert to the previous state.
Any manual interaction during a scheduled period should cancel any future adjustments
Last night I was trying to modify the dimmer device type to add the logic to the device itself. That way in theory two different apps could send in their desires and the dimmer would handle the complexity. In my case that’d work well because i have the same dimmer everywhere and could replace them all with a custom object, but it’s not as scalable as i’d like.
Current thinking is to make my own parent app that does all the timers and rule enforcement and then create simple child apps for the different behaviors.
I don’t doubt that I could write it all as gigantic monolithic smart app but that doesn’t sit very well with me. It’ll rapidly become hard to maintain when I want to tweak something.