Plugin: DelayLight

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?

The false manual trigger occurs 100% of the time after Luup reload.

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. :smiley: 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.

@rigpapa can you assist with the above query please?

Should be fine. More detail may help.

It’s as simple as I described - single virtual switch set as inhibitor:

but it doesnt work:


07

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.