-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sensors incorrectly report tampered conditions #117
Comments
What happens when you do tamper sensors ? |
So I had a sensor that had the reed switch open but the aux switch closed, and when it got tampered, both sensors were marked open, both tampered = false. How does qolsysgw decide if a sensor is tampered if it's not reported by the API? |
BTW, looking at the logs, I've noticed that I get a LOT of tampered sensor messages in the logs. The only reason why I noticed it is that I have a push notification every time the garage door status changes (open/close/unavailable). After all, this may not be limited only to dual sensors, as my PIRs routinely report tampered conditions and I know for a fact that they aren't tampered with, otherwise I would see messages on the IQP2 or on MobileTech! |
It seems to happen when some sensors stay open for a very long time; it seems like the panel is sending a redundant zone_action message when a status changes after a while... |
I documented in this document: https://github.com/XaF/qolsysgw/blob/main/docs/qolsys-panel-interactions.md (search "tamper") how I've identified (tests and checks) that the panel reports tampered sensors through the control4 API. I've not had any issue with that, even when keeping my windows open for a while, it does not seem to repeat-report the open status or send redundant messages through I'm not familiar with dual sensors: how are they working? I would have expected two sensors in the panel, if coming from the same physical sensor, to have zone ids that follow each other but it's not the case in your situation? |
I've looked at this further, and I still don't know why it reports that. Manually overriding the trouble check in the code fixed my issue. I've looked at panel config options and can't find anything, and MobileTech does not report any trouble conditions at this time. |
Resurrecting an old thread, I'm seeing the same behavior with one of my sensors. It is an outdoor PowerG sensor (PG9312). It does have an AUX input port similar to the initial report; however, I do not use the AUX input at all. This sensor is used on an outdoor gate that is opened in the morning and usually left open for about 12-14 hours and then closed at night. The issue I'm seeing is at night when the gate is CLOSED, Home Assistant shows that the gate is still OPEN even though on the IQ 4 panel it is properly showing as closed. Looking in the logs, I'm seeing that during the coarse of the day while the gate is still OPEN, there is an incorrect reported tamper event being sent. And then when the gate is CLOSED later in the evening, instead of that event being captured as CLOSED, it is clearing the tamper event, which leaves Home Assistant still believing the gate is OPEN. Usually after a few hours during a ZONE_UPDATE, the proper CLOSED state is eventually sent. I'm not sure if there is any solution to this, or if there is a way to just disable the tamper check altogether for this sensor. Either way, just passing along more details in case it is helpful to resolve this. I'm happy to provide any additional information/logs if it would be helpful. Sensor id=107-5354 / Sensor name=Driveway Gate / zone_id=10 Gate OPEN in the morning:
Incorrect gate TAMPER event (while gate is still OPEN):
Gate CLOSED in the evening (Home Assistant still reports OPEN):
A few hours later, proper CLOSED event is reported (during ZONE_UPDATE):
|
Same issue here with my multi-input sensors, like the PG9945 with reed + aux, and PG9WLSHW8 (8 inputs) also runs into this issue. If you have a sensor with multiple inputs on the same device ID, it'll create that problem. The only way to fix this is to bypass the trouble reporting in the code. |
Before submitting this form
I have checked that there hasn't been a similar issue submitted in the past
I have updated the issue title to something relevant and clear to understand the bug I'm facing
Description of the bug
I have a sensor on my hardwire translator that monitors my garage door. However, in some cases, it stays "open" but with a Tampered condition on qolsysgw, even though the sensor is secure on the IQPanel. It seems that triggering another sensor at the same time on my HW translator causes this issue.
Also, I have a PG9945 sensor that has a built-in reed switch as well as the AUX input. Same condition happens, it occasionally reports an Open condition with a Tampered = true, and closing the sensor reports an Open condition with a Tampered = false. Sometimes it clears itself on its own.
Further research seems to indicate that every time there is a sensor status change from the hardwire translator or a multiple loop sensor like the PG9945, it reports ALL of them through the API even though their status hasn't changed. This means we get 2 "Open" zone_event messages on an opened sensor on the API which is interpreted as a Tampered condition by qolsysgw.
This means we can't really report tampered conditions reliably on devices that report as multiple sensors/multiple loops. It just reports as "Open" in the C4 integration anyway, as there is no explicit field in the API for this.
Is there a way to disable Tamper reporting altogether? Perhaps on individual sensors?
Expected behavior
Garage open = open
Garage closed = closed, no tampered condition :)
Or, a way to disable tamper reporting on selected sensors, if not all of them.
DEBUG logs
Sensor is a PG9945 with ID 101-5348, zone 5 is the built-in reed switch, zone 19 is the aux input.
Z5 CLOSED/Z19 CLOSED -> Z5 OPEN/Z19 CLOSED
Z5 OPEN/Z19 CLOSED -> Z5 OPEN/Z19 OPEN
Z5 OPEN/Z19 OPEN -> Z5 CLOSED/Z19 OPEN - REPORTS TAMPER ON Z19 DUE TO DUPLICATE OPEN MESSAGE
Additional context
No response
The text was updated successfully, but these errors were encountered: