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 
).
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 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
Edit: i was too fast also
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:
- Add a reset delay period to the āfollowā output mode;
- 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