Git Product home page Git Product logo

reactor's Issues

Interface issue, reordering conditional groups

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

Time conditions display in "raw" (internal/JSON) form

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).

Quickly find all devices used and where

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.

Scene with no groups causes startup crash

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).

Can't detect device

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.

device_detection_error

veralog.txt

Backup/Restore should handle Reactor state/configuration

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?

Luup Restarts

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..

Consider/research: activity execution options

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.

Detect circular activity/scene references

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.

Variable watches may be duplicated

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.

Lua and Scenes not running

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

Add built-in execution of scenes

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.

RunScene action (UPnP) cannot run Activities

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).

Status tab reporting incorrect status

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.

Reactor_TV_Ping

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

Unable to delete conditions

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.

getstate() insert tool fails to launch

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
2019-03-26 (1)
2019-03-26

Flap Detection

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

Taking one variable state and applying to another.

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

Add separate condition for group state of current or other ReactorSensors

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.

delay timer

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?

Condition Hold Times (feature request)

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"?

RS with Interval condition loses sanity on date/time conditions

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.

using a geofence to trip / untrip a reactor virtual sensor?

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!)

Conditional nesting

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

Reactor_Logic

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.