Gradually turn on lights.

[cw-kid]

"This feature applies to rule-based reactions only; it is not a feature of global reactions (and for the removal of doubt, will not be in future)"

Good news about the option for additional further conditions within actions.

I have a few existing rules I can rebuild for this new feature.

Also If not with Global Reactions, will we at some point be able to initiate a rule sets actions via a http request sent in to MSR?

And have no other trigger on that rule set?

A manually triggered "scene" if you like.

Thanks.

[LibraSun]

You already can, and it works great. See @toggledbits separate post about the MSR API for a current list of HTTP requests you can send.

So long as you predicate your Rule with a Trigger that watches an Expression Value, all you need to do is send that value. Ideally, your Rule (or another one) would 'reset' the empty variable. I like to name these watched variables things like "Do", or "Go" or "Run". The setup can be as simple as letting 0 be the resting state, and the Trigger can watch for (changes) from (0) to (1), or even just [ <> ] [ 0 ].

Send an HTTP request to set that variable to something non-zero to cause the Rule to execute.

Later, perhaps in the Reset Reaction, set your "Run" variable back to 0. Works like a charm!

[cw-kid]

OK thanks I didn't know we could do that. That should work also as you suggest.

I'll give it a try and ask you if I get stuck

[cw-kid]

Presumably you could only have one expression variable named "Run" for that particular rule set.

So we need a differently named expression variable for each rule set we wanted to trigger in this manner.

Not too much of a problem if we don't have too many of them.

[LibraSun]

In a fancy pants setup, you could designate a single (again, empty/expressionless) Global Expression called "Run". Create an auxiliary Rule whose sole purpose is to 'reset' that expression back to 0 (after a nominal 2-second delay, say) whenever it changes.
You could then Trigger an almost infinite number of other Rules, each with a Trigger watching for [Expression Value] [Run] [changes] from [0] to [N] where N is that Rule's assigned trigger. So long as you don't anticipate too much traffic of this type - in other words, whereby incoming HTTP Set commands trip over each other - such a setup should work smoothly and consistently.

PRO TIP: Knowing that I will forget these N assignments, I always place a Comment with notes, or even a hand-built Object in an Expression somewhere, reminding me...

1 = Lights Out
2 = Time for Bed
...
12 = Nightlight Toggle, etc.

[cw-kid]

OK I think I get what your suggesting. We can just have a Global Expression named "Run" and it can have any number value set via a http request sent in to MSR 1,2,3,4 or whatever and then your different rule sets would monitor for their trigger that run =1 or run =2 etc.

[cw-kid]

If that is possible then it kinda makes Global Reactions redundant.

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