Vera device extended attributes ?

[cw-kid]

Hi

How are Vera extended attributes meant to work in Triggers ?

I wanted a trigger on Comm Failure for a particular device. (A motion sensor)

In PLEG I can just select any of the variables for the device and these are the items I see in the drop down list:

urn:schemas-micasaverde-com:serviceid:SecuritySensor1
urn:schemas-micasaverde-com:serviceid:HaDevice:1
urn:schemas-micasaverde-com:serviceid:ZWaveDevice:1
urn:schemas-micasaverde-com:serviceid:ZWaveNetwork:1

I can't see how to do the same in MSR ?

Thanks

[toggledbits]

@cw-kid said in Vera device extended attributes ?:

How are Vera extended attributes meant to work in Triggers ?

Like any other attribute, although the one you chose to highlight there (mapped_by) is for my debugging and probably useful to nobody else.

Because Vera has so many state variables for some devices, it's not reasonable to map and copy them all right out of the gate. It would be overwhelming to most new users. If there's something you need to get to, you just need to let me know. It's really a big part of the purpose of this phase: discovering both what devices, and what data in those devices, are the most-used.

When I fill out the per-user device configuration, you'll be able yourself to pull data that isn't published by default, enable or disable an action a specific device can perform, or even create your own mapping entirely for a device that doesn't yet have one. Future stuff.

I'll get the comm failure variable mapped for you today.

[cw-kid]

OK thanks that sounds great.

I have two problem motion sensors in Vera and it says "Can't Detect Device" in the UI7 GUI, for no obvious reason as the motion sensors still function fine.

In PLEG I currently just monitor for their CommFailure = 1 and set it back to 0.

Its a fudge fix for Vera being crap at handling these motion sensors, seems a later firmware update at some point in time made this happen, as it never happened in the past and those sensors never use to say "Can't Detect Device".

[rafale77]

@cw-kid said in Vera device extended attributes ?:

Its a fudge fix for Vera being crap at handling these motion sensors, seems a later firmware update at some point in time made this happen, as it never happened in the past and those sensors never use to say "Can't Detect Device".

The vera will flag battery operated devices it fails to receive a wakeup signal for a time >2x the wakeup interval. It is a common behavior in controllers and I don't think it is new. You should see complains about this from the beginning of vera. I thought I had suggested to vera dev to change this behavior to run this flag so as not to only consider the wakeup packets but all packets as the "last alive" time to eliminate exclusive dependency on the wakeup process. I guess I was ignored. If I remember correctly made the same suggestion to z-wave.me and it got quickly implemented.

The vera has the tendency to miss a lot of zwave traffic due to its very bizarre "maintenance" scheme whereby it sends request to every battery devices to do a network heal whenever they wakeup (wakeup NNU) which basically disables the device and the network nodes around it while it is polling them for about a minute. And the nightly heal which essentially does the same for all devices no matter how they are powered, freezing the entire network for 30min (depending on how large your network is) at least and causing luup engine hangs and crashes as the unfinished tasks accumulate. All very unique "features" of the vera. There was another thing about the battery operated devices which I had requested for the longest time to eliminate but it escapes me at the moment.

Combine this with a weak antenna and a noisy RF environment and you get a lot of "Can't detect device"

[cw-kid]

@rafale77 Yes I'm sure they could of improved many things.

I only get "Can't detect device" on mainly two motion sensor devices and its always the same two.

I have other motion sensor devices that don't seem to have this issue or certain not all the time like these two do.

I have polling set to 0 for all battery operated devices and their wakeup interval is 86400 / 24 hrs.

[rafale77]

Try also update the LastWakeupTime to be the same as LastTrip and reset the sensor failure with the setFailure command in luup code for that device or maybe even waking them up manually. I think these devices may not be waking up at all or may just happen to be waking up when your zwave network is doing something else like a heal or an nnu so it is missing them every time.

[cw-kid]

@rafale77 Looking at one of the motion sensors that has "Can't detect device" on it now, its lastwakeup time is: 1606495613 or Friday, 27 November 2020 16:46:53

Its an Everspring SP816-1 outdoor one. Looking in its user manual it does say its maximum wakeup interval is 1 day, so I should be OK with 86400 seconds I have it set as.

Wonder why its not waking up? It's still detecting motion events perfectly fine. Might have to take it down and check the batteries and wake it up manually.

[cw-kid]

The other problem motion sensor is a Neo Cool Cam NAS-PD02Z. I can't even see a "LastWakeup" variable / value on that device at all, it has no field for it in the GUI showing.

[rafale77]

Yep that's the problem. The vera tags its battery operated devices as "can't detect" using this variable. For your information:
WakeupInterval is a parameter of the vera. It is the interval the vera is going to measure to as it expects the device to update.
ConfiguredWakeupInterval is a parameter stored in the device. It is the number the vera got the last time the device was configured and told the vera that's the setting it has.
LastWakeup is the date the last time the vera saw the device to have woken up.

The logic in the vera is as I said before, "if os.time() - LastWakeup > WakeupInterval*2 then set Device fail =1"....
Now more funny... The device wakes up to its lifeline associated group. (group 1). It is possible that your device was not completely configured and that the association was not setup correctly. The best way to know is to wake the device up to see if you see the variable. If not then try reconfiguring.
More fun... some devices won't accept any other nodeID than "1" in this association group so if your vera's zwave has a different ID... well it will never report to the vera that it has woken up.

[cw-kid]

@rafale77 said in Vera device extended attributes ?:

WakeupInterval is a parameter of the vera. It is the interval the vera is going to measure to as it expects the device to update.
ConfiguredWakeupInterval is a parameter stored in the device

ConfiguredWakeupInterval on both of these motion sensor is
86400 I can see this value on each device.

The WakeupInterval on both of these motion sensor is
86400 I can see this value on each device.

I've just woken up the Neo Cool Cam one that had the missing LastWakeUp value and its still missing. I then polled it OK but still no LastWakeUp field showing up. Might have to try and reconfigure it.

As for the Everspring one outside, Vera says it hasn't woken up since November LOL. I'll have to take it down and have a look also.

[rafale77]

Idea popping in my head to make this behave more like z-way... have a scene to update the LastWakeup variable every time the Tripped variable changes... That would be a quick patch to overcome the stupidity of the firmware.

[cw-kid]

@rafale77 Sounds like a good idea.

If I could have a MSR rule do this? even better.

[rafale77]

@cw-kid

It's possible to do it on the MSR but this is the version on the vera:

1. Create a scene with trigger being your sensor's tripped event (tripped or untripped)
2. Add the following lua code as the scene lua:

local dev = --the device id of the sensor--
local t = os.time()
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "LastWakeup", t, dev)
if luup.variable_get("urn:micasaverde-com:serviceId:HaDevice1", "CommFailure", dev)=="1" then
  luup.set_failure(false,dev)
end

Done...

You could possibly even implement this to all sensors by making it a function and set a variable watch on all the tripped values in the startup lua... After this, you would also have to run

[cw-kid]

Great thank you. I will give it a try.

[cw-kid]

Just tried the code in the Vera test window against the outdoor Everspring motion sensor. It works. Its updated its lastwakeup value to just now and gotten rid of the "Can'r detect device" red banner also.

[cw-kid]

I ran the code against the other Neo Cool Cam motion sensor with the missing LastWakeUp field and now that field is present and up to date with that time stamp.

I've setup two functions in the Vera startup for each motion sensor to run this LUA code and two MSR rules to trigger upon their motion being tripped etc.

[cw-kid]

But the "Can't Detect Device" error comes back again shortly after the motion sensor has been untripped for a while.

Damn you Vera firmware haha.

As soon as its tripped it goes away, with what we have setup

[rafale77]

Note that if you don't trip these sensors regularly, you will still see a problem eventually so it is best to fix the wakeup. If they get tripped regularly then you don't need to worry too much about it.

On your last edit: Please ensure to use the code I updated. I made a mistake the first time around using the wrong service ID.

[cw-kid]

This is what I have in the functions:

-- Porch Motion Sensor Fix LastWakeUp and Can't Detect Device Errors
function PorchMotionSensorFix() 
   luup.log('VeraScenes.PorchMotionSensorFix')
   local dev = 304
   local t = os.time()
   luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "LastWakeup", t, dev)
   if luup.variable_get("urn:micasaverde-com:serviceId:HaDevice1", "CommFailure", dev)=="1" then
   luup.set_failure(false,dev)
   end
end

-- Lounge Motion Sensor Fix LastWakeUp and Can't Detect Device Errors
function LoungeMotionSensorFix()
   luup.log('VeraScenes.LoungeMotionSensorFix')
   local dev = 331
   local t = os.time()
   luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "LastWakeup", t, dev)
   if luup.variable_get("urn:micasaverde-com:serviceId:HaDevice1", "CommFailure", dev)=="1" then
   luup.set_failure(false,dev)
   end
end

[rafale77]

Yup it should work. I don't see why it would flag them as failed again... The firmware checks every 10min so you have to wait 10min to be sure it doesn't come back.