Upgrade Issues

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