Questions about coding child devices

[JDRoberts]

Continuing the discussion from Motion activated light only if light is already off?:

@mlasevich

Ok, so I managed to play with it a bit the other night. The good news is that I got something working - wrote a whole SmartApp that includes creating virtual devices and connecting to actual switch and to motion sensor and runs timers for auto-off, etc. (I realize much of this is duplicate of existing functionality, but I did it mostly to understand how this works) Overall its pretty cool to be able to write things in Groovy - but I got a number of questions due to somewhat lacking documentation. Specifically things like:

I found the way to create devices from app using the semi-undocumented addChildDevice() method (it is mentioned in documentation examples, but not in the reference page for methods available to SmartApps) - I was wondering if there was more documentation on this and if there is a way to create other components programmatically - specifically if there is a way to create “switch” apps (not sure if they are apps or devices or neither)? There is nothing in documentation (but then again, addChildDevice is missing too) and simple attempts to check what methods are available via reflection seem to have been disabled for security reasons. (So, is there a functional way to dump all the available methods?)

Also, it seems that there is some weird bug in the apps I am hitting that does not allow me to delete my custom smart app instances. I get errors. I found that if I delete the section of the code in update() that re-subscribe to the events and then update the app before deleting it, it works. It seems the issue is some dependency loop in creating child devices and subscribing to their events and then order of deletion of said subscriptions and child devices. (and yes, I tried an extra unsubscribe right before the code that deletes the child device, but delete still fails) Again, more documentation on lifecycle of SmartApp and child device creation would be ideal.

Next, I am trying to understand if there is a way to change state of a “switch” device without triggering events. More specifically I am trying to figure out a way to both control an actual (non-virtual) switch device AND react to that switch being controlled via means outside this smartapp. I realize the frequent way of using this is via a proxy virtual switch, however this is a problem if the light in question is controlled by the physical switch itself or a secondary controller that bypasses the ST hub altogether. Is there information on which smartapp triggered an even inside the event?

Lastly, and this is something I thought would be obvious but i find no way to do this - is there a way to provide default value for input fields in preferences?

Thanks,

-M

Just moving the coding questions into their own topic so the discussion, which should be interesting, will be easier to find in the archived later.

[bravenel (Bruce)]

@mlasevich

Next, I am trying to understand if there is a way to change state of a “switch” device without triggering events. More specifically I am trying to figure out a way to both control an actual (non-virtual) switch device AND react to that switch being controlled via means outside this smartapp. I realize the frequent way of using this is via a proxy virtual switch, however this is a problem if the light in question is controlled by the physical switch itself or a secondary controller that bypasses the ST hub altogether. Is there information on which smartapp triggered an even inside the event?

One thing you should look at is what caused the on/off event. Assuming your handler is like this:

def switchOnHandler(evt) { ... 

Then evt.isPhysical() will be true is the physical switch turned on the light. And evt.isDigital() will be false in that case.

I’ve had the problem to solve of distinguishing between the two, because if a SmartApp does something to turn on a light, then the light itself will report switch.on. But that second switch.on will have evt.isDigital() be true.

Lastly, and this is something I thought would be obvious but i find no way to do this - is there a way to provide default value for input fields in preferences?

That would be defaultValue: value. You can use description: string to put something in the field that will be filled, while defaultValue: does what you want.

Hope this helps.

[mlasevich (Michael Lasevich)]

@bravenel

Then evt.isPhysical() will be true is the physical switch turned on the light. And evt.isDigital() will be false in that case.

I’ve had the problem to solve of distinguishing between the two, because if a SmartApp does something to turn on a light, then the light itself will report switch.on. But that second switch.on will have evt.isDigital() be true.

Thanks, I will look into the contents of the event. What I ideally want is to know is if it was triggered by my own app or by something else. I also wonder if the switch was triggered by something like z-wave secondary controller, if it will report isPhysical() or not. Got some testing to do.

@bravenel

That would be default: value. You can use description: string to put something in the field that will be filled, while default: does what you want.

Actually, in the interest of future searches, that is not exactly right. Someone in the other thread suggested “defaultValue: value” and I confirmed that does work

-M

[bravenel (Bruce)]

Good catch on defaultValue! My bad – memory getting leaky.

isPhysical() will be true ONLY for the physical switch. A z-wave secondary controller will lead to isDigital(). Obviously, that complicates things a bit. If need be, you can use state variables to set flags that keep things straight. So if you are trying to tell who threw an isDigital() command, at least you can tell if it was your app or something else.

[bravenel (Bruce)]

I should add to my last post, that this stuff can get hairy very quickly, and ambiguous. If you toss in sequencing uncertainty, you can’t be sure of the exact order that things happen. When you find yourself struggling with that, it’s time to back off and rethink what you’re trying to do, to find a simple solution that is not ambiguous.

[mlasevich (Michael Lasevich)]

@bravenel

isPhysical() will be true ONLY for the physical switch. A z-wave secondary controller will lead to isDigital(). Obviously, that complicates things a bit. If need be, you can use state variables to set flags that keep things straight. So if you are trying to tell who threw an isDigital() command, at least you can tell if it was your app or something else.

Ugh. Really, what would be nice is one or more of:

• Event information including whatever app id that called switch.on()
• Adding optional switch.on(variable) where the variable would be included, unmolested, in the generated event

Of course unless we want to rewrite every single device type, that is something that should really be part of the platform

@bravenel

I should add to my last post, that this stuff can get hairy very quickly, and ambiguous. If you toss in sequencing uncertainty, you can’t be sure of the exact order that things happen. When you find yourself struggling with that, it’s time to back off and rethink what you’re trying to do, to find a simple solution that is not ambiguous.

I am not sure what you mean by that. I do not want anything ambiguous - I just want to know if the event I just received was generated by me or not. This is my attempt to reduce the complexity and avoid unintended recursion loops or unnecessary virtual devices. Any app state should be always kept in the app (which, BTW, should be one unit of code). Devices should not keep any app-specific state, but pass information through in a very generic way.

At least that is what I think. I have been doing this on my off time for less than two days - I accept that I may be way off here.

-M

[bravenel (Bruce)]

@mlasevich

Any app state should be always kept in the app (which, BTW, should be one unit of code). Devices should not keep any app-specific state, but pass information through in a very generic way.

You’re right on. Keep going…