MSR UI on a mobile browser

[cw-kid]

@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

[toggledbits]

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 Armed is 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 null when 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.

[cw-kid]

@toggledbits

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]

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.

[toggledbits]

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

[cw-kid]

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

[toggledbits]

@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

                                      ^^^^^^^^^^^^^^^^

[cw-kid]

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

[toggledbits]

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 arming service, 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.

[cw-kid]

OK I won't do anything on the Vera side or attempt to add back in the "Armed" variable using the New Service function.

[toggledbits]

The other issue, found that, will be fixed in today's build (restart reporting system entity missing).

[cw-kid]

@toggledbits

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.

[toggledbits]

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 arming capability will make sure that its state attribute always exists with a value of true, false, or null, the first two following the value of SecuritySensor1/Armed when 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 Armed variable appear on the device. It can't do that. It only affects how it reads the device data that is available. So something created Armed on the Vera side in the interim, perhaps Vera itself.

[cw-kid]

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

[toggledbits]

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.

[cw-kid]

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.

[toggledbits]

Change out sdata for status and see what it reports.

[cw-kid]

@toggledbits

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

[toggledbits]

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?

[cw-kid]

@toggledbits

http://Vera-IP:3480/data_request?id=status