Streamlining code: groups of switches, individual timers

#1

Hello. Looking for some design help.

In Core, I built a light timer such that if most lights were turned on (manually), they would turn off after 1 hour. A few key notes.

  1. I do not yet have motion sensors,
  2. Most lights come on by piston already so this really covers the others,
  3. Each light ran it’s own timer…IE If light A was turned on at 6:03pm and light B was turned on at 6:14pm, then at 7:03pm only light A would turn off, while light B would continue to wait until 7:15pm.

In Core, I did this in one piston, but each light was it’s own If on, then in that clause there was the ability to take action, back in the top level of the piston, each light got an ‘OR’ in between.
If Light A (then),
or
If Light B (then).

Feels like with all the great functionality in webcore, we can write this much more streamlined with variables or loops or something. Anybody got any design ideas? One of the last Core automations remaining as I just do not want to rebuild it as 23 pistons in webcore.

Oh, if possible all switches should respect the on/off state of a single additional virtual switch (If Virtual is on cancel timer) - I do not use modes at all, and this would be ‘guests over override switch’ when lighting outside of the norm is expected.

#2

i’ve never used it but i have a feeling its as simple as this

image
image.png1178×545 24.1 KB

#3

Cool, I think that’s it. I deployed it with the 60 mins. But I’ll test it with shorter intervals later. Cheers! PS: Very cool option Adrian!

#4

That will just turn off all lights in the variable 1 hour after the last event… and a new event with a different light will just reset the timer.

Instead, you’ll need to disable parralisim in the piston settings (click on the green piston title when in the editor)… and instead of the ‘with lights’ use ‘with $currentEventDevice’

#5

yep forgot about that bit! i had seen it before but couldn’t remember where. the allow multiple schedule is correct though?

#6

BTW what does

actually do?

#7

Seems to be the default

image
image.png765×92 3.92 KB

Updated to the CurrentEvent, still need to find time to test with shorter intervals.

#8

Here is where I am so far (again still got to test), thanks all for the help. Nice and simple piston! PS Switch 4 is my virtual manual override. Off = allow schedule. Again, I do not use modes, etc.

Mostly the lights included here are transient rooms (hallways/baths/exterior lighting) and closets, etc. But with the ‘physically’ turned on part, I can even include lights that might get turned on that in main living spaces as again - most lighting is automated with presence/illuminance.

image
image.png1178×600 30.2 KB

#9

Sorry, I meant to say ‘enable paralism’

Will result in each execution of the piston starting a new branch and it effecting the last.

#10

I updated to enable paralism and ran several 4 minute tests. To detail:

Light A, manually turn on at 0:00
Light B, manually turn on at 1:30
Light A, auto turns off at 4:00
Light B, still on (20 mins later)
Light C, manually turn on at 6:30
Light C, auto turns off at 10:30
Light D, manually turn on at 11:30
Light E, manually turn on at 12:00
Light D, auto turns off at 15:30
Light E, still on (20 mins later)

With this piston as written, this a) paralism and b) allow multiple schedules works for events that start outside of any current schedule. Lights A, C and D each initiated without other (sort of) schedules already running. Light B started when Light A schedule was under way and did not get it’s own schedule. Same goes with Light E, starting when Light D schedule was running. Light B and E did not turn off either when the earlier schedule was running or under their own 4 minute schedule.

This is close, but not quite what I wanted. Of course we would have many more Light B or E cases when the schedule time is the 60 minutes not the 4 minute test interval I am currently running.

#11

Try make the ‘with’ asynchronous as well…

The other direction of attack might be allong the lines of:

If any of lights stay on for greater than 1 hour
Then
With $current event device
Turn off

Building the ‘manually turned on’ part into this might be tricky… maybe use of a second variable list to keep track of the interactions and arrayItem() to retrieve the interaction.

Do all of your selected devices actually report the correct interaction??? Most devices don’t so it’s fairly rare to be able to use that feature!

#12

Here is where I ended. Note I tested this once, and it worked. I did the Light A, Light B example again. Light A turned off @ 4:00 and Light B turned off @ 5:30! Cool. Not sure if it was all needed, I think it is, but this includes all of: parallelism, multiple schedules, async and $currenteventdevice inside the ‘with’. For now I am not restricting to physical turn on, as in one test of the old piston, it failed as Robin suggested it might.

I’ll update if I find it starts failing.

image
image.png1178×651 32.3 KB