OBJEX-Labs / Smart-DoorWindow-sensor

Open source Smart door/window sensor. ELPMs based with a custom power latch to obtain a deep sleep mode current of (1-100nA).
https://objexlabs.com/
CERN Open Hardware Licence Version 2 - Weakly Reciprocal
76 stars 15 forks source link

Using Tasmota instead of custom firmware... #4

Open belveder79 opened 1 year ago

belveder79 commented 1 year ago

Hi Salvatore, amazing work! I came across your video on Youtube as I was discussing with my colleague about the Ultra-Low-Power module of the ESP32 which the ESP8266 does not have. I recently acquired a few of Tuyas super-low-cost devices, something like this.

https://expo.tuya.com/product/1075075

Because I'm not putting those devices in my home in the "unpatched" version, I used the OpenBeken firmware - which is pretty much like Tasmota - and I discovered a major flaw, namely the time to connect the device in the home network. So while the sensors essentially work the way they should, every time they are activated it took really minutes sometimes to "message" to the home network, which drained the batteries of all 4 sensors within 4 weeks. So I kicked them out...

Since I'd consider myself a power user of Tasmota, I wonder if you can't just offload a large amount of coding effort by simply using a Berry script inside an ESP32 Tasmota build to get the device from deep-sleep to life and back.

I have worked on a smart keybox, which has a physical switch like in the fridge (door open - light on, and vice versa). I teamed that up with a raw ESP32 (a plain version without any peripherals) and found it to work amazingly well for a long period of time.

Now my understanding is that you try to optimize your version based on the electronics used mainly, while I wonder if that might really be the major bottleneck in aiming for the "long-life" battery usage...

Let me know if you are interested to discuss further...

salvatoreraccardi commented 1 year ago

Hi @belveder79, thank you for your comment and your interesting question.

The efficiency of a battery-powered smart device depends mainly on:

  1. Hardware and its energy efficiency optimisation.
  2. The choice of network protocol(WiFi, WiFi6, BLE, Zigbee, Thread...).
  3. The firmware, which is very often not optimised.
  4. The number of times the device is 'woken up'.
  5. The quality of the batteries used.

Of course, I'm talking about all those smart devices that usually stay in deep sleep most of the time waiting to be activated. My idea is therefore to optimise the hardware as much as possible, reducing power consumption due to poor device design. And subsequently, as you also pointed out, develop firmware optimised for the device. Taking particular attention to the data transmission time to the cloud/gateway.

Clearly, if the firmware is faulty and takes minutes to handle the transmission of a very simple piece of data (opening and closing a door), then yes, it is a bottleneck and hardware optimisation will be of little use. Furthermore, some firmware in smart devices transmits data in uncrypted, and this is a huge issue for data security. Data security is more important than energy efficiency.

From my point of view, energy optimisation depends on many factors and is also closely related to the type of device one is designing.

belveder79 commented 1 year ago

Hi @salvatoreraccardi,

I fully agree with your assessment. Could I somehow get one or two of your devices to do some testing myself concerning firmware and such? They look really nice...

salvatoreraccardi commented 12 months ago

Currently I have no other prototypes available, next week I will upload a video on my channel about a very interesting new project for those who want to develop an extreme low power solution. I suggest you stay tuned :)