Call for Beta Testers -- Reactor 3.5

Plugins & Plugin Development Reactor
#61

OK. That helps. My buddy @akbooer’s favorite: luup will return nothing rather than nil in some circumstances. Update to stable branch 20019.2

1 Like
#62

That works great :slight_smile:

1 Like
#63

16 posts were split to a new topic: SMTP notification problem with Gmail

#64

The current beta/stable version of Reactor 3.5 is looking like a release candidate. The outstanding issue with SMTP notifications through Gmail reported by @ElCid was solved with configuration, as intended, and I’m not aware of any other outstanding issues in 3.5 (although I’m still taking stock of everything that transpired while I was travelling).

Barring anything else that comes up, plan on 3.5 being generally available Monday 2/17.

Edit: Update list of changes for this version…

  • POTENTIAL BREAKING: ReactorSensors no longer support the “Invert” state variable to reverse the sense of logic output to the Tripped state of the ReactorSensor. The better (and now required) choice is to apply “NOT” to the “root” group if needed. I doubt anybody has used the “Invert” flag, though.
  • POTENTIAL BREAKING: Until 3.5, tripping the ReactorSensor “manually” (e.g. with the UI buttons, or calling the “Trip” or “Reset” actions on the ReactorSensor, would run the root group’s corresponding activity. This is a legacy behavior from before Reactor had groups. As of 3.5, “Tripped” state is just a flag, and will no longer run any activity when changed. However, changes in the root group’s logic state will still drive the “Tripped” value (“root” true == Tripped, “root” false == Not Tripped/Reset), and the root group’s activities will run in response to logic changes as they would for any other group. The reverse path, however, is no longer true–forcing the ReactorSensor to trip or untrip doesn’t run the root’s activities. I doubt anybody actually relies on this behavior, and it actually creates more problems than it solves, which is why I’m removing it. If you must have the behavior, you should redo your logic, but while you’re figuring out how, you can set UseLegacyTripBehavior = 1 on any ReactorSensor that requires it. This flag and the ability to use the legacy behavior will be removed for 4.0. Also note that this change only affects Reactor activities; it does not change the behavior of Vera scenes using a ReactorSensor as a device trigger.
  • Enhancement: Added a “Stop Group Activity” to stop a specific activity, or all activities, running on the current ReactorSensor or another.
  • Enhancement: The “Run Group Activity” action now allows you to force-stop all other running activities before launching the selected activity. This is a short-cut for using a separate “Stop Group Activity” before.
  • Enhancement: “Pulse” output mode for conditions now allows repeat pulses with a configurable off/false period between and a limit on the number of pulses.
  • Enhancement: The new Expression Variable condition type allows direct condition testing of an expression’s most recent result value without using a self-referencing Device State condition.
  • Enhancement: The new Set Variable activity allows direct setting of a variable without using a self-directed Device State activity with a SetVariable service action. The target variable must be “expression-less” (that is, its configured expression is blank/empty).
  • Enhancement: New “Run Activity” button on each activity allows the entire activity to be tested. This does not stop other running activities, including contra-activities (i.e. if you run the “is TRUE” activity for a group it does not stop the group’s “is FALSE” activity if it is currently running).
  • Enhancement: Make event log entries more human-readable.
  • Enhancement: Reactor table in “Run Lua” actions now publishes state for all conditions (in table Reactor.conditions; keys are condition IDs). This makes the current condition states and values accessible directly in Lua without additional “gets”.
  • Enhancement: Reactor table in “Run Lua” actions now publishes group states (in Reactor.groups) by name as well as by ID. Previously the keys were group IDs. Now you can use either in “Run Lua” actions.
  • Enhancement: Do not check firmware version in debug mode, specifically for allowing testing on any firmware, including alpha/unblessed.
  • Enhancement: The Activities tab now can filter the display by “true” and “false” activities (suggestion by tunnus).
  • Enhancement: Update LuaXP to latest version (1.0.1); adds date() and map() functions, more trig; see GitHub - toggledbits/luaxp: Luaxp is a simple arithmetic infix expression parser/evaluator written in Lua
  • Enhancement: The new getstatetime() expression function is now available to return Luup’s last-modified timestamp for a state variable.
  • Enhancement: In places where variable substitution is allowed (i.e. where you can use {variablename}), you can now use an expression (same syntax as Expressions tab, just surround the expression in curly braces).
  • Enhancement: The “Device Spy” on the Tools tab reports changes in state variables (dynamically) on a selected device. This is intended to help users find state variables that change as the device is used/updated.
  • Enhancement: Add option for sequence (“after”) condition restriction to ignore current state of predecessor (so timing is based only on last true edge of predecessor).
  • Enhancement: When a ReactorSensor is disabled, its Status view will show all gray (as if all groups were disabled, which they effectively are).
  • Enhancement: Features that require the “Allow Unsafe Lua” flag now generate an alert if the flag is not enabled.
  • Internal: Clean up mechanism for determining SSL parameters for SMTP connections.
  • Internal: Upgrade of configuration is only done by core now; no duplication of effort on the JS side.
  • Fix: Improve the list contents for the “relative to” conditions on Interval conditions.
  • Fix: Fix color of text for ALTUI users using dark themes.
  • Fix: Fix reinitialization issue when switching between tabs without saving and user elects to abandon changes.
  • Fix: Do not clear operands when changing operators.
  • Fix: Condition value field IDs “unique-ified” similar to hotfix 19318-01 for some Mac browsers.
  • Fix: Delay input fields need same unique ID treatment, similar to hotfix 19318-01, for some Mac browsers.
  • Fix: “try” action operating in Activity editor was not substituting variables correctly; partly a limitation introduced by the evolation of variable, and partly bug, but in any case, fixed.
  • Fix: After clearing condition state, make sure initial update/restart runs all activities eligible (esp. root).
  • Fix: Try to reduce complexity of the interaction with VeraAlerts for notifications; fixes some issues in scene handling that create odd side-effects for users, and allows editing of recipients in the Activities tab. Messages on VA-controlled notifications are still required to be edited in VA. Recipient changes still require user to enter VA’s “Edit” tab to get those changes to take effect. It is what it is.
  • Fix: Cosmetic bug in the appearance of scene list for Run Scene activity.
  • Fix: Cosmetic bug–“updates” action does not need “ignore case” checkbox.
  • 19240-01: SMTP notifications to Google/Gmail fail with 555 5.5.2 Syntax error (L_Reactor.lua)
  • 19273-01: Using a variable reference in a delay doesn’t work properly. (L_Reactor.lua)
  • 19288-01: It appears certain Unicode characters can make the ancient JSON library that is standard in current Vera firmware hiccup and produce empty results, erasing a ReactorSensor’s configuration. Several different approaches to preventing damage to the config are implemented in this hotfix. (J_ReactorSensor_UI7.js, L_Reactor.lua)
  • 19317-01: Fix variable substitution in “Try” action operation in Activity editor (J_ReactorSensor_UI7.js)
  • 19317-02: Fix action editor incorrectly reselecting currently configured value (J_ReactorSensor_UI7.js)
  • 19318-01: Work around issue with Chrome getting confused when multiple data-list fields have same ID (minor but apparently really annoying)
  • 19337-01: Attempt to deal with inconsistencies in variable handling in Vera’s JS API
  • 19354-01: Fixes for VeraAlerts notifications mentioned above were backported to 3.4.
1 Like
#65

Hey @rigpapa, welcome back! I just pulled and uploaded latest stable as a final run through but stable has been running well on my system. I had one day where non of my Reactors fired but I’ve written that off to a one-time event that was probably due to the Vera beta. Hope you and yours had a great trip.

Cheers,
Bruce

#66

My house and dev Plus’s are both on the beta, and although several people have reported actions not running since 7.30 (witness thread by that title), I have not seen it myself, and most of the other reports have been attributable to other causes. If that happens again, collect as much data as you can as soon as you can, because at the moment, I have pretty much nothing, and nothing that points to anything in Reactor itself.

1 Like
#67

I trust your QA, Patrick!

C

1 Like
#68
#69
#70