The Sonoff contact sensor is configured to report the battery status every 2 hours.
While closed, I put the contact into a kind of double Faraday cage ( a metal pot inside a metal fridge ). Opened the contact at around 7 am when there was no Zigbee connection.
The contact state didn't change, as expected.
15 minutes later, I removed the sensor from the fridge. The Zigbee connection was restored at some time later, but there were no any messages sent by the device.
When the battery reporting time came at 7:17 am, the contact status was polled by the driver, and the device reported correctly that the contact was open!
Looking at the debug logs, I see now that the true contact state was actually requested and received 36 minutes earlier before the periodic battery report - exactly at the time, when the sensor announced that it is rejoining the Zigbee network (it fell off the mesh when was in the fridge) :
The final version of the driver is not fully ready yet, but as it happens very often - I switched to working on another interesting project ... ... so I am publishing the update now, even if it is semi-baked at the moment.
Please download the Tuya Zigbee Contact Sensor++ driver latest development branch version (1.1.2, 2023/10/20 12:46 PM) from the link in the second post of the driver thread. (this is a direct download link)
Change the driver manually, then from the Preferences section, enable the 'Advanced Options' and hit Save.
Configure the Battery Reporting interval to be 2 hours, for example.
Enable the new "Poll Contact Status" option
Hit Save.
VERY IMPORTANT AND OBLIGATORY - pair the SONOFF sensor again to your HE hub.
Pairing again to the hub is needed because SONOFF battery-powered devices are extremely 'sleepy', so changing the configuration/reporting parameters is best done during the re-pairing process.
Let me know if the driver works with your setup first. A screenshot of the 'State Variables' after open/close tests will be useful. Press the F5 button on the browser to refresh the web page before making a screenshot.
I think I installed the driver. I can only get to the driver preferences after re-pairing and selecting the driver for this device right ?
It is in 'open' status now (tank level was high). I emptied the tank a bit, so at some point it should report 'closed'. If it does that I shall be eternally grateful
Any variation may result in a failure to configure the Sonoff contact sensor properly.
These Sonoff devices are rather difficult to configure, the only time when it works is during the pairing process.
From the State Variables screenshot, it seems like the battery reporting was not configured...
Are you sure you followed all 5 steps without missing any (especially step 5)?
lastRx: battCfg shows the latest battery reporting configuration, as received and confirmed by the device. '-1' means it was not received/confirmed successfully.
stats: rxCtr is the number of the received Zigbee messages from the device. txCtr is the number of the transmitted messages.
stats.rejoins is how many times the device has lost the Zigbee network and has joined it later again.
stats.outOfSync shows how many times the contact open/closed status received by polling differed from the last contact status received ''normally'. Here your count is too high (mine is 0), but there may be a bug in the code - I didn't test this last addition.
Anyway, if it seems to work - leave it this way. Check later the Events page - are there any battery level reports there?
No, I don't think that this extra polling once every 2 hours will significantly decrease the battery life.
HOWEVER - what undoubtedly affects the battery life is the quality of the Zigbee connection to this device, Every time the Zigbee connection is lost, it will try and try to re-connect again. So the best approach again to is strengthen your network by placing a accu-powered Zigbe repeater in between.
I'll try to describe what I did step by step, so you can tell me what I did wrong. Originally my sonoff sensor was using a different driver. Generic zigbee if I recall correctly.
I deleted the device and any place it was in use (dashboards and rules).
I re-paired it, renamed it and then went to the device preferences to select your driver that I had downloaded previously. I selected the advanced settings and set the polling and battery update as you mentioned. I hit the initialise, ping and refresh buttons a couple of times for good measure and that's it, I installed the sensor and it seems to be working.
Should I delete the device once more and re-pair as I read now in step 5 ?
OK, now I understand... Because this device fingerprint is defined in two drivers at the same time, when you delete it and pair it again, it will automatically pick up the driver that was last used. In your case it was the Markus driver.
If you remove it and pair it again now (after the Tuya driver was already assigned), next time it should pick up the Tuya driver when paired as a new device.
But wait, if you see battery reports on the events web page- this means that Markus's driver has also configured the battery reporting correctly (most probably it did), so there is no need to go through the whole procedure again,
Just have in mind, that changing the reporting time interval will require to save the new preference first, then pair it again. The new battery reporting configuration will be successful only after re-pairing the Sonoff sensor. However, if it reports the battery level frequently enough - there is no need to repeat the procedure.
This is my last events page. It seems to be reporting properly. I have high hopes that this will have fixed my problem. I'll keep this page updated. I'll also see about adding a repeater somewhere in between. Thanks a million !
OK, it seems to be working at the moment - let's leave it working this way for now.
There are still some small things to clarify myself and to improve in the driver, but I will come back to this later.
Excuse my ignorance. The open / closed status in the batteryVoltage events is embedded in the batteryVoltage description. How can I access this to set some rule in rule machine ? Been trying for a while now and it seems I'm too dumb to do it
Hubitat automation is entirely event driven. So the open/closed status received with battery status will only generate a new event if the existing status was the opposite of the polled status.
For instance, in this post, you can see there's a closed event generated by polling at 20:01:34.605. My guess is that contact state was open and after polling it changed to closed, therefore generating a new event.
Having said that, I think that it is possible to write a driver that forces the generation of an event - even when there's no change in device status. Although this is discouraged for the additional load it adds on the hub. What are your thoughts on this, @kkossev?
). Opened the contact at around 7 am when there was no Zigbee connection.
