Security Sensor LastTrip behavior
-
I am not sure if this is the behavior inherited from the vera but I was looking at the codes and got annoyed that the LastTrip variable updates even when the variable set is to "untrip" the sensor. A bit of a pet peeve but I ended changing this behavior in the openLuup code to only update the LastTrip when it is a trip action. This is particularly annoying because of timed lighting or other sensors which are sending API calls to openLuup on a regular interval defeating the purpose (at least the one I think it is meant to have) of the variable.
I just moved this line
set ("LastTrip", tostring(os.time()))down to the armedtripped part of the code in the luup.lua file.
@akbooer was there a reason for that behavior?
-
IIRC, this is what Vera does. There's nothing wrong at all with recording a trip when the sensor isn't armed. That's why there is an
ArmedTrippedvariable which is only set when armed. -
That's not quite what I meant. The current behavior is that it is recording a LastTrip time stamp variable for an untrip event.
What I did by moving the call down is to have it update the time stamp variable only when it is an tripped = 1 event regardless of it being armed or disarmed. I was just puzzled as to why why it would record the untrip event. I just took advantage of the conditional already in the code for the armed tripped part of the code. -
Ah, I see. Well, I know (I think I know) that I researched this behaviour thoroughly when doing the initial implementation, but still having a Vera, I may be able to check that. It' s just that I don't have any motion sensors attached to it currently. Perhas someone else can help us to check it out?
-
...or, of course, this may be a 'feature' of the ZWay bridge, only.
-
I would not be surprised if this was one of these "not so smart" features of the vera and in my case it is not even relevant to the z-way bridge but it can be:
Examples:
- Say I want to use a motion sensor to turn on the light and wait for a certain interval of time without any tripping before turning it off. I used this LastTrip time stamp to measure that time... bummer. The time will be off by quite a bit since it gets updated by the untrip event.
- I have Home Assistant and a tomographic presence detection system sending updates to an openLuup motion sensor. I set one to send updates every 2 seconds (because its event based logic seems to not quite work) no matter what the status is. This LastTrip variable gets updated every 2s... making it not very useful.
-
Does the trip time get treated similarly?
-
Not sure what you mean. "LastTrip" I think is the only time stamp related to trip time?
-
Yup.. don’t know what I was thinking.
-
I have a generic handler on status to log lasttrip on tripped/untripped. Maybe this could be an openluup extension on a custom service id, leaving the actual behavior intact.
-
rafale77replied to akbooer on Feb 13, 2021, 7:40 PM last edited by rafale77 Feb 13, 2021, 2:46 PM
@akbooer said in Security Sensor LastTrip behavior:
Oh, wait, yes I do. Does the time toggle on trip AND untrip?
Not completely sure to understand the question.
The LastTrip variable does get updated to os.time with both trip and untrip. The code calls for an update every time a set variable call is made to the tripped variable of the security sensorID and that's the problem. It would be easy enough to create a new variable through a plugin or in the set variable function if the original behavior actually serves a purpose. For now I am trying to see if it does on my setup. It is however a misnomer for the variable since it really doesn't record the last time the sensor was tripped. It records the last time the sensor state got updated... -
So I can see now why one would want the "LastTrip" variable to record the untrip event... for door sensors where potentially someone could run a scene off of this timing. It doesn't make sense for a motion sensor since it isn't really an event per say for that type of sensor, it is a self reset of the sensor. I have now modified the code to only record the time if the "Tripped" value has changed unlike what it is doing now. Ideally I would have preferred a different behavior according to the type of security sensor.
PS: made a pull request with a proposal. For the motion sensors.
-
I have tested this for quite few days now and it all makes a lot more sense at least for the logic I used. I am even wondering why one wouldn't create another timestamp variable "LastUntrip" rather than using LastTrip for both trip and untrip. It appears indeed that having it tag both types of event was the behavior on the vera and I think i will keep my version for the motion sensors since it makes all my motion sensed lighting behave with the delay expected.
-
So you’re suggesting that we retain the original behaviour, but you don’t approve of that in the case of motion sensors? What shall we do with your pull request?
-
Since openLuup is luup on steroids, I'm officially suggesting differentiating its behavior, while retaining the luup original one for compatibility. So, something like LastTrip/Untrip in a different service definition should work better than altering it and causing troubles to other plug-ins assuming a different behavior.
-
I have an alternate suggestion. Preserve the Vera Luup behavior, and create new state variables for the alternate behavior, perhaps TripTime and UntripTime? Maybe come up with a prefix to denote openLuup-specific states, and apply this throughout?
-
The reason for my post was to try to get opinions and insights for the source and usage of this behavior.
I like the @toggledbits ' suggestion. Though the initial behavior doesn't appear to be well thought through, I think it is water under the bridge and it would be a bit too risky to deviate from it. I was going to change my PR to add functionality rather than modifying existing ones. I am thinking of adding LastTripTime and LastUntripTime? -
Well, that's what I was suggesting anyway, so my vote is for it, definitely
-
toggledbitsreplied to rafale77 on Feb 23, 2021, 1:43 PM last edited by toggledbits Feb 23, 2021, 8:45 AM
@rafale77 said in Security Sensor LastTrip behavior:
Though the initial behavior doesn't appear to be well thought through
You say that almost as if it wasn't the norm...
...and that would have gotten me banned over there...
Edit: to embellish with a more useful comment... regardless of how stupid the behavior, I guarantee you, from personal experience, that someone relies on it.
