Designed by Smart Bee Designs, the tiny Bee Motion Mini combines an ESP32-C3 wireless RISC-V SoC with a PIR sensor for motion detection reporting over WiFi, Bluetooth LE, or Bluetooh Mesh.
The board was designed to be as small as possible to fit into a 3D printed case with a LiPo battery and placed/hidden anywhere you want. Motion detection range is up to 5 meters, and the Bee Motion Mini can connect to services like MQTT, ITTT, or NodeRed to trigger other devices upon motion.
Bee Motion Mini specifications:
- Wireless module – Espressif Systems ESP32-C3-MINI-1 module with ESP32-C3 WiFi and Bluetooth LE 5.0 RISC-V SoC up to 160 MHz, 4 MB embedded flash
- PIR sensor – Passive infrared motion sensor with dome lens, 5-meter range
- I/O- UART Tx/Rx for flashing firmware, 3.3V, and GND
- Misc – BOOT and RESET buttons
- Power Supply
- JST PH.20 connector for LiPo battery
- 3.3V via header
- 3.3V regulator
- Dimensions – Small!
There’s no USB port on the board, and only I/Os are the Tx/Rx pins used to flash the firmware through an external USB to TTL adapter that is not included with the board. That also means you can’t trigger other devices upon motion through GPIOs, and it’s specifically designed as a purely wireless motion sensor. Neither USB and I/Os were included to keep the board as small as possible.
The ESP32-C3 PIR sensor board is not open-source hardware, but I suppose it does not matter that much since the design is pretty straightforward, and you can find an Arduino sketch on Github showing how to poll the PIR sensor. The Bee Motion Mini is listed on Tindie for $18, but is currently out of stock. You can always join the waiting list if you are interested.
Via Hackster.io
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Very curious about the autonomy on LiPo per request ? Because starting a WIFI connection consume a lot of battery.
In my SmartHome I use Fibaro PIR with Node-RED to handle lighting (Philips HUE) in every room according to temperature and ambiant light. I change the battery every 1-2 years !
Similar reaction here. ESP32-based boards are usually not ideal for battery-powered applications, as the gap between the sleep states (where the ESP32 basically can’t do anything but monitor pin changes) and active states (needed for BLE or WiFi but use quite a bit of power) is quite large, and the cost of a wake up can be enormous. And BLE or WiFi without frequent wake-ups can be problematic.
Not sure if any progress was made in the -C2 version in that respect, but the original ones were pretty bad at that game.
Surely you don’t want to have an Arduino sketch looping over a poll of the GPIO pin as in the linked example! That would drain the battery in hours at best.
Also it would be interesting to have details about the regulator used. Many if not most ESP32 boards have regulators that use so much current that deep sleep is useless.
> Many if not most ESP32 boards have regulators that use so much current that deep sleep is useless
Indeed, I’ve been bothered by this as well, to the point of thinking about using an ATTINY85 to drive a P-FET and deliver the juice to the ESP only when needed. In the end that was rendering the project a bit too boring and I gave up.
This TI design has ideas for how to handle the power.
https://www.ti.com/tool/TIDA-00759?HQS=ti-null-null-productcentre-refdes-rd-ElectronicSpecifier-eu
Yes indeed, that’s several orders of magnitude better. Not surprising considering TI has a long experience in extremely low power designs.
Yeah. You’d implement the pull using the ulp core and only wake the main system when you have to. Also, wi-fi isn’t required, and ble would draw about 5-10mAh, which could be basically negligible depending on how active the system is.
I think this could be a viable platform, though using an nrf52840 would be a lot less work.. a bit more expensive, perhaps
The sensor controller (ULP type thing) on the Ti chip draws 8.2 µA/MHz
As a anecdotal counterexample, I have these xiaomi smart devices (thermometer/barometer/scale) that run on a coin cell and work over bluetooth. From my understanding it just does a periodic broadcast and some always-on basestation (ex: your phone) can listen for that and process it. I don’t think there is any intrinsic reason it needs to be a huge battery drain.
Are those ESP32-based? I would be surprised.
Having sensors running for years doing BLE or Zigbee is not too much of a problem if the MCU is adapted for that (like the nRF5 series, the EFR32, and many more). Even advertising every second or so and listening for connection requests (for BLE) can draw very little energy if the MCU can switch stuff on and off quickly and efficiently. In the case of BLE you need to be awake a few ms per cycle, and with chips drawing less than 10 mA sending or receiving, you can have an average current of less than 20 µA **while actually advertising and listening for connection requests**.
This is not quite my experience with the ESP32. To start doing anything wireless (BLE or WiFi) you need to switch the ESP32 to fully active, and that takes quite a bit time and energy (spikes over a hundred mA, average current while awake around 50mA, time to wake up longer than the advertising cycle…). You just can’t do BLE advertising efficiently.
WiFi can be even worse because it’s not designed with that in mind. It may be OK in some applications if the device wakes up rarely and at that point does the whole WiFi association/auth/DHCP/TCP/TLS/HTTP/MQTT cycle, but that severely limits the applications.
TI offers a reference design for a BLE based motion sensor which can run a decade on a coin cell. The Espressif product line is not really optimized for this specific application.
These devices can either do periodic broadcasts or they can wait for an event (like weighing something or temp change) and broadcast then. If my memory serves me the TI design was built to send a packet once every seven minutes on average.
Devices like this work best if there is something nearby with mains power which can cache the periodic broadcast and make it always accessible.
Of course this is likely a fine device if you don’t need extreme battery performance.
In regards of battery life of ESP32 (non-RISV-V variant) when signalling over WiFi: A proper power management and LDO gives quite decent runtime. WiFi connection details can be cached and that speeds up the reconnection tremendously. Real world measurements are at: https://github.com/Torxgewinde/Firebeetle-2-ESP32-E
Impressive results for an ESP32. Didn’t know the Firebeetle-2-ESP32-E was properly optimised for running on battery contrary to so many others.
In my experience on some networks just getting an IP from DHCP takes a good second, so definitely YMMV, but good to see that in at least some situations this is quite feasible.
IMHO, this is a totally useless board without some GPIO pins. As a Halloween prop builder having some GPIO pins would make this a killer board, even if you had to increase its size.
Hi,
Creator of the bee motion mini here. The bee motion mini was always ment to be as small as possible which ment I had to cut features like breaking out GPIO pins. You can use the RX and TX pins as GPIO pins when it’s not being programmed however.
That being said, I do have a larger model called the Bee Motion which is bigger, but has many GPIO pins broken out, USB-C, lipo charging circuit and breadboard friendly.
That model is currently going through it’s last revision (hopefully) testing before I put it up on tindie.
Cheers,
Paul from Smart Bee Designs.