maybe someone can help me on that.
i have a RaspBerry PI and have connected a few binary inputs to it. a small python3 app that submits the status on change and every xx minutes to the vera.
everything working perfectly…
exept of one thing. i have a Trigger set up turn on the garage light if the garage door sensor is triped.
the PI simply makes a curl with … &serviceId=urn:micasaverde-com:serviceId:SecuritySensor1&Variable=Tripped&Value=0
(its inverted (use a reed sensor))
so every time this url will be executed … the trigger does fire, even if the Value was “0” before.
is this a bug or standard behavour on SecuritySensor1 devices ?
and the main question, how do i stop this from happening ?
attached the trigger edit screen … (which is very straight forward)
No, this is not the standard behavior but you should provide a little bit more detail and maybe we can help you to find the issue.
One recommendation for you would be to try the “Dashboard” and then click on “Overview” assuming you are using UI5 with the latest firmware. You can see sensors under security and their trigger status. I love that overview page as I can see what windows and doors are open even if I am not at home. This might help you troubleshooting your issue.
maybe someone can help me on that.
i have a RaspBerry PI and have connected a few binary inputs to it. a small python3 app that submits the status on change and every xx minutes to the vera.
everything working perfectly…
exept of one thing. i have a Trigger set up turn on the garage light if the garage door sensor is triped.
the PI simply makes a curl with … &serviceId=urn:micasaverde-com:serviceId:SecuritySensor1&Variable=Tripped&Value=0
(its inverted (use a reed sensor))
so every time this url will be executed … the trigger does fire, even if the Value was “0” before.
is this a bug or standard behavour on SecuritySensor1 devices ?
and the main question, how do i stop this from happening ?
attached the trigger edit screen … (which is very straight forward)[/quote]
You may be getting this problem because you are periodically setting the device’s state-variable Tripped which will update its timestamp and signify a change to the trigger logic. You should not set a variable unless the value has changed.
I suggest that you change your PI code so it only sets Tripped when it has changed. An alternative would be to add an action to the virtual-device plugin - say SetTripped newTripped=… and have that set Tripped only if newTripped is a change. Your PI code can call the action instead of directly setting the variable.
Oddly enough, this is the standard behavior for the Security Sensor.
If you look inside of:
[tt] S_SecuritySensor1.xml[/tt]
you’ll see the section for the Tripped stateVariable:
[tt]
Tripped
[/tt]
This default was changed several yrs back, by MCV (it used to be no-repeats). Most things won’t trigger a Scene based upon a “duplicate” value change, but in this case it will because the [tt]S_SecuritySensor1.xml[/tt] has told it to
Apparently there was some sort of Z-Wave sensor that required this behavioral change, since it wasn’t guaranteed to always toggle states… odd, something to do with sleep states IIRC.
So Rex’s answer is correct, you just need to track the changes (at the caller, probably) and not send the same state transition.
@RexBeckett yes this is exactly what iam doing (and iam not smart enough to implement that properly either) …
well i’m working on it.
i change the Device definition to be a DoorLock … and POOF … it worked right away … so @guessed is right … this is SecuritySensor Related only.
[quote=“guessed, post:4, topic:178939”][tt]
Tripped
[/tt]
So Rex’s answer is correct, you just need to track the changes (at the caller, probably) and not send the same state transition.[/quote]
i tried a more simple aproach … and duplicated the D_ and S_ file
and changed the XML to “no” and also try with “no-repeats” …
but the outcome is the same as before
looks like i really have to go down the more complicated road and try getting done a real virtual MotionSensor Switch.
.oO( or i just leave it with the DoorLock1 Definition … since it is for my Driveway Gate … its acceptable )
i tried a more simple aproach ... and duplicated the D_ and S_ file
and changed the XML to "no" and also try with "no-repeats" ...
but the outcome is the same as before :(
This type of shortcut tends not to work with Vera. You would need to create a new device type to use your modified (and renamed) files.
looks like i really have to go down the more complicated road and try getting done a _real_ virtual MotionSensor Switch.
If you decide to do this, we can probably help.
Best Home Automation shopping experience. Shop at Ezlo!
)