Battery Lifetime Experiences with Door Sensors running OpenBeken

Hey,

I just wanted to share my experiences with door sensors using OpenBeken, actually those here:

https://de.aliexpress.com/item/10050056013505...1sea%21AT%210%21AB&curPageLogUid=mKl79w79H1ek

I think the chipset is the CBU one... after installing OpenBeken, I found that the sensor drained the battery basically within 4 weeks, for all of the 4 sensors I had deployed - I kicked them out immediately then... more closely looking into the issue of empty batteries, I found that sometimes it took minutes to get into my home WIFI, while the reception of the signal in the places I had the sensors installed is actually not the issue. The "startup time", so to say, was just killing the batteries..

Now I really wonder if the CBU is actually the problem (which I doubt), or if this is more a software-related issue inside the OpenBeken implementation (which would make more sense to me) - or if I am the only one having such issues.

Any comments appreciated!

The battery life of OpenBeken sensors depends strongly on the sensor configuration. In case of non-TuyaMCU devices, you can choose any sleep interval, even the very long one, just to prolong battery life.
If you are suspecting that there is a WiFi connection issue, you can check whether your MAC address ends with 00 00, that indicates that you have deleted your RF calibration partition.
I haven't experienced this issue yet, but it might be worth to double check whether your autoexec.bat contains an emergency sleep mechanism or/and change the emergency sleep mechanism in the driver. Something like: "If there is no wifi connection for 30 seconds, then go back to sleep".
Can you show which script are you currently using on your sensors? Are you using our hardcoded door sensor driver or are you using a custom one written in autoexec.bat script?

If you are using specifically our DoorSensor driver, have you tried adjusting DSTime setting?

Sorry, I did not have time to follow up with that yet, but I plan to do so as soon as I can get some stuff off my table.

In the meantime I disassembled them all, as the battery was essentially empty after 3 days or so on my front door - totally useless. Anyway, I noticed that the sleep interval is essentially not the problem, but there is an issue with connecting to the WIFI, and at least I was finally able to replicate it with devices described here in another topic..

I have a Velop MX4000 System with 2 routers broadcasting the same SSID name on different channels in different rooms. Working with a single SSID from my mac, mobile phone or cheapo router works fine, but as soon as there are more than one SSID with the same name it gets completely messed up and takes ages to connect. This is also somewhat related to this report and especially this one. The problem happens somewhat systematically. Deploying a sensor at the edge of the cloud it works kind of ok, as there is a super-strong SSID like 90% and a very-weak one with the same name like 5%. But as you move more into a 70/20 range, it starts making problems and tends to take a long time. It does not seem to be a CB3S issue only, as I noticed a similar behavior with smoke detectors with a CBU having the same issue, and the TW3S as well...

While one of the other authors argues about it working with Tasmota (or not knowing why it works or not), I followed a similar discussion on the Tasmota forum, as I indeed also had exactly the same problem with Tasmota. I had an ESP32 camera working totally fine in my office, but not working at all in my garage. From the two nodes of the mesh, the signal strength was like 80/20 and 20/80 for both locations. Setting it up in my office did make it work in my office (first time connecting to the nw with id 1) but failed in the garage. Setting it up in my garage (first time connecting to id 2) made it work for the garage, but almost unusable in my office. However, that is the standard case - you don't move your device unconfigured out of your work place to configure it at the place of installation.

Anyway, I don't recall the thread, but I know that SetOption56 and SetOption57 were the solution to the problem, which I later also fixed with 20 more devices from gas leak detectors to power plugs - it is like day and night experience after doing that. Without looking into the code, those functions seem to store the network id to select the network to connect to, rather than the SSID name (something in the ESP library stack) and since the ESPs are also usually static and don't move, you can do that once and don't necessarily need SetOption57 (unless you expect to have one of your mesh nodes to become unavailable from time to time, e.g. if you decide to turn them off intentionally).

Anyway, can something like that be implemented on the OpenBeken side or is already done so without me noticing it? Aside of making individual stuff from Tuya work, I guess this would be a huge profit for the project overall, as this problem will not go away and seems not to be linked to particular router vendors but, to be more a general issue. For the Fritzbox case in one of the threads, I argue that either the channels were now assigned differently and therefore it works, and if it changes again, it will not work any more...