LastTrip on non armed sensors

I’m trying to implement some logic where the house goes into away mode when all motion sensors haven’t reported movement for a while. It seems the LastTrip variable is only updated when the sensor is armed, but I don’t want my internal ones armed all day. Is there another variable for this or how do people approach this in general?

One solution is to leave all the sensors armed and add conditions to your scenes/PLEG logic to allow or ignore the trip depending on the state of a VirtualSwitch/MultiSwitch. This switch could be an existing Home/Away or a new one.

See Conditional Scene Execution for more on this.

I don’t use the Arm/Bypass mechanism on any of my sensors so I don’t know for sure. It may be that the timestamp for the variable Tripped gets updated even when the sensor is not armed. You can access this using a luup.variable_get(…).

local status, timestamp = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1","Tripped" ,123)

The timestamp is an integer number of seconds since 1st January 1970 (The Epoch). It may be compared to the current time from os.time().

this is what I use within a scene and it seems to work well for my needs.

function set_time(lul_device)
local tNow = os.time()
luup.variable_set(“urn:micasaverde-com:serviceId:SecuritySensor1”,“LastTrip”, tNow, lul_device)

What firmware version are you on? I’m on UI7 and my motion sensors (Ecolink & Fibaro) report fine regardless of arm/bypass state.

Hi CopyCatz, I am surprised to see your statement (LastTrip variable is only updated when the sensor is armed) because myself I do a similar thing at my home as you are trying to do…Actually what I do is check if there is no movement in the house for over an hour then I check if my DSC alarm system is turned ON, and if not then I send myself an alert so I can take an action if necessary…and I have never noticed that problem that you say the “[tt]LastTrip[/tt]” variable is only updating when the sensor is “Armed”.
Now that you have me worried about my setup ;), I will take a look at this tonight but I suspect (I hope) that you’re wrong with your findings and that your problem is somewhere else.