Trying to set variable with HTTP API request
-
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}
@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).
-
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.
-
First of all, you guys totally beat me to the "But is your
scenevariable 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
lookupfashion, 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" -
@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 ofsome_varnever changed
Proposed: MSR can react to refreshed value assignment using new "Updates" comparator (available only under [Expression Value])Thoughts?
-
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.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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.
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=frontcamThis 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) -
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.
-
T toggledbits locked this topic on
