Questions about coding child devices


#1

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

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. :wink:


Motion activated light only if light is already off?
(Bruce) #2

@mlasevich

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.

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.


(Michael Lasevich) #3

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.

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 :slight_smile:

-M


(Bruce) #4

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.


(Bruce) #5

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.


(Michael Lasevich) #6

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

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. :smile:

-M


(Bruce) #7

You’re right on. Keep going…