Luup Reload Condition

Hi @rigpapa in the past i used a Luup Reload Condition as a trigger in reactor but since couple of months ago it stopped working it does not trip when the luup is reloading. is it a bug in some of the last releases?

Everyone, I’m going to start being a real stickler about the posting and question/help guidelines in this category. None of this information is new, but either nobody reads it, or I’ve trained everyone to ignore by too often taking the short path and just answering the question. But it makes more work for me, one guy, answering questions from a lot of people (and not just in this category, but I also get PMs, direct email, and Github). These days, I’m homeschooling two high schoolers, and working on other development projects, so my time is quite limited (and valuable, at least to me).

Please review: About the Reactor category (START HERE--READ THIS BEFORE POSTING) - Reactor - Ezlo Community
…which also links to this: Reactor Docs - Support & Suggestions

And many of these questions can be answered by the community of Reactor users, and I’d like to see more of you step up more often. For a while there was pretty solid contribution, but lately it seems I’m the only one answering questions. Hopefully that’s not a reflection of how many users have moved on (it seems to have started quieting sharply right after the time that rafale77 was banned).

6 Likes

It is, unfortunately. There’s really close to no traffic these days in this forum. I’m sorry I can’t help and I feel your pain.

I understand your frustration @rigpapa. The family and other obligations goes first.
I’m also feeling guilty to have asked questions that have been answered before, but the search engine in this forum is way too bad. But, sometimes when I arrive at the forum you have already answered the question which we (the community) could have answered as well (and I am here daily). I appreciate your app very much and is for now one of the reasons I stay with Vera. I will from now answer better to the questions I can answer in order to support the community (if you haven’t answered them before :slight_smile: ).

1 Like

Sorry @rigpapa but i tried to find an answer and solution but was not able to do it. i feel your pain i’m with a small kid which is asking for my attention all the time since kindergardens are closed and between work, family, maintaining vera and beta testing ezlo in a “spare time” i can imagine if a lot of people are asking questions.

so anybody else :slight_smile: i found this in the documentation

The “Luup Reload” condition pulses true briefly after a Luup reload, when Reactor is ready and running. It resets automatically, and takes no parameters. If you need to trigger an activity at startup, this condition offers a way to get that done

but in my case it does not i don’t know why in the status it says false as of (time when i reloaded the luup) but it does not trip the sensor. I use this sensor in Home Assistant to track when i have often luup reload and track the health of the vera system, but since a while it stopped reporting to HA also. I tried to add a virtual switch in action but it does not turn on the switch also.

Here is my logic summary:

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.7-20190 config 20190 cdata 20045 ui 20190 pluginDevice 11 LuaXP not loaded
    System: Vera version 1.7.5186 (7.31) on Sercomm G450 ID 36 (Vera Plus); loadtime 1599771422/1599771432; systemReady 1599771437
       Env: Lua 5.1; JSON dkjson 2.5+LPeg; UnsafeLua=nil/true
Local time: 2020-09-10T22:57:44+0200; DST=1; Kisela Voda, Kisela Voda Macedonia; formats %d/%m/%Y %H:%M:%S
House mode: plugin 1; system 1; tracking off
  Sun data: 
  Geofence: not running
        RS: 1599658922,1599659012,1599659027,1599659042,1599659747,1599664641,1599664666,1599664731,1599664907,1599664933,1599665518,1599665795,1599669926,1599673472,1599707830,1599723154,1599723415,1599723550,1599742814,1599744838,1599745034,1599745061,1599745345,1599746810,1599747059,1599747303,1599757050,1599758100,1599758976,1599759418,1599759697,1599766293,1599766309,1599766508,1599766577,1599766791,1599767046,1599767515,1599768270,1599768327,1599769205,1599769266,1599769429,1599769590,1599771063,1599771143,1599771206,1599771282,1599771325,1599771432
        NS: 0:X,1599427380:U
************************************************************************************************************************************
Luup Reload (#223)
    Version 20045.9 09/10/20 22:54:02
    Message/status: Not tripped
    Condition group "Reactor Sensor 3" (AND)  false as of 22:57:13 <root>
      &-F-reload  [true => false at 22:57:13; F/F as of 22:57:13/22:57:13] <cond0>
    Activity root.false
        Delay 2 inline
        Device luup reload switch (253) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
    Activity root.true
        Device luup reload switch (253) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="1" )
    Events
        2020-09-10 22:57:12: Reactor startup (Luup reload)
        2020-09-10 22:57:12: Starting (Luup Startup/Reload)
        2020-09-10 22:57:13: Sensor update starting
        2020-09-10 22:57:13: Condition cond0 test state changed from false to true
        2020-09-10 22:57:13: Condition cond0 evaluation state changed from false to true
        2020-09-10 22:57:13: Group Reactor Sensor 3 test state changed from false to true
        2020-09-10 22:57:13: Group Reactor Sensor 3 evaluation state changed from false to true
        2020-09-10 22:57:13: Preparing Reactor Sensor 3.true (root.true) activity
        2020-09-10 22:57:13: Launching scene/activity root.true
        2020-09-10 22:57:13: Deferring scene execution, system not ready (root.true:1)
        2020-09-10 22:57:13: Changing RS tripped state to true
        2020-09-10 22:57:13: Sensor update completed; 0.024s
        2020-09-10 22:57:13: Sensor update starting
        2020-09-10 22:57:13: Condition cond0 test state changed from true to false
        2020-09-10 22:57:13: Condition cond0 evaluation state changed from true to false
        2020-09-10 22:57:13: Group Reactor Sensor 3 test state changed from true to false
        2020-09-10 22:57:13: Group Reactor Sensor 3 evaluation state changed from true to false
        2020-09-10 22:57:13: Preparing Reactor Sensor 3.false (root.false) activity
        2020-09-10 22:57:13: Stopping activity "root.true"
        2020-09-10 22:57:13: Launching scene/activity root.false
        2020-09-10 22:57:13: Deferring scene execution, system not ready (root.false:1)
        2020-09-10 22:57:13: Changing RS tripped state to false
        2020-09-10 22:57:13: Sensor update completed; 0.033s
        2020-09-10 22:57:18: Starting "root.false" group 1
        2020-09-10 22:57:18: Activity "root.false" finished
        2020-09-10 22:57:18: Stopping activity "root.false"
    Devices
        Switchboard Plugin (12) urn:schemas-toggledbits-com:device:Switchboard:1 (1/-1); parent 0; plugin 9194; mfg  model ; dev D_Switchboard1.xml impl I_Switchboard1.xml
        luup reload switch (253) urn:schemas-upnp-org:device:BinaryLight:1 (3/1); parent 12; plugin -; mfg rigpapa model Switchboard Virtual Binary Switch; dev D_BinaryLight1.xml impl 
    Watches
        Device #223 Luup Reload service urn:toggledbits-com:serviceId:ReactorSensor variable TestTime
        Device #223 Luup Reload service urn:toggledbits-com:serviceId:ReactorSensor variable cdata
        Device #223 Luup Reload service urn:toggledbits-com:serviceId:ReactorSensor variable TestHouseMode

Edit: My guess is the reload is happening too fast for the switch to be turned on, because if you see midway through stopping activity "root.true" occurs

No its not running a scene. Its just turn on the switch and turning it off after 2 seconds and nothing else. I’m fliping the switch so i can have some event in the ha because the sensor for some reason dont trip also. But regardless it is not turning on and off the switch and everything is saying that it should :slight_smile:

Edit: i was too fast also :slight_smile:

1 Like

try setting the conditions to ‘pulse’ for a few seconds. My guess is before the action can completed the RS sends a stop command, just shooting in the dark here though

Pabla is correct. The Reload condition is very fast and produces a very short pulse, so short that it does not display in the UI (which has a refresh rate of about once per two seconds). You can confirm it working in the “events” section of the logic summary (this is why I ask that the logic summary always be posted, not screen shots–the events section is a vital tracing tool to see what Reactor might have been thinking).

        2020-09-10 22:57:13: Condition cond0 test state changed from false to true
        2020-09-10 22:57:13: Condition cond0 evaluation state changed from false to true
        2020-09-10 22:57:13: Group Reactor Sensor 3 test state changed from false to true
        2020-09-10 22:57:13: Group Reactor Sensor 3 evaluation state changed from false to true

As Pabla suggested, for the way you’ve set up your activities, you need to stretch out the length of the Reload condition’s true state. You can do this one of two ways:

  1. Add a reset delay period to the “follow” output mode;
  2. Change the output mode to pulse and set a pulse length.
    Either way, as you’ve set up the activities, you need the pulse length to be longer than two seconds.

Let’s talk about your activities. Pabla noted that the event log shows “stopping root.true”. This is because the Reload condition has gone false very quickly. When Reactor runs activities, it reasons that having the “true” and “false” activities for a group running at the same time is more often than not a Bad Thing. So when an activity starts, if there is a counter-activity for the same group, it is first stopped: when the “true” activity starts, it will stop the “false” activity if it is present; and when the “false” activity starts, it will stop the “true” activity. This prevents the two states from competing for control of devices.

Because the default timing of the Reload condition is a very short pulse, the transition to true and back to false happens very quickly (milliseconds). That means it is probably being pre-empted from running the “true” activity at all because the “false” activity is being started almost immediately after–it’s a race and “true” loses. When you add the suggested delay for the Reload condition, this effect will be mitigated, but you also could have structured your activities differently: you can put all of the actions in the “true” and leave the “false” activity blank. If the “false” activity is empty, Reactor will not stop the “true” activity (the preemption is only done when both “true” and “false” activities are present).

An alternate approach is that now that you are introducing a delay to the Reload condition, that delay can be used for timing of the light going on and off. Just remove the Delay action from your “false” activity, and set the reset delay (or pulse length) of the Reload condition to however long you want the light to be on. You’ve currently got an extra delay you don’t really need.

3 Likes