Advice reqeusted to migrate MSR from Bare Metal to Container

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

[cw-kid]

@rafale77 I'll take a closer watch over it and see, it may have been 10 minutes.

[cw-kid]

I tripped the Everspring motion sensor and then untripped it. Started a stop watch and I'm up to 13 minutes now and the error has just come back again. Also the motion sensor hasn't been re-tripped again during this time.

[rafale77]

I have two of these everspring sensors and have no problem with them. I highly recommend to reconfigure it. Now I don't know why the error would come back. There has to be another mechanism causing this. Likely some variable not set properly.

[cw-kid]

OK Ill take it down the Everspring from the Porch and have a look at it.

The Neo Cool Cam is also giving me this same "Can't detect device" error that one never even had a LastWakeUp variable present, until I ran your code.

I have a Fibaro motion sensor and that seems OK though.

[rafale77]

Ok I now have another recollection of a mechanism by which the vera flags these devices as failed... It is from the database in the zwave chip itself. The only way to reset this on the vera is to get the device reconfigured because a flag was set at the serial level. On Z-way you can remove this flag with a click but the vera doesn't offer this option. So... you should not see these anymore after you have the devices reconfigured. The way I previously addressed this was running the vera on a USB stick and then stick it into a windows PC and use the PC controller software from silabs to reset the failed flag before sticking it back into the vera. there should also be a serial command from the command line to do this on the vera but I forgot...

[cw-kid]

@rafale77 Is Z-Way good then? It's from Z-Wave.me right.

They are also the main Z-Wave distributors for Europe based in Germany.

I only need two projects to support a Z-Wave platform that could be used as just a radio. MSR and The Home Remote dashboard app.

[rafale77]

@cw-kid

Z-way is indeed the most comprehensible zwave network controller I know. I used it as a tool alongside the vera for some time before completely replacing the vera thanks to @akbooer's bridge updates for openLuup. I could do and see all kinds of things on my zwave network which obviously the vera doesn't offer and is a great part of why I have learned as much as I have about the vera quirky zwave management.

Specifically for you problem, this is the screenshot of what z-way offers. You can manually mark a device as failed or unmark it (I don't have this option right now because I don't have any failed devices) on the right. There are also a lot of explanation everywhere on the UI as to what each thing does. You can force secure and unsecure inclusions etc etc... so many other things. And yes it works awesomely well with openLuup to which you can transfer all your scenes and plugins. You will be able to get MSR to work with it.

[cw-kid]

So Z-way is the Z-Wave controller / radio.

Then OpenLuup sits in the middle somewhere and can run Vera plugins and has a HTTP API like Veras Luup Requests?

Openluup can Bridge to the Z-Way controller to control the Z-Wave devices.

And MSR can talk to OpenLuup.

That about right?

Just trying to understand how it all fits together.