Need help reducing false positive notifications

[cw-kid]

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.

[toggledbits]

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

1. Under the config section for the vera controller in reactor.yaml, add a dump_entity: line indented two spaces relative to the config.
2. After the dump_entity: line, add "device_699": true and make sure that's indented two space from dump_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 this

Make sure you only use spaces for indenting. The restart MSR. Wait a moment, and a file called vera-device_699.json will be created in your logs directory. Grab and post here.

[cw-kid]

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

[cw-kid]

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

[cw-kid]

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

[cw-kid]

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:

https://reactor.toggledbits.com/mantisbt/view.php?id=159

[toggledbits]

All x_vera_state attributes were removed several builds ago. You'll find a x_vera_svc replacement 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.

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