Plugin update resets Vera scene conditions to "tripped + armed"

Plugins & Plugin Development Reactor
1

Running Reactor v2.3, and have used it successfully for many logic switches. Very, very useful!

I have noticed the following behavior, and I believe it occurs whenever the Reactor plugin on my Vera auto-updates: If I have scenes involving a Reactor logic switch which triggers as “tripped, whether armed or disarmed”, it converts to “tripped when armed”. Likewise, If I have scenes involving a Reactor logic switch which is “un-tripped, whether armed or disarmed”, it converts to “un-tripped when armed”. In both cases, I notice because my scenes don’t work correctly, but once I go back to each scene trigger and return it to “armed or disarmed”,

This is problematic to me, because all of my Reactor logic switches are set up logically to work whether armed or disarmed. As such, it appears that with each update to the Reactor app, I have to go revalidate the scene triggers for any scene involving Reactor. For now, I’ve solved this by turning off “auto-update” on the Reactor app, but this is obviously not the desired end state.

Am I missing something that would mitigate this issue?

2

[quote=“agflight85, post:1, topic:200582”]Running Reactor v2.3, and have used it successfully for many logic switches. Very, very useful!

I have noticed the following behavior, and I believe it occurs whenever the Reactor plugin on my Vera auto-updates: If I have scenes involving a Reactor logic switch which triggers as “tripped, whether armed or disarmed”, it converts to “tripped when armed”. Likewise, If I have scenes involving a Reactor logic switch which is “un-tripped, whether armed or disarmed”, it converts to “un-tripped when armed”. In both cases, I notice because my scenes don’t work correctly, but once I go back to each scene trigger and return it to “armed or disarmed”,

This is problematic to me, because all of my Reactor logic switches are set up logically to work whether armed or disarmed. As such, it appears that with each update to the Reactor app, I have to go revalidate the scene triggers for any scene involving Reactor. For now, I’ve solved this by turning off “auto-update” on the Reactor app, but this is obviously not the desired end state.

Am I missing something that would mitigate this issue?[/quote]

Between 2.1 and 2.2, I attempted to change the order of scene triggers on ReactorSensors and stepped into a Vera hole (my fault–learn something new every day here) that caused problems for a few people still using them. Most people are converting/have converted to have Reactor run their scenes, and I think even more are now running all their actions from within Reactor, no scenes needed in many cases (e.g. unless some reuse of the actions would make separating them out to a scene handy). That broke some users coming up from 2.1, so I published a hotfix to put the order back. If you never saw/got/posted that hotfix, any scene trigger you created in 2.2 would have the modified (incorrect) ordering/trigger template IDs. Then 2.3 incorporated the hotfix resetting the correct IDs, which would restore the 2.1 ordering permanently, but would break any 2.2 scene triggers that didn’t post the hotfix.

So, I’m guessing you never got the hotfix at 2.2, and any scene triggers you created then changed when 2.3 updated. Sorry about that. I do announce/list all of the current hotfixes available in this thread, so you may want to keep tabs on that going forward.

3

Hello, I am also having problems with Reactor 2.3 after an auto update. My sensor had been working fine until this. Going to a sensor Activities tab, a message box pops up that says “Your specified trip and untrip scenes have been moved to new-style actions. Please save.” After clicking OK the new Trip Actions group has a new added first row called “Run Scene” followed by “name?(#1550570718)(missing)”. There was no Run Scene in the original sensor. I cannot get the sensor to run. Screen shots are attached. This issue is not listed in the Hot Fix for 2.3. Thanks for your help on this.

4

Very odd. The value in the “Run Scene” you show is a timestamp that translates to Feb 19 5:05am EST, which makes no sense, that value should have a scene number or name, not a timestamp. It seems like something got oddly corrupted. Has this happened to other Reactor sensors?

Anyway, to fix, first, go the “Advanced” tab of the ReactorSensor, sub-tab Variables, and make sure the “Scenes” value is empty (just set it to “,”).

Then, on the ReactorSensor’s “Activities” tab remove the “Run Scene” activity from your trip actions, and hit “Save” to update the configuration.

One more thing… the way you are doing this. It’s OK to have a scene delay of 5 hours, but the side effect of doing it this way is that if the condition that triggers the actions resets itself (e.g. someone puts the fan back in auto mode), the scene will still be waiting the delay in the background, and will execute on the five hour mark. In other words, your actions will run even if the conditions that triggered them are no longer true. That’s likely not a problem for this use case, but making a habit of doing it this way may have side-effects for other tasks.

A better way to approach this is to take your condition (which I assume is something straightforward like “device Fan Mode is not AUTO”, and open the condition options by clicking the downward-pointing arrow to the right of the condition value. This opens a panel of options. Set the “sustained for” option to your 18000 (seconds, = 5 hours). Then, remove the delay from your actions. The way this works is that the condition will only become true if the fan is not in auto for continuous five hours, and if it is, THEN the actions will run and immediately. If someone puts the fan back in auto two hours after taking it out of auto, the condition resets and the actions won’t run, because they don’t need to. This ensures that the action only run when they really need to.

Also please don’t post screen shots. More useful is going to the Tools tab and finding the “Logic Summary” link, and posting the output of that. That gives me a more complete picture of what the sensor configuration is, and what Reactor is doing with it in that moment. It even gives me a little history leading up to that point.

5

Thank you for the great advice on all fronts. The scene variable appeared blank, but when I put a “,” in as you suggested, and deleted Run Scene activity, the error did not happen again. I switched to using the “Sustained For” method. :slight_smile: