Call for Beta Testers -- Reactor 3.5

I need a few willing participants to test Reactor 3.5 pre-release. Any and all are welcome.

The release can be installed from the Github stable branch:

  1. Back up your current Reactor configuration using the Backup/Restore tool on the Reactor master device. Recommended: download the backup file and save it locally. This release should be interoperable with 3.4 (so you can revert if you need to), but it’s always good to take out a little insurance.

Vera Users:

  1. Go to the stable branch: https://github.com/toggledbits/Reactor/tree/stable
  2. Click the green “Clone or download” button and choose “Download ZIP”. Save the file somewhere.
  3. Unzip the file.
  4. In the Vera web UI, go to Apps > Develop apps > Luup files
  5. Group-select and drag the unzipped files, except any “.md” files, to the “Upload” button in the Vera UI.
  6. After the uploads complete, Luup will reload. When that’s done, hard-refresh your browser.

openLuup Users:

  1. Go to the “Plugins” page.
  2. Type stable in the Update box.
  3. Hit the “Update” button.

Please report any issues on this topic/thread. If your pet bug or feature/suggestion isn’t mentioned below, let me know.

Changes for 3.5:

  • Enhancement: “Pulse” output mode for conditions now allows repeat pulses with a configurable off/false period between.
  • 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-referencing Device Action activity with a SetVariable service action. The target variable must be “expression-less” (that is, its configured expression is blank/empty).
  • 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); solidifies some date parsing behaviors; adds date() and map() functions; see https://github.com/toggledbits/luaxp for full change log.
  • 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: 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 evolution 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: Cosmetic bug in the appearance of scene list for Run Scene activity.
  • Fix: Cosmetic bug–“updates” action does not need “ignore case” checkbox.
  • Hotfix 19240-01: SMTP notifications to Google/Gmail fail with 555 5.5.2 Syntax error (L_Reactor.lua)
  • Hotfix 19273-01: Using a variable reference in a delay doesn’t work properly. (L_Reactor.lua)
  • Hotfix 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, possibly 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)
  • Hotfix 19317-01: Fix variable substitution in “Try” action operation in Activity editor (J_ReactorSensor_UI7.js)
  • Hotfix 19317-02: Fix action editor incorrectly reselecting currently configured value (J_ReactorSensor_UI7.js)
  • Hotfix 19318-01: Work around issue with Mac Chrome and derivatives getting confused when multiple data-list fields have same DOM element ID
3 Likes

I could but I’m not sure I can sensibly test any of that :smiley:
C

Could I point out that if you are testing this on openLuup, and already have an earlier version installed, then all you need to do is type stable into the update box on the Plugins page and click the update button.

2 Likes

Right! Amended instructions!

1 Like

Forgive me if i’m kicking in open doors here, I haven’t played that much around with reactor recently:
Is there a way to have “Rising edge” / “Falling Edge” triggering instead of it being triggered on value?

I need a little more here… just woke up… no coffee yet, too much blood in my caffeine system…

1 Like

Hehe, know the feeling.
To be precise, i’d like the reactor sensor to trigger on value change, without it staying “triggered” at all. This may simplify some conditional logic i think… (Just had a class on FPGA state machines :wink: )

Have you seen the “changes” operator for conditions?

1 Like

Now I have. Perfect. :slight_smile:

Tried this now, it seems it still stays triggered as long as value is 1?

Don’t supply terminal states. Just leave the operand fields blank. You should also add a delay reset of a couple of seconds–the pulse it will generate is so quick that the UI can’t keep up.

But if operands are empty it will trigger on any change? thats what I mean, I want to trigger (in this case) on rising edge only, opening for manipulating the input device without getting into throttle situations. UI is not that important, the result will be evident on the devices the actions run…

Not that important, but i think its a useful function. :slight_smile:

Got it. Here are three examples:

  1. Plain “changes” – pulses on any change from any value to any value
  2. Pulses on rising edge;
  3. Pulses on trailing edge.

2 Likes

Secondary delays are perfect now on 3.5. Thanks.

1 Like

I have issues with two sensors:
One returns an error “Error executing function undefined():” and my conditions tab is empty
The other (the one sensing lua errors on reloop, from the othe thread) worked fine, but now it has an red icon (like: tripped) when reporting untrip status.
Sometimes reloading luup or rebooting clears these issues, sometimes not.

Happens when the Vera is reloading when you go into the RS (or any plugin that has to load a JavaScript UI). If the web server isn’t answering request, it retries once, then punts.

A hard-refresh might be better to resolve this (and faster). Unfortunately since 7.29, I’m seeing increasing frequency of device UIs (dashboard and control panel) not being in sync with user_data, like the status request isn’t reporting an accurate set of deltas… not just ReactorSensors, but even Z-Wave switches and motion sensors, other devices. When it happens, I can often go into the Advanced > Variables tab for the device and it not only shows inaccurate values, but if I choose “Edit” is shows a blank edit field where it should show the current value. I’ve been looking to see if there’s some deterministic/reproducible set of circumstances so I can report this to @edward, but so far it just appears random. But in any case, a hard-refresh seems to restore everything to sync… for a while.

With Holiday travel behind me, I decided take the latest beta for a spin. I’m running Reactor ver 3.5develop-19354 © 2018,2019 Patrick H. Rigney, All Rights Reserved. with git commit sha 110c582

All Reactor sensors are in the correct state at this time. Will take about 24 hours to know if anything is awry. I ran the official 7.31 Vera firmware beta for last 24 hours so if Reactor beta issues arise, I’ll let you know. In the mean time, keep up the great work - Reactor 3.5 is a pretty nice upgrade. :+1:

1 Like

Thanks for jumping in! I installed 7.31 within minutes of them publishing it and ran my full battery of automated tests, no problem. But like any similar test suite, it hits the same stuff the same way every time, so good for regressions but little else. Having more hands and eyes on it is always the best answer.

Hi running 3.5-19354, and I have this strange Issue:

Note that “BAD_LYS” is only detected in 2 of 3 checks. strange thing, is that sometimes, It is true on all 3 tests.

under 3.4 I have no issues with this.

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy