A New Parking Assistant using ESP8266 and WS2812b LEDs

 

Need a higher tech, but inexpensive solution DIY solution to assist with parking in a consistent location?  This project uses a low-cost ESP8266 and a strip of WS2812b LED pixels to replace that old tennis ball on a string you have hanging from the ceiling now!  And if you have Home Assistant or another automation system, you can optionally enable MQTT to use the system as a vehicle presence system.

An overview of the project can be seen in this YouTube video.

Background Info and Prior Version

Way back in 2019, one of the first DIY projects I did was to create an LED parking assistant for my wife.  Her side of the garage isn't very deep and there is little room at the front and back of the car when parked in the proper position.

This original system used a Raspberry Pi and a rather costly (~$70) LED matrix panel.  It involved a lot of wiring, two power supplies and some tricky Python setup.  But it has worked well and is still in operation today.  And while this was originally build prior to the time I was using MQTT with Home Assistant, I'd eventually go back and add MQTT.  But the system was not easy to setup and configure.  Changing settings or options required editing the Python code.  If you are interested in this older version, you can watch a YouTube video or read the related blog article.

But with what I've learned since about ESP controllers and LED strips, and the fact that at the time of this article, Raspberry Pis are extremely hard to come by... and very expensive if you do, I decided to see if I could create a lower-cost, easier-to-build (and use), version.  The remainder of this article covers the build, configuration and use of this new system.

The New System

The new system uses LED pixels and different end-user configurable colors to create a 'countdown' to the proper parked position.  It will flash if the car is pulled too far forward, indicating the driver should backup.  Multiple 'countdown' effects can be selected and all distances for different "approach zones", from a minimum of 12 inches up to 16 feet can be entered via a simple web interface.  More on this below.

If you prefer to watch instead of read, you can see a YouTube video of the system, but this article will contain additional information, such as parts lists, wiring diagrams, etc.  So, you may want to watch the video for an overview and then return to this article for more specific build details.

Parts List

As usual, I like to start with the parts list required for the project.  Note that if you've done other LED projects in the past, you may already have a number of these parts.  In fact, I built the entire system from spare parts I already had and didn't need to purchase a single item... but your mileage may vary!  Some items may be optional or substituted (others cannot), and I'll try to note that in the list or the build information that follows.  These are the actual parts I used.

QTY	Item	Notes
1	Wemo D1 Mini / ESP8266	4MB (microUSB) version required
1	Logic Level Shifter
1	TFMini-s Lidar Sensor
1	WS2812B LEDs (1M strip)	Recommend 24-40 LEDs @ 60 pixels/m
1	ElectroCookie Protoboard
1	5V 3A Power Supply	> 40 LEDs will require bigger supply
1	LED aluminum channel	Length will depend on number of LEDs
2	Barrel Connectors	Other connector types may be used
2	JST Connectors
	Dupont Connector Kit
	3M mounting tape
	¼” Wire braid sleeve	Optional – for a neater installation
	Controller Enclosure (example)	See Github for my 3D printer version
	Various wire (20-24 gauge)

Some of these links may be Amazon affiliate links.  Use of these links will not affect your pricing, but this blog may earn a small commission if you make a purchase.  Use of these Amazon links is one the best ways to show your support for the blog and related YouTube channel... at absolutely no cost to you!

The system has been tested with a Wemos D1 Mini, and although any ESP8266 dev board (like a NodeMCU) should work, there are currently some incompatibilities with certain other ESP8266 boards.  A D1 Mini (v3) is highly recommended at this point.  

The current firmware version is not compatible with the newer D1 Mini v4 boards with USB-C due to issues with the UART/serial bus.  

Whatever board is used, it must have at least 4MB of flash.  The older versions that only have 1MB or 2MB will not be able to accommodate the firmware.  

Unfortunately, many of these parts only come in packs and not individually.  That means if you have to buy parts, you'll likely have to purchase more than you need for this project.  But the good news is that you'll have plenty left over parts for future LED projects!

Obviously, you also will need standard DIY electronics tools and supplies, such as solder, soldering iron, heat shrink tubing, etc.

Can I use a cheaper distance sensor?

If you've glanced at the parts list above, you probably noticed that the TFMini-s LIDAR sensor is easily the most expensive part, currently going for around $40. So, before beginning the project, I decided to test the TFMini-s against a couple of lower cost options to see if the additional cost was really necessary.  I opted to compare the TFMini-s against two other distance sensors I has used on other projects, the ~$3 HC-SR04 ultrasonic sensor and the ~$6 VL53L0X time-of-flight sensor.

To test these sensors, I connected all three to a single ESP32 with some simple Arduino code that would take a measurement from all three sensors once per second for 3 minutes.  I actually set this up in my garage and use my car to test accuracy, range and more importantly the precision or stability (noise level) of each signal at 1, 5, 10 and 15 feet.  If you don't care about the test results and just want to take my word for it that (spoiler alert!) the TFMini-s is the best sensor for this project, feel free to just skip over the rest of this section!  

But before I get to the actual test results, let's look at a few key specifications for each sensor.

HC-SR04 Utrasonic Sensor

• Working Voltage: DC 5V
• Working Current: 15mA
• Max Range: 4m (~13.1 feet)
• Min Range: 2cm (~0.78 inches)
• Measuring Angle: 15 degree
• Interface: Pulse/Echo (two GPIO pins)
• Approx Cost: $3

VL53L0X ToF Sensor (v2 breakout board)

• Working Voltage: DC 2.6 - 5.5V
• Working Current: 40mA (peak)
• Max Range: 1.2m* (~3.9 feet)
• Min Range: 50mm* (~2 inches)
• Measuring Angle: 25 degree
• Interface: I2C (two GPIO pins)
• Approx Cost: $6

TFMini-s LIDAR Sensor

• Working Voltage: DC 5V
• Working Current: 140mA (avg.)
• Max Range: 6m* (19.7 feet)* 
• Min Range:  30cm* (11.8 inches)* 
• Measuring Angle: 2 degree
• Interface: UART or I2C (two GPIO pins)
• Approx Cost: $40

*Both the VL53L0X and TFMini have programmable settings to adjust range and accuracy.  For example, the TFMini-s reports a true range of up to 12m, but at a substantial reduced accuracy beyond 6m.  For the purposes of this test, all devices will be used at default, out-of-box settings, which are listed above.

Test Results

A few notes about the testing itself.  First, accuracy is somewhat relative here.  Both because it was impossible to get the actual 'sensor' precisely aligned on the breadboard.  In addition, due to the curvature of the front bumper of the car there is some slight differences in distance from the sensors to the actual car.  What I'm really looking for here, though, is the range and "stability" of the measurements... in other words, does the signal bounce around or does it remain steady at various distances.  All measurements were taken in millimeters.

 1 Foot

At one foot, all three sensors reported 'in-range' readings.

Click chart for larger view

Sensor	Min mm	Max mm	Avg mm (inches)	Variance (inches)
HR-SC04	308	312	309 (12.2”)	4 mm (0.2”)
VL53L0X	323	332	327 (12.9”)	9 mm (0.4”)
TFMini-s	300	300	300 (11.8”)	0 mm (0.0”)

All three sensors performed OK at this distance, although the VL53L0X had the most 'bounce' varying by close to a 1/2", while the TFMini-s showed a solid, consistent signal throughout the entire test.

5-feet

Five feet was already beyond the maximum range of the VL53L0X.

Click chart for larger view

Sensor	Min mm	Max mm	Avg mm (feet)	Variance (inches)
HR-SC04	1537	1568	1549 (5’1”)	31 mm (1.2”)
VL53L0X	--	--	--	--
TFMini-s	1510	1520	1519 (4’10”)	10 mm (0.4”)

The HR-SC04 is a little bit noisier at this distance, but the total variance between the minimum and maximum reading was still only around 1.2".  The TFMini-s did have a slight bit of noise as well, but it only had a max variance of 0.4".  Both are still contenders at this point.

10-feet

Click chart for larger view

Sensor	Min mm	Max mm	Avg mm (feet)	Variance (inches)
HR-SC04	2995	3035	3015 (9’11”)	40 mm (1.6”)
VL53L0X	--	--	--	--
TFMini-s	3040	3050	3049 (10’1”)	10 mm (0.4”)

The results are about the same at 10 feet.  There is a slight increase in the variance for the HR-SC04, while the TFMini-s variance remained the same.  Interestingly, the TFMini-s reported a slightly higher distance at this range, while it has been slightly lower at the shorter distances.  But this could be due to the fact that the angle of the car is slightly different.  And the true distance using the tape measure is just an approximation anyway.  At this point, both sensors have acceptable accuracy.

15-feet

15 feet puts the car just inside the entrance to the garage and where I'd want the parking system to "activate" and wake up.  Unfortunately, 15 feet is also beyond the range of the HR-SC04, so I can only show the results for the TFMini-s.

Click chart for larger view

Sensor	Min mm	Max mm	Avg mm (feet)	Variance (inches)
HR-SC04	---	---	---	---
VL53L0X	--	--	--	--
TFMini-s	4640	4670	4650 (15’3”)	30 mm (1.2”)

The TFMini-s is showing just a little bit more noise at this distance, but the variance is still only about the same variance the HR-SC04 showed at only 5 feet.

Testing Conclusions

Due to both the longer range and the steadier signal, especially at the shortest range (where the parked distance is most critical, especially in my case where there is very little room for variance), I decided that the TFMini-s was worth the extra cost for this project.

The HR-SC04 might work if you have a little more leeway in the final parked position for your car and don't mind the system not waking and providing feedback until you are only 10-12' from the final parked position.  However, the code I am providing is designed for the TFMini-s.  If you want to use a different sensor like the HC-SR04, you will have to modify the code yourself to remove the TFMini and add the appropriate library for the HC-SR04.

LED Strips and Number of Pixels

There is one final consideration before getting into the actual build of the controller board and that is the size of the LED strip and the number of pixels.  A longer display with more pixels means greater "sensitivity" (shorter distance change related to pixels lit) but also means a bigger power supply with higher current requirements.  If the current requirements get too high (over about 2 amps), then a separate power run and more wiring will be needed (more on this below). There is also the consideration of number of pixels per meter.  WS2812b pixels strips come in a variety of 'densities', such as 30 pixels per meter, 60/m, 100/m, 144/m, etc.  Using the higher densities, such as 100/m or 144/m would permit more pixels in a shorter length, but it could result in a hard time for the driver to differentiate the various pixels, especially if a diffuser is used (recommended).

On the flip side, if you have the space for a lengthier display, you could use 30 pixels per meter, which gives greater separation between pixels.

Regardless of the density of pixels selected, I recommend a total number of pixels somewhere between 24 and 40.  Anything less than 24 and there will be too little 'resolution' or 'sensitivity' especially when using effects where the distance is shown by moving from the outside edges to the center or from the center to the outside (effectively cutting the number of pixels in half from a sensitivity standpoint).  Anything greater than about 40 will require a separate power run from the power supply directly to the LED strip and not through the controller board.

While technically not required, the effects will work better if you have an even instead of an odd number of pixels.  For example, choose 30 or 32 instead of 31 pixels if possible.

For my build, I opted for 36 pixels at 60 pixels/m.  This gives me a display length of about 2 feet, which will fit nicely in the planned installation location yet provide adequate resolution and sensitivity.

The code, as provided, has a hard limit of 100 pixels maximum.  This is due to limitations of the ESP8266.

Building the Controller

If you've seen any of my other LED-related videos, this controller is very similar to the ones that I use for WLED.  But I'll cover the basics, along with some of the key differences between this controller and the WLED version.  

Click image for larger view

The above diagram shows the final wiring for the completed project, but first I'll focus on the controller board itself.  I usually test everything on a breadboard first, and I recommend you do the same, before creating the permanent soldered version.

Testing components and connections on a breadboard

But since the ElectroCookie prototype board is basically laid out just like a standard breadboard, the connections are the same for both versions (the only exception is the power for the LEDs, but I'll cover that in a bit.

First, connect the ground rails on both sides of the board together.  On the ElectroCookie board, there is a small gap that can be jumpered with wire or a solder bridge (circled in orange in the wiring diagram).  We need a ground connection on both side.

Do not connect the positive rails... just the ground!  We will be running 5V on one side (bottom in diagram) and 3.3V on the other for the positive rail, so assure you are only joining the negative or ground rails.

You can make connections and solder on the components in any particular order that works best for you and your soldering skills, but I'll present them here in the order I used.  I'll also reference the row letters and column numbers from the ElectroCookie board in the above diagram.

I like to make all my 'on board' wiring connections first (those that just connect one point on the ElectroCookie board to another).  I generally use 18 gauge solid core wire for these connections:

1. Connect A2 the the positive (+) power rail on the lower side of the board.  This will eventually be the same column (2) where the 5V pin of the D1 mini is mounted. When connecting to the power rail, use the 3rd or 4th hole from the end, as we will need the first couple of power rail holes for the external 5V connection and for a wiring bridge on the back side (more on this in a minute).

2. Connect A3 to the ground (-) negative power rail on the same side.

3. Connect J2 to the positive(+) power rail on the upper side.  This will provide 3.3V to the power rail from the 3V3 pin of the D1 Mini.

4. Add a positive and negative connection from each power rail to power the LV and HV side of the logic level shifter.  I used B21 and J21 for the ground connections and A22 and I22 for the (+) connections.

5. The next onboard connection will connect pin D6 of the D1 Mini to the LV4 pin of the logic level shifter.  I connected J5 to H19 for this step.

A side note on the logic level shifter.  Many people claim that a logic level shifter isn't needed.  And in some cases, if the distance between the controller and the start of the LED strip is kept very short, it may be possible to get away without it.  But because the D1 Mini outputs a 3.3V signal and the LED strip expects 5V, voltage drop due to longer wiring runs may cause the LEDs to flicker, show incorrect colors or effects, or simply not work at all.  Depending on how you mount your components, there may be a wiring run of a couple of feet between the controller and LEDs.  For this reason, I highly recommend you use the logic level shifter to avoid any potential signal problems to the LEDs.

6. There's one final onboard connection to make, and this is done on the underneath side of the board.

Click image for larger view

Normally, you would not run the power for your LEDs through the controller board.  The small traces are not rated to handle the high current that LEDs can draw.  But in this case, since I'm only using 36 pixels and don't plan on using full bright white for the LEDs when parking, the LEDs should only draw about 1A max for other colors and effects.  But even then, the traces on the ElectroCookie board are pretty thin.  To help, a wire bridge connection is added.  I ran 20 gauge solid wire from the second hole on one end of the 5V rail to near the opposite end (for both positive and ground).  The board has been flipped horizontally in the above picture as related to the original wiring diagram.  The external 5 VDC connection from the power supply will eventually be connected to the first column holes on the right and the LED power will be connected right next to the bridge wires on the left.  Just assure you are making this bridge on the 5V rail side of the board and not the 3.3V side.

Alternate power connection for larger number of LEDs

If you are using more than about 40 LEDs or plan on running full bright white for any extended period of time with more than around 20 LEDs, then I recommend you split off the main 5V power from the power supply and run lines directly to the LEDs.

Click image for larger view

While you can run wiring directly from the power supply to the LEDs, if you want to keep the wiring neater and still use a single run from the controller to the LEDs, you can just split off a 5V and GND connection from the power that is running to the controller and simply pass this line straight through underneath the ElectroCookie board (not connecting to anything).  On the out side, you can then pick up the data signal line and run power and data from the controller to the LED strip.  Note that you can also do this even with lower number of LEDs as an extra precaution if desired.

At this point, you can go ahead and solder the D1 Mini and logic level shifter onto the board or you can first install the firmware, then solder the components.  Regardless if you do it before or after loading the firmware, just assure that the pins on both the D1 Mini and logic level shifter are lined up properly with the wiring you installed.  In my diagram, the D1 Mini 5V and 3V3 pins are soldered into column 2 and the logic level shifter is soldered between columns 19 and 24.

Loading the Firmware

Step by step instructions for loading the firmware are covered in the Github wiki, which is also where you will find the firmware.   And since I'm lazy and don't want to create the instructions twice, please go to: 

https://github.com/Resinchem/ESP-Parking-Assistant/wiki

Note that you only have to complete this step the first time the firmware is installed.  Any future updates can be uploaded over the air via WiFi using the web interface.

However, note that the board will not boot and you will not be able to onboard the controller to your WiFi until the TFMini has been connected.  So, after you install the firmware, return back here to complete the build process.

If you didn't mount the D1 Mini and logic level shifter before installing the firmware, go ahead and complete that step now per the above instructions.

Preparing the LEDs

I've covered using using WS182b RGB LED strips in a lot of my other videos, but if you've never worked with them before, you might want to take a peek at the following before proceeding:

YouTube: Using WS2812b RGB Light Strips

Blog Article: RGB LED Strips - A Beginner's Guide

First, cut your LED strip to the desired number of pixels.  As mentioned above, and while it is not a requirement, the parking effects work best of you use an even number of pixels (e.g. use 24 or 26 instead of 25).

Solder leads onto the DATA IN end of the strip (indicated by the arrow on the LED strip).

The length of these leads will be dependent upon your installation and where you mount the controller in relation to the LED strip.

I do like to place all of my LED installs in aluminum channel, specifically made for LED strips.  Unfortunately the aluminum channel and diffusers (like many other parts) cannot be purchased in individual quantities.  The smallest "pack" is either 6 or 10 pieces of 1M (3.3 ft) length.  So, if you don't already have some of this channel on hand, you'll have to spring for the pack.  Now, you could do away with the aluminum channel and attach the LED strip directly to the wall, using either the LED strip adhesive backing (will likely fail over time) or double-sided tape.  But the LED lights themselves can be very intense, especially when looking at them straight on, so I do recommend some sort of diffuser so that the driver isn't blinded when trying to park... especially in a darker garage!

If you are using aluminum channel, cut it and the diffuser to length.  I like to put down some double-sided 3M foam mounting tape to assure my LEDs don't come loose over time... especially in the garage where the temperatures can swing pretty high and low in the summer and winter.

Remove the protective tape from both the 3M tape and the back of the LED strip and carefully install the LEDs in the aluminum channel.  The 3M protective tape can be a little difficult to get started.  I found a pair of sharp point tweezers can help get underneath the backing and get it started.

Once you have the LEDs installed, solder on a JST connector to the end of the leads.  You can use a male or female connector... just be sure you use the opposite on the lead coming from the controller.  I generally standardize on using a female connector for the 'data in' end of an LED strip, but because the male end was just a bit too large to fit through the opening of my 3D printed enclosure, I swapped them for this project.

I placed a little 1/4" braided sleeve and heat shrink tubing over the leads just to make everything look a little neater, but this is totally optional.  However, do be sure to use heat shrink tubing, electrical tape or some other insulator over each of your wire connections to be sure that the bare wires or solder joints do not come into contact with each other.

I also added a dab of hot glue to the solder joints at the LED strip.  This is just to help reinforce the connection and avoid tearing the copper pads off the LED strip when bending or twisting the lead wires during installation.

Connecting the TFMini, LEDs and power supply

The actual connections to the controller board are covered in the wiring diagram above, so I won't go over those again.  However, I like everything on my projects to be 'swappable' in case a component needs to be replaced or upgraded, so all the external components will have connectors to connect to the leads from the controller.

TFMini-s Connectors

The TFMini comes with a couple of connectors in the package.  I opted to take the one shown in the photo above and cut off one end.  THESE TWO ENDS ARE NOT THE SAME!  Only one end fits into the TFMini's port and has wiring colors in the order of black, red, white and green.  The other end, the one to remove, will not fit in the TFMini and has a different wiring order.

On the cutoff end of the TFMini connector, I added my own female 4-pin Dupont connection.  A 4-pin male version was created that contain the leads that will lead back and be soldered to the controller board (per the wiring diagram).  Once again, the length of these leads will depend upon the distance between the controller and TFMini for your particular install. Once again, I would come back and add some braided sleeve to make things a bit neater.

LED Connectors

A JST connector was added to the LED strip in the above step.  Now we just need the opposite type of JST connector added to the leads that will be soldered to the controller.

Again, the length of the leads will be dependent on your particular install and the use of the braided sleeve is optional.  Leave a little exposed wire for soldering to the controller board (like in the picture for the TFMini lead connection above).  Also just be sure to use a female JST connector on the leads if you used a male connector on the LED strip, or vice versa.

Power Supply Connectors

I simply removed the existing connector from the 5V power supply and added standard male barrel connector.  The lead to the controller is a female barrel connector.  Assure you are observing the correct polarity when connecting the barrel connector to the power supply!  If the positive and negative leads aren't clearly labeled on the wiring, you should check the polarity with a multimeter or voltmeter (I'd recommend doing this even if the wiring is labeled!).  When positive is connected to the positive lead of your meter, the measurement should show a +5V.  If you get a negative voltage reading, the polarity is reversed.  If you end up with reversed polarity, very bad things will likely happen to your controller when you plug it in for the first time!

Final Connections

Now that all the connectors are created, you need to solder the ends of each connector to the controller board, again following the wiring diagram shown above.  You can make these connections from the top side of the board (soldering underneath) or from the underneath side of the board (soldering on top).  This will be somewhat dependent upon your particular enclosure.  I made all my lead connections from the underside of the board, soldering on top.

This is how my final controller looks with all the leads connected.  Now I can install the individual components in the garage and simply connect everything together.  It also allow me to easily remove and replace any individual component should one fail or an upgrade is desired.

But before actually mounting in the garage, I'd recommend one final bench test before putting everything up on the wall.  Just connect the components together on the workbench.  Note: always connect the power supply last.  The board will not boot up if the TFMini is not present at power up.  If this is the first time you've powered up the controller after installing the firmware, you will need to complete the steps to onboard the controller to your wifi before you can access the web settings page and actually see the LEDs respond.

First time setup and connecting to WiFi

Again, full step-by-step instructions for configuring the and using the app are provided in the Github wiki, so I'm not going to repeat those here.  In addition, if future upgrades change any processes or add new features, they will be documented in the wiki... so information in this article could be out of date.  For those reasons, I'll only provide some quick highlights here.

Like many smart home devices, before you can use the controller, you first have to join it to your local wifi.  And like many other devices, the process with this controller is much the same.

When the controller is first powered on and hasn't been setup for wifi, it will begin broadcasting a local hotspot.  The default name of this hotspot (at time of this article... again check the Github wiki for changes) is "ESP_ParkingAsst".  Using your phone (or tablet or laptop), join this local hot spot using your device's wifi settings.  

If after a minute or so you do not see a hotspot for ESP_ParkingAsst, look for a hotspot that begins with ESP-xxxxxx (this is the default for ESP hotspots, so it's possible that the special hotspot is not recognized) and try joining that hotspot.  If you are prompted that there is no Internet connection, choose to stay connected anyway.

After connecting the the hotspot, open a local browser and go to the IP address: 192.168.4.1.  The following wifi setup form should be shown:

Click the 'Configure WiFi' button and the controller will scan for all wifi signals in range.  If you wish to skip the scan and manually enter your WiFi SSID, you can click the second button.

Select your preferred wifi network for the controller from the list or manually enter the SSID.  Enter the password for the wifi and scroll down to the device name.

Each parking assistant device on your local network must have a unique name.  This is used for a number of internal connections, such as wifi hostname, OTA hostname and MQTT client (if MQTT is used).  Having more than one device with the same host name may cause problems or result in errors with the parking device.  You can enter any name you like, up to 16 characters max, but can only uses letters and numbers (A-Z, a-z, 0-9).  Do not include any spaces or symbols in the device name.  Note that to later change this name, you will need to perform a full reset via the web interface and complete this onboarding process again.

Click "Save" and the controller will restart and attempt to join your wifi network.  If successful the hotspot will disappear and your phone (or tablet/laptop) will disconnect and you can reconnect to your selected Wifi.  Note if you have more than one WiFi network...  your controller and the device you will utilize to access the web settings need to be on the same wifi network.

You now need to locate the IP address assigned to the controller by your router.  This will vary based on your particular router, but here is a sample from my router:

Click for larger view

The controller will attempt to join your wifi using the device name you entered as a hostname, but your router may not recognize or accept this host name.  If you don't see a device with this name, then look for the MAC address you (hopefully) copied down when flashing the original firmware.  If you cannot find either the hostname or MAC address, check and see if the controller is once again broadcasting its hotspot.  If so, that means it failed in connecting to your wifi network.  Connect back to the hotspot and repeat the wifi setup, assuring you enter the wifi password correctly.

Once on your wifi and you have the IP address, all future settings, options, upgrades, etc. can be done via a web interface.  You will only need to repeat this step if you change your wifi or if you perform a full reset of the controller via the web interface.

Settings, Options and the Web Interface

See the Github wiki for full information on settings, options and other features of the controller.  I'm only going to touch on a couple of items here.

Parking Zones

Many of the options and settings work on the concept that the controller uses four separate "parking zones" as your vehicle moves closer to the sensor:

Click for larger view

1. Wake Zone: When your vehicle first enters the edge of the wake zone (farthest zone from the sensor), the LED strip will light up in a solid color (set by you - shown as green above) to let you know the system is awake and actively tracking the vehicle.

2. Active Zone: As soon as the vehicle enters the active zone (shown in yellow above, but again, you can specify the color use), the LEDs will use the effect you've selected to indicate the car is approaching the next zone.  For example, when using the "Out-In" effect, the LEDs will light up starting on the outside edges and continue lighting up towards the center as the vehicle approaches the desired parking spot.  Other effect are available as well, and these are described in the Github wiki.

3. Parked Zone: This is the desired final parked location of the vehicle.  When the front edge of the vehicle enters this zone (shown in red above, but again you specify the color), the LEDs will all turn solid.  How wide you make this zone will depend upon your particular situation, but if at all possible, a parked zone width of at least 6" is desired.  Otherwise, it may be hard to precisely stop between the active and back up zones.  Also recall that if the front of your vehicle has some curvature, the reported distance of the sensor may vary based on the left/right position of the car as related to the sensor.

The variance will depend somewhat upon the curvature of your vehicle(s) and how consistently the driver parks the vehicle left/right of the sensor.  For this reason, you should make the parking zone as wide as possible while still having the car in the desired parking location.

4. Backup Zone:  If the vehicle pulls too far forward, the LEDs will begin to rapidly flash (color of your choice), telling the driver to backup.  The LEDs will continue to flash until the vehicle leaves the backup zone.. or until the parking timer expires.

A note on the active zone size and the sensitivity of the LEDs:

Your initial inclination might be to make the active zone as large as possible.  But in actuality, a smaller active zone means the LED lights will be more 'sensitive' to changes in distance.

For example, let's say you have a total of 24 LEDs and you set the active zone distance to be a total of 8 feet (96").  This means a new LED will light up for each 4" traveled by the car.  However, if the active zone is reduced to 4 feet (48") a new LED will light up for every 2" of travel.  The greater sensitivity can be helpful as you approach the parked zone... especially if you have a narrow park zone.

So, you may want to experiment with different active zone differences, but as a general rule, you may want a wider wake zone and a narrower active zone to provide better sensitivity for the driver.

The web interface allows you to set many of the options (and more) discussed above  You can, for example:

• Specify or change the number of LEDs, along with both the active and standby brightness of the LEDs
• Set the time the LEDs are active for parking and when a car exits.
• Specify colors to use for each of the four parking zones.
• Select from a list of different effects for the active zone
• Enable (or disable) MQTT functionality for use with home automations systems like Home Assistant.
• Reboot or completely reset the controller
• Upload future releases over wifi right from the web interface.

Once again, please refer to the Github wiki for details on the use of all these options.  The Github repo will always contain the latest firmware version, along with any changes or additions to the features and options, including any new effects or colors that might be in a future release.  Just one final note about the web configuration.  Have just a bit of patience when loading the web site.  Remember, this is running on an ESP8266, not a powerful web server, and that it is also running the parking process, listening for MQTT commands or OTA updates and other processes at the same time.  It may take a few seconds for the web page to first appear, or to update when going from one web page to another.

Installation 

If you've still been bench testing up to this point... and everything is working, it is time to finally install the parking assistant in the garage!  Your installation may vary greatly from mine, based on a number of factors, but I'll cover my install in the event it might help you with yours!

Everything mounted, connected and working!  The original Raspberry Pi version of the parking assistant can be seen at the far right.

The first, and probably most important part of the installation will be the mounting location of the TFMini-s distance sensor.  Ideally, you want this mounted at a height where it is going to reflect off of a solid portion of the vehicle, like the bumper and not the grill.

I simply measured the height to this part of my vehicle... about 18" in my case.  Remember that the TFMini-s only has a 2° field of view, so the 'beam' is pretty narrow.

I then mounted the TFMini at this same height.  As far as horizontal distance, ideally the sensor would be mounted so it is pointed at the forward most position of the vehicle (normally the center point), but this somewhat depends on the driver parking the car in the same left-right orientation each time (see curvature of the car above).

The only other somewhat important location for mounting is the LED strip.

You want the LED strip mounted close to eye-level for the driver.  Too high and the driver may have to crane their neck to see the LEDs as they near the final parking spot... too low and they may disappear under the hood.  Note that if you have limited wall space, you can also mount the LED strip vertically.  In fact, the 'full strip' effect can be run in either direction from what would be the top of the strip down, or from the bottom up when the strip is mounted vertically, regardless of which end the wiring is connected to.

The location of the controller and power supply are totally up to you, based on your configuration, location of AC power, etc.  Just assure you manage any cable runs so they don't pose a trip hazard if located near a door like mine.  In all honestly, I made my cable runs a little too long.  If this was going to be a permanent installation for me (it's not... it was really done just for this blog and related video... I know, nuts right?), I'd probably go back and shorten some of those leads.  But for now, my wife likes and has become accustomed to the Pi version.  And since it still works just fine, I'll likely keep that one.  But this one was definitely cheaper to build and easier to setup and configure.

Testing and final tweaking

Once everything is installed, it's time to get all the settings configured and tweaked for your vehicle.  I highly recommend you start out with a large piece of cardboard, a trash can on wheels or other flat surface to set the initial settings instead of using your car.  I can't be held responsible if you crash your car though the wall of the house because the settings were incorrect... or if the system doesn't work as expected!

The web interface allows you to quick make temporary changes and test them before writing them permanently to the settings.  So, using your temporary 'car substitute', enter some initial distance values for the various parking zones and test them.  You can also play around with colors and effects at this point if you want.

Once you have the settings pretty close, then (and only then) should you try it with a vehicle.  If you will be parking close to a wall in the final parking position, I'd also recommend having an observer on hand when you try the parked (and backup) zone settings for the first time.  Once you are happy with the settings, simply check the box to make the settings the new boot defaults.  Of course, you can always change the settings again if needed or desired.

Congratulations!  You now have a reliable, configurable parking assistant (and it's definitely cooler than that tennis ball on a string hanging from your ceiling!).  And if you have Home Assistant or another MQTT-compatible automation system, you can use the parking assistant as a vehicle presence detector for your other automations.

Future Development

Update (Feb. 2024):  Since this article and video were originally published, a number of improvements and enhancements, along with various bug fixes, have been made.  These include, but aren't limited to:

• Ability to define a custom MQTT topic

• Implementation of Home Assistant Discovery.  Click one button and your parking assistant will be added to Home Assistant with no YAML or other configuration required on your part!

• Mobile-friendly versions of all the settings web pages

Always check the Github repo release notes and wiki for the latest information as changes made to the firmware may impact or alter some of the details provided in this article.

Depending on interest... and my available time and project load... I may continue to develop the firmware and add more new features over time.  Let me know in the comments if you build your own and you have ideas for improvement or new features.  Naturally, I can't guarantee that I'll be able to implement them... but I definitely won't if you don't ask!  Of course, the source code is also available so if you are experienced with writing Arduino code, you can always fork the repo and make your own version and improvements.  

Thanks for reading... let me know in the comments if you have questions!

Links

Github Repo for this project (latest firmware, wiki, more info on settings, etc.)

YouTube video of this project

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 use any of my Amazon links to make a purchase at absolutely no cost to you.  Or if you prefer to say thanks directly, you can buy me a one-off cup of coffee at: