Run rule on dimmer change?

[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:
http://msr-ip:8111/api/v1/variable/testme/set?value=123

I updated and tried this:

http://192.168.0.100:8111/api/v1/variable/run/set?value=123

"run" is the name of my Global Expression.

In the web browser I get this response:

Cannot GET /api/v1/variable/run/set

I can't see anything related in the reactor log file.

[LibraSun]

(a) 'run' is all lowercase in Global Expressions?
(b) which exact version of MSR are you running?
(c) have you also tried PUT just for testing this?

[cw-kid]

@librasun said in Trying to set variable with HTTP API request:

(a) 'run' is all lowercase in Global Expressions?

Yes it was run all lower case. I deleted that Global Expression and created a new one called scene all lower case and tried the HTTP command again but I get the same problem.

Latest build 21118

No I have not tried PUT, I would have to try that in the Postman application.

[cw-kid]

PUT doesn't appear to be working either:

[toggledbits]

@cw-kid The PUT body has to be of the form described in my other post. It needs to be a JSON object containing "name" and "value" keys.

Here's what I get for GET on a browser:

And using curl:

[cw-kid]

@toggledbits

I don't want to use PUT really at all.

I want to just use GET.

I'm not sure why its not working for me in the browser then ?

I just tried it in a different web browser MS Edge and I get this response:

Cannot GET /api/v1/variable/scene/set

[LibraSun]

Yeah, I'm going cross-eyed spotting any syntactic issues with what you've attempted thus far.
Did you do a hard refresh on your browser after starting up 21118? (Not that that should matter much I suppose, just curious.)

I've only used the formal PUT (with JSON) method, but will go test my setup using GET and join in the fracas momentarily.

[cw-kid]

It seems to be related to the name of my Global Expression which was called "scene"

I have just created another Global Expression named "my_scene" and now its working in the browser:

{"name":"my_scene","expr":"","index":2,"value":"123","since":1619705665552}

[toggledbits]

@cw-kid said in Trying to set variable with HTTP API request:

It seems to be related to the name of my Global Expression which was called "scene"

Name doesn't matter. Here's "run":

and "scene":

and "variable":

and "set":

[toggledbits]

@cw-kid I will also note that your screen shot in the prior post shows an expression in "scene". That's a no-no. You have to leave the expression blank. Only expressionless variables are settable (as is true within MSR as well).

[cw-kid]

Yes I have just realised my mistake, I was adding a 0 and 1 directly in to that "scene" Global Expression box to test some things e.g. triggering a rule set.

I removed the 0 and then it started working.

[cw-kid]

@LibraSun

In the other thread that seems to be locked now you said:

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.

What does this mean ?

"or even a hand-built Object in an Expression somewhere"

I'd like to add a comment next to my Global Expression but seems you can't do that currently.

[LibraSun]

First of all, you guys totally beat me to the "But is your scene variable empty?" question, LOL. Knew it!

Secondly, here's where I document my more elaborate variables (this may surprise you...):
INSIDE THE VARIABLE ITSELF!!

If you define, for instance:
sceneList := {'1':'Coming Home','2':'Leaving Home','3':'Daytime','4':'Nighttime'} , getEntity ( dev_Num ) . param . value . etc.
// result: the value of param under device #dev_Num (first half, my made-up documentation object, gets ignored)

Then you have a handy reference for the possible values you might see coming from the last part of the expression (namely, after the last comma). This is a made-up example, but should illustrate where I sometimes tuck things, since expressions can be multi-part.

I might even USE the object in some true lookup fashion, within the variable itself (again, this is pseudocode in the middle part):
hMode := hm = {'1':'Home','2':'Away','3':'Night','4':'Vacation'} , devNum = 345 , devMode = getEntity (devNum).houseMode , hm[devMode]

// result: "Away" (string) when houseMode .eq. "2"

[LibraSun]

@toggledbits Tricky question: Since MSR can receive variable values via HTTP, will there be a corresponding method by which MSR senses these events as "Updates"? You understandably omitted "Updates" as a conventional Trigger – particularly with respect to hub-paired entities – since MSR is not privy to controller internals...

...but now we've come full circle to MSR being the nexus of variable values being updated (not just via HTTP, but also from within Rules and Expressions). Given that MSR tracks the timestamp of when a value (even the same value) was assigned to a variable, might this present a means by which a new "Updates" mechanism could operate?

EXAMPLE
User sends http://<msr-ip:port>/api/v1/variable/some_var/set?value=5 at midnight
User again sends http://<msr-ip:port>/api/v1/variable/some_var/set?value=5 at 12:02am
Currently: MSR cannot be made to react, since stored value of some_var never changed
Proposed: MSR can react to refreshed value assignment using new "Updates" comparator (available only under [Expression Value])

Thoughts?

[toggledbits]

I've anticipated that, and there are some undocumented flags available on the request, but there are some conflicting scenarios I'm still working out.

[cw-kid]

@toggledbits

This has stopped working and I'm not sure why?

I was sending this command previously to MSR to set a Global Expression called "scene" and change its value:

http://192.168.0.4:8111/api/v1/variable/scene/set?value=frontcam

This was then triggering a RuleSet to run etc.

However now I am getting an error in the browser when I try it:

ReferenceError: self is not defined
    at /home/username/reactor/server/lib/httpapi.js:512:21
    at Layer.handle [as handle_request] (/home/username/reactor/node_modules/express/lib/router/layer.js:95:5)
    at next (/home/username/reactor/node_modules/express/lib/router/route.js:137:13)
    at Route.dispatch (/home/username/reactor/node_modules/express/lib/router/route.js:112:3)
    at Layer.handle [as handle_request] (/home/username/reactor/node_modules/express/lib/router/layer.js:95:5)
    at /home/username/reactor/node_modules/express/lib/router/index.js:281:22
    at param (/home/username/reactor/node_modules/express/lib/router/index.js:354:14)
    at param (/home/username/reactor/node_modules/express/lib/router/index.js:365:14)
    at Function.process_params (/home/username/reactor/node_modules/express/lib/router/index.js:410:3)
    at next (/home/username/reactor/node_modules/express/lib/router/index.js:275:10)

[cw-kid]

Fixed in build 21189

Thanks

[toggledbits]

I'm not sure how this worked for you before... really odd... that code is untouched for months... the line that was breaking was debug/logging, added on April 28. You would have first seen it in version 21118, and it was unchanged until today. Really weird we didn't see that raise its head before. But in any case, I'm glad you found it, and the fix is working.

[cw-kid]

It's not something I've been using often and I'd known it had broken for a few months and not looked into it, which is why I only reported it had broken yesterday..