-
I decided to move my MSR pi to a permanent place and after that i cant connect to it. I can se in the logs that it has connection with hubitat ..
I says
2021-04-22T20:11:54.649Z Controller:ERR SystemController#reactor_system disk usage not available: Error: Cannot find module 'diskusage-ngWhat has happened? I did a hard remove by powercable....
/MattiasFull log
2021-04-22T20:10:56.493Z Controller:NOTICE Controller HubitatController#hubitat is now online.
/home/pi/reactor/server/lib/SystemController.js
2021-04-22T20:10:56.497Z app:NOTICE Starting Reaction Engine...
2021-04-22T20:10:56.498Z Engine:INFO Reaction Engine starting
2021-04-22T20:10:56.499Z Engine:INFO Checking rule sets...
2021-04-22T20:10:56.514Z Engine:INFO Checking rules...
2021-04-22T20:10:56.559Z default:ERR [IndividualFileStrategy#/home/pi/reactor/storage] failed to read cs-rule-knbyvokt in /home/pi/reactor/storage/states/cs-rule-knbyvokt.json: SyntaxError: Unexpected end of JSON input
Trapped unhandled Promise rejection SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at IndividualFileStrategy.getDataObject (/home/pi/reactor/server/lib/IndividualFileStrategy.js:126:38)
at Container.getDataObject (/home/pi/reactor/server/lib/Container.js:91:53)
at Rule.getRuleStates (/home/pi/reactor/server/lib/Rule.js:601:98)
at Rule.getConditionState (/home/pi/reactor/server/lib/Rule.js:626:46)
at new Rule (/home/pi/reactor/server/lib/Rule.js:491:47)
at Function.getInstance (/home/pi/reactor/server/lib/Rule.js:500:36)
at /home/pi/reactor/server/lib/Engine.js:584:50
at Array.forEach (<anonymous>)
at Engine.checkData (/home/pi/reactor/server/lib/Engine.js:582:36)
SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at IndividualFileStrategy.getDataObject (/home/pi/reactor/server/lib/IndividualFileStrategy.js:126:38)
at Container.getDataObject (/home/pi/reactor/server/lib/Container.js:91:53)
at Rule.getRuleStates (/home/pi/reactor/server/lib/Rule.js:601:98)
at Rule.getConditionState (/home/pi/reactor/server/lib/Rule.js:626:46)
at new Rule (/home/pi/reactor/server/lib/Rule.js:491:47)
at Function.getInstance (/home/pi/reactor/server/lib/Rule.js:500:36)
at /home/pi/reactor/server/lib/Engine.js:584:50
at Array.forEach (<anonymous>)
at Engine.checkData (/home/pi/reactor/server/lib/Engine.js:582:36)
Promise {
<rejected> SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at IndividualFileStrategy.getDataObject (/home/pi/reactor/server/lib/IndividualFileStrategy.js:126:38)
at Container.getDataObject (/home/pi/reactor/server/lib/Container.js:91:53)
at Rule.getRuleStates (/home/pi/reactor/server/lib/Rule.js:601:98)
at Rule.getConditionState (/home/pi/reactor/server/lib/Rule.js:626:46)
at new Rule (/home/pi/reactor/server/lib/Rule.js:491:47)
at Function.getInstance (/home/pi/reactor/server/lib/Rule.js:500:36)
at /home/pi/reactor/server/lib/Engine.js:584:50
at Array.forEach (<anonymous>)
at Engine.checkData (/home/pi/reactor/server/lib/Engine.js:582:36)
}
Trace
at process.<anonymous> (/home/pi/reactor/app.js:197:151)
at process.emit (events.js:315:20)
at process.EventEmitter.emit (domain.js:467:12)
at processPromiseRejections (internal/process/promises.js:245:33)
at processTicksAndRejections (internal/process/task_queues.js:94:32)
2021-04-22T20:10:56.599Z Controller:WARN HubitatController#hubitat 'Allow control of HSM' appears to be disabled in your Maker API configuration
2021-04-22T20:10:56.604Z Controller:NOTICE HubitatController#hubitat current mode is Kv\u00e4ll (131)
2021-04-22T20:11:54.649Z Controller:ERR SystemController#reactor_system disk usage not available: Error: Cannot find module 'diskusage-ng'
Require stack:
2021-04-22T20:12:16.879Z Controller:ERR HubitatController#hubitat mapped capability x_hubitat_healthcheck has no implementation -
I have created a Global Reaction with this LUA code for my Vera to run.
However when I run the Reaction nothing happens. I can't see anything in the log file either about this rules ID number.
If I run the same LUA code on Vera in the test window it works OK.
OR any other suggestions how I can set this up in a global Reaction (Scene) in MSR ?
Instead I could use the VeraScenes.lua file in the Vera startup library, but I am wondering why I can't just paste the LUA code directly in to the MSR rule.
Thanks
local status = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 419) --Status of Safe to Arm virtual switch if status == "0" then --Safe to Arm luup.inet.wget("http://SOME-HTTP-REQUEST") luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","SetHouseMode", {Mode = 2}, 0) --Set House Mode to Away luup.inet.wget('SOME-HTTP-REQUEST' ,5); else --Not Safe to Arm luup.inet.wget("SOME-HTTP-REQUEST") luup.inet.wget('SOME-HTTP-REQUEST' ,5); end -
Hi,
I've been using Pushover in VeraAlerts, but now want to send my notifications from MSR.
I see in the reactor config directory that the notification. yaml file includes Pushover, but is showing #TBD. Is this where I need to set up my Pushover user key etc. and if so what and how should the information be entered?Any help would be appreciated.
-
For years of participating in the other community, I've watched people post a single error message from a log file when asking for help. I'm now seeing the same behavior (I guess not surprisingly, given the genesis of this community) here. But it's got to stop.
When you post just the error message, you leave out vital context that may give clues to more quickly troubleshoot whatever problem you are having. Very often, by the time someone responds to ask for more, the message is gone (e.g. rotating logs on Vera) or has become too difficult to locate.
Please, when posting anything from a log file, you should be giving context with the message by including, let's say at least 10, messages before, and a few after. Particularly in the case of MSR, almost every exception that is logged is accompanied by a context-defining message immediately before, and in many cases, a follow-on additional data dump related to the error.
Thanks for listening.
P.S. My weekly (it seems) reminder: when things go wrong that obviously aren't just the UI doing something dumb, you must look at the logs.
-
I have a rule that closes my curtains when I start my Xbox activity on the Harmony hub.
In the Contraints I have that it's day time.
In the Reset Reaction it opens the curtains when I end the Xbox activity etc.
Today it was day time and I started the Xbox activity and the curtains closed.
When I turned off the Xbox it was night time, however my curtains then opened.
I expected the curtains to remain closed as by then it was night time.
Not sure the best way to handle this? But I want a rule that closes the curtains if it's day time and I want to play on the Xbox. If it's still day time when I end that Harmony Activity then open the curtains again. Or if it's night time then keep the curtains closed.
I figure if I start playing the Xbox and it's already night time then the curtains would already be closed anyway via the sunset offset schedule that closes the curtains.
-
What does Blocked mean in running reactions?
Anyone having a lot of empty alerts that is not possible to erase?
Hubitat - MSR
/Mattias!
Skärmavbild 2021-04-22 kl. 12.09.15.png -
I'm moving the discussion on this out of the Mantis PR #178 for the benefit of all/documentation, and also because it's easier to type and format here.
@LibraSun wrote in that PR:
I'm 99% certain you'll explain this one away as "expected" but I naively believed it would yield different results:
In an expression defined by:
a=[1,2,3],
each i in a:
shift(a)
// result (array) [1,2] (unexpected
// expected [1,2,3]This has me thinking that 'each' is leaving items on the table, as I tried unsuccessfully pointing out above.
The issue here is that your expression shift(a) is modifying the iteration subject array in place. Basically, here are the iteration steps that are run, starting with a=[1,2,3]
First iteration: a=[1,2,3]; the local i is assigned the first array element 1, but it is not used in the expression. The expression shift(a) results in 1 and causes a to be reduced to [2,3] (the first element is shifted off and becomes the result). Since this is the last value in the expression, 1 is added to the each result array. Second iteration: a is now [2,3] because the previous iteration modified it. So i is assigned 3, because the iteration is on the second element/iteration through the array, but i is not used in the expression. The shift(a) causes a to be reduced to [3] and its return value is 2, so the value 2 is added to the iteration result array. Third iteration: a is now [3], and we are on the third iteration, but the iteration index of 3 (third iteration) is now off the end of the array (only 1 element long), so iteration stops.The result of this each is therefore [1,2] because those are two values that were shifted out, and a is left at [3] because there was no third run of shift() to remove it.
As I said in the PR, modifying an array you are iterating through can be dangerous and confusing in many languages, because iterators keep state during iteration, and some operations you can do inside the iteration can and will invalidate that state in some way. In Lua on Vera, this often leads to deadlocks and crashes so bad that the box reboots, not just a Luup reload. It's a Bad Idea, and programmers who know are very wary of doing this type of thing in any language unless they are certain of the side-effects/lack of side-effects.
Your additional example:
a=[1,2,3], // The array 'a' is [1,2,3]
a=unshift(a,0), // The array 'a' is [0,1,2,3]
a=push(a,4), // The array 'a' is [0,1,2,3,4]
each i in a: // Iterating over the 5 elements of 'a'
shift(a) // Take the first element of 'a' and append it to result array [ ]
// result [0,1,2] (unexpected)
// and array 'a' is now [3,4]! (also unexpected)Also correct result. All of the gyrations before the each are not relevant to behavior here. At the start of the each, the array is [0,1,2,3,4] (5 elements). Iterations:
a=[0,1,2,3,4], i=0, shift(a) returns 0 and modifies a to [1,2,3,4]; the each result array is now [0] a=[1,2,3,4], i=2, shift(a) returns 1 and modifies a to [2,3,4]; the each result array is now [0,1] a=[2,3,4], i=4, shift(a) returns 2 and modifies a to [3,4]; the each result array is now [0,1,2] Iteration stops because the iteration index/step is 4, but there remain only two elements in a=[3,4] (we're off the end of the array).So the each result is [0,1,2] and a is left with [3,4] and this is correct operation.
Key points:
each keeps state during the iteration (as most iterators do) about the subject of the iteration; if the subject changes in a way that affects the state, unexpected results may occur; The functions push(), pop(), shift() and unshift() modify the array in place. If you say b=shift(a) you get a value in b and a modified (shorter) a. -
I've imported all reactors from openLuup, and find myself moving a lot of entity-actions from triggers to constraints.. It would help a lot to have "drag & drop", or a move function for this?
-
Just thought i'd mention it, as I've walked into it multiple times when editing rules:
dbc9e2c8-887e-46bd-8e3c-1364eb99bb03-image.pngWhen I make/edit rules, i'm used to pressing "save" through the process, and when I do that, theres only the red one left to press. It does make sense, as its already saved, but I'll stop and think one more time when it says w/o saving.
In my head, a exit button which causes a pop-up warning if changes are not saved makes more sense - like in vera reactor.Feel free to discard the idea, its just something to get used to mabye. 🙂
-
Followers will be aware of the problems I had setting up MSR, so it won;t come as a surprise that now I have problems Upgrading to the latest version. (How much I wish for a "Click to Upgrade" Button.....)
I've been stuck on this for 6 days and am ready to throw in all into the to hard basket, surely HA shouldn't be this problematic?
There, I've said it now I feel better....
So what's the problem, I can upload the file using WINSCP but no matter what I've tried it won't un-tar and over write the existing files in the Reactor Directory.
I receive the following error message which may as well be written in Martian 🙂 in my case.
Command 'tar -xz --directory="reactor" -f "reactor-0.1-21101-0db64f0-generic.tar.gz"'
failed with return code 2 and error message
tar: reactor: Cannot mkdir: Permission denied
tar: reactor: Cannot mkdir: Permission denied
tar: reactor/INSTALL.md: Cannot open: No such file or directory
tar: reactor: Cannot mkdir: Permission denied
tar: reactor/LICENSE.md: Cannot open: No such file or directory
tar: reactor: Cannot mkdir: Permission denied
cut for sanity sake....This goes on for ad infinitum for every file.
I tried with both users, no change, can anyone decipher this and explain why WINSCP won't untar the file?
-
How can I do this?
The topic in the instructions is very limited.Other Controllers
Other controllers that you may find as add-ins will each have their own specific configuration instructions. Please refer to their accompanying documentation.What information should I be looking for?
I've tried port 1880 which is used for node-red, assuming that this is a listening port - no go. Really not sure how to go about this as everything I do is mostly trial & error.
BTW, I added my Vera Lite into the mix successfully, HS4 would make it a trifecta!
-
Hi Everyone,
In the Vera Reactor logic, I used to use the operator "updates" in a lock condition.
If I entered the door and the code used was "Mike," it would hold the condition true indefinitely because "Mike" was the last stored value. Since it is held indefinitely, setting the condition to pulsed would not allow the condition to fire again because it never went false. If I entered a different code, the condition would go false, then entering "Mike" again would cause the condition to go true.
I did this using the operator "updates" in an AND condition along with the lock code. The code condition would stay true with "Mike," and when "Mike" is entered consecutively, the "updates" condition will go true each time, and then the whole condition would go true, triggering the action.
Since "updates" no longer appears to be an operator, how would I do this in the new logic? I think I remember a discussion about this, but I searched and can't seem to find it.
I'm not a programmer, so I am probably missing the easy way to do this.
-
For MSR users with SiteSensor still installed back on Vera, you might want to consider letting MSR take over those duties. Here's a quick run-down of how I imported one of my SiteSensor recipes into a Rule on MSR, using OpenWeather API* as an example.
STEP 1: Copy the Basics from Vera
(a) Go to your Vera > Devices, locate SiteSensor (the main instance, not one of its children devices) and click ► for details then click SETTINGS.
(b) Copy and paste (into Notepad or other text editor) the Request URL along with each of the defined expressions.STEP 2: Create a Rule on MSR
(c) Jump into Rule Sets and click "Create Rule". Click its title to rename the rule 'OpenWeather (API)" and click 'Rename'.
(d) Decide on appropriate Triggers (in my case, it's an OR group that includes an [INTERVAL] set to "Every 3 hours" plus a few [ENTITY ATTRIBUTE] entries reacting to things like entering/leaving home, waking up, etc.).
(e) In Set Reacion, create an [HTTP REQUEST] > [GET] action.
(f) Paste your old "Request URL" into the "Request URL" box.FYI GET calls to OpenWeather API* take the form:
http://api.openweathermap.org/data/2.5/weather?zip=<your_ZIP_code>&id=<your_Wx_ID>&appid=<app-id>&units=imperial(g) Create four new blank Expressions (name them openWx, Tx, Hx and Rx).
(h) Click SAVE & EXITSTEP 3: Process the Response
(i) Re-open rule "OpenWeather (API)" by clicking the 'Edit' icon.
(j) Within the [HTTP REQUEST] action, assign "Capture response to:" ► openWx
(k) Down in Expressions, click "[+]Add Expresssion" then enter the following:
Tx := round(openWx.main.temp,1)
// yields current outdoor temperature
Hx := round(openWx.main.humidity)
// yields current humidity conditions
Rx := openWx.rain ? ( openWx.rain['3h'] ? openWx.rain['3h'] : 0) : 0
// yields predicted rainfall, if present; otherwise 0
(l) Click SAVE & EXIT. Enjoy!Naturally, your specific needs and workflow will differ from the one I've outlined here. For instance, you may wish to explore the contents of the JSON object in openWx for additional data of interest to you, and define variables to match.
My goal here has been to illustrate some key concepts needed for moving from SiteSensor over to MSR:
Some syntax is the same, such as dot notation for object.item.access; Other syntax has changed, such as the use of ternary A ? B : C in place of IF (A, B, C); Manually setting an [INTERVAL] in lieu of SiteSensor's timed schedule;Pro tip: If your workflow demands that other Rules react to the output of the "OpenWeather (API)" rule, then be sure to create all of the aforementioned Expressions under "Global Expressions" instead, so they become accessible across all Rule Sets.
Once the transition is complete, you can either DISARM SiteSensor on Vera or remove it entirely with "Remove Device" (which will automatically remove all of its child devices).
*Additional reading:
OpenWeather API : https://openweathermap.org/api
FREE SUBSCRIPTION REQUIRED TO USE THIS SERVICEPRO TIP: See below for optimal way to incorporate OpenWeatherMap into your MSR workflow(s), by enabling the service directly in the reactor.yaml config file.
-
In my Vera config I have two SiteSensors (one for Ambient Wx, one for OpenWxMap) that point to two unique Reactor devices for controlling HVAC in my home. This is done for redundancy - if the Ambient API drops it returns zero data which then triggers a standalone Master API Reactor device to flip on the OWM SiteSensor and corresponding HVAC Reactor device to continue controlling the house conditions.
Once the Ambient API returns to available the Master API Reactor device flips back to the Ambient SiteSensor and corresponding HVAC Reactor device, turning OFF the SiteSensor for OWM to save on API calls.
I've been able to duplicate one half of this, including the Master API role, in MSR. But... here's the tricky part... I can't turn "off" the MSR Rule Sets for the OWM version. As such, HVAC is sent conflicting data and doesn't know what to do.
Before I go alls deep into explaining how all of this currently works, am I missing something somewhere that would allow me to trigger the on/off of MSR Rule Sets?
-
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)/100which 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.
-
Hi
I am assuming in time MSR will have some API documentation.
I am going to ask Bill the developer of the Home Remote dashboard app if he can add support for MSR.
Specifically support for MSR global Reactions (Scenes), where hopefully they can be imported in to the Home Remote Designer application and then we can more easily create dashboard tiles that when pressed would run a particular MSR global Reaction etc.
Currently in Home Remote it's possible but not so easy to create a tile that runs a http request when pressed and I have tested this and it does work and will run an MSR global Reaction.
But I'd much prefer if in the Home Remote Designer application MSR could be added as a device type and then all its global Reactions
imported as it does with Vera and other systems. -
Hi
Will Global Reaction rules have Constraints added at some point?
And maybe the other functions like Reset Reaction and Expressions.
Thanks
-
How are folks handling situations where they want to have Conditional Actions or Branching Logic in their Set Reactions for a rule? Are you creating Duplicating the same trigger and setting different conditions and Actions?
Is there an approach where you combine a main rule with your entity triggers with sub rules that trigger off Expressions? You then could write your conditions as Set Variable actions in the Main Rule for the Expressions that evaluate to true or false. Each sub rule would trigger based on the expression changing to true and then could also change it back to false after.
Not sure if that's worth the complexity for the reusability and control over duplicate triggers.
-
OK, people, here we go! At long last, Multi-System Reactor developer preview is available!
The package can be downloaded from the Reactor bug tracker, a MantisBT system (at https://reactor.toggledbits.com/mantisbt/). There is a download button in the left margin, as well as links to the documentation, which you will need for installation.
UPDATE 2021-02-24 -- To keep spammers off, I've locked down registration on the Bug Tracker. To get access to the Bug Tracker and preview downloads, please PM me (not reply here) your full name and email address and I will set up an account for you.
This version of MSR will run on Linux systems, including RPi's under Raspios Buster, running node.js version 12.10 or higher (v14.15.1). For RPi users, there is an installation script that will install a local copy of node.js (for the logged-in user).
Bugs reports will be handled through the bug tracker only. Discussion and questions in this forum are fine, though (if that leads to a bug report, we'll transition).
This version supports Vera (and openLuup to the degree it's compatible with Vera Luup), Hubitat, and Home Assistant. Some of the device support on the H platforms is still a bit basic, but it is largely controlled by configuration and progress can be made quickly.
The documentation beyond installation is a mess. Of course, I started with the existing documentation and have been massaging into MSR's particulars, but it still has a long way to go on the detail.
I know I don't have to say this, but I will anyway... let me know how it goes!
-
I looked through the forum, but could not find it, so my apologies if this has been asked. It would be nice to be able to push a message to MQTT for further upstream integrations.
Alerts - (vera>device_699) does not have attribute ?attr?
-
After restarting MSR I now have four alerts:
Three of them are referring to an Everspring EH403 outdoor flood light.
(vera>device_699) does not have attribute ?attr?
In the rules trigger I am using this:
x_vera_srv_micasaverde_com_SecuritySensor1.Tripped
This is a bit of an odd ball device in Vera as it doesn't create a motion sensor child device natively.
The parent device I have configured as a Binary Light, but it does have a "Tripped" variable for the PIR motion sensor portion of the device.
These rules have been working OK however.
As a test now, if I manually set the "Tripped" variable to 1 then my rules actions are run OK.
-
@cw-kid The alert may be new, but the error being thrown in the log file would not be, so you probably didn't notice (i.e. the new alert is generated in the same breath as the log message that's been there for a while now).
Just to clarify, are you testing the action device or is this a virtual device you are copying to?
If it comes up again, go the rule editor right away and see if it exists there or not. That would be instructive. Then go look on the Vera side (hard refresh your browser first to make sure the UI Variables tab is showing you current data, it rarely does). If it's there, it would be good to know what value it has.
And a device dump from a startup may also provide a clue:
- Under the
configsection for theveracontroller in reactor.yaml, add adump_entity:line indented two spaces relative to theconfig. - After the
dump_entity:line, add"device_699": trueand make sure that's indented two space fromdump_entity.
It will look like this:
controller: - id: vera # other config redacted for clarity config: # your source and other stuff redacted for clarity dump_entity: <---- add this "device_699": true <--- and thisMake sure you only use spaces for indenting. The restart MSR. Wait a moment, and a file called
vera-device_699.jsonwill be created in yourlogsdirectory. Grab and post here. - Under the
-
@toggledbits said in Alerts - (vera>device_699) does not have attribute ?attr?:
Just to clarify, are you testing the actual device or is this a virtual device you are copying to?
In MSR my rules trigger is looking at the "real" device the parent device and its "Tripped" variable, this is device ID 699, this is configured as a Binary Light device.
The virtual motion sensor device I created and that I am copying the tripped status to from the parent, I am not using this device in MSR as a trigger. But I guess I could do instead.
Virtual Motion Sensor:
And this is an actual child device of the parent, which is a LUX sensor.
You can download the device dump for the parent device 699 here.
-
I had to restart MSR a few times to do that device dump, after the first restart the alerts went away and cleared. After the second restart they are back again.
Not sure I know what you mean here?
"If it comes up again, go the rule editor right away and see if it exists there or not."
-
Device 699 information from the Entities area:
power_switch.state=false x_vera_device.configured=true x_vera_device.device_number=699 x_vera_device.device_type="urn:schemas-upnp-org:device:BinaryLight:1" x_vera_device.failed=null x_vera_device.mapped_by="*;device_type=urn:schemas-upnp-org:device:BinaryLight:1" x_vera_device.mapped_class="generic_switch" x_vera_svc_micasaverde_com_HaDevice1.ChildrenSameRoom="1" x_vera_svc_micasaverde_com_HaDevice1.Configured="1" x_vera_svc_micasaverde_com_HaDevice1.FirstConfigured="1616524758" x_vera_svc_micasaverde_com_HaDevice1.LastUpdate="1616525032" x_vera_svc_micasaverde_com_HaDevice1.ModeSetting="1:;2:;3:;4:" x_vera_svc_micasaverde_com_HaDevice1.PollRatings="5.00" x_vera_svc_micasaverde_com_SecuritySensor1.Armed="0" x_vera_svc_micasaverde_com_SecuritySensor1.ArmedTripped="0" x_vera_svc_micasaverde_com_SecuritySensor1.IgnoreTripTime="2" x_vera_svc_micasaverde_com_SecuritySensor1.LastTrip="1617297343" x_vera_svc_micasaverde_com_SecuritySensor1.Tripped="0" x_vera_svc_micasaverde_com_ZWaveDevice1.AgiInfo="X" x_vera_svc_micasaverde_com_ZWaveDevice1.AlarmType="0x7,0x8," x_vera_svc_micasaverde_com_ZWaveDevice1.AlarmVersion="0,2" x_vera_svc_micasaverde_com_ZWaveDevice1.AssociationNum="0" x_vera_svc_micasaverde_com_ZWaveDevice1.Capabilities="211,156,1,4,7,1,L,R,B,RS,|37S,49S:5,85,89S,90S,94,108S,112S,113S:4,114S,115S,122S,133S,134S,152,159," x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredAssoc="" x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredVariable="1-PIR Trigger Off period,2d,60,2-Lux sensor threshold,2d,30,3-Lux auto report,2d,1" x_vera_svc_micasaverde_com_ZWaveDevice1.FirmwareInfo="96,4609,29529" x_vera_svc_micasaverde_com_ZWaveDevice1.LastArr="1617238811,7" x_vera_svc_micasaverde_com_ZWaveDevice1.LastNnu="1617238807,7" x_vera_svc_micasaverde_com_ZWaveDevice1.LastReset="1616524754" x_vera_svc_micasaverde_com_ZWaveDevice1.LastRouteUpdate="1616525092" x_vera_svc_micasaverde_com_ZWaveDevice1.ManufacturerInfo="96,18,1" x_vera_svc_micasaverde_com_ZWaveDevice1.NodeInfo="55,5e,98,9f," x_vera_svc_micasaverde_com_ZWaveDevice1.PlusInfo="1,5,0,12,7,12,7" x_vera_svc_micasaverde_com_ZWaveDevice1.PollOk="2" x_vera_svc_micasaverde_com_ZWaveDevice1.PollSettings="60" x_vera_svc_micasaverde_com_ZWaveDevice1.SecurityFailed="0" x_vera_svc_micasaverde_com_ZWaveDevice1.SensorMlType="3" x_vera_svc_micasaverde_com_ZWaveDevice1.SubscribedAlarms=",0x7,0x8," x_vera_svc_micasaverde_com_ZWaveDevice1.VariablesGet="1,60,2,30,3,1," x_vera_svc_micasaverde_com_ZWaveDevice1.VariablesSet="1-PIR Trigger Off period,2d,60,2-Lux sensor threshold,2d,30,3-Lux auto report,2d,1" x_vera_svc_micasaverde_com_ZWaveDevice1.VersionInfo="3,4,61,1,1" x_vera_svc_micasaverde_com_ZWaveNetwork1.ConsecutivePollFails="0" x_vera_svc_micasaverde_com_ZWaveNetwork1.LastPollSuccess="1616525034" x_vera_svc_upnp_org_SwitchPower1.Status="0" x_vera_svc_upnp_org_SwitchPower1.Target="0" zwave_device.capabilities="211,156,1,4,7,1,L,R,B,RS,|37S,49S:5,85,89S,90S,94,108S,112S,113S:4,114S,115S,122S,133S,134S,152,159," zwave_device.failed=null zwave_device.manufacturer_info="96,18,1" zwave_device.node_id=133 zwave_device.version_info="3,4,61,1,1" Capabilities: power_switch, toggle, x_vera_device, x_vera_svc_micasaverde_com_EnergyMetering1, x_vera_svc_micasaverde_com_HaDevice1, x_vera_svc_micasaverde_com_SecuritySensor1, x_vera_svc_micasaverde_com_ZWaveDevice1, x_vera_svc_micasaverde_com_ZWaveNetwork1, x_vera_svc_upnp_org_SwitchPower1, zwave_device Actions: power_switch.off, power_switch.on, toggle.toggle, x_vera_device.set_variable, x_vera_svc_micasaverde_com_EnergyMetering1.ResetKWH, x_vera_svc_micasaverde_com_HaDevice1.AllowPairing, x_vera_svc_micasaverde_com_HaDevice1.Poll, x_vera_svc_micasaverde_com_HaDevice1.Reconfigure, x_vera_svc_micasaverde_com_HaDevice1.Remove, x_vera_svc_micasaverde_com_HaDevice1.SetPollFrequency, x_vera_svc_micasaverde_com_HaDevice1.StressTest, x_vera_svc_micasaverde_com_HaDevice1.ToggleState, x_vera_svc_micasaverde_com_SecuritySensor1.SetArmed, x_vera_svc_micasaverde_com_ZWaveNetwork1.AddNodes, x_vera_svc_micasaverde_com_ZWaveNetwork1.BackupDongle, x_vera_svc_micasaverde_com_ZWaveNetwork1.DownloadNetwork, x_vera_svc_micasaverde_com_ZWaveNetwork1.HealNetwork, x_vera_svc_micasaverde_com_ZWaveNetwork1.PollAllNodes, x_vera_svc_micasaverde_com_ZWaveNetwork1.PutByte, x_vera_svc_micasaverde_com_ZWaveNetwork1.ReconfigureAllNodes, x_vera_svc_micasaverde_com_ZWaveNetwork1.RemoveNodes, x_vera_svc_micasaverde_com_ZWaveNetwork1.ResetNetwork, x_vera_svc_micasaverde_com_ZWaveNetwork1.SendData, x_vera_svc_micasaverde_com_ZWaveNetwork1.SetPolling, x_vera_svc_micasaverde_com_ZWaveNetwork1.SimulateIncomingData, x_vera_svc_micasaverde_com_ZWaveNetwork1.UpdateNeighbors, x_vera_svc_micasaverde_com_ZWaveNetwork1.UpdateNetwork, x_vera_svc_upnp_org_SwitchPower1.SetTarget, zwave_device.poll -
I just updated to the latest version of MSR 21091 and now I have some more new alerts regarding this particular device:
An Entity Attribute condition in rule Deck Floodlight (Disarmed) - Tripped (Day) - Send Alert failed because the referenced entity Deck Floodlight (vera>device_699) does not have attribute x_vera_svc_micasaverde_com_SecuritySensor1.Armed
Not sure what I can do about this Everspring flood light device and these alerts ?
So I have edited my rules to use the virtual motion sensor device instead for their triggers instead of the parent device (Binary Light).
Also this is a new but similar Alert regarding the Vera Day or Night plugin
An Entity Attribute condition in rule Night - Day / Night Plugin failed because the referenced entity Day or Night (vera>device_43) does not have attribute ?attr?
Status 1 or 0 appears to have gone missing for this rule:
-
All
x_vera_stateattributes were removed several builds ago. You'll find ax_vera_svcreplacement for it. You could also just use the native date/time and sunrise/sunset conditions, rather than relying on yet another plugin.And by the way, the alerts from 21090 will persist until you dismiss them. You should not see any
{attr}in messages from 21091, but alerts from 21090, if they were not dismissed, would still have them. With a few exceptions (controller up/down), alerts don't go away until you dismiss them.So I have edited my rules to use the virtual motion sensor device instead for their triggers instead of the parent device (Binary Light).
This isn't going to help the troubleshooting. Please go back to the prior configuration, and let's continue trying to figure this out.
-
@toggledbits said in Alerts - (vera>device_699) does not have attribute ?attr?:
ou could also just use the native date/time and sunrise/sunset conditions, rather than relying on yet another plugin.
I think I added it just as a test to see if I could use the status of the Day or Night plugin. I've changed it to use x_vera_svc...status I didn't see that earlier when I looked.
All my other rules are using the MSR inbuilt sunrise/sunset conditions.
I've cleared the other Alerts and restarted MSR, as yet none have come back.
Thanks
-
Now that we know exactly what state variable it was complaining about, I took a look at the vera-device_699.json file you posted earlier, and sure enough the state variable
Armedis missing (go check my work, please). So that seems like there's an odd device implementation thing going on in Luup.I think we can work around it, though, and make it stable for your rules, by telling MSR that the device is special and instead of letting just have default Vera-specific capabilities, give it additional MSR-native capabilities. These will give you
nullwhen the variable is missing, but you can handle (or ignore) that more easily and it won't throw an error or alert. So you'll just test your device using the MSR-native attributes instead of the Vera service ones.I'll make up the changes to the device configuration file and PM it to you, and you can try it. It should work.
-
On the Everspring Flood light parent device (Binary Light) I've just looked in Vera and there is no "Armed" variable.
There is this variable however which is strange.
"urn:micasaverde-com:serviceId:SecuritySensor1 / ArmedTripped"
I could add an "Armed" variable to the device using the "New Service" function in Vera, think I know how to do that.
-
New Alert just appeared
"An Entity Attribute condition in rule Vera Luup Reloads failed because the referenced entity vera>system could not be found"
The rule looks to be OK however:
EDIT: Actually I think this Alert might happen if I manually reload the LUUP engine on Vera.
This rule is meant to keep track of the number of LUUP engine reloads.
-
@cw-kid said in Alerts - (vera>device_699) does not have attribute ?attr?:
On the Everspring Flood light parent device (Binary Light) I've just looked in Vera and there is no "Armed" variable.
It would have to have been there at some point or you could not have chosen it for your rule. The list in the rule editor only shows what exists on the device/entity, not what it thinks would normally be there. So it was there at one point, and disappeared later, and this is not that unusual in the Vera world, sadly.
You can try re-creating it. It would be educational to see if it "sticks" after a reload, and after changing house mode, which aside from user action are the principal ways that variable gets played with.
-
@toggledbits said in Alerts - (vera>device_699) does not have attribute ?attr?:
It would have to have been there at some point or you could not have chosen it for your rule
"Tripped" I was using "Tripped" as the trigger in the rule not "Armed".
Looking in the device dump .json file I did the other day I can't see "Armed" in there either. So maybe this device never had it in the first place.
-
@cw-kid said in Alerts - (vera>device_699) does not have attribute ?attr?:
An Entity Attribute condition in rule Deck Floodlight (Disarmed) - Tripped (Day) - Send Alert failed because the referenced entity Deck Floodlight (vera>device_699) does not have attribute x_vera_svc_micasaverde_com_SecuritySensor1.Armed
^^^^^^^^^^^^^^^^ -
@toggledbits said in Alerts - (vera>device_699) does not have attribute ?attr?:
An Entity Attribute condition in rule Deck Floodlight (Disarmed) - Tripped (Day) - Send Alert failed because the referenced entity Deck Floodlight (vera>device_699) does not have attribute x_vera_svc_micasaverde_com_SecuritySensor1.Armed
oh LOL that was a Constraint. So yes looks like I was using "Armed" also at some point.
So it has vanished as you suggested.
-
Whew! OK... that's good (no, really). So, I have the changes for the device def. I'll send that via PM. You can drop it into your reactor/server/lib directory and restart Reactor. It should give you the standard
armingservice, with a value report of null (if it's still missing at that point -- hope so, don't change anything on the Vera yet!). Even if you don't use it, I'd like to confirm this approach would work if it comes up for other devices. -
OK I won't do anything on the Vera side or attempt to add back in the "Armed" variable using the New Service function.
-
The other issue, found that, will be fixed in today's build (restart reporting system entity missing).
-
OK I have uploaded the vera_devices.yaml file and restarted MSR.
For the Everspring Flood light parent device this is what I am now seeing:
SecuritySensor1.Armed is the last item in the list in the drop down box.
So what does this mean ?
It can't see the actual "Armed" state if that variable has now vanished off Vera.
It seems to think its "false" not null.
-
Your other snip shows the variable is there now, at the bottom of the list, therefore it has appeared and has a value, and null is not to be expected. This is exactly why I am taking this approach: the
armingcapability will make sure that itsstateattribute always exists with a value of true, false, or null, the first two following the value ofSecuritySensor1/Armedwhen it is present on the device, or getting null if it is not. This is easier to handle in rules/conditions than getting an error thrown; you can treat null and false as equivalent, in all likelihood, which is exactly what a simple is TRUE condition operation would do.For the sake of clarity, the update did not make the
Armedvariable appear on the device. It can't do that. It only affects how it reads the device data that is available. So something createdArmedon the Vera side in the interim, perhaps Vera itself.