Cabinet Lighting

[ajbrandt]

1) Give a description of the problem
I want someone to give this a once over. There are things that could be done better, and I’d love for this to be optimized.

2) What is the expected behavior?
I’m not even sure if I need async, but after adding it, it seemed to get rid of the semaphore logging all of the time for a while. The concept is that the lights above the cabinets turn on an hour before sunset. The dim down to 15% when the kitchen light is off and there is no motion and trigger to 100% with motion or if the kitchen light turns on. In night mode, the long strip turns off and it’s used as a nightlight. the strip that is on brightens up to 100% if there is motion then dims back to 15% when it’s quiet again.

3) What is happening/not happening?
It’s performing as it should. I overthink everything and would like this to have a once over so that I can learn the more efficient ways to set something like this up.

4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)
I really don’t have any logs because I guess i had them off and there’s really not a lot of activity with them during the day because they’re off at this time.

[Mike1616]

Well, let’s break this down, bit by bit…

This part is fine. No issues here.

This part is not…and it’s a common theme you have going on. You’ve got two (or more) triggers in the same IF block multiple times. Those can never be true simultaneously so one will get unprocessed, but it will still act as a Trigger, but it won’t evaluate to True because, well…milliseconds matter. But I can see why this would cause all the piston waiting. You’re subscribing to too many events.

Same here:

The rest looks fine. I would just clean up the Triggers versus Conditions thing you’ve got going on and it should work better. Read the article if you need more insight on what I’m referring to. Just click on any of the words Condition or Trigger and it will take you there.

[ajbrandt]

That’s what I was thinking. That’s why I posted it here. The problem I was having was with the triggers. If the kitchen changes to off, then the piston wasn’t firing because the kitchen light can be turned off without triggering the motion sensor, so it was inactive and not firing the piston because activity changes before the light times out and turns off. I see now that it’s not the correct remedy. How do I address this? What would you do? Am I trying to get it to consider too many conditions? the kitchen light won’t turn off unless the dining room light is off. But i don’t want the cabinet lights to dim unless the kitchen light is off.

[Mike1616]

I don’t you’re trying to do to much…but I now understand a bit more about how you want things to work. I did a little testing on my own on this one too and I see a bit more how WC works when you put Timed Triggers (stays) alongside Event Triggers (changes).

What it looks like it’s doing to me is that when the Changes part happens, it sets up an event for the future to see if the Stays part is still true. So essentially the piston sets up a Timer for itself to rerun (in your case) in a minute to check if the Stays part (the lack of motion) is still true.

The reason this is working for you is that you’re putting both the Trigger and the Condition in the OR section and obviously one of those will be true a minute in the future…but it will be the Condition which is now true as the Trigger will now be false.

So you’re getting the desired effect…but I think you’re perhaps grouping things together in a manner which is causing the piston to be work a bit harder than it needs to.

I think the remedy would be to use OR for the Triggers and use AND for the Conditions…

In other words…something like this:

(IF motion stays inactive for 1 minute
OR
Switch 1 changes to off
OR
Location mode changes to Night)
AND
(Switch 1 is off
and
Location mode is Night.)
THEN

I’d just duplicate this piston that you have working. Then make the changes to it that I’m suggesting and see if it works any better. That way if all this makes no difference (or makes things worse) then you can go back to the original. This might be a bit more piston theory than science at this point…so I don’t want you tossing away working code on my suggestion alone.

I do believe it should make things work better, but…as they say…no matter how brilliant the strategy, it’s important to occasionally look at the results.

[ajbrandt]

Thank you for the insight. I will work on this and post my revised piston with results.