toggledbits / reactor Goto Github PK
View Code? Open in Web Editor NEWReactor (for Vera and openLuup) is a Vera Home Automation plugin that provides advanced programmable logic.
Reactor (for Vera and openLuup) is a Vera Home Automation plugin that provides advanced programmable logic.
A group that uses the NUL operator can still be assigned actions in Activities, but there is no way for these activities to run.
cstate.vars needs to be enhanced to store both value and error message, so the error can be properly displayed on the Status tab.
A missing parameter from the (attempted) initialization of house mode (on the Reactor device) causes a Lua failure at startup for new installers.
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?
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).
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
Request from user Andr on Vera forums, here: http://forum.micasaverde.com/index.php/topic,111066.0.html
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.
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
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!)
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
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.
Clone an entire Reactor Sensor. Suggestion by dJOS and sebby.
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.
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.
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).
Need to detect when the sensor oscillates between tripped and untripped too rapidly (user-configurable parameters).
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.
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.
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
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.
Stop an activity running in current or another ReactorSensor
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).
Sensor TV Tuner Routine shows tripped and true conditional groups but does not execute attached activities. Snippet and Logic summary attached.
Forum user LibraSun has requested that the Notify action be extended to include CallMeBot support.
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.
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.
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:
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
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.
The configuration UI incorrectly sets up "not equal" conditions on service values. This is an error in the menu value in the JavaScript.
Not just for service conditions, but geofence and others where it makes sense:
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"?
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?
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.
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..
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
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
Request by dJOS and sebby
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.
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.
Add checkbox/option to rename the target device when restoring a single configuration to a specific ReactorSensor.
Just like the subject says
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.
SMTP in particular, but maybe others.
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.
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
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.
at least, for the numeric values.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.