[MSR] Native fan capabilty

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