This is a substantial update to my original standalone motion-activated LED controller. This version uses the ESP32, provides options for wired or wireless sensors using either simple motion or distance-based time-of-flight sensors. It also has major improvements to the onboarding and companion web application.
 |
| Click to view YouTube Video |
My original stair lighting system required three ESP8266 controllers, Home Assistant and ESPHome to function. Numerous individuals asked for version that did not require Home Assistant, so I followed up the above video with one that used Arduino code and a couple of hardwired PIR sensors to try to duplicate the Home Assistant-based version. While this version worked, it was pretty basic, wasn't the easiest to setup and configure. And when I later updated the Home Assistant version to use better ToF sensors instead of the ghost-trigger prone PIR sensors, the standalone version was stuck with wired PIR sensors.
This update completely changes that! The standalone version has been completely redesigned and rewritten from the ground up. In some cases, the standalone version now offers more features and options than the Home Assistant version. But the Home Assistant version is still available to build and much of what I cover in this article can be used to build either version.
=============================================================
This document primarily deals with the hardware and provides the physical build instructions for the system. To see the full set of features or to learn more about the firmware or how to use it, please refer to one or both of the following:
=============================================================
Note: While I am showing the use of this system with a staircase, others have used this system to provide LED lighting in a dark hallway, under a bed or in other unique manners. Primarily, the system is a LED display that can be triggered by one or more sensors in a variety of ways. So you don't need stairs to build and use the system!
Home Assistant vs. Standalone Version
As mentioned, the original staircase version required Home Assistant, ESPHome and a lot of manual YAML to create the helpers and automations. The new standalone system eliminates most of those manual steps. Here's a high level comparison of the two systems with the latest updates:
|
|
 Home Assistant
Version
|
 Standalone
Version
|
|
Required Infrastructure
|
WiFi Home Assistant ESPHome WLED
|
WiFi
|
|
Sensors |
|
|
|
Sensor Number |
2 |
1 or 2 |
|
Sensor Comm |
Wireless |
Wired or Wireless |
|
Sensor Type |
PIR or ToF (can mix/match) |
PIR or ToF (can mix/match wireless version) |
|
LEDs |
|
|
|
Type of LED |
Any WLED-compatible1 |
WS2812b1 |
|
Max LEDs |
8002 |
6002 |
|
Controller(s) |
|
|
|
ESP32s Needed |
3 |
1 – 3 |
|
System |
|
|
|
Control Options |
Home Assistant |
Native App
MQTT / API Home Assistant3 |
|
Firmware Updates |
Over-the-air |
Over-the-air |
Notes:
¹When using WLED, any WLED-compatible LEDs can be used. Other LEDs can be used with the standalone version, but a minor firmware modification would be required.
²Appropriate power supply, power injection and wiring required to support higher numbers of LEDs. To use more than 600 LEDs with the standalone version, firmware modifications would be needed.
³The system can be completely configured and controlled via the native app. Use of MQTT, the HTTP API and integration with Home Assistant are entirely optional and not required.
As you can see, the upgraded standalone version is much more on par with the original Home Assistant-based version, and in some cases offers even more options. And since the update now offers optional Home Assistant integration via one-click Discovery (no YAML needed!), you can now also use the standalone version with Home Assistant as well.
In terms of the build, it is nearly identical for both versions. There are some minor differences, which I'll note below, but the primary difference is in the installation and configuration of the firmware. For the most part, the remainder of the article will focus on creation and configuration of the standalone version.
Parts List
As noted, the physical build is nearly identical so the parts for the two different versions are almost the same. I'll break out those parts that are only for a specific version. Not all parts are needed for all builds and you will likely only need a subset of these parts. Your selection of system and sensors will dictate the actual parts needed. What I include here are the parts I show in this article or the related YouTube video. See the discussion following the parts list for more information and to help determine the type of system that works best for your needs.
Base Primary Controller (wired or wireless sensor version)
|
Item or Part |
Notes or Additional Info |
|
Standard
30-pin NodeMCU style |
|
|
Logic Level Shifter (SN74AHCT125N) |
Optional,
but highly recommended |
|
|
|
|
Optional,
but recommended |
|
|
Optional. For mounting level shifter |
|
|
|
|
Sensors (common for either wired or wireless)
|
Item or Part |
Notes or Additional Info |
|
1
or 2 depending upon your build |
|
|
1
or 2 depending upon your build |
|
|
|
|
Wireless Sensors (additional components)
|
Item or Part |
Notes or Additional Info |
|
Can
use standard size ESP32 as well |
|
|
Optional
– skip to create smaller version |
|
|
At
least 1A, higher amps OK. |
|
|
|
|
LEDs (length, number of LEDs/m and form factor can be different)
|
Item or Part |
Notes or Additional Info |
|
Size/density
depend upon your needs |
|
|
Optional
|
|
|
Optional |
|
|
|
|
Power and Other Components (not all will be needed based on your build)
|
Item or Part |
Notes or Additional Info |
|
Based
on number of LEDs – see below. |
|
|
For
power supplies with barrel connector |
|
|
For
larger power supplies (> 15A) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bench Testing (additional parts that may be needed for breadboard testing)
|
Item or Part |
Notes or Additional Info |
|
Or
use multiple ½ size breadboards |
|
|
|
|
|
|
|
|
|
|
|
|
|
Selecting Components for Your Version
The difference between the Home Assistant-based or standalone versions are listed in a comparison chart above. But even after a version is selected, there are still different options for the sensors... and even more variations with the standalone version since it can use wired or wireless sensors. Before determining your final parts list from the above, you need to determine the end use and needed features for your final project
Sensor Selection
The first step is to determine whether PIR (motion) or ToF (time-of-flight distance) sensors make the most sense for your project.
PIR (passive infrared) Sensors
You may already be familiar with the simple PIR sensor.
Since they use a heat signature to detect motion, these sensors are best used in a climate-controlled area. In areas where the ambient temperature approaches body temperature, the range and accuracy of the PIR sensor suffers greatly.
ToF (time-of-flight) Distance Sensors
The VL53L0X is a small, inexpensive distance sensor. Why would we want to use distance instead of motion?
As you can see, the ToF has a shorter overall range, but more importantly, it has a much narrow field-of-view. This allows us to narrow in the range or area where the sensor will trigger the LEDs. In the firmware (or ESPHome node), a distance setting allows even more refinement. This distance is used to have the sensor return an ON/OFF (true/false) signal. In essence, from the main controller's perspective, it is just receiving on/off from the sensor, so the system works exactly the same with both types of sensors.
When and why might you want to restrict the detection range?
Let's say you have a staircase where portions are open on one side, either at the top or bottom of the stairs. Using a PIR sensor, due to its field of view and range, you might have a detection area that looks similar to the following:
Motion will be detected when simply walking near the stairs without actually using them. Ideally, we only want the LEDs to turn on when motion occurs in the yellow shaded area. However, the PIR sensor will detect motion anywhere in the red-indicated areas as well, which will also cause the LEDs to turn on (or off).
But by substituting an ToF sensor, there is a narrower field-of-view to begin with.
And by specifying a distance for the sensor, you eliminate any "motion" detected beyond the stairs. If you want to see how using a ToF sensor eliminates ghost triggers when just walking by the stairs, I show the difference in this video where the original Home Assistant system was upgraded from PIR to ToF sensors.
A ToF sensor can be configured more like a "break beam"... the LEDs trigger only when the beam is "broken". So the end goals of your project will determine the best sensors to use. As a general rule:
Use PIR Sensors When:
- You want to trigger motion over a broad range, such as when someone enters a room.
- The system will be in a temperature-controlled environment. PIR sensors do not work well in places like garages or attics where the ambient temperature could approach body temperature.
Use ToF Sensors When:
- You only want the LEDs to trigger when motion is detected in a smaller, specific area... such as when stepping on the first step of a staircase.
- The ambient temperature may approach body temperature
As covered above, there are a few additional limitations based on which system you are using.
Home Assistant System:
- Only wireless sensors supported (each sensor will need its own ESP32/power)
- It is possible to mix and match wireless sensor types via different ESPHome configurations.
The standalone system offers much more flexibility in the number, type and configuration of the sensors.
| Wired Sensors | Wireless Sensors |
Number of Sensors Permitted1 | 1 or 2 | 1 to 2+ |
Sensor Type Allowed | PIR or ToF | PIR or ToF |
Use Mixed Sensor Types | NO | YES |
User-Defined GPIO Pin | Yes | Yes |
Total ESP32s Needed2 | 1 | 2 – 3 |
Use Alternate Firmware3 | No | Yes |
Response Speed | Fastest | Slightly Slower |
WiFi Required4 | No | YES |
Sensor Power Source | Main | Main or Independent |
Power Source Connection | ESP32 Pins | ESP32 pins or USB |
|
|
|
Additional Notes:
¹When using wireless sensors, you can theoretically use more than two sensors. This is covered under the advanced topic below.
²Wired sensors use the same ESP32 as the main controller. For wireless sensors, a separate ESP32 or other controller is needed for each.
³Wired sensors must use the main controller's Arduino code. Wireless sensors can use the provided Arduino code, ESPHome or any other firmware that can post an HTTP API or MQTT message.
⁴Wireless sensors require WiFi to communicate with the main controller. However, even when wired sensors are used, WiFi is still need to configure and communicate with the system.
So to determine your actual needed parts, you need to first determine the type of system (Home Assistant-based or standalone) and the type of sensors desired. But there are some additional part substitutions that are possible.
Alternate ESP32s
Primary Controller
The system has been designed and testing using a standard 30-pin ESP32 WROOM32 (NodeMCU-style) for the primary controller of either system.
If using the Home Assistant/WLED version, then WLED will be installed on the primary controller. Any ESP32 supported by WLED can be used instead. While WLED technically still supports the ESP8266, the ESP32 is recommended for all new builds.
For the standalone version, any standard ESP32 can be used. The firmware was compiled using the ESP32_Dev board. If you wish to substitute other varieties of the ESP32, such as an ESP32-S3, you will need to recompile the firmware for the new board. More info can be found in the Github documentation.
Sensor Controller(s)
Wired Sensors (standalone version only):
No additional controllers are needed as the sensors are wired directly to the main primary controller. Currently, the only types of sensors supported are the aforementioned PIR and VL53L0X ToF sensor.
Wireless Sensors:
The system was designed and tested with a standard ESP32 WROOM2 Mini. Again any other standard ESP32 that compiles under the ESP32_Dev board should work. If you wish to use something like the Seeed Studio ESP32S3 to make an even smaller sensor, you will need update the underlying firmware to reflect the different ESP32 board. For the standalone controller, more information on this option is provided in the Github repo documentation.
Additional Wireless Sensor Options:
You can theoretically use any type of wireless sensor desired. This is described in a bit more detail under the Advanced Topics section that follows.
LEDs
Home Assistant (WLED) Version:
In the Home Assistant version, the primary controller will be running the popular WLED firmware. This means that you can substitute the WS2812b with any type of LED strip supported by WLED. Since the controllers run off of 5V, 5V LED strips are recommended. If you wish to use 12V or 24V LEDs, then you will need to provide the proper voltage conversion to power the controller.
Standalone Version:
The firmware is specifically designed for WS2812b LED strips. You may use any type, form factor (e.g. pixie, bullet, etc.) or density (30/60/144 LEDs/m) within the WS2812b family. But note that the number of LEDs will directly impact the size of power supply and wiring needed.
It is certainly possible to use other LED types, but this will require at least some modifications to the firmware and you'll need to compile your own version. See the firmware documentation for more info on modifying the default firmware.
Once you have determined the hardware desired for your build, it's time to get started with the actual build.
Mounting:
Most LED strips come with adhesive on the back. But this adhesive isn't the best and the LEDs may come loose over time due to the surface to which they are mounted or just due to the small heat that the LEDs generate.
When installing a linear run on a flat surface, I prefer to mount my LEDs in special aluminum channel made for LED strips.
These include diffusers as well to soften or even out the glow from individual LED pixels. They also include mounting brackets with tiny screws that barely leave a hole in the surface if you later opt to remove the LEDs (without concern about adhesive marring the surface).
I even like to add a little 3M double-sided mounting tape in the channel.
This tape comes in the same width as the LED strip and when the adhesive from the back of the LED strip is adhered to the double-sided tape, there is much less likelihood of the strip ever coming loose. But how you opt to mount your LEDs actually have nothing to do with the build of the system, so you can decide the best mounting process for your particular project.
Breadboard Testing
While technically not necessary, I strongly recommend that you create a bench or breadboard test version before creating the final soldered version. This allows you to test your wiring, the firmware and various components before you create the much more permanent version. Nothing is more frustrating that creating the final system to only discover you have a failed component.
Important: GPIO Pin Selection
The system is configured with default GPIO pins, which is what will be used for all wiring diagrams shown. But you are not required to use these specific pins and can use any desired appropriate GPIO pin for your build. There is only one exception:
GPIO0 (pin "0): While a valid GPIO pin on most ESP32s, within the firmware, this pin has a special meaning. When a GPIO pin is set to "0" in the settings, it means that device is not in use and will be ignored. Do not wire any of your sensors to GPIO0 or that sensor will be unusable!
It is also advisable to avoid use of any strapping pins (those pins used in the boot process). If possible, stick with the default pins shown in the diagrams below. If you need or want to use different pins and are unsure which ones are appropriate, you can refer to the following from Random Nerd Tutorials:
ESP32 Pinout Reference: Which GPIO Pins to Use?
ESP32 Pinout Reference: Which GPIO Pins to Use?
Primary Controller
As mentioned, the base primary controller build is identical for both versions of the system (Home Assistant and Standalone).
 |
| Click to enlarge |
When we move this to the soldered version on an ElectroCookie, we'll use pin header and a socket for the ESP32 and level shifter.
The pin headers not only allow the components to be easily removed to reflash or erase, but in the case of the ESP32, it elevates the board so that wiring connections can be made using the through-holes underneath the board. But female pin headers really weren't designed for breadboard use and the pins are too short to make a reliable connection.
Instead, the best method is to use two breadboards connected together.
The ESP32 is just wide enough to span the joined power rails. This leaves multiple connection points on each side of the ESP32. However you opt to mount your components, it is the physical wiring connections that are most important.
Alternatively, you can also use something like one of these protoboards, which also accommodates the ESP32, but also provides multiple power rails/voltages and has ample space for connecting other components.
While the ESP32 can be powered via the USB port, we want to use a single source to power both the controller and the LEDs. Anything more than a handful of LEDs will draw too much current for the USB port on the ESP32 and exceeding more than an amp or two could cause the breadboard to melt. So we'll split off the 5V from the power supply and run one set of leads to the LEDs and another set to a power rail on the breadboard. This creates a 5V power rail that will use to power the ESP32 via its VIN and GND pins.
On the opposite side, we'll use the ESP32's 3V3 and GND pins to create a 3.3V power rail. This will be used for powering wired sensors. If you plan on using wireless sensors, you can skip creating the 3.3V power rail.
Logic Level Shifter
Always a controversial subject when it comes to LED strips, a logic level shifter is used to shift the 3.3V logic signal from the ESP32 to the 5V logic signal expected by the LEDs. It is true that you can sometimes omit the shifter if the controller is kept close to the start of the LED strip, but longer wiring runs can cause the LEDs to malfunction. If you need or wish to locate the controller more than a foot or so from the start of the LEDs, I highly recommend that you add the shifter. Even if you don't need the shifter, it doesn't hurt to have it. But the opposite is certainly not true. If you need the shifter due to voltage drop for longer wiring runs and you omit it, the LEDs may fade, flicker or otherwise misbehave.
Side Note: If you look closely at the YouTube video, you'll note that I do not have the shifter wired in for the breadboard testing. Since my controller was within about 18" of the LED strip, I didn't initially wire it for testing. But I'd later verify that the shifter worked before moving to the soldered version.
If you do opt to include a shifter, I no longer recommend those cheap bi-directional I2C-compatible shifters. Instead, I recommend using the SN74AHCT125N IC:
Note the orientation notch on the chip as the pins themselves aren't labeled. This shifter is technically a quad-gate buffer IC and can shift up to four different signals. Since we only need to shift a single signal, we'll pull the other three inputs to ground as a precaution and not leave them as floating, although this technically isn't necessary as only the GND pin and a ground connection to 1C are required. Otherwise, we connect 5V and GND as shown. The LED data from the ESP32 GPIO pin is connected to "1A" and the shifted outbound signal to the LEDs are connected to "1Y".
Note that the default GPIO pin for LED data is GPIO4, but this can be changed via firmware settings with WLED or the standalone controller app.
Sensor(s)
How the sensors are built depends upon whether you are opting to use wired or wireless sensors.
When using the Home Assistant-based system, only wireless sensors are supported. Both sensors will use ESPHome and you can use either PIR or ToF, but the ESPHome configuration must be created to use the appropriate sensor type.
Wired Sensors (standalone controller only)
The Home Assistant version only supports wireless sensors, so this section is only applicable to the standalone controller version and only if you've selected to use wired sensors. One sensor is required, but the second one is optional. If you do use two sensors, both must be of the same type.... PIR or ToF.
PIR SENSOR WIRING
 |
| Click to Enlarge |
PIR sensor wiring is very simple. Using the 3.3V power rail created from the 3V3 and GND pins of the ESP32, we'll connect power and ground accordingly. The data line connects to a digital GPIO pin. By default, the system uses GPIO18 for the first sensor and GPIO19 for the second sensor, if included. However, you can use different GPIO pins and just specify those used via the controller's web application.
Important Note: Check the pinout of your particular PIR sensor carefully. Some versions have the (+) and (-) pins reversed from what I show above. Reversing the polarity will likely lead to some magic smoke and a destroyed sensor!
ToF SENSOR WIRING
 |
| Click to enlarge |
Just like the PIR sensors, you may use one or two wired ToF sensors. Also like the PIR sensors, these are powered via the 3.3V power rail. The VL53L0X ToF sensors are I2C devices, meaning they need two GPIO pins each... a data pin (SDA) and clock pin (SCL). The default pins for the first ToF sensor are GPIO21 for SDA and GPIO22 for SCL. The second sensor, if included, uses the default GPIO25 for SDA and GPIO24 for SCL. You can use different GPIO pins if desired and specify the pins used via the web application. Just assure you don't reverse SDA and SCL or the sensors will not work.
Wireless Sensors (both controller types)
Each wireless sensor is a self-contained device, with its own ESP32 and a 5V power source. Separate leads can be run from the controller's power source if desired, or you can use a separate power supply, including using the ESP32's USB port as the power connection.
 |
| Wireless PIR Sensor - Click to enlarge |
 |
| ToF Wireless Sensor - Click to enlarge |
Whether creating wireless PIR or ToF sensors, the wiring is nearly identical. 3.3V is provided to the sensor from the 3V3 pin of the ESP32. Since the sensor draws very low current, you can power the ESP32 via the USB port or by the 5V pin, but not both at the same time! Only provide power via one method or the other.
Since the ESP32 Mini only has one ground pin, connect it to the (-) rail on the 5V side and just run a jumper to the (-) for the 3.3V side. Only connect the ground or negative rails together. Do NOT connect the (+) rails!
The PIR sensor just uses one digital GPIO pin. GPIO18 is the default, but you can use any appropriate GPIO pin and set it in the web application.
For the ToF sensor, it uses the default I2C pins of GPIO21 (SDA) and GPIO22 (SCL), but again you can use different pins and just specify those in the software.
LED Strip Prep and Installation
The number, type, density and general layout of the LEDs are dependent upon your project. Just note that the standalone controller as a hardcoded limit of 600 LEDs, while the Home Assistant/WLED version has a recommended limit of 800 LEDs per data pin. But this comes with a caveat.
If you plan on running parallel LED strips, such as on both sides of a set of stairs or both sides of a hallway and you always want these strips to stay perfectly in sync, the LED data signal from the controller will be split.
However, the power supply needs to be able to provide adequate power to ALL LEDs. In the above example, the controller would be set to 250 LEDs, but the power supply needs to be sized to adequately handle 500 LEDs.
Because of the potential high current draw of LEDs, the 5V power for the LED strips should not pass through the controller. Instead the 5V power from the supply is run in parallel to the LEDs and controller.
 |
| Click to enlarge |
Again, assure the power supply is capable of handing the total current draw of the LED strip(s) and that you are also using appropriately sized wire. If you need assistance determining the power supply and wire sizes, I recommend you use the online WLED Calculator.
Most commercial LED strips come with a 2.54 3-pin JST connector pre-installed at the start and end of the LED strip, along with an extra male JST connector. You can utilize the pre-installed connector and extra male JST connector to connect the LED strip to the system.
 |
| Click to enlarge |
Of course you can also solder wires directly to the LED strip if desired.
Just be sure to note the directional arrows on the LED strip. Data only flows in one direction, so assure your wiring is connected to the 'incoming' end of the strip.
LED Strip Mounting
Most addressable LED strips have adhesive on the back of the strip. You can use this to just "stick" your LEDs wherever you like... and other than any wiring runs, mounting has no impact on functionality. Personally, for straight long linear runs, I like to use aluminum channel made for LED strips.
These come with diffusers you can use or omit. In addition, they come with mounting brackets that use very small screws... ideal for mounting the channels on the stair stringers while only requiring very tiny holes for the brackets. Of course, if you don't want even the tiny holes, you can attach the aluminum channel with double-sided mounting tape or even something like 3M Command Strips.
But speaking of double-sided tape, I will often lay down a layer between the aluminum channel and the LED strip.
This is more important when mounting the LEDs vertically, as I've found that the adhesive on the back of the LED strips isn't that fantastic and the small amount of heat from the LEDs can cause this to eventually fail and the LED strip will work loose. But when using the double-sided tape in addition to the LED adhesive, I've never had an LED strip come loose. But where and how you mount the LEDs is completely up to you.
Firmware
Once you've determined your parts, assembled a test version, you'll need to install firmware on your controller(s). The firmware used will depend upon the controller and sensor types used.
Home Assistant Version
Main Controller (controller connected to LEDs)
The main controller uses standard WLED for the firmware. Full information on installation and configuration of WLED can be found on the Official WLED website.
Sensors
Each wireless sensor will need ESPHome installed as the firmware. The Home Assistant-based Github repo contains the ESPHome configurations for both PIR and ToF sensors. If you've never created and installed an ESPHome node before, you can find step-by-step instructions in this video:
 |
| Click image to launch video |
Automation and Helpers
The system is configured and put into use via Home Assistant automations and helpers. In essence, automations are need to tell the LEDs to turn on or off (with which color, effect, speed, etc.) when a sensor is triggered. The Github repo contains sample automations and helpers (in YAML) that can get you started. Of course you can also use the UI editors in Home Assistant to create the helpers and automations if desired. See the Home Assistant documentation if you need assistance creating any of these entities.
Standalone Version
The standalone version uses precompiled .bin files that you simply need to flash to the ESP32 controller. The firmware files, along with full instructions on installation, configuration and use of the firmware is covered in the Standalone Version Github Repo, so only a high level overview is provided here.
Main Controller
When using wired sensors, this is the only controller. The firmware is "universal", meaning the same firmware is used regardless of the number and type of sensors used.
Once the universal firmware is installed and onboarded, you then use the integrated app to tell the primary controller the number and type of sensors in use. You can also set the GPIO pins used for each sensor.
Wireless Sensor(s)
Each wireless sensor has its own controller and firmware. Again, the precompiled firmware is available in the Github repo, but the same universal sensor firmware is used regardless of sensor type.
Once installed and onboarded, you'll use the sensor firmware's integrated app to specify the sensor type, GPIO pin(s) used and whether you wish for the wireless sensor to be treated as "Sensor1" or "Sensor2" by the main controller. Again, full details can be found in the Github repo.
Soldered Wiring Diagrams
Once you've designed, built and tested your design on breadboards, you may wish to create more secure and reliable soldered versions. How you opt to create the soldered version(s) are really up to you, just as long as all the electrical connections are correct. I'll provide some sample diagrams of how I opted to move these to soldered versions. If you need or want to use different GPIO pins than those I show here, be sure to review the note on GPIO pin use under the breadboard versions above.
Primary Controller (all versions)
To handle the width of the ESP32 and to avoid using "double-width" ElectroCookies, I opt to install the ESP32 on pin headers:
This allows the through-hole connection points under the ESP32 to be used. I can run wire on the top and solder from the bottom, or run the wire along the bottom and solder from the top.
In the above example, the LED data line is run on the top of the board and underneath the ESP32. But the 5V power lines and GND from the power rail to the ESP32's power pins are run on the underside of the board. Routing of the wiring connections are ultimately up to you as long as the following connections are made:
 |
| Base Controller (all versions) - Click to enlarge |
I opt to use 20 gauge solid core wire for all point-to-point connections on the ElectroCookie and 20 gauge stranded wire for the external connections (5V in and LED data out).
LED and Power Connections (all versions)
 |
| Click to enlarge |
As covered previously, the power for the LEDs are run in parallel because the ESP32 and ElectroCookie boards are not designed for the high current demand of the LED strips.
The above diagram shows the use of two LED strips. If your project only requires one, then simply eliminate the second strip and related wiring. The outbound LED data line from the controller could then be connected directly to the LED strip.
If you are using wireless sensors, then this is all that's needed for the main controller. This base controller is identical whether using the Home Assistant or Standalone version.
Adding Wired Sensors (Standalone version ONLY)
Staring with the base controller, you simply add your PIR or ToF sensors. You can use one sensor or two, but both sensors must be of the same type (PIR or ToF). You cannot mix and match sensor types when using the wired version.
PIR Sensors
 |
| Click to enlarge |
ToF (VL53L0X) Sensors
 |
| Click to enlarge |
If only using one sensor, simply eliminate the second sensor. The remaining sensor will always be considered "Sensor1". The GPIO pins shown are simply the defaults, but you can use other appropriate GPIO pins if desired. The sensor type and GPIO pins used are configured in the integrated app once the controller is onboarded to your WiFi (see the Github wiki).
Wireless Sensors (all versions)
If you opt to use wireless sensors, you must build a controller/sensor for each desired external sensor. I'm using smaller 1/4 size ElectroCookie boards, but that is optional. If you wish to make the smallest sensor possible, then you could just wire the sensor directly to the ESP32's through holes. However, in the case of an ESP32 Mini, there is only one ground pin. So you will need to run two wires from the ground pin... one for main power and one for the sensor.
As shown below, because the sensors draw very low current, you can power the remote controllers via either the USB port on the ESP32 or via its power pins... but not both at the same time! Never provide more than one power source to the ESP32 at the same time.
PIR Version
 |
| Click to enlarge |
ToF (VL53L0X) Version
Remember, for either system, you can mix and match the sensor types. One sensor could a PIR sensor for a broad detection range and the other could use ToF for a more focused trigger range. If using the Home Assistant version, the sensors will use ESPHome for the firmware. For the standalone system, the firmware for the wireless sensors is provided in the Github repo.
Advance Topics
The system is designed to be as flexible as possible for use in various projects. But you may have some unique needs, so the following section covers some slightly more advanced options.
Using Alternate Wireless Sensors (all versions)
While the video and above documentation covers the use of PIR and ToF sensors, you are not restricted to just these. In fact, you can use just about any type of sensor desired. Want to trigger the LEDs based on temperature, light level, sunset, presence, or a door or window switch? That is entirely possible with a few caveats:
Home Assistant Version
Since, by default, the sensors use ESPHome and control is handled via Home Assistant automations, you can use pretty much any type of trigger you like. Your sensor controller just needs to publish a state value that you can use in an automation. This can pretty much be anything you like... a numeric value, an on/off state or pretty much any other entity type that can serve as a trigger.
Standalone Version
For the standalone version, you can substitute any type of controller desired (ESP, Raspberry Pi, others) and any type of firmware (Arduino, ESPHome, Python, etc.). The only requirement of a custom wireless sensor is the ability to post to an HTTP URL or to send an MQTT message:
URL Example: http://controller_ip/api?devicenum=1&state=on
DeviceNum indicates whether the wireless sensor should be considered Sensor1 or Sensor2 by the main controller and the state indicates that the sensor is reporting ON or OFF.
MQTT Example:
Topic: cmnd/your_topic/sensor1state (or sensor2state)
Payload: ON or OFF (or true/false or 0/1)
your_topic is the MQTT topic you define in the main controller setup.
In effect, a custom wireless sensor just needs to report the sensor number and an on/off state to the primary controller over WiFi. Any controller/firmware/method can be used to achieve this as the primary controller is simply expecting an on/off state from the wireless sensor.
Important Note!
While it is certainly possible to use other hardware and sensors, it isn't something that I can maintain different versions of the firmware to support. I'm happy to answer any questions, but I can only officially support the hardware listed under the parts list.
Using More than Two Wireless Sensors (all versions)
It is also technically possible to use more than two wireless sensors. Why might you want to do this? Here is just one theoretical example.
Say you have a room with two entrances. Any time someone enters the room, you want the LEDs to turn on. So we use PIR sensors for the broad detection range. But when that individual sits in one of the available seats, you want the LEDs to turn off. For that, you can use the narrower range ToF sensors.
Home Assistant Version
Since the LEDs are handled via automations, you can define multiple triggers for that automation. So you'd add both PIR sensors as triggers to turn on the LEDs and both ToF sensors as triggers for the automation to turn the LEDs off.
Standalone Version
For the standalone version, each wireless sensor reports as Sensor1 or Sensor2 to the main controller. For this example, both PIR sensors would report as Sensor1 and both ToF sensors would be configured as Sensor2. Then triggering of either PIR sensors could be configured to turn the LEDs on and the triggering of either ToF Sensor could turn the LEDs back off (see toggle info that follows).
Sensor Placement and Toggle Settings
When using the standalone version, each sensor (Sensor1 or Sensor2) can have a toggle setting enabled.
Normally, triggering a sensor always turns the LEDs on. However, when the 'Toggle Off' option is enabled and the sensor is triggered while the LEDs are already on (e.g. triggered 'on' by a different sensor), then the LEDs will be turned off. This can be convenient with something like stairs or a hallway where the first sensor trigger turns the LEDs on, but if the opposite sensor is triggered before the Default On Time expires, the LEDs are immediately turned off. Otherwise (when Toggle is off), the LEDs will always turn on and remain on until the On time expires.
When using more than two sensors, care must be taken both with the sensor placement and the toggle settings or undesirable results may occur. Let's take a look at a slightly different scenario to see an example of this. It's the same scenario as above, but with a slightly different layout.:
For this scenario, say that both sensors have the 'Toggle Off' option enabled. Then let's say someone is just passing through the room. They enter from the top right doorway and the Sensor1 PIR triggers and turns on the LEDs. But in this case, the individual is just passing through the room, but they trigger Sensor2, which prematurely turns the LED off. Then when the individual exits the room, the LEDs are toggled back on. You can attempt to resolve this conflict in a few different ways.
One option is to simply reposition your sensors. Recall that both PIR and ToF sensors only detect what's in front of the sensor. The PIR sensors have an approximate field-of-view angle of 100°, but the ToF sensors only have a FOV of around 25°. In addition, the trigger distance of the ToF sensor can be changed to more narrowly focus the trigger range. So in the above example, simply moving the ToF sensor would avoid inadvertently triggering the LEDs when just walking through the room. Alternatively, I could have also shortened the detection range on the ToF sensor. Now the LEDs turn on when a person enters the room and turn off when they exit. The LEDs would still also turn off if someone opts to sit in one of the provided locations.
You can find more information on setting up the sensors in the firmware documentation guide.
Long Wiring Runs
Wire runs introduce resistance, which in turn results in a voltage drop. Longer wiring runs are also susceptible to electromagnetic interference, which can disrupt data signals.
LED Data Line
One of the best things to do to permit longer data line runs between the controller and the start of the LED strip(s) is to include a logic level shifter. While LED strips expect a 5V signal, they will often work with a signal down to around 3.2V. However, the ESP32 GPIO pins start at 3.3V, so it doesn't take much voltage drop before the data signal becomes an issue. But by boosting the logic level signal to 5V at the controller allows much longer data lines before the voltage drop becomes an issue. A shifter normally allows data line lengths of a few meters before voltage drop becomes an issue. However, if you need an even longer wiring run between the controller and LED strip, you can just a line level booster specifically made for LED strips and controllers. One option is a data line booster offered by QuinLED (also available via Dr. Zzs store):
This also has two different resistor settings, as adding a resistor to the data line can also help with a poor or "dirty" signal in some cases.
Wired PIR Sensor
If you experience problems with the data signal from a wired PIR sensor, there are a number of things to try.
1. Try using twisted pair Cat 5e or Cat 6 Ethernet cable for the power and data lines. Twisted pair wiring is less susceptible to EMI.
Simply use one pair (orange/orange-white in the above example) for the power and ground. Then use a different pair (e.g. green/green-white) for the data line. Note that the orange-white and green-white both need to be connected to ground. This generally isn't an issue on the controller side, where you likely have a power rail with ample ground connections. But in the case of the PIR sensor, there is just one ground pin. You'll need to create a cable or otherwise solder the "white" wire from each pair to the ground pin of the PIR sensor.
2. If you are still having problems, you can try adding a 47kΩ or 100kΩ resistor and a 0.1µF capacitor between the data GPIO pin and ground. These should be added in parallel.
3. If the signal is still unreliable, you may need to either use larger gauge wire (larger wire = less resistance), find a way to shorten the wire length or simply migrate to wireless controllers.. which can be placed anywhere a WiFi signal is available (even in a different room or different floor of your house).
Wired ToF Sensor
If wire length is causing a problem with your ToF sensor, you can first try the same twisted pair method as shown with the PIR sensor. However, in this case, you'd need three pairs... one for power, one for the data (SDA) line and one for the clock (SCL) line. This also means that you'd need to connect three ground lines to the single ground pin on the VL53L0X. A better option may be to use special I2C data line boosters.
These little devices are SparkFun QwiicBus I2C extenders. You wire one near the ESP32 controller, connecting the same 3.3V, GND and I2C clock and data lines. You add a second extender near the sensor, again wiring to the VL53L0x's Vin, GND, SDA and SCL pins. In between the extenders, you use standard Cat 5e or Cat 6 Ethernet cable, plugging the cable into the standard RJ45 ports on the extender board. The manufacturer claims you can receive a reliable signal of up to 100 feet (~30 m) using this method. I have successfully used these devices to get a reliable signal over about 35 feet, but haven't tested up to the full 100 feet. If you need even more distance, there is a midpoint extender as well that claims to allow up to 200 feet between the sensor and controller, but I have not used or tested the midpoint extender.
Side note: At the time this article was written, the price for the midpoint extenders has nearly doubled over the past few months. Originally around $25, they are now selling on Amazon for nearly $50, while the endpoint extenders are still around a reasonable $18. Since these weren't included in the parts list above, here are links to these items on Amazon:
QwiicBus Midpoint Extender (currently WAY overpriced)
Wrap Up
While originally designed to provide motion-activated LED lighting for a staircase, these new versions add substantial flexibility. You could use the system for a long, dark hallway, under a bed or pretty much anywhere you want to have motion or otherwise activated LEDs. The system and sensors selected depends somewhat on your current infrastructure and the needs of your project. In general...
Home Assistant/WLED Version
If you are already a Home Assistant user, are comfortable with creating automations and helpers, then this version may be your best choice. Since the primary LED controller runs the popular WLED software, you will have a much better selection of effects, the ability to use segments, playlists and more.
However, the Home Assistant version cannot use wired sensors and therefore a separate ESP32 and power source is required for the main controller and each sensor used.
Standalone Version
The standalone version only requires WiFi for full functionality. No other system, hubs, online account or subscriptions are needed. It has the most flexibility in sensor use and placement. If using wired sensors, then only one ESP32 and power supply are needed.
Even if you are a Home Assistant user, the standalone version offers optional MQTT and Home Assistant discovery, so even this version can be integrated and used in Home Assistant if desired. This would extend the system and allow it to be used in other automations, scripts and shown on dashboards.
I certainly didn't cover all the feature of the standalone version here. See the Github Wiki, or watch the related video, to see more about the full feature set for this version.
Of course I'm always happy to answer questions and love to hear about users that take my project and find unique or different ways to use it. So be sure to drop me a note in the comments here... or in the Github Discussion area if either apply to you!
And as always... thanks for reading!
Additional Information and Links
Supporting this blog and related YouTube channel
It takes significant time and effort (and often expense) to create these articles and videos. If you'd like to support future content on this blog and the related YouTube channel, or just say thanks for something that helped you out, you can consider buying me a one-off cup of coffee or two at:
No comments:
Post a Comment
To help eliminate spam and to keep all conversations civil, submitted comments are moderated. Therefore your post may not show up immediately. Please be patient as most reviews are completed within a few hours.