Modular Lighting Based On Time and Type

#1

1) Give a description of the problem
This is an optimization attempt. The piston(s) work as expected, but it feels like there is a cleaner way to do this. The goal is to use a single piston per lighting group for ease of additions and changes.

2) What is the expected behaviour?
Turn light on/off and determine brightness using a mixture of global and local variables and a time of day schedule.

When the light turns on, or when there is an appropriate time of day change, adjust the lights accordingly.

3) What is happening/not happening?
This works. It just isn’t clean or efficient.

**4) Post a Green Snapshot of the piston![image|45x37]
Schedule - Time of Day
Controller - Den Light

5) Attach logs after turning logging level to Full
1/8/2024, 8:51:27 AM +363ms
+57ms ╔Received event [Den Light 2].switch = on with a delay of 21ms, canQueue: true, calledMyself: false
+59ms ╚Event queued (57ms)
1/8/2024, 8:51:08 AM +150ms
+2ms ╔Working queued event [Den Light 2].switch = off with a delay of 169ms, canQueue: false, calledMyself: true
+5ms ║RunTime initialize > 4 LockT > 0ms > r9T > 1ms > pistonT > 0ms (first state access 1 m:3 2 2)
+19ms ║Runtime (17468 bytes) initialized in 1ms (v0.3.114.20231008_HE)
+20ms ║╔Execution stage started
+28ms ║║Comparison changes_to = false (event device/attr eXcluded)
+29ms ║║Comparison (enum) off changes_to (string) off = true (1ms)
+31ms ║║Condition #2 evaluated true (7ms)
+37ms ║║Comparison changes_to = false (event device/attr eXcluded)
+37ms ║║Comparison changes_to = false (event device/attr eXcluded)
+39ms ║║Condition #3 evaluated false (7ms)
+40ms ║║Condition group #1 evaluated true (condition did not change) (16ms)
+43ms ║║Executed virtual command cancelTasks (0ms)
+46ms ║║Executed virtual command setVariable (1ms)
+48ms ║║Cannot set the piston state while in automatic mode. Please edit the piston settings to disable the automatic piston state if you want to manually control the state.
+50ms ║║Exiting piston due to exit statement
+53ms ║╚Execution stage complete. (32ms)
+55ms ╚Event processed successfully (53ms)
1/8/2024, 8:51:07 AM +990ms
+3ms ╔Received event [Den Light 1].switch = off with a delay of 19ms, canQueue: true, calledMyself: false
+82ms ║RunTime initialize > 81 LockT > 0ms > r9T > 1ms > pistonT > 0ms (first state access 76 m:80 3 78)
+96ms ║Runtime (17455 bytes) initialized in 1ms (v0.3.114.20231008_HE)
+98ms ║╔Execution stage started
+107ms ║║Comparison (enum) off changes_to (string) off = true (0ms)
+109ms ║║Condition #2 evaluated true (7ms)
+116ms ║║Comparison changes_to = false (event device/attr eXcluded)
+116ms ║║Comparison changes_to = false (event device/attr eXcluded)
+118ms ║║Condition #3 evaluated false (7ms)
+120ms ║║Condition group #1 evaluated true (condition changed) (18ms)
+124ms ║║Executed virtual command cancelTasks (1ms)
+128ms ║║Executed virtual command setVariable (1ms)
+130ms ║║Cannot set the piston state while in automatic mode. Please edit the piston settings to disable the automatic piston state if you want to manually control the state.
+133ms ║║Exiting piston due to exit statement
+137ms ║╚Execution stage complete. (39ms)
+140ms ╚Event processed successfully (138ms)
1/8/2024, 8:51:08 AM +73ms
+2ms ╔Received event [Den Light 2].switch = off with a delay of 92ms, canQueue: true, calledMyself: false
+3ms ╚Event queued (2ms)

#2

I’ve started rewriting this and experimenting with using a switch block, but still figuring out the best order to do it and prevent double executions due to the “light on” trigger.

#3

I’m not sure exactly what you’re looking to achieve. I wrote a piston to turn lights on based on motion in a room, with the ability to set different levels & time for them to be on based on night or day. Adding other light/sensor pairs is just a matter of updating the variables.

Although this works well, the piston is very complex and I’m not sure its the best way to go.

One thing you may need to consider is if you use an array of devices, they are stored in alphabetical order. So in my case my sensors & lights have to follow a naming convention where the matched pair are the same position in their two respective arrays.

#4

Right now I’m using this per piston, so I can copy the piston, set the devices and functions, and then it run. (ex. Bar lights, accent light true, night light false). Mainly just built in case the devices are changed, or something needs updating. Partially practical, partially a neat thought experiment.