It rarely happens to me, but the reason for the question was because the problem occurred today on a contact sensor....
Thinking about it, there's actually nothing the driver can do as it is not possible to interrogate these devices. The driver has to wait until the device itself actually sends the data.
1 Like
Yes, that was what I mentioned above, at the hourly check-in of the device. If the status info comes on the hourly check in moment, why not overwrite? If a status was missed, the problem is solved at the next check-in moment...
What I’ve written below may not be relevant to Hubitat, but it is what I’ve observed with Aqara contact sensors reporting under zigbee2mqtt.
There is no hourly check-in. Check-in can occur even 3-5 hours later. And contact status is not always reported. Sometimes temperature or battery are the only things reported by the Aqara contact sensor.
2 Likes
Don't know if this is a driver issue, The sensor is an Xiaomi contact sensor.
The true state of the device is closed
In de logs I see the device was closed
In the events of the device the last event was open, the closed state I see in the log is missing
The device state in Hubitat is open
Does anyone have a theory on this?
Interesting. FWIW, the data that z2m provides for the “hourly” checkin doesn’t always include contact status.
1 Like
If you look at the timings, the sensor goes closed and then open 5ms later.
I have seen this before. For me it was all to do with the positioning of the magnet. I had to move it till I found a position where it didn't happen.
There is also an app floating around that stops this.
I'll try and find it although it didn't work for me.
EDIT: Here it is.
definition(
name: "Debounce contact",
namespace: "hubitat",
author: "Bruce Ravenel",
description: "Debounce double reporting contact sensor",
category: "Convenience",
iconUrl: "",
iconX2Url: "")
preferences {
page(name: "mainPage")
}
def mainPage() {
dynamicPage(name: "mainPage", title: " ", install: true, uninstall: true) {
section {
input "thisName", "text", title: "Name this debouncer; debounced contact device will have this name", submitOnChange: true
if(thisName) app.updateLabel("$thisName") else app.updateSetting("thisName", "Debounce contact")
input "contact", "capability.contactSensor", title: "Select Contact Sensor", submitOnChange: true, required: true
input "delayTime", "number", title: "Enter number of milliseconds to delay for debounce", submitOnChange: true, defaultValue: 1000
}
}
}
def installed() {
initialize()
}
def updated() {
unsubscribe()
unschedule()
initialize()
}
def initialize() {
def debounceDev = getChildDevice("debounceSwitch_${app.id}")
if(!debounceDev) debounceDev = addChildDevice("hubitat", "Virtual Contact Sensor", "debounceSwitch_${app.id}", null, [label: thisName, name: thisName])
subscribe(contact, "contact", handler)
}
def handler(evt) {
runInMillis(delayTime, debounced, [data: [o: evt.value]])
log.info "Contact $evt.device $evt.value, start delay of $delayTime milliseconds"
}
def debounced(data) {
log.info "Debounced contact $data.o"
def debounceDev = getChildDevice("debounceSwitch_${app.id}")
if(data.o == "open") debounceDev.open() else debounceDev.close()
}
1 Like
Hmm, I should expect it is the last known status I see in the log's, strange
This is an issue that some of us have run into previously. And reported to @markus. But in any case, those drivers aren't being maintained anymore ..... and I don't think it should happen with @chirpy's driver.
I am using chirpy's driver....
I've had that before on a contact sensor. I also wonder about the reliability of some of the reed switches on the devices. As they're relatively cheap now, when I've started having issues on contact sensors I try moving the magnet. If that doesn't work, it gets replaced and the old one repurposed as a transmitter for a dry contact switch with the reed switch removed.
I can look at getting the settings from the periodic update, but as has been mentioned, if the contact reed switch is having issues or it's suffering from magnetic bounce, it's it might be time to reposition or replace it.
1 Like
Trying out these drivers on one of everything as they were recommended over the unsupported ones.
The one device type that stopped reporting after the udates was * Xiaomi Aqara Water Leak Sensor : SJCGQ11LM [*].
Something to kick it in the pants? It's in the supported list.
EDIT: I re-paired the device so we'll see if it just didn't like the change.
This sensor is working fine for me
I’m finding that the leak sensor is dropping off. I’ve repaired it a few times. Have just tried it again now. Once paired, if I press the top of the leak sensor I can see battery information appear in the logs - but this info isn’t appearing on the “events” tab of the device. Odd. @chirpy ?
dev:11212021-03-03 08:02:37.991 infoLeak sensor 1 voltage changed to 3.01 volts
dev:11212021-03-03 08:02:37.990 infoLeak sensor 1 battery changed to 100%
dev:11212021-03-03 08:02:37.985 debugProcessing Xiaomi data (cluster:0000, attrId:0005, encoding:42)
dev:11212021-03-03 08:02:37.980 debugIncoming data from device : read attr - raw: 71900100007C050042156C756D692E73656E736F725F776C65616B2E61713101FF42220121BD0B0328120421A8010521590006240000000000082104020A2171B0641000, dni: 7190, endpoint: 01, cluster: 0000, size: 7C, attrId: 0005, encoding: 42, command: 0A, value: 156C756D692E73656E736F725F776C65616B2E61713101FF42220121BD0B0328120421A8010521590006240000000000082104020A2171B0641000
dev:11212021-03-03 08:01:53.902 debugIncoming data from device : catchall: 0104 0001 01 01 0040 00 7190 00 00 0000 0B 01 0682
dev:11212021-03-03 08:01:50.182 debugIncoming data from device : catchall: 0000 8021 00 00 0040 00 7190 00 00 0000 00 00 1000
The events should only update if there is a change in the state of the event (this is the HE preferred way). The fact you are seeing it in the logs does mean it is working as expected 
1 Like
I was going to say, if you re-pair the device (but do not remove the device from HE) and once done, hit Configure on the device page, that usually sorts these devices out.
1 Like
I added an Aqara door and window sensor (MCCGQ11LM). When I add that switch to the HE alexa skill, the alexa app shows that as a temp sensor, and not a open/close sensor.
Known issue? Workaround?
(the sensor works fine in hubitat FWIW)
That's a side-effect of using a combined driver, unfortunately. The simplest workaround might be to create a Virtual contact sensor and use that on alexa and then map the physical device to the virtual device using Rule Machine.
1 Like
