Copying a global reaction

[LibraSun]

Yes and no. My only use case for Global Reactions has been rare times when I want to call the exact same routine from multiple other Rules, without it living inside yet another Rule. Good for compactness and ease of editing. Otherwise, I never use Global Reactions.

EDIT: Just looked again. I have none!

[cw-kid]

@librasun said in Build 21117:

My only use case for Global Reactions has been rare times when I want to call the exact same routine from multiple other Rules, without it living inside yet another Rule

That's true I didn't think of that use case.

I have only been using Global Reactions like manually triggered Vera scenes, as I could send a http request in to MSR and have that Global Reaction run.

However Global Reactions have limitations e.g. they have no contraints / conditions.

[cw-kid]

@LibraSun

Do you have an example URL to set a Global Variable ?

variable/:name/set - (PUT) set the global variable specified to a value (JSON data); the request body must be application/json type.

How do you specify your value for the variable ?

[cw-kid]

I just updated to this build I think:

[cw-kid]

To me this reads like we won't be able to send a simple one line HTTP request to MSR to change a Global Variable to trigger a Rule Set:

variable/:name/set - (PUT) set the global variable specified to a value (JSON data); the request body must be application/json type.

Which if so, this probably isn't going to work for me.

Its difficult enough already to have the Home Remote dashboard app send out a HTTP Request when a dashboard button is pressed.

If I have to also contend with a request body and having to specify application/json type etc, I don't think I'll be able to do it,

[cw-kid]

I can't even seem to get Postman working as a test.

Trying to set the Global Variable named "run" to a value of "3"

<pre>SyntaxError: Unexpected token 3 in JSON at position 0<br> &nbsp; &nbsp;at JSON.parse (&lt;anonymous&gt;)<br> &nbsp; &nbsp;at createStrictSyntaxError (/home/pi/Documents/reactor/node_modules/body-parser/lib/types/json.js:158:10)<br> &nbsp; &nbsp;at parse (/home/pi/Documents/reactor/node_modules/body-parser/lib/types/json.js:83:15)<br> &nbsp; &nbsp;at /home/pi/Documents/reactor/node_modules/body-parser/lib/read.js:121:18<br> &nbsp; &nbsp;at invokeCallback (/home/pi/Documents/reactor/node_modules/raw-body/index.js:224:16)<br> &nbsp; &nbsp;at done (/home/pi/Documents/reactor/node_modules/raw-body/index.js:213:7)<br> &nbsp; &nbsp;at IncomingMessage.onEnd (/home/pi/Documents/reactor/node_modules/raw-body/index.js:273:7)<br> &nbsp; &nbsp;at IncomingMessage.emit (events.js:314:20)<br> &nbsp; &nbsp;at IncomingMessage.EventEmitter.emit (domain.js:483:12)<br> &nbsp; &nbsp;at endReadableNT (_stream_readable.js:1241:12)</pre>

[LibraSun]

@toggledbits to the rescue??

FWIW, I'm on rev. 21117 and currently do not have any inbound HTTP calls in my workflow. Wish I could help you more!

[LibraSun]

Quick question for @toggledbits ...

Will having a Constraint Group in Reset Reaction -- all by itself, doing nothing, and with no other Actions defined in the R.R. -- cause the Rule to stop the Set Reaction mid-stream if the Rule goes unset? And if so, will that behavior manifest only when the R.R. Group is TRUE?

Or will MSR be agnostic towards orphaned/FALSE Constraint Groups in the R.R., allowing the S.R. to run to completion. I'm thinking that's how most users would expect things to go, but felt it prudent to inquire. Thanks!

[toggledbits]

Facts:

1. Reactor only looks at the number of actions on the reaction to determine if it is "runnable" as a counter-reaction.
2. Constraints are evaluated, which is to say, their states are determined, at the same time the triggers are evaluated, including constraints in action groups (so before either the SET or RESET reaction is run, the constraint states have already been determined).
3. Constraints are considered for logic purposes only at the time they are applicable: the rule constraint state is only considered if the rule is transitioning from reset to set and is preparing to run the SET reaction; reaction constraint states (regardless of location) are only considered at the moment the group is encountered during the reaction run.
4. When a reaction is stopped, all child reactions (i.e. groups, with or without constraints) are stopped as well. So if a set rule resets with a runnable RESET reaction, and there are still groups running from the SET reaction, the remaining SET reaction groups will be stopped together with the SET reaction itself.

[toggledbits]

@cw-kid said in Build 21117:

Trying to set the Global Variable named "run" to a value of "3"

Documentation fail. The PUT body needs to look like this:

{
  "name": "<variablename>"
  "value": <new value, any valid JSON type>
}

The variable name given must match that in the URL.

I just added a GET for this as well just for simplicity/basic use only, to be in next build:

http://msr-ip:8111/api/v1/variable/testme/set?value=123

In this case, the value set will always be a string type, because that's what query parameter values are.

[cw-kid]

@toggledbits said in Build 21117:

I just added a GET for this as well just for simplicity/basic use only, to be in next build:

Perfect thank you

[LibraSun]

How will subsequent updates to the Docker image be managed after rev. 21117? I'm uncertain whether the Synology NAS > Docker > Registry approach to things means we no longer have to download new Image files and re-launch the Container. Would love to have an Auto-Update option somewhere in the mix.