Thank you, that solved the problem 
@chirpy, do you have a command list for these products?
kinda off topic, but using Aqara wall switches...
i have the 2 button wall switch (wired): lumi.switch.b2naus01
and im hoping there is a command to disconnect(disable) the physical buttons from changing the release... aka a child lockout in my case
maybe its not supported... how can i find out (ideally with documentation of commands from manufacturer)
thanks
mitch
Unfortunately, Xiaomi do not document anything. It's all done through reverse engineering. There seem to be only a few switches that allow you to disable the physical relay in the switch and I've no idea if this is one.
1 Like
@chirpy, I thought my previous driver updated the state of the sensor on the hourly check-in. Incase of a "missed" status change the state was corrected after max 1 hour,
Does you driver has that same functionality?
There's nothing in the driver to do that. I've never seen a missed status change for any of these devices.
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
