This is an example of a Very Simplified Project for a Xenon and a cheap ($2) PIR Motion Sensor for Low-Powered Applications, taking advantage of the Gen3 Mesh and EN Pin.
By allowing the Motion Sensor to control the Xenon’s EN Pin directly, no other hardware is required.
The Motion Sensor is the External Watchdog.
There are only (3) connections, Li+, Gnd, and EN
The Xenon will remain in Shutdown while the Motion Sensor watches for movement, with a current of only 66 µA. When the Motion Sensor is activated, it pulls the EN Pin HIGH, causing the Xenon to boot.
My results show the Xenon joining the Mesh Network and Connected to the Particle Cloud in about 4 seconds. The Xenon performs a Publish and enters Deep Sleep, waiting for the Motion Sensor to time-out (max Runtime is adjustable), then is Shutdown as the Motion Sensors pulls the EN Pin LOW.
A full Motion Cycle and Publish consumes on average 0.10 mWh. This is dependent on your POT settings as discussed below. I have mine set for about 22 seconds max Run-Time. But the Xenon enters Deep Sleep after 4-5 seconds (unless the Mesh Connection wasn’t successful) .
To start, you need to adjust the maximum RunTime allowed with the “Delay” POT on the Motion Sensor:
Turn it CC to the limit, then back a hair.
This is your maximum Run-time Setting for the Xenon (again, mine is 22 seconds).
Next, select your Trigger Mode:
I use Single Trigger, but it’s your choice.
Once you flash the firmware, you can adjust the maximum Run-Time (Delay) POT to suit your needs.
The Xenon’s RGB light will turn OFF as it enters Deep Sleep waiting for the Shutdown.
The D7 LED will remain on until the Motion Sensor pulls the EN Pin LOW for the Shutdown.
The only purpose of leaving the D7 LED on is so you can adjust the Runtime (Delay) POT easily while testing. It’s unnecessary otherwise and wastes energy.
Here’s the code :
SYSTEM_THREAD(ENABLED)
// create a softDelay, safer than delay()
inline void softDelay(uint32_t t) {
for (uint32_t ms = millis(); millis() - ms < t; Particle.process());
}
void setup() {
pinMode(D7, OUTPUT);
}
void loop() {
digitalWrite(D7, HIGH);
if (waitFor(Particle.connected, 20000)) { // Will continue once connected, or bail-out after time-limit
Particle.publish("Motion", "Motion Detected", 300, PRIVATE);
softDelay(4000); // A safe delay to allow the Publish to complete
// digitalWrite(D7, LOW);
}
System.sleep(SLEEP_MODE_DEEP);
// You should turn D7 OFF prior to the Deep Sleep after testing, but this shows you when the SHUTDOWN actually occurs.
}
Current Testing Performed with µCurrent Gold, and 4.116V on the Li-Po Connector:
Xenon Shutdown but Motion Sensor “watching” = 66 µA = 6.5 mWh per day.
Each 22-second Motion Event Cycle with Publish = 0.105 mWh per Event
Primary Batteries:
(3xAA) Energizer L91 can likely produce 5,500 mWh at this low demand.
That’s 2 years on (3xAA) batteries for a location with infrequent Motion Events.
OR
50,000 Motion Events & Publishes for a busy location.
OR
1 Year with 70 Events per Day, etc, etc, etc.
Adding a RTC and using Manual Mode could be used to eliminate the Cloud Connection and Publish for frequent Motion Events, if desired.
If you don’t have to use Primary Batteries, use a 0.5 Watt Solar Panel & Li-Po and never look back.
This same Motion Sensor (w/ EN Pin) Concept will work for a Boron, but the RTC becomes almost necessary.
is attractive.