cstate.vars needs to be enhanced to store both value and error message, so the error can be properly displayed on the Status tab.

Hey Patrick,

I can't seem to delete conditions within a group but I can delete the whole group. This is happening across all sensors. I am able to delete condition groups just not individual conditions within groups. My work around is to change them to comments. I thought possibly if I moved problem conditions out of the group first then I would be able to delete but that did not work either.

Ability to import a group or all gorups from another ReactorSensor into a group. Or import a group in the current RS into a group (would satisfy the clone issue #11

Not just for service conditions, but geofence and others where it makes sense:

• The option to delay transitions (false->true and true->false), separate timing for each; the default would be immediate (current behavior/of course).
• The option to hold a state for a minimum period of time. This is basically the extension of a pulse from the condition: a short true of the condition test turns into a longer true output state of the condition itself. And maybe shorter? e.g. reset the condition state even though the underlying test is still true (no further true until it resets through false---how does this relate to current latching feature?) This timing would apply equally to true and false states (with possible different timing values for each).

Question/thought: how does the above effect how we implement time-triggered resets for service "changes" operator, intervals, and reload conditions? All have pulse periods.

Question: is "delay on" different from "sustained for"?

Request from user Andr on Vera forums, here: http://forum.micasaverde.com/index.php/topic,111066.0.html

I started to put together a new sensor called TV Tuner Routine and I am using a ping sensor within a conditional group (device 97). The device tab is reporting it as being on when veras UI reports as correctly as on/off depending on the on/off state of my TV. Lua activity linked to group also not executing so I am assuming it is more than cosmetic. It is definitely stuck and not just delayed. I pulled a snippet after letting the device cycle on/off by powering on and off the TV. logic summary and snippet attached.

[TV Tuner Routine_Summary.txt](https://github.com/toggledbits/Reactor/files/3000486
/TV.Tuner.Routine_Summary.txt)
Snippet4.txt

Hi Patrick,

Had this issue pop up spontaneously. Can't detect device across all sensors. Tried Vera soft and hard boot, restore from backup. I am on new beta since release and has been fine up until today. Log attached.

veralog.txt

Hi Patrick

I am looking for instruction on the easiest way to take the input state of my receivers Main Zone input and apply it to Zone 2's input. For example if my Main Zone input is AV1 and Zone2 to was set to AV4 when it was last powered off. When I power on Zone 2 again I would want the input to switch to the same input as the Main Zone in this case AV1. I know I can probably work through this with conditional groups but thought there may be a easier way to store or get the Main Zones input as a variable and apply it Zone 2 when needed.

Thanks
John

Hi Patrick,

I started playing around with the beta and I am trying to figure out the proper nesting structure. Basically I need to execute different activities based on the status of 4 virtual switches on a multiswitch (in my attached PNG I only show 2, AV1 and AV2 to save space in the example) but only if certain conditions are true.

Please see attached PNG for further info on what I am trying to accomplish.

Thanks,

John

Forum user LibraSun has requested that the Notify action be extended to include CallMeBot support.

SMTP in particular, but maybe others.

Feature request to hide unused activity groups to make for a cleaner UI. Perhaps a radio button on the group conditional or at the root of activities to toggle on/off.

It seems that group activity Lua and Scenes are not running when triggered by associated group conditional. The Lua runs fine through a standard Vera manually triggered scene

The configuration variables, particularly things like notification settings (SMTP parameters, SSL parameters, etc.) should be backed up with the rest of the configuration.

It should restorable, optionally when "ALL" is restored, or perhaps separately?

At the moment, I'm thinking that duplicating Vera's scene editor to create Reactor's own "Action" tab would be a large code increment for a relatively small benefit. Basically, doing it would just reimplement Vera's existing scene actions. So, I'm leaning away from doing it that way, because I think I can fix the two biggest problems with Vera scenes: (a) they don't complete if Vera reboots/Luup reloads, and (b) you can't stop them during execution.

So, my current plan is for Reactor to have its own scene execution, but leave the editing/creation of scenes in the hands of the existing Vera UI. You would create your scene in the existing Vera UI, but rather than specify the ReactorSensor as a trigger for the scene, you will configure the ReactorSensor to run the scene from within Reactor's configuration tabs.

As always, discussion around this idea is welcome. I can go either way, I'm just leaning toward keeping Reactor as lightweight as possible, to maximize its utility on older hardware, and keep its performance up on all platforms.

Several users have requested some way to find what and where devices are used across all Reactor configurations.

Currently, the workaround way is to go to the Reactor master device, request a Logic Summary, and it will contain all device references in situ.

Request by dJOS and sebby

Stop an activity running in current or another ReactorSensor

Clone an entire Reactor Sensor. Suggestion by dJOS and sebby.

Since Reactor controls its scene and activity runs, it should detect if a run ends up making a circular reference, so that a scene or activity ends up running itself; stop and flag trouble, as it could be an infinite loop.

Need to detect when the sensor oscillates between tripped and untripped too rapidly (user-configurable parameters).

Intermittently, the choose action input parameter will be truncated and the pop up menu will not open. The work around is to the delete action and try again. Some times it will take a few tries. Browser is Chrome.

Using Safari Version 12.1 (14607.1.40.1.3) under macOS 10.14.4 Beta (18E215a), I am not able to edit the Condition sustained for field. I am running Reactor stable 32033c0 . I am able to edit the field using Chrome so this must be a Safari-only issue.

Also, apologies for the multi-updates - inadvertently hit the enter key which prematurely filed the issue.

A scene that has no groups will quietly fail when run by a ReactorSensor (it's logged, but there's no indication in the UI). The scene is therefore left in "unfinished" state in the scene state data. Later, when Luup restarts, Reactor sees the unfinished scene during its startup work, and attempts to run the scene groups, causing a startup crash (Reactor is attempting to iterate over an empty/none-existent array).

If an RS contains an Interval condition, any date/time conditions that follow in the evaluation order do not test date correctly.

The problem is that the Interval condition task was modifying a time variable on the state handle that the other conditions need, resulting in incorrect time comparisons thereafter.

The short-term workaround is to make the Interval condition at late as possible in the evaluation order, and after all date/time and sunrise/sunset conditions.

Hey ! Just discovered reactor, loving it! Think it might be just what I'm looking for!

I didn't see this, so don't know if it supports yet... but I'm looking to be able to use the entry or exit of a geofence to trip a virtual sensor. Right now, vera's native geofencing flips a house mode to away only if All geofence users leave the fenced area. I have a scene that turns on the house lights when someone "enters" the geofence, (by tripping the house to "home mode") but it doesn't work if someone else is already home :( (because the house doen't flip to away mode unless ALL users have exited the geofence previously)

I was hoping I could use reactor to trip a virtual switch so that anytime a user with the defined geofence on their phone enters the geofence, it will turn on the lights. Prob isn't even necessary to flip house modes. I just want the "entry into a geofence" to execute a scene.

is there any geofence variables I can reference through reactor to accomplish this?

(if I should be posting this in the micasaverde forums, please advise! thanks!)

A ReactorSensor that uses expression results in its conditions may trigger a self-watch, resulting in two consecutive re-evaluations of conditions (nothing changes in the repeated evaluation). This needs to be optimized.

Depending on how far the test time is from actual time, using test time may cause the sensor to compute a negative time delay, which is then lower-bound to 1 second, causing rapid repeated evaluations of the condition. These are not serious or harmful to operation, just wasteful, and it doesn't happen otherwise, only in "Time Test" mode.

Provide a shortcut mechanism to create multiple ReactorSensors. This would facilitate a restore of, for example, 25 ReactorSensors from a single backup file on a fresh Reactor install.

Hey Patrick,
I'm using Chrome on windows 10-- latest build-- for my client browser. Running latest development openLuup with Altui on Armbian latest build. Latest Beta Reactor ver 3.0beta-19083.

I'm trying to create some variables using the expression builder but there is no noticeable action occurring when I click on the Insert device state button. Attached are the logic report and screenshots.
LogicSum.txt

Patrick,

I am using group state to pick up the true or false status of a conditional group in a separate sensor. I am getting an unexpected false when the conditional group is showing true in originating sensor. Summary and snippet attached.

Snippet_Group_Condition.txt
Logic_Summary_Group_Condition.txt

Just like the subject says

A bug in the tracking of watches may cause multiple watch requests for the same device/service/variable, which results in multiple watch triggers when the variable changes. While Reactor already "debounces" these requests, it makes for odd runs of messages in the event log (which logs the pre-debounce callbacks). Otherwise it's harmless.

Currently (dev3.0) ReactorSensors can examine the state of another group (in the current or another RS) by referring to the GroupStatus_ state variable. This is a little klunky, and exposes implementation details to which the user should not be exposed.

Create a new "Group State" condition to do this, for better UI presentation and clarity.

Currently, only service conditions have the "sustain for" and sequencing options.

There are fine workarounds, but it would be nice for a more direct solution, in situ.

I want to Turn "on" a light when a door is open and leave the light on for 8 minutes and I can not get that to work. Can you help me with that?

at least, for the numeric values.

The current implementation of the Run Scene UPnP action cannot run group activities, it only looks for Vera scenes. Either this action should be extended, or a new action created for the purpose (although I think the latter is much less desirable).

Add checkbox/option to rename the target device when restoring a single configuration to a specific ReactorSensor.

Patrick,

I had some issues with the drag and drop reordering feature in the condition tab. Upon moving groups or subgroups above other groups everything seemed fine, however after saving and leaving the tab, upon returning some of the groups below where gone or the group was still there but the variable content was gone. I was able to replicate this a few times.

John

Sensor TV Tuner Routine shows tripped and true conditional groups but does not execute attached activities. Snippet and Logic summary attached.

TV.Tuner.Routine_Summary2.txt

Snippet5.txt

Allow an interval condition to trigger from the time another condition (which may be a group) went true. When selected, the interval only fires while the selected condition is true.

A missing parameter from the (attempted) initialization of house mode (on the Reactor device) causes a Lua failure at startup for new installers.

I am considering introducing the following options for running scenes and activities within Reactor. Before diving in, a bit of background: currently, Reactor runs activities as fast as Vera will take them. If an action uses the 'run' tag exclusively, it is run "in line," meaning Reactor (or really Luup) waits for the action to complete before moving on to the next step. If the action uses a 'job', however, Luup submits the job to its job queue and runs it later (Luup's scheduling algorithm is not documented, but appears to be FIFO). If an activity contains a delay, the delayed actions are detached to a separate task in Reactor, and Reactor immediately moves on to other business. The delayed actions are then run at the scheduled time with the same heuristic as above. By example, if a Reactor sensor has three eligible group activities, they will run sequentially at the end of condition evaluation.

Now then, the options:

1. Detach -- the entire activity would be run as a Luup job. This would not change Luup's scheduling of the actions within (run vs job, etc.), but it would affect Reactor's performance in getting to its next evaluation or starting its next group activity: this would reduce the time required by Reactor to start group activities. Using the above example, if the first of the three eligible group activities is long-running, and the second is time-critical, the second will, currently, always be delayed by the first, perhaps to its detriment. By being able to "detach" the first group activity, the second group would be able to execute almost immediately, and the actions of the first group will run as soon as the Vera/Luup scheduler allows.
2. Serial -- If an activity contains an action that Luup runs as a job, Reactor would wait for the job to complete. If within an activity, the successful completion of a later step is dependent on an earlier step, and the earlier step runs as a job, the job may not run at all prior to the later step being run. By turning on the "serial" option, Reactor would see that the action was queued as a job and wait until the job completes. Additional options would allow a timeout (Reactor would continue the activity if the timeout was met before the job signalled an exit status), and continue-on-error, by which the user could specify if the remaining actions in the activity should execute if a job fails.

If a time condition is used, the display in the status pane shows its JSON (internal) form rather than a nice human-readable form.

This is an intentional omission for the moment because there are a lot of combinations of set and unset values in the date/time range spec, and translating it to a human-readable form that will be correct is vital (errors will serve only to confuse).

Within the same ReactorSensor, it would be pretty easy to warn the user if they are about to delete a group that is mentioned in a Group State condition, and/or flag the Group State condition as an error after the group is deleted.

A group that uses the NUL operator can still be assigned actions in Activities, but there is no way for these activities to run.

The configuration UI incorrectly sets up "not equal" conditions on service values. This is an error in the menu value in the JavaScript.

Patrick,
Been getting a lot of luup reloads under the new vera beta firmware. It seems to happen when I put my sensors to the test. It seems stable when idle or with sensors disabled. Let me know if you need any data pulled since I am not sure what would be helpful in this case.

John

P..S. If possible please fix typo in subject..

On a new service, or an existing service where the service options have not been used, the repeat count comes up with "2" instead of blank, and the "sustained for" field is disabled and grayed out, confusing users.