Parking Assistant with MQTT and Vehicle Presence Sensors

 

This blog actually covers two related, but separate projects.  The first is a digital parking assistant for the garage and the second is vehicle presence detection.  These can be used independently or in conjunction within your home automation platform, like Home Assistant to create automations or other routines.

Many people, myself included, have used the old tennis ball on a string as a parking assistant for tight garages.  And honestly, this is a cheap, reliable system that works.  Batteries never need replaced, Internet or power outages do not affect the functionality and everyone understands how it works.  But what fun is that?  And if you have a smart home or home automation platform, you sure can't integrate the tennis ball into that platform.

In addition, if you use your garage as your workshop as well like I do, you will eventually find these hanging balls to be annoying!  Bumping into them with your head or catching the string on a ladder and yanking it from the ceiling will soon become frustrating.  That was the case for me, when I started looking for a solution I could integrate into Home Assistant. This project uses Python running on a Raspberry Pi, an LED matrix panel and a LIDAR distance sensor and is based on a project published on the Instructables web site, Pi Based Parking Assist System.  But my project utilizes only single sensor, adds MQTT for integration into automation systems and makes some other changes.  In addition, I opted to add vehicle presence detection as a secondary project, so that cars on both side of the 2-car garage can be detected as home or away.

A YouTube overview video of both the parking assistant and vehicle presence detection can be viewed here.

Parts List

As always, I like to provide the parts that I used.  You may be able to substitute or find alternative sources at lower prices.

Parking Assistant

QTY	DESCRIPTION	Notes
1	32 x 32 RGB LED Matrix
1	5V 3A Power Supply	For LED Matrix. Pi requires own power
1	Canakit RPi 3B+ Starter Kit	Can purchase individual components
1	TF Mini LIDAR Module
1	CP2102 USB to TTL Serial Converter
~24	Dupont Jumper Wires	Length will depend on your install
	Heat shrink tubing (recommended)

Vehicle Presence Detection

QTY	DESCRIPTION	Notes
1	NodeMCU ESP8266
2	HC-SR04 Ultrasonic Distance Sensor
1	5V USB Phone Charger
1	Tailwind Garage Switch Kit	*Optional – any reed switch will work
	20-24 Gauge Wire	Length will depend upon install

Some links may be affiliate links.  While this does not affect your pricing, the blog may earn a small commission to use towards future projects.

Parking Assistant 

I'm not going to cover all the steps here for installing an operating system and initial setup of the Raspberry Pi.  If you want step-by-step instructions on how to do this and install the necessary libraries for the parking assistant, I'll refer you to the original article that I followed:

Instructables Pi Based Parking Assist System

Follow steps 4-6, except instead of installing their project files at the end of step 6, grab the Python files from my Github .  My version eliminates the side sensor (I could never get reliable results) and adds MQTT for Home Assistant integration/automations.

If you are familiar with setting up a Raspberry Pi and installing libraries, here's the Cliff Notes version of the steps needed:

• Install the latest Raspberry Pi Lite version (this will run headless so desktop is not needed)
• Configure for your WiFi and enable SSH
• Install the following additional library:
• lmport and compile and bind the zheller rpi-rgb-led-matrix library

Note: At the time I initially created and installed this application, Python 2.7 was in use.  If you are using Python 3+, other libraries may need to be updated as well.

Regardless of whether you follow the step-by-step guide or the Cliff Notes version, you then need to complete the following steps:

• Install the Paho MQTT Library
• Copy the parking_tf.py file from the Python folder in my Github to a dedicated folder created under /home/pi on the Raspberry Pi.  If you want to avoid potential permission and pathing issues, you should copy the .py file to the following folder, created when you install the zheller library:

 /home/pi/rpi-rgb-led-matrix/bindings/python/samples

• Edit the options at the top of this file to match your MQTT information, nominal parked distance, etc.  See the Github readme files for more details on these options.
• Finally, install the serial library by running:  pip install pyserial

Wiring and Mounting

Before wiring, you'll want to determine the approximate mounting locations for the display, distance sensor and Raspberry Pi.  You are going to need 5V for both the Pi and the Matrix display, so you'll also need an outlet close by (or an extension cord) so that you can plug in your 5V power supplies.

This shows my installation (obviously, yours will vary).  The most important is the location of the LIDAR distance sensor.  While not required, ideally this will be mounted to align with the front most portion of the vehicle... likely the center of the front bumper.  But you can play with the placement to meet your needs.  Next important is the placement of the matrix display.  This should, ideally, be at eye level of the driver and in the center of the field of view.  In my case, both the sensor and display are slightly right of center due to the door.  The location of the Raspberry Pi is completely arbitrary, but I mounted mine to try to minimize the length of wire runs and to use simple Dupont connectors without extensions as much as possible.

Connecting the Matrix to the Raspberry Pi

Connect the Matrix to the Raspberry Pi per the following diagram and chart:

(Note: The following refers to the physical pin position on the RPi, not the GPIO number):

RPi Pin #	Matrix Input	Wire Color	Notes
POWER
2		Red	Not needed if powered by USB
9		Black	Can be repurposed to power case fan
SIGNAL
14	Ground	Black	Unlabeled pin on right side of input
20	Ground	Black	Unlabeled pin on right side of input
25	Ground	Black	Unlabeled pin on right side of input
7	Strobe (STB)	Grey
11	Clock (CLK)	Yellow
12	OE	Pink
15	A	Purple
16	B	Orange
18	C	Green
22	D	Magenta
23	R0	Red
13	G0	Green
26	B0	Blue
24	R1	Red
21	G1	Green
19	B1	Blue

In my case, I opted to not use the power connections (Pins 2 and 9) and power the RPi via USB.  This allowed me to use these two pins to power a small integrated fan in the RPi case, as our garage gets pretty warm in the summer.

For the remaining connections, the matrix comes with a ribbon cable, so you can simply use male-to-female Dupont connectors and insert the male end of the Dupont cable into the female end of the ribbon cable.

If you take this approach, be sure to double-check the pin location as related to the ribbon cable.  Secure the Dupont connectors to the ribbon cable with tape or hot glue.  Then splice the supplied cable for power supply for the matrix to the positive and negative leads of a 5V (3A minimum) power supply.

Next, connect the LIDAR sensor to the USB-TTL adapter according to the following diagram:

Now plug the USB-TTL adaptor into a USB port on the Raspberry Pi and mount everything in position in the garage

Testing and Setting the Parking Distance

Once all wiring and mounting is complete, you are ready to power up, test the system and set the parked position distance for your vehicle.  First, connect the 5V power for the matrix, then the 5V power for the Raspberry Pi.  Until you've setup the parking program to run on boot, you will need to SSH/remote into the Raspberry Pi and manually launch the program:

cd /your_path_to_the_program_file

sudo python parking_tf.py

If all is functioning properly, the four corners of the matrix should light up (assuming the LIDAR sensor is not detecting any object closer than about 118").  You can then place an object (a flat piece of cardboard works well) at various distances between around 2" to 118" and see the display respond.  In addition, you can SSH into the Pi and watch the parklog.txt or your MQTT broker and see updates posted.  By default, both the log and MQTT are updated once every 3 minutes.

Now you will need to determine the distance when your vehicle is in the desired parked position and update this in the Python code.  The easiest way to start this process is to park your vehicle in the desired final position.  Wait a few minutes and open the parklog.txt file on the Raspberry Pi.  This will show you the mm measured at that position.  Use this as the starting value as the Python program's nom_parked_Front value.  Stop the program, edit the value with nano or vi, save and restart.  You will probably need to test and tweak this a few times to get it just right, but you want the center "+" to appear just as the car reaches the perfect position.

Running at boot (and daily rebooting)

Ideally, once everything is functioning as planned, you can add the Python program to launch at boot.  This is handy should power be lost, or in my case, I reboot the Pi daily.  I do this to purge the text log, which continues to append data every three minutes.  Without this reboot/purge, eventually the log would fill up all the storage on the Pi.  For this, I use crontab with the following commands:

To start parking_tf.py at boot:

sudo crontab -e

@reboot /bin/sleep 30; sudo /usr/bin/python /your_path/parking_tf.py &

To reboot the Pi daily (in this case at 7 am):

sudo crontab -e

0 7 * * * sudo shutdown -r 0

MQTT

By default, the parking application will publish to the root topic parkpi/parking

This can be changed in the code (line 397).  It publishes the following topics and payloads:

Topic	Payload	Notes
lastupdate	hh:mm:ss	Local time of last update
status	OK or ERR	Success or failure of last read
frontdist	nnn	Current distance (mm)
cardetect	car or nocar	car if distance less than max
powerstate	sleep or active	Current display power state*

Note that the display will 'wake' when an object is detected at less than the maximum distance and then power down into a 'sleep' state after about 1 minute (this is considered the maxOperationTimeParked in the code and determines how long the display remains awake after activation).

Using the MQTT topics and payloads in Home Assistant are covered below.

PART 2

Vehicle Presence Detection

My version of the vehicle presence detection consists of detectors for two vehicles plus an optional reed switch to indicate the opened/closed position of the overhead garage door.  This can easily be modified for just one vehicle or even three vehicles.  I added the reed sensor to the garage door because, at the time, I did not have a smart opener that could be integrated into Home Assistant for automations.  For example, if Home Assistant detected that both vehicles were gone and the door was closed, arm the alarm system after 15 minutes.  The door reed switch is completely optional and won't be needed if you already have a door sensor in Home Assistant (or if you don't want to use door position in any automations).

This is the wiring diagram I used.  Each HC-SR04 sensor is connected to the VIN (5V) pin on the NodeMCU and ground is connected to any GND pin on the NodeMCU.  The remaining two pins on the HC-SR04 (trigger and echo) are connected to GPIO pins on the NodeMCU.  In my case I used D1 (trigger) and D2 (echo) for the first sensor and D5 (trigger) and D6 (echo) for the second.  You may use different pins, or your pins may be in different locations on your NodeMCU, so check carefully.  If you opt to use different pins, you just need to modify the ESPHome code below to match your wiring.

The optional reed sensor is connected to a GND pin on the NodeMCU and any unused appropriate GPIO pin.  I opted for D7 and enabled the pullup resistor on that pin.  Again, change the ESPCode as appropriate for your install.

ESPHome

Before assembly and mounting in the garage, you'll want to load ESPHome to the NodeMCU via USB cable.  After the initial load, you can load future changes and revisions over-the-air (OTA).  Note: ESPHome is currently undergoing some enhancement that may allow you to complete an initial load OTA, but as of publication of this blog, this is still a work-in-progress.

If ESPHome is not installed in Home Assistant, or if you have not created a new node before, you can find information on how to do so at Getting Started with ESPHome and Home Assistant.  Using the wizard, you will enter a name for your new node, select the platform (e.g. ESP32), enter your WiFi credentials and set an optional over-the-air update password.  This will create a starting .yaml file that so far will only connect the board to your WiFi.  Now you have to define the sensors and other options for the binary.

For the vehicle sensors as described above, you will need to add the following sensors to the generated YAML code:

sensor:

  - platform: ultrasonic

    trigger_pin: D1

    echo_pin: D2

    name: 'Car 1 Distance'

    unit_of_measurement: 'ft' 

    accuracy_decimals: 1

    timeout: 3m

    filters:

      - multiply: 3.281

  - platform: ultrasonic

    trigger_pin: D5

    echo_pin: D6

    name: 'Car 2 Distance'

    unit_of_measurement: 'ft'

    accuracy_decimals: 1

    timeout: 3m

    filters:

      - multiply: 3.281

binary_sensor:

  - platform: gpio

    pin: 

      number: D7

      mode: INPUT_PULLUP

    filters:

      - delayed_on_off: 500ms

    name: "Garage Door"

    device_class: garage_door

Here's a bit of explanation for the code above:

For the distance sensors, the platform for ESPHome is ultrasonic.

The trigger and echo pins define the pins on the NodeMCU that you connected to the sensor.  Change these if you used different GPIO pins.

name is the name of the sensor entity as it will appear in Home Assistant.

unit_of_measure will also be used by Home Assistant (I use feet instead of the default meters)

timeout is the number of meters for the timeout. Most sensors can only sense up to 2 meters.  I increase this to 3 to avoid getting an undefined value.  If the distance measured exceeds this amount, the max distance of the sensor will be returned.

filters allow me to apply a multiplication factor to convert the default meter measurement to feet.

By default, the sensors will update once every 60 seconds.  If you wish to change this, you can specify an update_interval. See the ESPHome ultrasonic sensor page for more details an other options you may wish to apply.

The binary sensor is for the optional garage door reed switch.  This code is pretty self-explanatory, except that I added a delayed_on_off filter to debounce the sensor.  See the ESPHome binary sensor page for more details and additional options. 

Again, modify the above code to remove any sensors you are not using, or to add any additional sensors (such as a third vehicle).

Assembly and Mounting

Once you have ESPHome loaded on your NodeMCU, you are ready to install and mount everything.  Since both the NodeMCU and HC-SR04 have pins, you can use simple Dupont connectors (although you'll have to extend the length from the NodeMCU to the sensor).  Or you can opt to solder, use breadboards, etc.  That is up to you, but if you use wire connectors, such as wire nuts or Wago connectors, the entire project can be completed without soldering.

This photo shows how I opted to mount everything.  The distance sensors (HC-SR04) are positioned approximately over the center of the vehicle roof when the vehicle is in the normally parked position.  The NodeMCU is mounted in the center and also near the power outlet to supply the USB power via a phone charge or similar AC-to-USB adapter.  

Here's a view from the reverse angle that also shows the optional door sensor.  Use caution when running this wiring to assure that it doesn't interfere or get tangled in the door rollers when the door opens and closes.

Once powered up, the new ESPHome node should be auto-detected in Home Assistant and once it is adopted into the ESPHome integration, three new entities will be created (or whatever number you defined):

My car presence sensors are named "scarlett_distance" and "mks_distance". Yours will be whatever name you specified in the ESPHome node configuration.

Home Assistant

So why did I combine these two separate projects into a single blog article? It because within Home Assistant these two projects, along with phone presence, will be used to create away and home automations.  And since this includes the home alarm system, I did not want automations that enable or disable the alarm system without multiple checks and balances.

All in, with both projects and the phone presence, the following can be used in automations:

• Two separate devices and methods to determine whether the car is home or away.
• Two separate garage door sensors to determine whether the door is opened or closed.
• Two separate mobile phones to determine home/away status.

So, for example, the alarm system is only disarmed if:

• BOTH garage door sensors change from closed to open AND
• A car is detected by the parking sensor AND the vehicle sensor AND
• One of the two mobile phones have entered the home zone.

If any of the above checks fail, the alarm system is not automatically disarmed.  So even if the door somehow opens, unless at least one vehicle and one of our phones is detected by Home Assistant, the alarm remains armed.

For all this to work however, there are a few entities we must manually created beyond the ones automatically created by ESPHome.

Parking Assistant

For the parking assistant, we have to create a sensor for each of the MQTT topics/payloads we wish to bring in and use in Home Assistant.  If you do not want to use a sensor, you do not have to create it.  Here are the sensors I created for each of the five available topics:

# ===============================

# ParkPi Parking Asssistant

# ===============================

  # Last Updated

  - platform: mqtt

    name: "Parking Last Update"

    state_topic: "parkpi/parking/lastupdate"

    value_template: "{{ (as_timestamp(now()) | int) |

                        timestamp_custom('%I:%M %p') }}"

  # Parking Distance

  - platform: mqtt

    name: "Parking Distance"

    state_topic: "parkpi/parking/frontdist"

    value_template: "{{ (value | float / 25.4 ) | round(1)}}"

    unit_of_measurement: '"'

    icon: mdi:arrow-expand-horizontal

  # Parking Status (OK / Err)

  - platform: mqtt

    name: "Parking Status"

    state_topic: "parkpi/parking/status"

  # Parking Car Presence (car/nocar)

  - platform: mqtt

    name: "Parking Car Presence"

    state_topic: "parkpi/parking/cardetect"

    value_template: >-

      {% if value == 'car' %}

        Detected

      {% else %}

        Not Detected

      {% endif %}

    icon: mdi:car

  # Parking Power State

  - platform: mqtt

    name: "Parking Power State"

    state_topic: "parkpi/parking/powerstate"

    icon: mdi:current-dc

Car Presence Detection

For this, there are two are binary sensors that were created, based on the measured distances of the vehicle sensors.  The default sensors just report distances.  While technically the distances could be used in the automation, it's not only more convenient to have a simple home/away sensor, the sensors do 'bounce' a bit in terms of measured value, so we can give the binary sensor a range to use for home vs. away.  This is the YAML that I used to create these binary sensors:

# ==============================

# Car Sensors

# ==============================

- platform: template

  sensors:

    scarlett_home:

      friendly_name: 'Scarlett Location'

      device_class: presence

      value_template: >-

        {{ states('sensor.scarlett_distance')|float > 4

           and states('sensor.scarlett_distance')|float < 5.5 }}

      icon_template: >-

        {% if states('sensor.scarlett_distance')|float > 4 and 

           states('sensor.scarlett_distance')|float < 5.5%}

          mdi:car

        {% else %}

          mdi:car-off

        {% endif %}

    

    mks_home:

      friendly_name: 'MKS Location'

      device_class: presence

      value_template: >-

        {{ states('sensor.mks_distance')|float > 4

           and states('sensor.mks_distance')|float < 5.5 }}

      icon_template: >-

        {% if states('sensor.mks_distance')|float > 4 and

           states('sensor.mks_distance')|float < 5.5%}

          mdi:car

        {% else %}

          mdi:car-off

        {% endif %}

In this case, recall that we already converted the measured value from meters to feet in the ESPHome node.  So we are dealing with feet in the automation.  If the reported distance from the vehicle presence sensor is between 4 and 5 1/2 feet the car is considered "home".  Otherwise, it is "away".  The actual measured distance for both of our vehicles is around 4 1/2 feet, and most of the time, the sensors report around 4.3 ft, so they are pretty accurate.  And with 9 ft ceilings in the garage, the measured distance when the car is away also registers right at 9 feet. So, why such a broad range?  Mostly because I didn't need it to be any more accurate.  If I made it too tight, something like a sunroof left open could change the measured distance by 3 or 4" and return in invalid result.  By allowing 6-12" on either side of the true value, it serves the purpose of just saying the car is home or away is OK for my purposes as I really don't care about the true measured value.

The icon_template in the definition is entirely optional. This just changes the icon in Lovelace when a car is home or away, but works on the same range and principle.

We can use the optional garage door binary sensor as-is from ESPHome and don't need to do anything here.

Lovelace Examples

These are just a couple of examples of how you might represent the entities in Home Assistant.

The top portion of the card is based on the binary sensors created from the ESPHome distance sensors and shows both cars are "home".  The lower section is from the Parking Assistant MQTT values and shows that the car is present, as well as other information.

Now, the "MKS" vehicle is "away".  This is indicated not only by the state change on the card, but by displaying a different image based on state.  These are not live camera feeds, but instead static images that were taken and placed in the \www folder of Home Assistant.  This is actually a picture entity card in Lovelace where we can change the image displayed based on the state of the related entity.  Here is the YAML that creates the Lovelace display shown above:

cards:

  - text: Vehicle Presence

    type: custom:text-divider-row

  - cards:

      - entity: binary_sensor.scarlett_home

        name: Scarlett

        state_image:

          'off': /local/scarlett_away.jpg

          'on': /local/scarlett_home.jpg

        type: picture-entity

      - entity: binary_sensor.mks_home

        name: MKS

        state_image:

          'off': /local/mks_away.jpg

          'on': /local/mks_home.jpg

        type: picture-entity

    type: horizontal-stack

  - text: Mari's Parking Assistant

    type: custom:text-divider-row

  - entities:

      - entity: sensor.parking_car_presence

        name: Car Detection Status

      - entity: sensor.parking_distance

        name: Parked Distance

      - entity: sensor.parking_power_state

        name: Current Power State

      - entity: sensor.parking_status

        icon: mdi:state-machine

        name: System Status

      - entity: sensor.parking_last_update

        icon: mdi:timer

        name: Last Updated

    show_header_toggle: false

    type: entities

type: vertical-stack

Conclusion

While separate projects, and each can stand alone, bringing both of these projects together in your home automation system provides you with numerous options for home/away automations.  And an added benefit of the parking assistant assures that your teenage driver doesn't crash the car into the garage wall!  Let me know if you have any thoughts or questions in the comments.

Supporting this blog and related YouTube channel

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: