-
Hello Everyone -
I have a peculiar situation that I'm hoping to get some help with.
Running Vera which is still handling my Zwave, MySensors, Zigbee, and still a balance of my Reactors.
However, I've also been running MSR for several months in preparation for an eventual move off of Vera.
Vera had one of its meltdowns this morning related to my Opensprinkler plug in.
After getting that straightened out, I added the OpenSprinkler plugin to HAAS and that's when I started having issues.
My existing MSR reactors (even simple ones) don't seem to fire their reactions. I can see the conditions go "true". If I manually fire the Reaction, it works fine.
I do see this a lot in the logs:
[1.0.2-21350]2022-05-16T19:02:44.518Z <Rule:INFO> Rule#rule-460 evaluation in progress; waiting for completion(Various rules - 460 is just an example)
Is there anything I can do to further troubleshoot?
-
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.
Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed. -
My MSR has been working flawlessly until a couple of days ago when it stopped sending Telegram Messages (or should I say they stopped getting through!). I have updated to MSR version 22004. The reactor.log is updating and is showing no errors:
[latest-22004]2022-05-15T17:52:31.417Z Engine:NOTICE Starting reaction Message Test (re-l37h2fkj)
[latest-22004]2022-05-15T17:52:31.417Z Engine:INFO Message Test all actions completed.
[latest-22004]2022-05-15T17:52:31.704Z Engine:INFO Enqueueing "Message Test" (re-l37h2fkj)
[latest-22004]2022-05-15T17:52:31.735Z Engine:NOTICE Starting reaction Message Test (re-l37h2fkj)
[latest-22004]2022-05-15T17:52:31.736Z Engine:INFO Message Test all actions completed.
[latest-22004]2022-05-15T17:52:32.007Z Engine:INFO Enqueueing "Message Test" (re-l37h2fkj)
[latest-22004]2022-05-15T17:52:32.035Z Engine:NOTICE Starting reaction Message Test (re-l37h2fkj)
[latest-22004]2022-05-15T17:52:32.036Z Engine:INFO Message Test all actions completed.
[latest-22004]2022-05-15T17:52:41.324Z Engine:INFO Enqueueing "Variable Telegram Test" (re-kvnm57c3)If I use the following in my web browser the telegram message gets through:
https://api.telegram.org/botxxxxx......./sendMessage?chat_id=xxxxx......&text=Test Message HTTPS
I am running MSR on my QNAP network attached storage. Any assistance would be appreciated.
Just another question...... I would like to post in the HOME HARDWARE VERA section of Smarthome, but I do not have the option to set up a new post. Do I need to request access for this?
-
Details of runtime environment:
Reactor (Multi-hub) stable-22055-9b40e12 Running as a service on Windows Server 2022 Std 21H2 Connecting to HASS (HASSOS) Is a migration WIP from OpenLuup/ReactorA complete description of your objective:
Using LetsEncrypt, application "certifyTheWeb", retrieve and apply SSL certificate to Multi System ReactorA description of your approach/solution/implementation so far:
Reviewed Config files, can't seen mention of certificate files in thereActual Question:
How do I apply a certificate to whatever web server Reactor uses? I'm familiar with managing certificates on IIS and Apache but Reactor doesn't use either of these and I have not been able to locat ethe config file that Reactor uses for this. Which config file needs editing to apply a certificate? Does it use the computer certificate store or it's own store (e.g. pem files)The reason I want to achieve this, other than the general goodness of having everything I can in TLS is that I have Reactor as an IFRAME in my HASS console and as HASS is HTTPS and Reactor is HTTP then the iframe refuses to open.
Search for "certificate" or "ssl" did not reveal anything relevant in this forum.
-
@toggledbits
Hi Patrick,
Running HASS 2022.5.3
MSR zwavejs-22126-834c3e9Seeing weird behavior in MSR with regards to my Zen32's. Not sure how to capture info that might be relevent but will describe what I am seeing.
In the example below I pressed scene 001 4 times. It flashed and changed the primary value to "4". The remaining buttons were previously showing the PV as "double" I pushed each button one time and they flashed and displayed the PV as 4.
zen32.JPGIn the zwavejs2mqtt debug screen that sequence looks like this.
2022-05-10 09:38:44.078 INFO ZWAVE: Node 45: value notification: 91-0-scene-001 5 2022-05-10T16:38:44.081Z CNTRLR « [Node 045] received CentralScene notification { "nodeId": 45, "ccId": "Central Scene", "ccCommand": "0x03", "payload": "0x898501" } 2022-05-10 09:38:45.982 INFO ZWAVE: Node 45: value notification: 91-0-scene-002 0 2022-05-10T16:38:45.984Z CNTRLR « [Node 045] received CentralScene notification { "nodeId": 45, "ccId": "Central Scene", "ccCommand": "0x03", "payload": "0x8a8002" } 2022-05-10 09:38:47.807 INFO ZWAVE: Node 45: value notification: 91-0-scene-003 0 2022-05-10T16:38:47.810Z CNTRLR « [Node 045] received CentralScene notification { "nodeId": 45, "ccId": "Central Scene", "ccCommand": "0x03", "payload": "0x8b8003" } 2022-05-10 09:38:48.858 INFO ZWAVE: Node 45: value notification: 91-0-scene-004 0 2022-05-10T16:38:48.861Z CNTRLR « [Node 045] received CentralScene notification { "nodeId": 45, "ccId": "Central Scene", "ccCommand": "0x03", "payload": "0x8c8004" }Let me know what other info you would like me to supply.
I have played around with a bunch of other key stroke combo's and it looks like buttons 2-5 display what ever button 1 is set to.
Have tested this on 4 different ZEN32's and it is same on all. -
Running zwavejs-22118-baab576 in MSR, HASSOS 2022.5.1
Due to an unreported issue in HASS, when I upgraded the 2022.5 yesterday, it dropped ZwaveJS2MQTT from my HASSOS build. Finally got it reinstalled and it appears to be working the way it was previously.
MSR is now showing zwavejs down and in entities, nothing is updating.Seeing this in the logs:
ZWaveJSController#zwavejs ws_open caught [Error]Error: connect ECONNREFUSED 192.168.0.16:3000Are there additional steps needed that are not mentioned in the manual?
At a loss to figure out what is causing issue. -
Hi!
After several tests, restarting the computer where the MSR is, and the MSR itself by Tools > Restart, I have a persistent error in the logs.
32d45bc3-51f8-4718-a113-3381e9d7edf2-image.png
Looking at the global expression (screen below), I see that it is highlighted as an error, however, if I look at two other expressions above that have the same structure, they do not present an error, so I do not think the problem is with the expression's code.
ca8a7867-4ac7-4f9a-9913-15a80da18f05-image.png
This expression uses a group, which validates 4 devices of type door sensor, whether the status is true or false, door open or closed.
"dgc_entrance_open": name: DGC Entrance Open select: - include_entity: - "hubitat>37" - "hubitat>38" - "hubitat>99" - "hubitat>130" filter_expression: > entity.attributes?.door_sensor?.state == trueI also compared it with other groups, the structure is identical.
Looking at the 4 devices in this group, I see that all are active in the MSR, have similar variables, are used in other groups and rules that do not present a problem.
52b099f4-b9c4-46cb-ad3d-c873b09b7e13-image.png
Looking at the log, I understand that it refers to some object that would be null, at which point I am lost on what to actually look at.
[latest-22118]2022-05-02T22:33:11.711Z <Engine:INFO> Reaction Engine starting [latest-22118]2022-05-02T22:33:11.719Z <Engine:INFO> Checking rule sets... [latest-22118]2022-05-02T22:33:11.746Z <Engine:INFO> Checking rules... [latest-22118]2022-05-02T22:33:11.748Z <Engine:INFO> Data check complete; no corrections. [latest-22118]2022-05-02T22:33:11.892Z <Engine:ERR> [Engine]Engine#1: error evaluating expression EntranceOPEN: [ReferenceError]ReferenceError: Invalid scope in reference to member attributes of (object)null [latest-22118]2022-05-02T22:33:11.893Z <Engine:ERR> [Engine]Engine#1: expression: sort(each id in ( getEntity('groups>dgc_entrance_open').attributes.sys_group.members ): getEntity(id).name) [latest-22118]2022-05-02T22:33:11.894Z <Engine:CRIT> ReferenceError: Invalid scope in reference to member attributes of (object)null ReferenceError: Invalid scope in reference to member attributes of (object)null at _run (C:\MSR\reactor\common\lexp.js:1449:31) at _run (C:\MSR\reactor\common\lexp.js:1443:33) at _run (C:\MSR\reactor\common\lexp.js:1443:33) at _run (C:\MSR\reactor\common\lexp.js:1536:38) at _run (C:\MSR\reactor\common\lexp.js:1480:33) at C:\MSR\reactor\common\lexp.js:1283:29 at Array.forEach (<anonymous>) at _run (C:\MSR\reactor\common\lexp.js:1282:28) at run (C:\MSR\reactor\common\lexp.js:1663:22) at Object.evaluate (C:\MSR\reactor\common\lexp.js:1699:20) [latest-22118]2022-05-02T22:33:12.232Z <Engine:NOTICE> Reaction Engine running! [latest-22118]2022-05-02T22:33:12.233Z <Rule:INFO> Rule#rule-kxjp2el2 (Mode DAY) started [latest-22118]2022-05-02T22:33:12.234Z <Rule:INFO> Rule#rule-kxjp7kc8 (Mode EVENING) started [latest-22118]2022-05-02T22:33:12.234Z <Rule:INFO> Rule#rule-kxjparz7 (Mode NIGHT) started [latest-22118]2022-05-02T22:33:12.234Z <Rule:INFO> Rule#rule-kxjpd0d6 (Mode AWAY ∆) started [latest-22118]2022-05-02T22:33:12.235Z <Rule:INFO> Rule#rule-kxjqrcr9 (Mode PARTY) started [latest-22118]2022-05-02T22:33:12.235Z <Rule:INFO> Rule#rule-kxjqyhnu (Mode VACATION ∆) startedFinally, if I return the expression and press the Try This Expression button, it is executed and the error disappears.
102e5013-b9aa-4c26-98f5-1ae545f8897f-image.png
This situation started to occur on the latest version of Reactor 22118, on a Windows 10 Bare Metal installation. Does anyone have a similar scenario?
Sorry for the long post, I tried to document as best as possible to try to identify the problem.
Thanks.
-
Please can anyone give me advice on a cheap way to run MSR (both initial cost and ongoing electricity cost). I currently run it on my QNAP network drive (which works very well incidentally). However, this draws a constant 35Watts (£90/yr @ 30p/kWh) and given the recent rise in fuel costs I am evaluating the best way forwards. Note, I only really need to turn my QNAP on for an hour a week to back-up my computer data. I understand that MSR can run on a Raspberry PI, but I am not competent with Linux! Thanks.
-
I just noticed that the new hotness picked up the entities from when I added an integration temporarily to my Home Assistant and popped a lovely info notice into the Alerts pane.
I know the info is new - but when did MSR suddenly become more real-time with devices being added to hubs? This is great!
-
Noticed in the last few nights that my Global Reaction to turn on a mere six lights in the evenings the same two devices no longer turn on. One is a dimming smart bulb, the other is a wall outlet.
This has been running flawlessly for months - just in the last few nights I've noticed these two devices being left behind and yes, it's always these two devices only.
"What changed?"
No Hubitat firmware updates No new devices added to Hubitat list itemTwo MSR updates (the last two, I keep up with the latest) list itemHome Assistant releases (should have zero bearing, HA is nothing more than pretty dashboards) list itemAdded MQTT to MSRI did do a z-wave "repair" last night and am waiting to see if this helps.
Is there any maximum or cap on number of devices that should be included in a Global Reaction?
*Marked as solved as the question asked was answered. The issue persists but the question was answered.
-
I've borked my install of reactor-latest-22118-0f0772c.tar.gz for some reason and am retracing steps. Running npm i --no-save --omit dev prompted to update npm and I did (current version now 8.6.0). Currently, attempts to load via browser/s (Brave and Safari) result in "This site can’t be reached192.168.1.xxx refused to connect." I am still able to SSH into the RPi.
I haven't panicked yet but did just pull my config and storage directories - I believe I read where that's enough for a back-up if a clean install ends up being needed.
So the question of the day: which version of nmp should we be running on for the latest Reactor?
-
I’ve looked and can’t find the answer which concerns me that the answer is obvious and thats why I can't find the answer to this.
I’m new to MSR and this is my first post, so please bare with me 🙂
What I’m trying to do is have a global expression that contains the current time so I can use it in Global reactions as well as Rulesets as part of my syslog messages.
Example of what I’m experiencing:
In Expressions, create a global expression: gMyTOD = strftime("%T %D”)
In Rulesets, in a rule, create a local expression: MyTOD = strftime("%T %D”)In that same rule create a Notify type of Syslog.
Set syslog message to: gMyTOD time is ${{gMyTOD}} and MyTOD time is ${{MyTOD}}
Trigger the rule.The result is that the local expression (MyTOD) contains the correct time but the global expression (gMyTOD) does not update and reflects the wrong time in the final syslog message.
Is there a different approach I should be using?
Thank you in advance for any insight.
-bh
-
Hi!
What's the easiest and most effective way to make this work? Do I ping a few websites every ten minutes or so, or is there a better approch? If I'm going to ping, what URL is recommended?
Once a month or so, my internet access is lost, and I have to cut the power to the router, to restart it. When I'm away this become a problem, so I thought that if I got a zigbee switch (in Home Assistant), problem is solved. But how do I (MSR) know if it's offline?For information, I have a set up with Asus routers, Home Assistent with zigbee-, z-wave and wifi devices (a total of appr. 150) and every of my 60-70 automation is done by MSR.
I run MSR ver. 22080-ae7212f (docker on my Home Assistant blue). HA ver 2022.4.6.
Thanks in advance.
Take care, you all!
/Fanan -
-
So, I have a rule set that it's triggered when a local variable changes. Since it's tied to my solar production, it could change very frequently, so I've just added a reset delay to calm it down, but it's not working as intended.
What I really need is a way to, let's say, define a percentage and define a variable to understand if the new value has changed +/- 10% before going true.
I've tried a couple of ways, but I'm posting here anyway, in case anyone has found a better way to tackle this. Thanks!
-
Perhaps a dumb question. Can I check from Home Assistant that MSR is up and running? I would like to see that in a status page in HA. I can of course ping the other Pi but it doesn't say anything about the MSR status.
-
@toggledbits Is there a way to get Current Alerts as an entity so I could monitor those and send notifications if needed.
My usecase is sometimes openLuup crashes and MSR picks that up pretty quick, sending a pushover notification to me would get my attention to restart it.
Of course there are many ways to monitor connectivity but since MSR already is doing that it would be neat to take advantage of it. -
Hey @toggledbits.
From the docs:You cannot control the state of rules via MQTT. Rule state is driven exclusively by the result of its conditions.
And I'm OK when rules are triggered by something else, but I've built a couple of rules to be used by other rules, to streamline the logic, and it'll be useful to invoke a rule via MQTT. It's probably close to what rule/:id/restart is doing in the HTTP api.
Thanks!
-
I'm trying to create some automation so I can control my pool variable speed pump from reactor rather than iAqualink (which sucks). My controller is MQTT enabled so I created several scripts for my desired speeds. (I know reactor has MQTT ability but honestly I read the docs and could not make much sense of it and since I already have it set up in Home Assistant, I figured I would just leverage that instead)
So I created all of my scripts and tested them, they worked perfectly. The I created a rule in reactor and set running the script as the action. The problem is that reactor is telling me that I have to make a selection. I try to click the dropdown and there is nothing to select. I cant save the rule, the only option is to exit.
9e0a3147-5058-4893-9860-2f0d759dfe3c-image.png
Here is my script in Home Assistant. Any advice on how to get this to work? If I am looking at this the wrong way I am open to suggestions (I would rather be able to call a specific action and specify a speed value but I cannot figure out how to do that). Thanks in advance.
-
Hi, I've been using msr for a while now and haven't had timezone issues until today when I updated to latest docker image (latest-22080-ae7212f)
both docker date command and my local date command show the same time, same timezone, but for some reason MSR shows the host time as 2 hours in the past as a result all my timed rules run 2 hours late.
my locale is set correctly in the host machine and is bound into the container as well.
One possible hint I get is maybe this from the container startup log, but other than timezone stuff everything else seems to be working fine and all my settings loaded up just fine.
[latest-22080]2022-04-07T07:52:52.423Z <SystemController:null> Module SystemController v22080 root {} CommonJS loading [latest-22080]2022-04-07T07:52:57.236Z <Engine:CRIT> SyntaxError: Unexpected end of JSON input SyntaxError: Unexpected end of JSON input at JSON.parse (<anonymous>) at IndividualFileStrategy.getDataObject (/opt/reactor/server/lib/IndividualFileStrategy.js:121:46) at Container.getDataObject (/opt/reactor/server/lib/Container.js:102:53) at new GlobalExpression (/opt/reactor/server/lib/GlobalExpression.js:105:179) at Function.getInstance (/opt/reactor/server/lib/GlobalExpression.js:123:89) at /opt/reactor/server/lib/Engine.js:1349:67 at Array.forEach (<anonymous>) at Engine.initializeGlobalExpressions (/opt/reactor/server/lib/Engine.js:1345:145) at Engine.start (/opt/reactor/server/lib/Engine.js:590:285) at /opt/reactor/app.js:362:103Let me know if I can provide further info to help debug this.
Thanks
Expressions and LuaXP Functions
-
Knowing that MSR Preview may not yet fully implement LuaXP (CORRECTION: MSR uses a different language lexpjs), I could not resist whipping up some text expressions for fun. Whereupon two things popped out at me:
- The new scaling (0.00 - 1.00) of Dimming Level will require a rewrite of certain Expressions that I use to balance my light levels. For example, it was my custom to monitor one lamp's brightness (0 - 100) with Reactor Luup, then set another lamp to 93% of that level, using this Expression:
floor(getstate( 9, "urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget" ) * 0.93)
Now, in MSR, it will become necessary to modify that to read:
floor ((getEntity( "vera>device_9" ).attributes.dimming.level * 0.93)*100)/100
which effectively scales the value up x 100 (so that floor() can act upon it correctly), then downscale it / 100. Just an FYI to ponder.
- I'm noticing that every edit, however minor, of an Expression in MSR requires an immediate SAVE click before the 'Run' button will become active. That is to say, I cannot repeatedly evaluate the Expression during editing, without clicking SAVE first.
Only mentioning this latter behavior since it departs so dramatically from Reactor Luup's paradigm.
-
@librasun There's going to be a lot to digest on all sides of the expression discussion, as expressions are one of the most-changed parts of MSR from Reactor for Vera/openLuup. A few days ago, I made another pass at the documentation for Expressions, to at least get most of the syntax and function changes out, if not the operational specifics.
Not really related to expressions, strictly speaking, The 0-1 issue is going to keep coming up, I realize. The original thinking was to allow more resolution, as the 0-100 mapping is actually lower res than the 0-255 or 0-65535 that many devices support at their closer-to-physical layers. To make that easier, I can take the HomeAssistant approach and have a mirrored set of values in another scale, like
level_percent
, and name the actions accordingly, likedimming.set_percent
. So I'll throw that on the list, and it should make a little less work. That said, ...@librasun said in Expressions and LuaXP Functions:
then set another lamp to 93% of that level, using this Expression
I'm not really understanding the problem here, and I'll frame my confusion with an example, and perhaps you can tell me where you see a problem I've missed... you've got a lamp that you set to 40% on Vera, or 0.40 as reported in MSR, and you want a second lamp set at 93% of that, so the second lamp would be set to 0.372. It's not a problem to store that value in MSR, and nor is it a problem to set that value using
dimming.set
, as MSR will convert it back to units of the system when it sends the action to it. So on Vera with a 0-100 scale, it would send 37, and if the host system accepted 0-255, it would send 94. You don't really need to round the numbers. Does it have to do with comparisons in conditions? If you're willing tofloor()
to two digits so you can do a comparison like<= 0.93
, then the equivalent without the rounding step is< 0.94
.There's no LuaXP in MSR. MSR uses lexpjs, which I also wrote, so of course there will be similarities for that reason alone, but also because basic infix expression syntax doesn't wander far from common ground. But there are changes, and lexpjs is a much more robust module, built on a proper grammar into a proper parser. This has enabled me to add a lot of flexibility into the language that didn't exist in LuaXP, and would have been a real pain to not have available in MSR. And I can also more easily evolve it. For the most basic usage, there's not much difference, but the expressions are used extensively in the device mappings, and so many of the "tweaks" applied are specifically to keep those expressions short and readable.
The biggest changes with regard to expressions are context and timing.
Rule-based expressions, the expressions that live within a rule, operate much like they did in ReactorSensors: they are evaluated prior to the evaluation of conditions; and they are evaluated in the order in which they are listed. A big difference is that rule-based expressions are not available outside their parent rule. There is no way to "export" them.
Global expressions are entirely new. Global expressions are accessible to all rules, both in rule-based expressions (referred to by name), and in Set Variable actions. They are primarily meant to be common-use data containers. They are only evaluated when they are referred to in an expression that is itself being evaluated; they do not evaluate continuously or on event. So for example, if you created a global expression
getEntity( "vera>device_9" ).attributes.dimming.level
, and that global expression was not used by any rule-based expression, it would not update when the dimming level changes and you would see no change in its value in the UI (and that is all expected). It will just sit there. If, however, you refer to it in a rule-based expression, that then becomes a driver, the rule's dependency on the device recognized, and both the expression and the rule using it would be evaluated when the dependent device changes.The disabling of the "Run" button on expressions when unsaved is a temporary simplification. Right now, there's no way to run an arbitrary expression. Any expression that is run is presumed to require its full state to run. That is, an expression inside a rule could refer to any other expression value in the rule, so all of the expression values in the rule are part of the execution context of every expression. Rules know how to build the context and run their stored expressions, but they don't know how to run a one-off expression within their context: there's no API to say "just run this arbitrary expression with your usual context as if it was part of the rule." All of that needs to be built. It will get done, but for the moment, you'll have to tolerate the inconvenience of having to save the rule/expressions first. Expressions didn't work completely and couldn't be used at all in actions until yesterday's build. One step at a time.
Note: In the process of writing this I did notice that the
and
,or
andnot
operators from Lua/LuaXP are not present in lexpjs currently as these keywords. They are directly equivalent to&&
,||
and!
respectively that are native to lexpjs, so I'll go ahead and add the syntactic sugar to the grammar so that the Lua keywords work, to reduce the load on Reactor users coming over from Vera. -
Excellent explanations, thank you! I will adapt my own uses to the new scaled dimming levels instead of trying to deal with them as integers like the old days. For the moment I cannot think of a pressing case in which integers would be required, but I dare say someone else will come up with one soon, so your idea of implementing set_percent might make sense in the long run.
I look forward to your full documentation of the "new" lexpjs language. Just let me know when you are ready for me to hammer very hard on that and assist with updating any documentation.
-
Every build includes the day's doc updates, if any. Get to that from the "Manual" link in the left nav.
Work in progress on the docs is often visible at https://reactor.toggledbits.com/docs/
-
Roger that. Meanwhile, out here in the weeds responding to your earlier interest why I'd want to keep something like dimming values granular/integer... it's because I sometimes base triggers off of a device's exact brightness level (e.g. when dim = 50). So I'll have to modify my thinking for when dim = 0.50. Trivial.
Having digested the docs for LEXPJS (https://github.com/toggledbits/lexpjs/blob/master/lexp.js), I can simply rely on the 2-argument ROUND instead of the 1-argument FLOOR and be done with it.
I'll keep an eye on those Docs as you suggest. Thanks again.
-
If you're looking at lexpjs on Github, better to look at the develop branch these days... master has not been updated in quite a while.
-
Started to play around with expressions in the MSR. Comparing two temperatur sensor and passing the lowest into a virtual sensor in Vera. It seems that the value in not passed to the virtual sensor or most probably I do something wrong. I have two similar rules, if Temp1<=Temp2 (shown below) and one if the Temp2<Temp1. I am not sure about the "Set Reaction"
-
The MSR variable/expression replacement is
${{ expression or variable name }}
. Try that. I fixed at least one substitution bug today, but I'm not sure if it would intersect your use in the reaction. You've got a device type in your service field for the set variable action, and I'm not sure what your conditions are meant to do. I think what you mean to do is something more like this:Expressions:
- Temp1:
getEntity( "vera>device_86" ).attributes.value_sensor.value
- Temp2:
getEntity( "vera>device_88" ).attributes.value_sensor.value
- MinTemp:
min( Temp1, Temp2 )
Condition:
- Expression Value:
MinTemp
changes
Set Reaction:
- Set Variable: service=
urn:upnp-org:serviceId:TemperatureSensor1
, variable=CurrentTemperature
, value =${{MinTemp}}
- Temp1:
-
Gotta ask: What precisely causes the field(s) background under 'Set Reaction' to turn yellow? For example, if I wrote {levelLamp} it's not yellow, but if I type ${levelLamp} or ${{levelLamp}} (as I knew the proper syntax to be) it turns yellow.
-
Yellow means it will accept the value but it may be out of range for the field. I suspect that's a side-effect of the bug I fixed. You'll need to wait for today's build before playing more (at least, if you want it to work
)
-
@toggledbits Thanks, I missed that the variable expression has been changed.
-
Ah-ha, I see that you went with zero-based array indexing in LEXPJS, versus the ol' one-based indexing enjoyed back in LuaXP. Gonna make my transition to MSR a bit more challenging as I transcribe my umpteen array-centric Reactor routines, but c'est la vie.
Glad I noticed this before getting to use the Backup/Restore approach, since I doubt it does (or can or even should) attempt an auto-translation of such things. In my case, being one-off on my table lookups could have meant setting the wrong House Mode, etc. Fun! LOL
-
Also, I'm noticing that if you define in Expressions:
obj = {ani:bird, typ:bard}
that, in order to access the value of "bard", instead of obj.typ (which returns {name:bard}), one must instead construct:
type = obj.typ.name // returns "bard"
Maybe that's normal? I had to really think about it as a non-programmer.
NOTE: In the process I also learned that the 'keys' of an object cannot be numbers; they must begin with a letter.
More importantly, I am already missing the array function CHOOSE -- can it be imported into LEXPJS?
-
I REALLY LOVE how you can now do the following array index references with minimal effort (and that this probably obviates the need for the CHOOSE function I mentioned above):
Expressions
idx = 2
listN = ["red","green","blue"]
findIt = listN[idx] // returns "blue"
-
Even with the release of 21072, it seems we are still waiting for "substitutions" to become allowable within Expressions. Is this correct?
For example, rather than this disallowed comparison in Triggers:
[Expression Value] [acMode] [ <> ] [ ${{houseMode}} ]
where acMode and houseMode are both defined expressions within that Rule...
I'm using this workaround:
[Expression Value] [ modesMatch ] [ is FALSE ]
for which I created the Boolean expression
modesMatch := ( acMode == houseMode )
Gets me where I need to be, just slightly less elegant. (For now.)
-
Correct. Not yet in conditions.
-
Good to know. Meanwhile, I'm profiting from variable substitutions working awesomely down in Reactions!
Although I bumped into a case you may not have fully considered? Namely, in a Rule designed to alter House Mode to match the current mode of my ecobee Thermostat, I cannot use substitution with your "House Mode" plug-in, since it only permits any of four preset options from a pick list.
That is to say:
[Entity Action] [ House Mode ] [ x_vera_housemode.set ] [ <mode> ]
does not let me select the mode dynamically, based on a variable; it's hard-wired.
Instead, I'm forced (as I always was in RFL) to execute Lua code against Vera herself:
[Entity Action] [ Vera Plus ] [ x_vera_sys.runlua ] [ luup.call_action( "urn:micasaverde-com:serviceId:HomeAutomationGateway1", "SetHouseMode", { Mode = ${{acModeNum}} }, 0 ) ]
I thought this would work, but it does not appear to be substituting for acModeNum in place, the way RFL used to do for, say. Reactor.Variables.acModeNum.
P.S. Alternatively, if you could surface Vera's and/or Reactor's "House Mode" action in the following manner, I could use it in the reaction:
[ Entity Action ] [ Vera | Reactor ] [ ...setHouseMode ] [ ${{acModeNum}} ]
Standing by for guidance, and hope you find this food for thought in later MSR revisions.
-
-
Thanks, my bad! Didn't even think to try that. Would have saved me like 45 minutes of poking around, lol.
-
Meanwhile, I seem to have dug another small hole in the VARIABLE SUBSTITUTION workflow, and it's been vexing me for over an hour. This action
keeps sending a literal
${{houseModeTxt}}
to its target, instead of the substituted value:
houseModeTxt := away (string)
Did not want to post this as a PR, since I think it's unique to me. Took me a while to even notice that Vera was throwing a bright blue error on her Dashboard, with the ecobee plugin complaining of being sent an out-of-range parameter (expects one of "home", "away", "sleep" or "smart1").
Thoughts? Am I having a fatal stroke here?