I have multiple 2Gig DW10-345 sensors and have started seeing an issue with signal latency. One zone in particular seems to be less responsive to the close event. It clearly sees the opening of the door, but then misses the closing about 10% of the time, resulting in a sensor stuck in the tripped mode until the door is cycled again. This has become a major issue with my alarm system, where it will trigger an alarm on a sensor that is stuck in a tripped condition but is actually secure (door is closed but sensor reports otherwise).
I have been trying to determine the actual meanings of several parameters associated with these sensors but can not find anything of substance. What I want to understand is the possible parameters for “Mode Settings” and “Ignore Trip Time” variables. I have played around with the Ignore Trip Time setting but is has not seemed to have any effect.
I realize that not every connected object may support every variable, but I would like to get a better understanding of how they might affect each connected device. Along the same train of thought is the “Capabilities” variable for some objects. Very little information is available as to the parameters and their intended use.
Can anyone shed some light on my sensor latency issue or offer some technical insight as to these somewhat cryptic variables. Thanks!
I am not going to be very helpful except to echo I have noticed this same behavior in my 2 AeonLabs DSB54-ZWUS door sensors. Maybe not 10% but I would guess 5% of the time. The one sensor closest to Vera (about 3’) is the one we use the most - many times a day, and it is annoying when it happens.
Don,
Although you can’t directly access the variables necessary to reset them with PLEG, you can write to them with LUA. The following code will reset a tripped sensor back to the untripped state. I hate to think that I would need to add this extra code to all my sensors, as it should not be necessary but this does work for sensors involved in either a security system or door entry/exit alerts.
luup.variable_set(“urn:micasaverde-com:serviceId:SecuritySensor1”, “Tripped”, “0”, 31)
luup.variable_set(“urn:micasaverde-com:serviceId:SecuritySensor1”, “ArmedTripped”, “0”, 31)
For those who are uncertain how to use this code in their system, replace 31 with your device ID.
In theory “Ignore Trip Time” is meant to prevent sensor from report “tripped” state until it is tripped for certain time. That’s what I’ve read on internet.
But when I played with this variable for one of my sensors (Fibaro binary sensor, if it matters) I also didn’t see much effect. If any then it was rather a delay between going back from “tripped” to “untripped” state, not the other way around.
I don’t know what are the units used for this variable. Default seems to be 2 for all sensors (at least those which I use), but are they seconds, miliseconds, other?
If you find a way to manage that, please give me an info.
[quote=“kartcon, post:3, topic:197265”]Although you can’t directly access the variables necessary to reset them with PLEG, you can write to them with LUA. The following code will reset a tripped sensor back to the untripped state. I hate to think that I would need to add this extra code to all my sensors, as it should not be necessary but this does work for sensors involved in either a security system or door entry/exit alerts.
luup.variable_set(“urn:micasaverde-com:serviceId:SecuritySensor1”, “Tripped”, “0”, 31)
luup.variable_set(“urn:micasaverde-com:serviceId:SecuritySensor1”, “ArmedTripped”, “0”, 31)
For those who are uncertain how to use this code in their system, replace 31 with your device ID.[/quote]
+1