I have an app that I wrote to control my back yard lights. It works fine, but sometimes it seems a little flaky. So just for my info I'm wondering about the following.
There are 3 separate light circuits on smart switches. If light 1 is turned on, by whatever method, then my app also turns on light 2 and light 3. The same thing occurs if light 2 is turned on, the app turns on lights 1 and 3. If light 3 is turned on it doesn't turn on any of the others. All that works fine.
I also have it set up if a particular door opens it turns on all 3 lights. Again this works, but sometimes differently. So here is the scenario.
Door opens,
App says turn on light 1
App says turn on light 2
App says turn on light 3.
Now when light 1 turns on it of course creates a trigger as explained above to turn on lights 2 and 3. So my question is when the door open routine runs and light 1 goes on does the routine complete the other 2 lights before it triggers the other routines? Or does it immediately branch off then come back?
That could be a good use for atomicState and some state checking before executing the actions. Set an atomic state.trigger = what triggered execution, execute the actions, reset atomicState to none.
In the actions, make sure there are 3 different routines for the 3 different triggers, and in each only execute the actions if atomicState.trigger=none.
If I understand, when a trigger occurs the system MIGHT immediately jump to that routine. Sorta like an interupt being executed.
I guess in my case there are several triggers that get triggered in very rapid sucession.
I will look into the atomicState method. I do look at the current state of the light and only turn on if it is off. But when it does turn on it does trigger the other routine which can check if it's on before trying to turn it on again, which is similiar to the atomicState method.
Again, it pretty well works ok, just sometimes there are some delays that kinda puzzle me and wondering what might be going on.
Is there some way to detect if the light was turned on using the physical switch rather than some other method?
I would suggest you may be thinking too linearly. There isn't just ONE copy of the app that can run at a time.
A trigger comes in, it runs the method specified. If in the middle of that running a new trigger comes in, another instance of the app runs that method specified. Etc.
Event type shows that - if the driver and device you are using supports it. Many do, but not all. You can look in the device event log and see if type is populated properly.
You can check the event properties after the subscription is triggered and received by the app.
May be able to do it in the subscription itself with filters, too, but I don't use filters much in favor of just filtering in the app.
Side note - even with atomicState you aren't GUARANTEED that the state will exist with the same value in all instances if new instances start firing off too fast versus the time the atomicState was set, or if whatever you are doing in your app runs for aing time each execution. It just makes it much more likely than using non-atomic state which only writes the value back to the database at the end of the instance execution.
Not sure the state method will really help. What I am trying to do is prevent the trigger unless from certain methods, such as physical.
If you filter a subscription. looking at the documentation, would it be something like this.
subscribe(device1, "switch", Handler, filterEvents:physical)
Again it's no big deal as things do work the way I have them, but interesting to me to learn as much as I can about this stuff.
But in that case the event still happens? It just won't, or will, do something if it is Physical. What I am trying to do is prevent the trigger if it isn't Physical. Which may not be possible.
The event is going to happen irrespective. I'm not aware of being able to filter the subscription for physical only events. Why are you worried about the app being triggered? If it is triggered by a digital event, does that test, and then exits, so what?
