Thanks for the help & advice you the man
I will probably move this back on to Reactor. I had been moving some simple lighting off Reactor that would work on DelayLighting. Thanks again for the Great Work
I installed DelayLight for the first time and setup a single sensor. The sensor turns on a light when a door sensor is triggered. I noticed that a LUUP reload causes the sensor to get a false manual trigger. Is this expected?
That would not be normal, but it could happen if somehow the light state isnât committed to saved, persistent user_data before the reload. That would take a Luup crash, because Luup is otherwise pretty diligent about rewriting state before it restarts. How often is this occurring?
Here are the first interesting log entries after the Luup reload for the DelayLight Controler (device 950) and DelayLight device (device 951) I created.
50 | 09/09/19 19:25:28.102 | luup_log:950: DelayLight: Starting timer 951 (âBOIL: LightTimerâ) <0x735aa520> |
---|---|---|
06 | 09/09/19 19:25:28.106 | Device_Variable::m_szValue_set device: 951 service: urn:toggledbits-com:serviceId:DelayLightTimer variable: LastPoll was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x735aa520> |
50 | 09/09/19 19:25:28.112 | luup_log:950: DelayLight: Timer 951 (âBOIL: LightTimerâ) Continuing âmanâ timing across restart⊠<0x735aa520> |
06 | 09/09/19 19:25:28.113 | Device_Variable::m_szValue_set device: 951 service: urn:toggledbits-com:serviceId:DelayLightTimer variable: Message was: Delay Off 59m now: Recovering from reload #hooks: 0 upnp: 0 skip: 0 v:0x143d160/NONE duplicate:0 <0x735aa520> |
06 | 09/09/19 19:25:28.114 | Device_Variable::m_szValue_set device: 950 service: urn:toggledbits-com:serviceId:DelayLight variable: Message was: Starting⊠now: Started 1/1 at 09/09/19 19:25:28 #hooks: 0 upnp: 0 skip: 0 v:0x1421ef8/NONE duplicate:0 <0x735aa520> |
The 3rd entry looks to be the most interesting. There was no manual trigger event or timer running prior to the restart.
What type of device are the controlled loads?
Looking at this more closely, it suggests you actually were in âmanualâ timing prior to the restart.
The message at 19:25:28.112 is created by pulling the value of the Status variable for the timer. The message is then output immediately after, so at restart, the last status that was written to user_data appears to be âmanâ.
The message at 19:25:28.113 shows a change in the âMessageâ field for the plugin⊠look at the âwasâ messageâitâs âDelay Off 59mâ, which is consistent with manual timing running before the restart.
So the two messages are consistent and both point to manual timing going into effect.
Iâd like to see more of a log prior to and after the restart. I will PM you my email address so you can send it to me.
Hello, how can I use DelayLight with days option? Like Delay Light 3 minutes at weekdays but delay light 5 minutes weekend?
You can use Reactor, or even just a couple of native Vera scenes on time triggers, to set the AutoDelay
state variable to whatever length of delay is appropriate for that period of the day.
Is it possible to use Reactor with PLEG? I have suspicious about vera secure cpu capacity to use both of it. What do you think about it?
I see no problem using the two of them together. But you can do the same thing I suggested above using PLEG, if thatâs what youâre already using, itâs not exclusive to Reactor. I just said that because I have an implicit bias as to that choice. And at this point, PLEG is far behind me and Iâm more than a little rusty at it, so I canât really guide you with specifics.
Thank you for your interest and sincerity. I will contact you when necessary.
Hi Patrick, can we use virtual switches being turned on as inhibitors?
Iâve made a WFH Virtual Switch to use as an inhibitor for a DelayLight device but it isnt preventing the timer from activating.
Should be fine. More detail may help.
Inhibitors donât inhibit manual timing.
Oh, that seems like an oversight to me?
No, thatâs by design. The description of inhibitors in the UI even specifically says they inhibit automatic timing. The idea is that the light is never out of controlâcanât be left on forever. If thatâs what you want to do, however, you can disable the timer instance.