Alerts - (vera>device_699) does not have attribute ?attr?
-
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.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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.
-
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.
@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.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@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.
-
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:
@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
^^^^^^^^^^^^^^^^Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@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. -
The other issue, found that, will be fixed in today's build (restart reporting system entity missing).
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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.Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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.@toggledbits said in Alerts - (vera>device_699) does not have attribute ?attr?:
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
But I still can't see the "Armed" variable listed in Vera. I have hard refreshed the browser.
-
Well, it would not be listed if it hadn't come back in user_data. If, since the last MSR restart, the Vera reported that variable even once, MSR would have it. If it later is missing, there's actually no way for MSR to know it's missing, it thinks it's just not being updated/no updates for it, so it keeps it at the last value it got. The only way to reset that cached state is to restart MSR.
-
This is confusing.
This is the SDATA for this device, "armed" is indeed present:
{ "name": "Deck Floodlight", "altid": "133", "id": 699, "category": 3, "subcategory": 0, "room": 5, "parent": 1, "status": "0", "configured": "1", "armedtripped": "0", "lasttrip": "1617376314", "tripped": "0", "armed": "0" },However I cannot see that variable in the Vera UI7 web GUI even after reloading the LUUP engine and hard refreshing the browser.
-
Change out
sdataforstatusand see what it reports.Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Change out
sdataforstatusand see what it reports.Status output:
{ "id": 699, "service": "urn:micasaverde-com:serviceId:ZWaveDevice1", "variable": "SensorMlType", "value": "1" }{ "id": 699, "states": [ { "id": 466, "service": "urn:upnp-org:serviceId:SwitchPower1", "variable": "Status", "value": "0" }The name of the device "Deck Floodlight" cannot be found, so I searched for its ID number 699 instead and that's all I could see.
I don't know what ID 466 is ? There is no device with that ID.
Its not its altid / node id that is 133
-
That does not look like a complete status output. Can you post the URL you used for that query? I assume you're doing that as an HTTP request?
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
That does not look like a complete status output. Can you post the URL you used for that query? I assume you're doing that as an HTTP request?
