As a couple of sharp-eyed viewers have noted, there is an error in my conversion from mm to inches when showing the minimum distance for the VL53L0X sensor. The correct value should be 50 mm ~ 2 inches. Sorry for the mistake!
I instantly saw that error when looking at the table, and I was also wondering why mixed units. Either put all in cm or all in mm. Basic science. I would make them all mm FWIW...
Well, pretty much for the same reason I went back and added mm as a display option for the web settings per request... to most non-US folks, inches have no meaning. For for most in the US, cm or mm have no real meaning. Many, myself included, would have no idea how long 48 cm is without using a converter... is that one foot, two feet, something in between? So, to try to appeal to everyone, I show distances both in the video and on the app's web page in both metric and imperial. But I can't make everyone happy all of the time. Internally within the code, everything IS done in millimeters.
@@ResinChemTech Ok, I'm still a bit confused... in your code when you retrieve the distance via tfmini.getData(distance), is the distance value in mm or cm?
This is a great project. Thanks for sharing. I made two minor modifications that improved my experience. - The first is an update of the libraries and recompile to eliminate some pesky wifi issues. Wifi is rock solid now with no more misc broadcast of local AP. - The second modification is to adjust the response time of the status bar. I found myself pulling into my garage and waiting for the bar to update. Many times as I was creeping forward to wait for the bar to change, I overshot the "ideal" range and had to backup. My fix is relatively simple. There is a delay(200) at the end of the MAIN LOOP, which I changed to delay(50). The response time of the status bar is much quicker. Thanks again for this project!
I absolutely love the way you describe the project and show it BEFORE you start building or showing the components. So many bloggers do the opposite and I never know what they're talking about because they wait until the end to demo it. Also, you are spot on with the level of information and video walk through when constructing your components. Thank you. (Subscribed).
Wow... thanks! I know that most of my videos are much longer than the "average" project video, but I try to provide the 'why' as well as the 'what' so viewers might be able to take my project or idea and figure out how to adapt it for their own needs. I appreciate the feedback. Showing the finished project at the start of the video is something that I've started doing more often recently. I'm glad you found it helpful. I will try to continue to do that in the future. Thanks for taking time to leave a comment... and thanks for the sub!
I am genuinely impressed by the clarity and structure of your presentation, starting with a comprehensive overview of the project before diving into the construction and components. This approach is refreshingly clear and keeps me engaged from the very beginning, unlike others who leave the audience guessing until the very end. Your dedication to providing a detailed walkthrough and the meticulous attention to detail in your projects, such as the original parking assistant, is truly commendable. The effort you invest in each project shines through, making them not just informative, but also incredibly inspiring. Thank you for your hard work and for sharing your knowledge with us. ( I am a subscriber - Miguel) 👏👏👏👏👏👏👏👏👏
Wow... thank you so much! While it does tend to make my videos longer than others, I take the approach of trying to explain the 'why' as well as the 'how' with the goal that if I can share the concepts, others may be able to take my ideas and apply them to their own projects as opposed to just "cloning" what I did. I greatly appreciate the time you took to post a comment (and the Super). It is comments like yours that inspire me to create more videos. Just as an FYI, I'm currently working on an update to this system that will make Home Assistant integration much easier, without the need to create any manual YAML. Thanks again... for watching, the kind words and the sub. Welcome to the channel!
Your original parking assistant is one of my favorite DIY projects. You've done it again! As with all of your projects, including as much detail as you do is wonderful. Thank you
Thanks! I really appreciate the kind words. The original was one of my early projects, so while it works pretty well, it was a bit complicated to figure out (and to maintain since the settings can only be updated by editing the Python code). I wanted to try to make one that was both easier to build (not to mention Pis are hard to come by these days), but also had a way to change settings without editing any code. Again, I do appreciate the comment. It's comments and feedback like your that encourage me to keep making videos!
This is so ingenious - and your detailed instructions are great. Unfortunately, we don't have a garage. We park two cars side by side in a wide driveway. Thus we have to pay attention to side-to-side position as well as positioning the left side car behind the other for easy driver's door access for the forward car. Sure would be great if we could figure out a sensor to mount on the house that would nail these two positions for the drivers.
Thanks... I appreciate the kind words. I've had numerous requests for something that provides lateral, or left/right, guidance. I'm considering a couple of different approaches... one that integrates lateral guidance into the existing system, or a separate system that would provide lateral guidance only. The second option may be of interest to you, but there are a few things that I think might still be a challenge for you. First, if this it going to be mounted outside and exposed to the elements, everything would have to be made waterproof... definitely not something that my current system has. Next, any sort of sensor that is going to detect lateral movement would likely have to be mounted to the side of the vehicle. If you just have an open driveway, I'm not sure where or how you would mount the sensor. But I guess that's why I try to explain the "why" as well as the "how" in my videos. I hope that viewers may be able to take my ideas or concepts and adapt them to their own projects or needs. So, maybe if I do add some sort of lateral detection down the road, maybe you can find a way to adapt it to your needs. Thanks for watching and taking the time to post a comment!
10:00 spot the mistake 😊, 2cm (20mm) is a lot less than 50mm (5cm), almost tempted to try something like this but will need a lot more accuracy than the LIDAR as i park outside and almost touch the garage door when parked, the reversing sensor on my van is not reliable so tend to go really slow and touch park.
Good catch... and you are 100% correct! In my effort to convert everything to inches and feet (since Americans mostly refuse to adopt the metric system), I advertently left a "0" out of the conversion calculator I was using... entering 5 millimeters instead of 50! Thanks for the correction! But the maximum range is correct and the ToF sensor quickly drops out of the testing ranges. None of these, I believe, would work in a situation where you have to park within an inch or so of a wall or door. I wonder if something like a contact sensor on a flexible surface (or spring) might work better in that case? Maybe something that you would slowly approach until you make contact... and that contact would then flip an LED or other indicator on? Just a thought. But thanks again for spotting the mistake... and I'll see if I can post some sort of correction somehow.
Awesome tutorial. For now, I just use a piece of wood that I boltet to the floor. But this is a far more sophisticated solution. Also, no trip hazard due to the piece of wood - which may or may not be an issue depending on the circumstances.
Thanks! Yeah... there are a lot of "low tech" solutions. I had a tennis ball on a string from the ceiling initially. But when I would be working on a project in the garage, seems like I was always banging my head into the tennis ball.. or catching the string on a 2x4, etc. Plus you really can't really integrate a tennis ball (or piece of wood!) into a home automation system to use it for something like vehicle detection. Thanks for watching and taking time to post a comment!
Great Project, it's just what I needed for my garage. I don't have much room to play with, and this helped with getting my truck parked just right. I was going to post on the Blog, but was having problems getting onto the comments. But FYI, I did have a problem at first with getting it set-up I found that I had set the TFMini looking right at the front license plate, and would get inconsistent operation. Thinking that the reflective part of the license plate might be interfering with the sensor. After moving the TFMini over 2' and resetting the distance, It worked like a charm. Thanks.
Glad you got it working! We don't have front plates on our cars, so I obviously haven't experienced that. But I guess it is entirely possible that the plate reflectivity could scatter the signal and cause the issues that you were seeing. A good point for anyone else that might install the system and have a front plate on the car. Thanks for taking time to share the issue (and resolution) and for letting me know that you successfully built the project.
That's great design with cost effective components. I appreciate the explanation of the more expensive TFMini-s and agree. You mentioned a car presence function. I immediately thought of car not present and garage door open possibly indicating someone drove off an left the door open. There would need to be some rules to go with that before taking some action and a way to disable it if you're working in the garage with the door open. But, could be useful for some.
Thanks... actually my parking sensor is used as a secondary presence sensor. There are two ultrasonic sensors mounted on the ceiling over each of the cars (connected to an ESP8266 running ESPHome... it also has a reed sensor for the overhead door connected) that also reports the presence (or absence) of either car and verifies the door position agrees with that reported by the smart garage door opener (Tailwind). So, I can crosscheck both car presence detectors and both garage door sensor positions before I take any automation action, especially actions related to arming/disarming the alarm system (which also adds phone presence detection as well). When it comes with anything to do with home security, I definitely want more than one sensor reporting. The parking assistant simply added yet another way to assure a car is present or not when compared with other sensors. And as you mentioned, even if both cars are out of the garage (maybe because I'm working on a project in the garage), my phone would still be present, so the automation to arm the alarm system would not fire. Just one of many automations related to presence detection. Thanks for watching... and taking time to post a comment!
Thanks for sharing this wonderful project. While I love all the features of this sensor, I build my sensors to give as gifts to friends. In doing this, I am conscious of cost and simplicity. I use the ultrasonic sensor mounted in a 3D printed enclosure along with the microcontroller. I then use a Cat 5 cable to transfer power to a conventional red and green LED mounted higher in its own tiny enclosure. I do not need a computer or phone to interact or set up my device once the microcontroller is flashed. The green LED is on unless the car is in the parked position. To program the parked position, just park the car in front of the sensor and push a momentary push button on the enclosure. The controller takes the reading at that moment and stores it in EEPROM so that the set point is not loosed during power outage. For my personal use, I will likely build your sensor. Thanks again for sharing.
You are welcome. Yeah... if I was building (or giving as a gift), I'd definitely pre-flash the controller. And I tried to add as many different options to mine to accommodate different use cases. But this does require onboarding to wifi and using the web interface... complicating things a bit for the end user. I love the idea of a momentary push button to store parking locations though. That's a great idea that never occurred to me (I love it when I get new ideas from my viewers)! I could see even adding four small different colored push buttons to a controller box that would set the four different zones in my case. Hmmm.... And of course by only having two LEDs, you not only eliminate the need to specify the number of LEDs being used, but also substantially reduce the power requirements. All great ideas! I do know that my wife, however, does like the 'countdown' approach lights in both the Pi and the WS2812b version. But your version is definitely simpler to build and use (writing that web interface and onboarding process for the measly ESP8266 was a pain!). Thanks for watching... and thanks again for sharing your build ideas.
Cool project. Have you given any thought about how to incorporate lateral alignment? My garage is pretty tight so getting the car aligned left and right is important too. Your original project has a display that looks like it could tell you to steer left or right. I have some ideas but they require a lot of ceiling-mounted sensors or a camera with some image processing (a sensor on a wall perpendicular to the front wall won't work for me). Anyway, I enjoy your projects, keep up the good work.
Actually, the original Raspberry Pi version did have a side/lateral sensor (another TFMini), but I could never get it to work consistently (yes, the matrix display actually has side arrows defined to help with that lateral distance... but I stripped that out of the project). For this new version, I toyed with the idea of trying to do something for lateral alignment, but it would probably take a completely separate processor, LED strip, etc. as the D1 Mini only supports one serial device. But there are a lot of possibilities, including moving up to an ESP32 for multiple serial ports. But it sounds like your problem is made more difficult if you can't mount a sensor on a side/perpendicular wall. Just thinking "out loud", you could do something like two TFMini sensors on the ceiling (you'd need these for the narrow field of view), mounted just to the outside of the lateral "lane". Then if either trigger, it would like up a corresponding LED to indicate straying too far to one side or the other. That's just an "off-of-the-top-of-my-head" idea. There are probably other ways to tackle it. For my situation, lateral distance wasn't as important... other than getting too far one way or the other also impacts the front reading due to the curved bumper. But the "parked" zone is wide enough to accommodate that in my case. Thanks for watching... feel free to reach back out if you have any other questions or thoughts!
Here is a silly idea that is lower tech. Perhaps have the wake mode also turn on a simple visible laser pointed "dead center" of a perfectly parked car. Then, when your angle is wrong, you will see the laser reflection on the wall and can work it to point straight back.
Thanks for the hard work you put into this project! I opted to use a different esp8266 controller I had laying around and spent a few hours thinking I had wired something incorrectly as I could only get 1-2 pixels to light up when booting but finally realized I needed to use pin d6 and have a little more patience. Working great!
Glad you got it working. I tried to build as much flexibility into the system through the web interface as I could, but selection of the LED data pin wasn't one of the things I included... so it's pretty inflexible on that account. Well, unless you want to modify the source code and compile your own version. But regardless, congrats on getting it up and running. My wife loves the one I built and it is a pretty big improvement (and cheaper) than the original Raspberry Pi version that it replaced. If you run into any questions or problems with the system, please don't hesitate to reach back out.
Great project and I loved seeing the comparison of the distance sensors. The vl53l0x sensors has a "long range" mode that might have helped cover the distance, but my guess is that it would do so to the detriment of close range readings (and since it's already so noisy...). I believe the vl53l0x has a bigger brother with great distance, but when I investigated it before, it didn't have ESPHome support, so I skipped it. Given the consistency of the readings and the small number of times you would need to use it, the TFMini absolutely sounds like the best choice.
Thanks... I probably spent too much time on the sensor test but I knew if I didn't, I'd get a lot of comments about using a $3 ultrasonic sensor instead. So I felt like it was important to show why I selected the TFMini. There may be other options out there that could work and might be cheaper, but I used ones that I had used in other projects (and had on hand!).
@@ResinChemTech The sensor test was very useful for me, personally. My guess is that the accuracy variances on the ToF (if not JUST noise) could be the increased field of view and the curved surfaces of your car. All of those distances could be correct at 25 degrees with the shape of the front of your car and the non-centered placement of the sensor. Placing the TFMini in the center might have given it a slight advantage, but it's largest advantage seems like the 2 degree view. I wonder what the variances would be with a flat, perpendicular board instead of the car's multi-curved surface?
I really appreciate the kind words. Many of my videos tend to be on the long side... and few people watch them all the way through, but I like to not only provide enough details for someone to recreate the project but also understand enough that they can take the concepts and maybe adapt them for their own projects. Thanks again for watching... and taking time to post a very nice comment!
Looks great, and amazing balance between speed and details. I never saw the Rasp.version video. If I did, I would have probably said the pie was overkill.😉
Oh, the Pi is definitely overkill and underutilized for this particular project! But I built it back in the very early days of my DIY/Home automation journey... and for me, it was more about learning the Pi, Python and if I could even get the matrix to work. That's one of the reasons I decided to remake the video. With what I've learned over the years, I could apply that to make a much lower cost, easier-to-build and much more friendly to use version. My wife actually prefers the new version, so as an added bonus, I now have an extra Pi and LED matrix to play with or use in another project!
@@ResinChemTech Oh, I think we all have that type of experience, when you cannot imagine why you did something that complicated 10 years ago with the knowledge you have now. But we have learned.
I needed a narrow field sensor and you have helped me decide on the TFMini. Much pricier than the high-value ultrasonic sensor though. Thanks for this great comparison video.
The narrow FOV was one of the reasons I used it as well... along with the range and better signal stability than the other options. Yes, it is a bit more expensive and I wouldn't use it for every use case, but for me it was the best solution for the parking assistant and my installation. Thanks for watching and taking the time to comment.
There is an option in the web settings to disable the sleep mode LEDs altogether so that they do not remain lit after the system goes to sleep. However, it wouldn't be too difficult to modify the code to turn off the sleep LEDs after 30 seconds or so. I currently don't have time with my current project load to make any modifications to the code, but if you are familiar with Arduino/C++ code, my version is out there on Github and you can freely clone or fork it and make those modifications ( github.com/Resinchem/ESP-Parking-Assistant ). Let me know if you do make those changes and I can consider adding them back to my code if I ever have a chance to get back to this particular project. I have a number of other requests for modifications as well, but I have to find an opportunity to circle back to this build... and not sure when that might happen. Thanks for watching and taking time to leave a comment and suggestion.
@@ResinChemTech Damn someone is quick today. Would love to do this but no garage and car parks behind motorcycle on the drive so no line of sight from a fixed spot. I rely on a mark on the fence that lines up with my mirror.
Thanks Chris! I'm sure you could have done it better justice... as I'm jealous of how well you produce your videos! I spent too much time testing the sensors, creating the firmware and writing the blog and Github wiki to leave enough time to produce a decent video (or create a good thumbnail). But thanks for watching and taking time to drop a comment!
Thanks! I was just thinking about building something like this earlier today, and your evaluation of the different sensors probably just saved me a lot of time!
Wow.. thank you so much! I'm glad I could help. I was curious about the sensors myself and I knew that if someone was going to spend $40 on a sensor, there better be a good reason over buying the $3 one! I really appreciate the SuperThanks! Please reach out if you have any questions when you decide to build your own.
Nice project but way more complex and expensive than necessary. I bought a laser that projects a large X pattern and mounted it on the ceiling. It is adjusted so that the X is centered on the dashboard when properly parked. You can see the X on the hood of the car as you pull in so it is foolproof! I powered the laser from the garage opener light socket so it turns on when the door opens. Cost was about $25 for all parts. No microcontroller, no code.
I guess it depends on what you are looking for. A tennis ball on a string cost next to nothing, doesn't require electricity at all, and basically does same thing as my system and yours.... help someone to park in the optimal position. There are many different ways to accomplish the same thing. For me, I also wanted a system that I could integrate into Home Assistant and use for vehicle detection and automations. Something the tennis ball could not do. But I appreciate you sharing your project. It might be ideal for you and others that don't want to go to the level of of difficulty I did for my project.
Great project and great video explaining each part... I would very appreciate if you could include in your Github a document showing the wiring connections from the different components to the ESP32 board. The LED strip looks pretty straight forward but which pins you used on the ESP32 for the TFmini is not as clear to me.
The wiring diagrams, parts and more info are all in the related blog article, which is linked to both in the video description here and in the wiki within the Github repo: resinchemtech.blogspot.com/2022/11/esp-parking-assistant.html Do note that the current firmware will NOT work with the ESP32. It is designed for the ESP8266 (and preferably the Wemos D1 Mini). You can find more info on that both in the blog above and in the Github Wiki.
@@ResinChemTech Thanks for the prompt reply... my mistake on the reference to ESP32. For my project, I'm going to use the ESP32 so fully prepared to make code changes. Also, my preference is to use I2C instead of UART, so I'm also looking to use the TFmini Plus since its default interface is I2C.
I'm using the VL53L0X for my parking distance sensor and it works great. Sure, the max distance range is shorter than with the other options, but that's not a problem really. It starts detecting the car a good 5-6' away and is rock solid stable as the car is driven in and parked. I don't get the fluctuation in distance that you did. I'm using just RGB LED strip and it just changes from green to yellow to red to tell the driver when to stop.
That's great that you got the ToF sensor to work for you. Due to the entry door into my house, the sensor is placed pretty close to the side wall so the wider FOV of the VL53L0X could have posed an issue. And my wife really likes the LED "countdown" approach as her range for being in just the right spot is pretty narrow. But like many DIY projects, there are multiple ways to accomplish a similar task. Thanks for taking time to share yours.
Same here! Seems like I always have a bin full of ESPs looking for a problem to solve! I will say that personally, learning Arduino/C++ code opened up a whole new world of things I could do with ESPs (like this parking assistant, my matrix clocks, etc.). Many of these projects simply wouldn't be possible using things like ESPHome alone. And by adding MQTT, it assures that I can always integrate the devices into Home Assistant as there wouldn't be any sort of native integration for these custom-built devices. Thanks for watching and taking time to leave a comment. Let me know if you do end up building the parking assistant and how it works for you!
Wow! Thank you so much... and yep, I have a t-shirt that says that exact same phrase (although the shirt itself does have a very high WAF!). I'm just really glad you got it to work and that the wife likes it. Thanks again for the donation. It is greatly appreciated and will go towards future projects.
Really cool project. Have you thought about a feature to align the vehicle with the garage opening? I have a two car garage, but there are two single garage doors. It's still one garage inside. Anyway, my wife has a large SUV and there are only a few inches of clearance on each side. She has already hit the side mirrors when not lined up correctly. In addition, she needs your project for depth. I wonder what the best way would be to add a couple more sensors with arrows left and right as she approaches. Any ideas?
I've had a couple of people ask about that. I think that a different side sensor (possibly ultrasonic) would be needed. The problem with the TFMini/LIDAR is the narrow field-of-view, which is ideal for the front sensor, but probably wouldn't work well as the side sensor. Someone else suggested something as simple as a laser on the ceiling that would put a dot on the hood of the car that the driver would line up with the center line. I'm giving it some thought. But I think it would probably either be a separate system from this one, or this one would have to be upgraded to an ESP32. The ESP8266 is about maxed out as it currently stands... I'm not sure it would support a second sensor... at least not another TFMini/LIDAR or something the would require another serial connection. I might take a shot at coming up with something when my current project load permits. Thanks for taking time to post a comment!
I know what I'm doing next week. $45 after tax is steep when we are used to -$10 but cheaper than a RPi. As always, great video! I look forward to seeing when you release new content.
Thanks! Yeah.. the LIDAR sensor is a bit expensive, but hopefully I showed why it is worth the extra money in this case (at least for me). And the final install could be much neater, but as I mentioned in another reply, this was just a temporary install for the purpose of making the video. Actually neither vehicle parks in the location where I mounted it for filming. So, it will be moved (or if the wife wants to stay with the Pi version, possibly stored away) and I'll definitely clean up the wiring if/when it gets remounted. Thanks for watching... and taking time to post a comment. If you do build your own, feel free to let me know if you have questions... or shoot me a message if you do build it and let me know how well it works out for you!
@@ResinChemTech I am going to have to rethink the mounting as well. There is a fridge in front of my wife's spot, that may change in the near future though. I'll reach out for help or to share my build.
Thank you for this video. I have watched it multiple times. I have electronic background, but are quite new to Arduino / ESP boards and have no experience on MQTT. Home assistant is brand new to me too, but would like to set it up in the future. Would you maybe have the code for the Ultrasonic sensor instead of the serial coms code. I would like to try it out, but trying to navigate through the code and is very new to me. Code snippets and advice about the code will really help. You have an amazing project here. Thank you for this. Was looking all over for this. Not sure if someone already asked this question. Keep on doing the great work!
I don't have a version that works with the ultrasonic sensor. As I covered in the video, I didn't feel that the ultrasonic sensor was stable and precise enough for my needs so I have no plans to develop an ultrasonic version. However, I do believe that someone may have forked my code and rewrote it to use an ultrasonic sensor. I have not tested this forked version nor do I know if it has been kept up-to-date with changes made in my version. You can see my full code (and find any forks) in the Github repo: github.com/Resinchem/ESP-Parking-Assistant I try to document within the code itself to help out with anyone trying to learn or for those that want to adapt my code. The wiki may also contain some useful information. Note that MQTT/Home Assistant is optional and not required for the system to work. So you could build the system now and then add it to Home Assistant via MQTT at a later time. I appreciate the kind words and interest. I've been asked numerous times about an ultrasonic version but feel that due to the noise, wider field of view and lower precision, I don't believe that it is a good choice for this project. It definitely would not work in my situation as my sensor needs to be near a side wall and the ultrasonic sensor would just measure the distance to that wall and not an approaching car. But it might work for others in situations where high precision is not needed and the sensor can be mounted far enough away from other walls and objects.
@@ResinChemTech Thank you for your quick reply. I can't find the sensor locally at the moment and I have the ultrasonic sensor. I appreciate it. Will do some more research. Thank you!
Yeah... that was one of the biggest pains with the original Pi version. Once I had it it 'dialed in', I didn't have to mess with it much, but when first setting it up, it was a real pain... as the Python program had to be stopped, opened and edited and then restarted for each change in distance. So, I knew with this new version, I wanted a web interface where the settings could easily be tested and changed without stopping the system.... and without editing any code. To be honest, development of the code was 95% of the effort (and a huge chunk of the time) in developing the new system. Thanks for watching and taking time to leave a comment!
This is a very cool project. Thank you for inspiration. Hence I need to fit bikes next to the vehicle, I think about extending by another sensor and also display lateral distance to the wall. Thank you for your sensor comparison. For another project I tested ultrasonic senosrs. It was really disapointing (worse than your measurements). I expect that there were other ultrasonic sources in my test field... some cars passing at the road messed up the sensor toally... Might be that they had ultrasonic sensors... so be aware if you use ultrasonic and other cars passing by (or even your car has sensors). Also be aware: Wind and floating air produce white noise, which also contain ultrasonic. As I work with different sensors in my professional life, I also think about combining the two cheap (Ultrasonic and ToF)) ones for longitudinal measurement and the ToF for lateral... I guess this gives enough information, but will take some sensor data fusion. Now I'm really hyped by this idea... but I have some other projects which are more urgend. I guess this will take some time.
Thanks! And thanks for sharing your info on ultrasonic sensors. They have their place, but also their limitations. Note that if you want to add additional TFMini sensors, you'll either have to move up to an ESP32 (since the D1 Mini only has one available serial port), or flip the TFMini over to I2C... which can be done by sending it a command over serial. Thanks for watching... and for taking time to post a comment.
@@ResinChemTech 😀 Wow, thank you for your respond and the additional hints. They'll come handy. I have some D1Mini, RasperyPi PiCo (without WiFi) and some ESP32 waiting for projects... not sure if I might drom Wifi, keep verison with few pins or go for the big ESP32... so much possibilities those days ☺
This is a great project and may be my first foray into this platform. I'm curious if you have come up with a left/right corrector for narrow garages? ceiling mount would be best since walls are usually cluttered. That would be a useful upgrade.
I appreciate the kind words... and the suggestion. But please note that I've received a lot of different requests for 'upgrades' for the parking assistant, including use of an ultrasonic sensor, an ESP32 version and, yes, adding lateral left/right guidance (among others). While I would like to look into to some of these possibilities, it is a matter of time and priorities among other projects. I have given the lateral guidance some thought, and I have a couple of ideas... but I don't know when I'll have a chance to try them out and determine what, if any, might be the best path forward. if you are interested in knowing when I release an upgrade to the parking assistant, you can place a 'watch' on the Github repository. I may or may not publish something on UA-cam if/when I implement some of the requested changes. Or you can just pop over to the repo or to the related blog article, as I do try to keep those up to date with all the latest changes and new features. Thanks again for watching and the recommendation.
Thanks! I think quite a few people have successfully duplicated the project for their own garages... at least based on the feedback I've received. I didn't consider wireless and while I think it would be nice to eliminate the wiring and provide a little more flexibility in terms of where you could mount the controller and LEDs, it would also likely present a number of challenges. First, you would have to add a second ESP or other board to connect to the sensor. The sensor uses UART to communicate and doesn't have its own controller... it's just a sensor... so a second board would be needed to communicate with the sensor and then to transmit that data to the primary controller. I also suspect it would introduce at least some latency. When you are approaching the final parking position and if you have a very tight tolerance, any latency could be a very bad thing! Finally, if looking at using WiFi for communication between the sensor controller and primary controller, many people have weak WiFi in their garages (if any WiFi at all... I've already had requests to create a version that doesn't require or use WiFi). I suppose you could use something like Bluetooth or ESPNow, but that adds more complexity and my code definitely isn't designed to talk to another controller over any sort of protocol. So while a wireless sensor is an interesting idea, I don't think it would be practical with my current design. But I appreciate the comment... and the thought on how to potentially improve the system.
You could use an ESP for your original project, or Pi for the new version. The Pi certainly can have a web interface. You don't have to use Python for the program language either. But an ESP is the more logical choice, as the Pi is essentially a full PC in a single package with GPIO pins.
Yeah... I think my goal here was to make something that was significantly cheaper, since Pis are so hard to come by these days... and the LED matrix wasn't cheap either (at least compared to a short strip of WS2812b pixels). The matrix also requires 16 different wires/pins between the Pi and the display (not counting power), basically eliminating the possibility of using a D1 Mini. Yes, a lot could be done to improve the original version... such as adding a web interface for the settings. But the new version is a much lower cost and an easier to build solution with significantly less wiring. My Pi version still works fine and I will likely keep it, but I wanted to share a system that basically offers the same features, but others could build without shelling out the extra money for a hard-to-obtain Pi or a matrix display.
As I mentioned, using a Pi is overkill anyway for this type of project. As for your matrix, just use a WS2812b matrix which just like your new project would only require one channel wire, besides power and ground.
Great project and tutorial. I've built one so far for my wife's parking spot and she loves it. I'll hopefully get one built for my spot this weekend and then one for my Mom and my brother in law. One thought I had is that it might be nice if there was a way to configure it without connecting to a home network. I have a decent signal in my garage but I'm not so sure about my relatives. Could the captive portal have an option to just configure the device without on-boarding? Also, I had to connect to my 2.4 GHz guest network vs my main network (2.4/5 GHz combined with a password with a % character). The device sees the main network but won't connect. Bout sure what the issue is.
Thanks! And glad your wife loves it (that's always a good thing!). First, just a quick note about installing the second device on your network. Be sure you are using at least v0.41 or later for the second device (or both). Versions prior to this had issues with duplicate names on the network (it never occurred to me originally that someone might want to build more than one). v0.41 and later added support for multiple devices on the same network. Next, as far as your network.. yes, the ESP8266 boards only support 2.4GHz networks. I'm using a standard wifi library developed by someone else, and there have been some reports that either certain SSIDs or passwords have problems connecting (there are reports related to both length and special characters). In fact, I've had one user that could not connect more than once with a particular router, but another router with the same credentials worked fine. I am keeping an eye on the issues and fixes for this library and will update my firmware with any fixes that arrive. Not a whole lot I can do in the interim, other than write my own wifi library... which is beyond my current capabilities! I have an open issue on the situation here: github.com/Resinchem/ESP-Parking-Assistant/issues/13 so you might keep an eye on that as I'll post any updates to the situation there. Finally, as the firmware is currently written, a wifi connection is required to access the web interface and to setup the device. The initial onboarding process (to connect to the wifi) isn't sophisticated enough to handle all the settings, like parking distances, etc. Now, you could use another device to provide a temporary hot spot for joining and doing the setup and once the system was running, wifi could go away. But as soon as the device reboots (or say loses power), it will try to rejoin the previous wifi... and if it fails, it will start broadcasting its own onboarding hot spot again and wait. But this is certainly something I can take a look at... either modifying or creating a version that would work without wifi. I have other requests as well, such as lateral guidance, so I do plan to circle back to this project when time allows.
There are a lot of different ways to take this same concept and reconfigure it for different needs and uses. There are numerous other projects out there that do a similar thing, but many of them use an Arduino and a simply 'stoplight'... green, yellow, red. I wanted to try to make something with an ESP8266, add a countdown effect (instead of just jumping from green to yellow to red) and to provide a web interface that allows a lot of different options and settings so the system could easily be configured for different purposes without needing to edit any code. It won't be a fit for everyone, but it might work well for some as it is relatively easy to build (compared to some other projects) and doesn't require any coding to install or use. Thanks for watching and taking the time to leave a comment!
@@ResinChemTech I was being silly, of course, with the reference to a simple stop block on the floor. This is one of a million different projects i'd love to do, along with remaking my homemade CNC, connecting my irrigation and HVAC controls into a custom interface, constructing some ultra long battery life temp sensors, building a complete garage motor and sensors from scratch, etc. I may not need this exact thing you made (my garage is deeper, and has a workbench an other stuff that would prevent me from having a good mounting spot), but the components and design ideas are still relevant to thinking about other uses.
I think it might be a great Christmas break project. It doesn't take a huge amount of time to build and won't break the bank in terms of buying parts. Thanks for watching. If you do end up building the system, reach back out and let me know how it works out for you.
What a fantastic project! Thanks for such a detailed explanation. Between this video, your blog post, and the project documentation in your Github project's wiki I felt confident enough to build a couple of these on my own and I ordered the parts (using your affiliate links in your blog post) to make a pair of these. I now have everything wired up on my bench but I've run into the same issue as "loggki" reported on your Github's "Issues" page. I'm also getting the standby lights on my LED strip but my MQTT receiver is showing that all I get from the sensor is the default "192" distance. Since I now have a pair of the TFMINI-s sensors I tried plugging in the other sensor but got the same result. Doesn't the fact that the 8266 is booting up correctly and is going into standby mode mean that it's able to talk to the TFMINI-s? I'm assuming that if I had things wired incorrectly I wouldn't have gotten to that point but I could be wrong about that. I tried powering everything up without have the sensor connected and it wouldn't boot (just like you'd said in your article) so that's what makes me think that the sensor must be getting power and must be able to be seen by the 8266. Would you like me to post this in the "Issues" area of your Github project instead of here?
Thanks! I appreciate the kind words... and the fact that you read all the documentation that took me forever to write! But your comments did make me think of something that I might need to change in my firmware code. I guess I never really expected someone to build more than one of these. The hostname for joining the wifi is 'ESP_ParkAsst'. I did this to make it easier for folks to get the IP address in their router (as opposed to some generic ESPXXXXX). But I'm not actually sure what would happen if two devices with the same host name try to join the wifi network... I might ask for your assistance on that one to see what your router is showing. But I don't think that has anything to do with your current issue. Would you mind reaching out to me via email? Some problems just aren't conducive to troubleshooting here in the comments (or via Github issues). If you are on Discord, once we connect via email, we can jump over there for more of a 'real-time' conversation if needed. You can get my email address by going to the 'About' page of my UA-cam channel. There will be a button to 'view email address'. Note that some folks that are on mobile devices (specifically iPads) apparently don't see this button, so you might need to use a full desktop view. I'd share my email here, but I don't like to do so because it gets picked up by the spam bots. If for some reason, you still can't get my email address, follow up to this comment and I'll find another way to share it.
It certainly can, but the code would need to be updated with ESP32 specific libraries and calls. The code is freely available on my Github, so it can easily be modified to work with the ESP32 if that's what you'd like to do. Just out of curiosity, what would you expect to gain by using an ESP32? For this particular project, an ESP8266 is perfectly capable of processing the sensor readings, lighting up a few LEDs and handling the web/MQTT requests. This is the reason I haven't seen the need to develop a version of the firmware for the ESP32 as I didn't feel that it would improve the system in any manner. But if you do have specific reasons, you should be able to update the code relatively easily. Thanks for watching and taking the time to leave a comment. I do appreciate it.
Thanks for your reply. The only reason would be that I have a bunch of ESP32's hanging around. But since I'm not much a coder/programmer, I'll just stick to ESP8266 and the rest of the parts you have listed. Thanks again for all your efforts. @@ResinChemTech
After watching several videos about how to wire up LED light strips similar to the one you used, I've noticed the other videos used a resistor in-line between the ESP and light strip data line as well as a capacitor on the power line. I'm curious to know if you did not include these intentionally and if so, why?
I have found that with over two dozen LED projects, I have only needed a resistor in one situation and that was due to a very long data line run in parallel with the ground wire. You can certainly include a resistor and a capacitor to "smooth" out the voltage, but I've simply found that I don't need them. It is similar to the debate about the logic level shifter (e.g. the I2C-compatible versions begin too slow). There is theoretical and then there is practicality and what I can see with my own eyes. On paper, you could/should add a resistor to "even out" the data line and a capacitor to even out the voltage. But again, with one rare exception, I simply haven't added either and have had no problems. I've also not heard from anyone that had an issue with the parking assistant that they built it based on my design. But like with most DIY projects, there are multiple methods and techniques. Since my projects are generally targeted towards beginners, I try to keep them as simple as possible... and that means not adding things like resistors or capacitors unless they are truly necessary for functionality.
I store bikes and such in front of the car so I can't really use this but I have been thinking about a simpler version with just two sensors on the ceiling. I'll just be limited to not present, OK and too far of course. The upside is that only the LEDs would be visible on the wall, the rest is on the ceiling on top of the garage opener.
I actually have two of the ultrasonic sensors on the ceiling of the garage, one over each of the cars that I use for my primary vehicle presence detection. Ultrasonic sensors are great in this case, because the distance between just car and no-car is pretty big and the noise level really doesn't matter. But you could extend that concept to turn on LEDs when the car enters the measuring angle range of the sensor and detects the car. Thanks for watching... and taking the time to pass along a good alternate idea!
Ha! Actually the matrix clock displays the outdoor temperature, but since the garage is unheated, it was still pretty chilly the day that I filmed this. But good eye on catching that. Thanks for watching and taking time to post a comment!
I wonder if having a front license plate would help the ultrasonic sensor. It being a perpendicular flat surface. I would expect less variance, but have no clue if it would effect the range.
I don't think it would impact the range... unless it was bejeweled or something that would tend to scatter the signal. Honestly, the curved front end doesn't make a huge difference unless you get really far left or right of the sensor. Since I have the actual parked distance in Home Assistant, I've been able to watch the actual measured difference when my wife parks her car. It might vary by an inch or so if she is a little to the right of center... but the 1" still puts her well within an optimal parking spot. I appreciate the suggestion.. and thanks for watching. I really just mentioned the curvature to explain why all 3 sensors in my testing didn't 'exactly' match the measured difference... and that you might see some slight variances as well.. but nothing that should have a major impact... unless you only have a couple of inches of clearance for your parked car.
In a two car garage set up, could you put each system in front of each car without issues? Or would there be a way to run it all on a single D1 mini with 2 separate sensors and 2 light strips? Perhaps, in a future version, you could have an audible sound (via bluetooth speakers) as you approach!
Yes, starting with version 0.41, multiple systems can be installed (e.g. one for each car... for as many total cars/parking spots you might have). You just need to assure each system is given a unique name when setting it up, and provide a unique MQTT topic for each if using MQTT. This is all covered in the Github wiki for the project. As far as adding sound, I have numerous requests for enhancements to the system... and a buzzer or audible tone is among those. I did provide some updates and a couple of new versions a few weeks ago, but honestly I don't know if or when I might have time to consider additional requests. Of course all my code is available, so it could be cloned or forked and those other features could be added by you or someone else. I just can't make any promises as to when I might be able to provide any new features.
Correct. It would probably require an ESP32 and pretty much an entire rewrite of the code to be able to share one MCU between two sensors and two light strips. As written each system is independent, with its own web interface and settings. The only thing you might currently be able to share would be the 5V power supply (running separate leads to each system) as long as it was able to provide enough current to power both systems.
Nice project. I keep threatening my wife to hang a tennis ball in the garage because she always pulls in too far. She's very resistant to that idea. I tell her that mostly to tease her, but the WAF (wife approval factor) is a big part of projects like this. I'm curious why you didn't put the LIDAR sensor in the box with the controller, and have it off to the side on a whip? Seems like it would be pretty easy to include it in the box, and would reduce the clutter on the wall.
Thanks! We used to have the tennis balls on a string too! But I hated them because it seemed like when I had the cars out of the garage to work on a project, they'd always get in the way. I'd either bump my head into them, or swing an 8' 2x4 around and catch the string, yanking them off the ceiling. And of course, you can't integrate a standard tennis ball into Home Assistant for vehicle presence! To be honest, this was really just a temporary install that I did for the video. My wife is happy with the old Pi version, and there's no real reason to replace it, as it still works well. And that particular spot on the wall I used doesn't work for either of our vehicles either... again, it was just done for the video or my wiring runs would have been much neater (requirement for the WAF!). But the idea to include the sensor in the same enclosure to reduce wiring is a good one.. as long as the D1 Mini doesn't cause any sort of interference with the TFMini. Not likely, but I didn't test it either.... wifi and EMF can play havoc with some sensors. Finally, I already had an enclosure designed for the current controller and I was both too lazy and spent too much time on designing the firmware, testing distance sensors and writing both the blog and Github wiki pages to create a new case design! But the overall install could be made much neater in a number of different ways. This one will probably come down and the parts will be reused for some future project. I may actually mount it right over the Pi display for a while and see if the wife might like this version better, but she probably won't! Thanks for watching and taking time to comment! For us, anything that got rid of the tennis balls yet still provided parking guidance was an improvement (and adding Home Assistant integration was a bonus for me!).
Great project! So. Very first time I have ever tried to put something together like this, I have followed the blog/vid instructions but since some of the steps are assumed I need some guidance please. I almost have all the connections soldered. I have some questions: on the following steps- "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. that connection" , this is a onboard connection and does not solder to anything else?" And Step 6. "There's one final onboard connection to make, and this is done on the underneath side of the board.- It looks like you have soldered all those 5v rail connection's together send then did the same with the Neg rail, is that correct? Last thing, you did not really explain how you put the ESP and the LS on the board- What I am asking is, Yes I can see you placed them then soldered each connection but am I supposed to connect any of the other wires I have soldered so far to those components or will the connections already made, make it all work? Thanks for any help. I assume since this is a "circuit" board that kinda answers my question (DUH) but I want to make sure :)
OK... I'll try to help out here as best that I can, but I'm not 100% sure I fully understand a couple of your questions... and I don't want to steer you wrong and have you connect something that results in smoking the ESP or something else! I'm guessing the step numbers you are referring to are from the blog article. 5 - Yes, you are correct. In this case, you are using an onboard connection, basically to connect the GPIO pin (D6) to the LV4 on the shifter. You can use any available hole in the ElectroCookie board for that is connected to the desired pin by the vertical traces on the underside of the board. Look at these traces and it is pretty obvious that they are electrically connected. For example, if you look at "column 5", any thing wired into rows A-E will be connected together. Same for column 5 and rows F-J. So, for this step, you just want to run a wire that connects the D1 Mini D6 pin to the logic level shifter LV4. 6 - What I am doing here is creating a voltage bridge to help with the higher current that the LEDs can draw. The traces on the ElectroCookie are pretty small and are not rated to carry much current. By adding some wire, I'm helping to deal with that higher current. Now, if you are not going to run the power from your LEDs through the board and are going to run 5V and GND in parallel to both the LEDs and the controller board, you do not need to add this extra wiring. As far as your last question... see the answer to number 5. When you solder the D1 Mini and LLS to the board, they will be automatically connected to the wiring that is soldered to any of the other columns connected by the traces on the ElectroCookie board. This is exactly like a breadboard where things plugged into the same "column" (on each half of the board) are wired together. I hope this helps. Let me know if you have any follow up questions... or when you get the project up and running!
@@ResinChemTech Thank you for the quick reply!! YES that helps greatly and I think I can move on now, you told me what I figured the answer was, I just am being over cautious since this is my first project!
Thank you for the awesome video, by any chances adding a buzzer which will have intermittent beep when red while long beep when red flashing just a like a parking sonar？
That's an interesting idea! I added a buzzer to my matrix clock countdown timer that would work similar to this. I did find that I needed to add a 5V step-up converter to boost the 3.3V signal.. as the buzzer was too quiet and weak at 3.3V. The code changes would be pretty trivial for this (although I'd probably want to add options in the web settings, which gets a little more involved). I will definitely add this to the list of feature requests for this project... but I can't say for sure when I'll have a chance to work on it based on other current projects. But thanks for watching... and the suggestion. It is an interesting one that no one else has brought up.
The LEDs will automatically turn off and the system will go into sleep/standby mode after the active parking time expires. The active parking time is a time that you specify in the options. You can see all the available options and settings here: github.com/Resinchem/ESP-Parking-Assistant/wiki/05-Using-the-Web-Interface I tried to build the system to allow it to be customizable via its web interface so you can tailor it to your particular needs.
Wonderful idea, thank you for all of your hard work! I built the project hardware, but when I load the FW, I get this behavior: I can connect via Wifi on the ESP_ParkingAsst SSID, and then set the local network SSID normally. After that, a reset causes the the device to show up in the local SSID network on my router's list for exactly 1 minute, then drop off and go back to creating it's own SSID. During that 1 minute, the device does not respond to HTTP requests or PINGS on the IP address my router shows it has. I bought the Wemos D1 Mini's off EBay, and assumed that this was the problem, so I bought more directly off of the Amazon link above, but get the same behavior on all devices I try. I tried loading the libraries to debug myself, but am getting a ton of warnings and an error. I am using "Generic ESP8266 Module" and loaded WifiManager, ArduinoOTA, ArduinoJson, TFMini-Plus libraries from the locations / authors you referenced. I also added FastLED from Dan Garcia and PubSubClient from Nick O'Leary (my best guess). Anyway, the errors are not missing *.h files, but mostly warnings about using the keyword Register. Here is the Error where is stops compiling: Compilation error: 'D6' was not declared in this scope. Thanks in advance btw!
Sorry for the delay.. for some reason UA-cam threw this in the "held for review" bucket due to 'blocked words'... no idea why, but I just now saw your message. Well, one think I know for sure is that if you are compiling for 'generic ESP8266', then you cannot use "D" numbers for the pins... you must use the actual GPIO number. Are you using the latest version of the firmware (v0.43), because I believe I changed the pin numbering to no longer use the "D" numbers to give greater compatibility with ESP8266 boards... other than the D1 mini. I know you said you were using the D1 Mini, but it you are using the D pin designations, then you must select the D1 Mini board for the compile. My gut tells me that the board is bootlooping due to this 'invalid' pin number (even though it compiles). Let me know what version of firmware you are using... and try the latest versions... 0.42 or 0.43 (you might try both) and see if that resolves the issue. If not, drop me another comment here and we'll troubleshoot a bit more.
@ResinChem Tech I really appreciate the reply, I have tried the .42 and .43 bins with the same result. I have not gotten the compiler to work yet, I'll look for the D1 Mini option. There are small differences in thr board silkscreens, and I suspect even the ones I got off Amazon may be an off brand. The parts report ESP8266EX when loading the bins, but from what I have read all but the very first run say this, so I don't think the EX has any significance.
If want to try compiling with the D1 Mini, I originally used the LOLIN(WEMOS) D1 R2 & mini board option in Arduino. But if you are using .42/.43 then there should not be any references to "D" pins anymore... just the GPIO number. I don't think the "EX" has any affect here, as I'm pretty sure that's what mine say as well. There is a possibility that you do have some sort of bad clone or batch of boards... but I'd like to rule out some other things before assuming that's the issue. If you like, could you reach out to me via email? There's only so much troubleshooting that we can do here in the comments. You can get my email address from the "About" page on my UA-cam channel. I don't put it here in the comments to avoid the spam bots from picking it up. I'll do my best to help you figure out what's going on... but we are just somewhat limited here in the comment section. Sorry you are having the issue. I do know that many people have successfully built the system, so something different must be going on here.
@@ResinChemTech Ok, progress! I got it to compile and turned on SERIAL_DEBUG. The behavior causing the problem is that, for some reason, wifiManager.autoConnect is returning FALSE even though my router is showing the device is connected to my home SSID clear as day. One time I did get "connected to your wifi...yay!" and everything including the web page worked perfectly for one glorius run! Then back to the old behavior upon restart :( All the parameters I set on the web page are stored perfectly still on boot. Wife is fussing, will investigate more later!
There must be some goofy interaction between my router (a really nice new Asus RT-AX86S) and the Wemos D1. The D1 connects about once every 20 times to my home SSID which is very close in proximity. It actually connects every time according to my router, but the autoconnect returns fail after a timeout. I disabled the wifi and the device works perfectly, my wife is very happy and so am I, thank you again!
Considering all, price included, TF mini is wrong choice. Ultrasonic is way to go. Heck, even ultrasonic and ToF TOGETHER and while averaging out distance is WAY better and safer because you can have redundancy for way less cost...
As I've mentioned to others, my source code is freely available and you can swap out the TFMini and related libraries for an ultrasonic or ToF sensor if you prefer to use those sensors instead. For me, neither of those other sensors work due to the fact that the sensor has to be placed very close to side wall due to an entry door. The FOV for both of the other sensors are too wide and the simply just report a consistent distance of the side wall. I choose to spend the extra $30 or so for what I consider a better and more reliable sensor, at least in my case. But you are free to substitute your own preferred sensor and modify the code (or write your own).
This a great update to the original version and I would love to build a couple of these. Do you have a ESP32 version of the code? Also maybe add a metric/US units switch on the interface for the rest of us?
I might consider an ESP32 version at some point if I have the time, but I can't promise when that might be. From my end, it then means I have to maintain and support two different versions of the code (the ESP32 requires different libraries and uses a different file structure, so it's not really feasible to have one code set for both ESP types). Just out of curiosity, why do you want to use an ESP32 when an ESP8266 has plenty of 'horsepower' for this particular project... and costs more as well? As far as the metric vs. imperial units... internally within the code, everything is done using millimeters... the values are simply converted to inches for displaying on the web interface, as the majority of my subscribers are in the U.S. It's really just a matter of taking out the conversions (divide by 25.4 to display on web, then multiply by 25.4 when taking the web entries and converting back to values for the code) and changing the labels on the web page. I could consider adding some sort of switch or option like you mentioned.. and I may do that at some point. But the source code is available in the repository, so you could easily fork the repository and modify just a few lines related to the web page to make everything millimeters or centimeters if you like. Or honestly, since you will only setup the distances one time and won't change them (unless you change vehicles), it might just be easier to take your measurements in centimeters and use an online calculator to convert to inches the one time you have to set up the zone distances. That's how I initially testing the program... I measured in inches, used an online calculator to convert to millimeters and entered that into the code. I would understand if you were having to enter distances all the time... but it's really just when you are initially setting up the system that you need to enter the distances and would need to do the conversions. But I appreciate the feedback... and will certainly consider both of your recommendations. But when I might have a chance to do so depends on my other project loads and finding the time to make those changes, so I do not know when I might be able to make these kind of requested updates.
I have started to get parts for this project. but i see some newer models of the lidar?MIni-I , worth the extra money? you should do a video and test them heh..also is there a diference in v3 and v4 of d1 mini? thanks.
I'm not familiar with any newer versions of the actual TFMini-s. I can tell you that the firmware has been tested and should work with boards that have either v1.4 or v1.8.1 printed on the back. It should theoretically work with the TFMini-Plus, but I haven't tested it. The Arudino library used is pretty specific to the TFMini (and the communication format for the TFMini is pretty specific too), so it is highly unlikely the existing firmware would work with any other type of LIDAR sensor... at least not without updating the libraries and possibly the function calls to get distance. Unfortunately, I don't believe there is a library that would work with all LIDAR sensors... so in my case, I opted to use the TFMini-s. You can always try another sensor (like the TF Luna... or one from a different manufacturer), but I almost guarantee that you will need to modify the firmware to make those work. As far as the v3 vs. v4 of the D1 Mini... I believe the code should still work, but again haven't tested the newer v4. I have quite an inventory of D1 Minis, so probably won't pick any of the v4 up until I've exhausted my current supply. Yes, there are some minor hardware changes (beyond the USB C), but I don't believe there is anything that would cause the code to not run. If you try one and find out that it does or doesn't work, please drop me a note to let me know what you find... and I can share that info with others in the Github repo.
Yeah... me too. Which is why the very first line of the video description says: "Get rid of that old tennis ball hanging from a string in your garage". The tennis ball is definitely an easy low-tech way to accomplish basically the same thing. But what fun is that? For me, I got tired of banging my head into that tennis ball... or catching a 2x4 on the string when working on a project in the garage. And of course you can't integrate a tennis ball on a string into your home automation system to use as a vehicle presence detector. But it is cheaper to make and easier to install!
You are most welcome. This has been one of my more popular projects and I've heard from a lot of folks that have built one for their own garage. It is definitely one of my wife's favorites! Thanks for watching and taking time to post a comment.
Super project 👍 short question: do you have to connect (+) and (-) left and right on the breadboard (loop through)❓Am Wemos D1 gets but then the connection 3V3 also then 5 volts from the power supply or ?
Thanks. Well, it's probably easier for you to look at the wiring diagram in the related blog article ( resinchemtech.blogspot.com/2022/11/esp-parking-assistant.html ) than for me to try to describe it here in text, because I can't post images in the UA-cam comments. But if I understand what you are asking correctly: 5V is fed to the power rail on one side and the D1 Mini 5V and GRN connect to this to get its power. The other power rail is 3.3V and is fed by the 3V3 pin from the D1 Mini. Only the ground is connected between the two power rails. The 3.3V on the one side is only there to power the LV side of the logic level shifter. Do not connect 5V to this second rail or you will likely destroy the D1 Mini. Again, it will probably make more sense when you look at the wiring diagram in the blog article. But if you have additional questions after reviewing that, just let me know.
Yes. The code, along with all the details on how to install it and use the web interface is found in the Github repo, which is linked both in the video description and in the related blog article which I linked to above.
Can I ask why you'd like to see this on an ESP32, when the firmware runs just fine on the ESP8266? What benefits do you expect to get from the ESP32? I suspect it would function exactly the same. I only ask this because to create a version for the ESP32, I would have to change multiple libraries and rewrite a good portion of the code. It would also mean that I would have to maintain two separate versions of the code moving forward (an ESP8266 and an ESP32 version). That is a fair amount of work, so I'm trying to understand what benefits an ESP32 would actually offer.
Thanks! Long story behind the chicken and why I use it for my channel... but I appreciate the kind words. Funny, but no one has every really mentioned the chicken or asked about it before.
Well, it's not quite as cheap and easy as a tennis ball on a string. But I won't bump my head on it all the time when working on projects in the garage! And I can't integrate a tennis ball into Home Assistant. Thanks for watching and taking time to leave a comment!
The wake distance has a max of 192 inches. It seems to be hard-coded to that. Is there a reason you made it max out at 192? I would like to make it around 250 but do not see an easy config value to change.
The issue is that when the TF-Mini is 'out of range' it returns an error code instead of a distance value.... which would cause all sorts of issues with the logic (and safety). I found the maximum reliable distance in my testing was around 200" (16.6'). To be sure that an error code wasn't returned, I set the maximum distance to 192", or an even 16 feet. If you are using MQTT, you'll also see the max distance reported as 200" when no car is present. This basically means the measurement is 'out of range' of the TF-MIni and it returned an error code instead of distance. You can certainly try increasing the maximum by removing the limitation on the web page in the code. But you would also have to take steps to handle error return values of something like 32,156 (I don't remember the actual code). You might get away with increasing the limit to 200 (but may still get occasional error), but I think you will have issues with error codes if you try to increase it all the way to 250. I decided to limit the max to 192 (16') as a safety precaution and to assure the application was reliable. But the source code is freely available if you'd like to try increasing the maximum value.
Interesting. Course my grandfather hung a tennis ball from the roof so his wife could park perfectly by just stopping when the ball touches the window.
Yeah.. I mention the tennis ball on a string in the very first line of the video description... and it has been brought up by others, along with numerous other "simple" ways to park a car. I used to have a tennis ball on a string in the garage. But I wanted something that was out of the way when working on projects (and not bumping my head into it.. or catching the string on a 2x4). Plus I wanted to integrate it into Home Assistant so that I could use car presence as part of other automations. That's something you really can't do with a tennis ball on a string. And for me, I already had all the parts left over from other projects, so why not! But it's not for everyone... and that's fine. For some, a tennis ball on a string is a very low cost and reliable way to go.
Is this also available in Centimeters? For worldwide replicas except US. Feet, inches and so on have no meaning for me. I think if I replaced 25.4 with 10 everywhere it would have to be cm. "# define" can be used for this.
As I mention in the Github wiki, internally the application actually uses millimeters. The distances are simply converted to inches only for the web interface display (and they are converted back to millimeters when the settings are updated from the web page). Removing those conversions and changing the labels on the web page are pretty trivial matters and I can consider releasing a "metric" version if and when I have the time and opportunity. Or, of course since the source code is available, you are also free to fork the repo and make those changes yourself. To be honest, since the distance settings would rarely change after initial setup (unless you move or get a new car), it would generally just be an simple one time use of an online calculator to do your measurements in cm or mm and convert them to inches for entry in the web app. I wouldn't mind offering a metric version, but it then gives me two different code sets that I have to maintain and update every time I make a fix or add a new feature... the imperial version and the metric version. Honestly, I wish the US was officially on the metric system like most of the rest of the world. But unfortunately that isn't the case. And since the majority of my UA-cam viewers are US-based, I opted to use the more familiar inches for the application. But I will certainly add a metric version to the list of requested features. I just can't make any guarantees when I will get to it with other current project loads.
I just wanted to follow up on this. After your request (and a few others), the latest release (v0.41) now has the option to show and enter all parking zone distances in either inches or millimeters. The setting can be toggled on the main web settings page and saved as a boot default so that the web application will always use your default unit of measure preference.
Is it possible to build this with a normal HC-SR04 sensor? I have tried different ones and different D1 mini's, but cannot get it to work. The system starts and the LED goes full blue, then the red/green alternate, followed by the outer most LEDs being blue, but no matter what, it is like the sensor is not even connected? I have the HC-04SR Trig connected to TX on D1 mini and Echo connected to RX on the D1 mini.
You'd have to modify the firmware. The firmware is written to work with the TFMini. Using any other type of sensor would require changing the libraries and logic to get a distance reading. The system is going straight into sleep mode (two blue lights) because it is not getting a valid distance reading.
Yeah... the TF Mini does cost quite a bit more, but as I covered in the video, I think it is worth it in this case... both for range and signal stability. I think someone may have forked my code and made it work for the HC-SR04, but I really didn't want to maintain two different versions of the firmware, so I'm only going to continue to provide updates and fixes for the TF Mini version. Glad you got it working... and thanks for letting me know!
How do you get an MQTT device created for this in Home Assistant? I entered all the relative MQTT info in the webpage setup for the parking assistant but I don’t see a device on my MQTT page in HA. If I use MQTT Explorer I can see the device there, so it is communicating properly.
Did you create the MQTT sensors in Home Assistant? These are not automatically created (yet... it's something I'd like to add if/when I get the time). Currently, you must manually create the sensors. See the examples here for how to create the sensors: github.com/Resinchem/ESP-Parking-Assistant/tree/main/examples
I like this project, will keep wife from banging into wall or leaving car too far out and getting hit by garage door when it closes. Now, if only I can have something guiding her out so she doesn't rip Sideview mirror off car when backing out or in. Haven't had a car in a while that has both Sideview mirrors. She's not allowed to drive new car into or out of garage.
Yeah... another viewer caught that as well. It was a mistake when I was converting from mm to inches. The minimum is 50 mm and should be listed as ~ 2". I'm in the process of posting a correction on the video now. Thanks for catching the mistake.
The antenna is integrated on the D1 Mini PCB. I have the controller in a 3D printed (aka plastic) enclosure, so it should not interfere with wifi reception. As long as you have a decent wifi signal in your garage, the controller should not have any problem using the built-in antenna. In my case, I do happen to have a Unifi PoE access point in the garage, so wifi signal strength is not an issue. But if you have any other wifi devices in your garage (like a smart garage door opener) that are able to receive a wifi signal, then this device should not have any issues connecting.
I was considering something like this myself, even though I have sensors front and back on the car, they're too conservative in the car for the required distance I need to be from the garage wall. Do you think the ultrasonic sensor would interfere with the cars sensors, or vice versa?
My wife also has the front sensors and I haven't noticed any interference with the TFMini LIDAR sensor. I have not tried ultrasonic sensors, basically for the reason I cover in the video. The nice thing about the TFMini/LIDAR is that the field of view is very narrow. So, if for some reason there was unforeseen interference, it should be possible to place the TFMini sensor in such a way as it is pointing an area of the front of the car without the sensors. Again, I haven't tested with ultrasonic, but I haven't seen any sign of interference using the TFMini/LIDAR (and the original Pi version uses the same sensor and has been in use for over 3 years).
Love the project wonder if it would work with a long range ultrasonic and a short range to 20$ in parts vs 40$ I may download and tweak if you don’t mind another fork?
Go for it! I have numerous reasons why I don't want to add an ultrasonic version to my project. Personally, I'm very happy with the TFMini and need its narrow FOV due to the sensor placement in my garage. But mostly, I plan on further enhancing this project when I have time, possibly adding lateral guidance as well... and I just don't want to have to update and maintain multiple versions of the project. So, while I might add something like ultrasonic for a side sensor for providing lateral guidance (not sure yet), I have no plans to modify the current version... or create a new version... that replaces the TFMini primary front sensor with any other type of sensor. But if someone else wants to fork and make a version that works with ultrasonic, or some other sensor or combination of sensors, that's fine by me. In fact, if you get a working version, I'll happily provide a link to it on my page pointing folks that feel they need or want to use ultrasonic to that repo.
You could certainly add either. I've used both a 1000uF capacitor on the 5V supply and have also added a resistor on the data line (mostly with a long parallel run next to the ground), but I also have a lot of LED installs where I've used neither without any impact. So, it is somewhat of a personal choice. You can add either or both if desired without impacting the project.... but it generally also works fine without either option, especially for a project like this one.
I would love to do something liket this but then i have never done anything like this so I would assume it's not a great project to sort of jump into eh ;)
Actually, it's really a pretty simple build and isn't a terrible first time project to try. My related blog article ( resinchemtech.blogspot.com/2022/11/esp-parking-assistant.html ) has wiring diagrams and step-by-step build instructions. Then the Github repository wiki where you get the firmware code ( github.com/Resinchem/ESP-Parking-Assistant/wiki ) has full details on installing the software and how to use it. The only challenging part might be soldering if you've not done much before. But you can even try creating a version on a breadboard first with just jumper wires (the blog shows an example). Then the only thing you'd have to solder are the leads to the LED strips. And if it helps, check out my channel and I also have an introductory video on using LED strips that could be helpful with that step. But this project would be both a good introduction to using LED strips and microcontrollers. And, as always, I'm here to help and offer any assistance that I can if you have questions!
The ESP8266 is always on... but the LEDs can be set to turn off completely when in standby. The idea to only turn on when the door opens is a good one... but there is some delay in the boot up process for the controller to join wifi, setup OTA updates, spin up the web server, etc. It could be anywhere from just a second or two... to 10 seconds or more depending on your wifi and how quickly the controller is able to join. But it probably takes at least that long for the overhead door to open anyway, so it is a viable option. Of course, if the controller is "off" it won't be available to respond to a "wake up" command. It would probably require an ESP32 running deep sleep and some kind of switch connected to a GPIO pin to wake it. The other option is a smart outlet or switch that would supply power to the controller... and automation would turn on the outlet when the door opens. This could be done with the current firmware. Any other options would likely require mods to the firmware. For me anyway, the ESP controller and the two pixels lit at the end of the strip (which again, can be disabled via the web options) draw such little power, I'm not sure much would be gained by the time you add other components like an RF reader, reed switch and some sort of controller for the overhead door, etc. In fact, the external components required to turn off the parking assistant might end up using more power than the parking assistant does when it is in standby mode. Lots of ways to tackle it if you truly want to power down the system when not actively in use. I appreciate you sharing the idea.
The average power usage of the tf mini s is 700mw. Is there a stand by function? For my use case it would be nice if there were a option to activate the tf mini over mqtt when the garage opens and deactivate when closed.
To my knowledge, the TFMini does not have any command to turn it off or to put it into any sort of low power or standby mode. A possible solution would be to add a DC relay to the controller that would kill the 5V feed to the TFMini and use a pin on the ESP to control that relay... enabling it when the door opens, then disabling (or shut off) the relay after whatever time or other event you determine. But to be completely honest, at 700 mw, that works out to about 0.0168 kWh per day, running 24 hours a day, if my math is correct. That's around 6.1 kWh for an entire year. I know energy costs are different in different areas, but here in Indiana it is about $0.12 / kWh. That means the TFMini, running 24 hours a day for a full year would cost about $0.75... yeah, 75 cents for the year. It would probably take you 6-8 years to recoup the cost in savings that you'd spend for a relay to shut it off.
Yes... and the cost of the ESP8266, which also runs continuously at an average of a few hundred milliamps as well. Then the LED power is very dependent upon both the number of LEDs and the brightness level they are set to. But even with these, I would still say that the entire system, operating under "normal" conditions, such as a car departing and arrive a few times each day, would not cost more than a few dollars a year to operate. If overly concerned about energy usage of the system, then you might consider a different option, such as a tennis ball hanging from a string, which provides the same basic parking guidance and uses no electricity at all.
So I got all your stuff working on a breadboard but hes my problem. My wife backs up. So I want the lidar on the wall in the "back" of the garage, but the light strip on the wall in the "front" of the garage (so she can see if if she looks out the windshield as shes backing up). Any way to modify it to be one D1 mini connected to the tf mini and another one connected to the light strips? I'm assuming running data wires 30 feet from the front of the garage to the back would be too far. Also, is there anyway to get deeper integration into HA? Cause I work in the garage, so I dont want the lights blinking everytime I walk in front of them. I was thinking I could put in logic to say if the garage door is closed, then dont turn on. ONLY turn on when the garage door is open. I see your have MQTT settings in there, but I dont see a way I could actually "control" the D1 mini from HA.
Well, there are a number of possibilities, but some would require that you make pretty substantial changes to the code. To use 2 D1 minis, there has to be some way for the one connected to the LIDAR to communicate to the one connected to the LEDs to tell it which LEDs to light up. MQTT would be one option, but it would need to update rapidly and the LED D1 mini code would have to be rewritten to subscribe to the MQTT topics (currently the code only publishes MQTT). It might be possible to use Home Assistant and automations as a "middle man" for communications between the pair... but again, significant code changes would be needed on both ends. As above, you can't afford any significant delay in the communication or the driver would risk overshooting the parking spot because the LED strip didn't update fast enough. You might try a bench test and see if you can get a decent signal to the LEDs from the controller at 30 ft or so. With the logic level shifter on board, the data signal may be OK (I'd use larger wire, like 16 or 18 gauge to minimize voltage drop). Similarly, you'd probably want to run the power wires for the LED (+5V, GND) directly from the power supply and not via the board (so run 5V in parallel, with one run going to the controller and the other running straight to the LED strip)... again using the larger gauge wire. Run the long wires between the controller/power supply and LED strip... not between the controller and LIDAR (in other words, keep the controller at the back with the LIDAR). I've had run lengths of around 20 ft. between the controller and LEDs work. If needed, there are signal boosters you can install along the run to the LEDs to up the voltage back up to 5V if needed. Quindor over at QuinLED sells one: quinled.info/quinled-data-booster-for-sale/ You could also use a couple of sacrificial LED pixels along the line to boost the signal, but you'd have to slightly modify the code to not include these pixels in the count process.... this would be a more minor code change than the other options. If you can get a successful wiring run between the controller at the back and the LEDs at the front, that's going to be the easiest solution. Anything else will require pretty substantial modifications/rewrites to the the current firmware code. Let me know if I can help out any further.. or if you do get it to work with a long wire run.
@@ResinChemTech Thanks for the thorough response. Couple comments/questions... 1. I tested with 36ft of 18 AWG stranded. It seemed to work OK, but when I had the LED's on solid red, they would flicker once in a while. I checked out those boosters but they are sold out. How would I use sacraficial pixels? Would I say, put one pixel between the 36ft run, so at 18 ft, connected +,- and data wire to each end of the pixel? Or would i just need to connect data wire? 2. What are your thought on splitting the difference between the LIDAR and the LED's? So put the box with the D1 somewhere in the middle, run say 10ft of cable to the LIDAR and then 26ft to the LED's? 3. If I went the sacraficial pixel route, but you be able to assist changing the code for however many pixels I needed to use? I guess thats gonna determine if I do that, or wait for the boosers to come back in stock.
As to #1, you are correct.... you would connect all three wires (+5V, gnd and data to the single pixel on each end). Each pixel automatically boosts the data line to 5V before passing down the line to the next pixel... so it acts just like a logic level shifter. Just be sure to observe the data direction (data arrow) on the pixel. If you try to pass the data signal through the sacrificial pixel in reverse, the signal won't be passed on at all. 2. You could certainly try putting the controller in the middle, but I have no idea how sensitive the LIDAR module might be to voltage drop... with either the power or the I2C signal. The spec calls for a voltage of 5V +/- 0.1V. But I'd probably be more concerned about the data signal. All I can say is to try it and see if you still get consistent results. 3. If you just need one sacrificial pixel, you might be able to get away with the code as it is... just include that pixel in the total LED count. It might mean that the 'center' of the LED strip would be off by one pixel. The sacrificial pixel will light up as part of the motion... but you may be able to live with that... and if using the 'standby' feature where the first and last pixel are lit when in standby, the sacrificial pixel will be lit (since it is technically the first pixel), but that feature can also be turned off via the web app. Again.. try it and see if it is acceptable for your use case. Having one pixel on the ceiling (or along the wall depending on how you are running the wiring) that lights up when the system activates may be OK if you can live with it. I'm just not sure if or when I might have time to modify the code for you, if you are unable to do it yourself. It's not that I'm unwilling, I just a number of my own projects that I'm working on... and I'd also have to build a system using a sacrificial pixel that I could use to test the code changes, as I currently don't have a system built like that. But I'd definitely try the sacrificial route and see if you make it work acceptably, as opposed to waiting on if/when they might be back in stock and paying the extra money. Let me know how it goes... and if you get the sacrificial pixel to work if you go that route.
Thanks for sharing the video! I love to see how others implement some of my projects. Although I am a bit jealous of how clean your garage is... but you can keep all that snow! And thanks for the shout-out and credit! I haven't used one of those Falcon F-amps before. In fact, I wasn't even aware of them. But it's good to know about them since the Quindor version I recommend is often out of stock. I can throw these out as an alternative now as well. As a side note, I wanted to ask if you have a Discord account. I started a Resinchem Tech Discord server a few months ago, but right now it is a small group of folks by invite only (I'm not ready to open it up to everyone yet). But there is a good mix of some beginners (to Home Assistant and DIY electronics) to one or two that are pretty advanced. We chat about various projects (or sometimes just misc topics), help each other out when needed and I will often ask for feedback about upcoming videos. If you have a Discord account and are interested, I'd love to invite you into the group. I would just need to get your full Discord handle (e.g. name#nnnn). If you prefer not to post it here in the comments, you can send it to me via email, which you can find on the 'About' page of my channel. Once I have that, I can send you an invite. No big deal if you aren't interested, but I think you'd be a good fit with the folks that are a part of my server.
Any thoughts about a location where you can't mount them directly in front? The upper corner of the room is an option, but that obviously creates some issues
About the only thing I can think of if the sensor has to be mounted to the side or overhead would be a simple "stop" style for the LEDs. There wouldn't be any approach or countdown, but when the car reached the spot where the sensor sees a drop in distance, it could turn the LEDs on. There would also be no backup... in essence, you'd be reduced to a single "zone"... the park zone, as opposed to the 4 different zones when the car is approaching the sensor straight on. This particular system would work in that manner (I think), but it would simply go from the standby mode directly to the parked zone, with no wake or approach along the way.
@@ResinChemTech yeah. That's what I was thinking. Unfortunately there is just no practical way to mount a sensor on the opposing wall in my garage. Thanks for the feedback
The question is whether the ToF would have a stable enough signal. As shown in my testing, the ToF was already the noisiest signal, bouncing around by up to a half inch even when only 12" from the source. I've noticed that as well with the ToF sensors I use on my stair project (although the noise isn't an issue for that particular project). So, it's not just the range, but the stability of the signal... you don't want the signal bouncing around as you approach the final parking zone. The TFMini-s/LIDAR sensor was by far the most steady, consistent signal at all the tested distances when compared to both ToF and ultrasonic. And of course a ToF sensor would not work with my firmware, as it is specifically written for the TFMini-s using the serial port. But my code is available on Github, so if someone wanted to modify it to work with a ToF sensor/I2C, they are certainly free to do so.
@@ResinChemTech You are right - they can be a bit noisy. However there are two things that are relevant but maybe not considered. 1) use a running average to increase the SNR or even use two ToF sensors (that clears up the visual feedback noise) 2) half an inch is insignificant on something with the physical characteristics of a car. It moves too fast with too much momentum / poor contrrol feedback and the front isn't completely flat. Do you really need to position it to less than half an inch? I would suggest that almost no-one does. So my comment is some thoughts for people to minimise the cost. I always try to minimise the energy usage - just because it is part of the mental challenge of my projects. What might be quite fun is to use the "new" microwave presense detectors that are a few $. Nice project, BTW!
Hey... no problem. I always appreciate ideas and recommendations. I guess I just said what I said because I wanted to state why I picked the sensor I did (my wife's final parking spot is almost 3 ft from the sensor... don't know how much noisier the ToF might be at that distance) and she actually does have a pretty short range for her car to fit just right... (but it is more than an inch!). And my sensor is placed relatively close to a side wall and the larger FOV of the ToF might be an issue (but I didn't test). I also didn't want anyone to think they could just drop in a different sensor or sensor type and get my code to work (and yes... I've gotten comments from those that have actually thought they could). Others have said they built something similar with an ultrasonic sensor and it worked fine. That's the great thing about DIY... more than one way to tackle a project. For me in my situation, the TFMini was the best choice. And like you, I'm always looking to minimize costs. I've received requests for this project, and others, to create an ESP32 version. And my point is always, why? If the ESP8266 is adequate for the job, then the ESP32 is overkill and you are spending extra money for basically nothing. No one has given me a good reason other than they already have an ESP32 and don't have an ESP8266. But I do appreciate your comment and recommendation. If folks can build a similar system with a ToF sensor... or even ultrasonic and save some money, then that's great. I just didn't want someone else to see the comment and think they could just swap out the TFMini sensor and still use my firmware. Sorry if I came across as a bit defensive!
I’d be interested in modifying this to be installed on the rear bumper of my old truck. Then it could be something usable even if I park outside of the garage. Would it be reasonable to think that it would work in a mobile application?
I think there are a number of challenges to something like that. First is power... a standalone battery would not last long, but I suppose you could power it off of the 12V truck battery, assuming you stepped down the voltage to 5V for both the controller and LEDs via a buck converter or something. You could use 12V LEDs, but you'd still need 5V for the controller. The next challenge would be to make everything waterproof. Nothing that I used, from the LED strips to the enclosure (or the sensor for that matter) is waterproof and would not stand up to rain, snow, etc. Finally, the system is only designed to work with WiFi... not cellular data. That means it would only be possible to access the settings when at home and the wifi is available to both the device and your phone/laptop, etc. While the system should technically work without wifi once configured, I actually haven't tested what would happen if wifi was suddenly removed after it was running. I don't think the code would crash... but again I haven't tested it. I also don't know how the sensor would work or be impacted in various environmental conditions... rain, fog, direct sunlight, etc. Not the kind of things that it would experience inside a garage. I think all in all, it would probably be better to take the general concept of what I've done and build something more suited for mobile use... as opposed to taking what I have shown and trying to make it work on a truck or car.
@@ResinChemTech Thank you for the thoughtful response. I’ll start with building the garage version and see what ideas it sparks in the process. You’ve done a really nice job with this project. Well done.
Thanks! My video "production" really didn't do it justice. But let me know if you run into any questions or problems during your build. Good luck... and let me know if/when you get it done!
As a general rule, heat is a bigger problem for electronics than cold. But all components list a temperature operating range. Just from a quick glance online, the TFMini sensor shows a working temperature range between 0°C and 60°C. The D1 Mini lists its minimum operating range as -40°C and WS2812b LEDs show a minimum operating temperature of -25°C (for the LED pixel, not necessarily the strip). You can find the minimum operating temperature for the rest of the components online, but it looks like the TFMini sensor is probably the limiting factor at 0°C. It might continue to work below this temperature, but may not be reliable. If your garage or parking area is subzero for extended periods, I don't think you could rely on this system to operate normally and consistently, primarily due to sensor limitations.
Great project. Made one too, connected everything, can open the web interface but can't save the wifi setup and connect to my router. Can you help me please? Tfmini S is connected.
By web interface, are you speaking about the wifi onboarding app via your mobile phone, or the settings web page? The settings web page is only accessible if you have completed the onboarding via your phone. Just to verify, have you followed the steps in the 'First Time Setup' section of the Github wiki? ( github.com/Resinchem/ESP-Parking-Assistant/wiki/03-First-Time-Setup ). There is also a troubleshooting section in the wiki that has some steps to follow if you have issues with the web/wifi setup. Do note that there is one open issue as well that has to do with wifi. There can sometimes be an issue if your wifi SSID has special characters. This is a limitation of the wifi library (not mine) that is used. You might also check out that discussion about wifi in the Github issues and see if it appears this might also apply to you. It's hard for me to provide much more assistance based on the information you provided. However, if you continue to have problems after reviewing and following the steps above, could you post more details in the 'Discussion' area of the wiki? There is a Troubleshooting and Assistance category available. It is easier to provide help there, since the UA-cam comments prohibits posting of things like images, diagrams, code blocks, etc. I'll do what I can to help.
Thanks for your fast reaction. It's the onboarding app on the phone. After I select the ssid and fill in the password and save, the board does not reboot and does not connect to the router. My password contains some special signs.
Hello. Did some extra testing. It is the ssid name that causes the problem and not the password. I set up a guest network with the same password and it works, I could connect without any problem. My ssid has 12 caracters what seems to be the problem. I'm able to set up the parkassist but can't integrate it in homeassistant. Hope this problem can be resolved.
Well, I'm glad you were at least able to locate the issue (and thanks for updating me). As you probably saw from the Github issue, this is an underlying issue with the wifi library used. This is not something that I developed or control and I'm not smart enough to create my own! The issue has also been posted in the Github for the wifi library and I am watching closely for a fix. As soon as a confirmed fixed is released, I'll update my code to include the fixed library. But unfortunately, there isn't much I can do on my end until the developers of the wifi library repair the issue on their end. If/when that happens, you'll see a new release for the parking assistant published in my Github, and it will state that the wifi SSID problem has been fixed.
Thank you for sharing this project! I used esp flasher and put your latest bin file on a node mcu. I have the node mcu on a development board. The node mcu has a esp8266 chip. I am able to join the AP and enter 192.168.4.1 and then enter my wifi network information and enter that I have 36 pixels. The node mcu then reboots and I can't ever find it again... My router doesn't see it either. I do have the TF Mini installed as well. Any ideas?
There could be a lot of potential causes here. First, do you have the latest firmware (v0.41)? Versions of the firmware prior to v0.40 had issues with some of the newer versions of the TFMini-s sensor... but this has been fixed. If you no longer see the device in your router, can you see if it is broadcasting the hotspot again (ESP_ParkAssist) when this occurs? This most likely means it is not joining your wifi network successfully. Your SSID and password must be exactly correct. If, after entering your wifi information, the board restarts but cannot join your wifi, it will not be seen in the router and will start rebroadcasting the hotspot. Also assure you don't have any firewall or other network settings that might prevent the device from joining your wifi. Based on what you describe, failing to join your wifi seems to be the most likely cause. Next, you might want to try reflashing the firmware again (using the latest v0.41), assuring you use the option to erase the current flash if your flashing software has the option. I did have a couple of situations that the controller went into a boot loop after flashing, but flashing again (with the same firmware) solved the issue. I don't believe this is your problem, as it would happen right when the board powers up and not after entering wifi information, but it is worth a try, as occasionally a flash doesn't work quite right. It's also a remote possibility the board you are using is bad. Assure the board has at least 4Mb of flash memory. Assure you have the TFmini wired correctly. TX goes to RX and RX to TX. Reversing these will cause all sorts of issue. Finally, while I have not tested with a NodeMCU (just the D1 Mini), it is at least possible that your board doesn't match up to the same GPIO pins. For the D1 Mini, TX is GPIO1, RX is GPIO3 and D6 is GPIO12. Make sure these match with the pins you are using. Try out the above suggestions and let me know. If I get the chance, I'll also see if I can try hooking up a NodeMCU and make sure it works correctly for me. But I do know that a number of others have successfully built the system using the D1 Mini.
I wanted to follow up and let you know that I just released a new firmware version (v0.42) that attempts to improve the compatibility with some generic ESP8266 boards and I also opened up a Github issue related to what appears to be an incompatibility with some NodeMCU boards. You might try this new firmware as well as the other suggestions I made. I do know that the D1 Mini works well and multiple others have reported success using that board.
It’s a perfect project as I have left over Node MCUs, ws2812 remnants, and aluminum strips, and diffusers, and wiring from Christmas lights and ambient TV lighting projects.
Wow! Thank you so much! I'm glad you liked the video and the project. I really appreciate the support and it will go towards funding additional project like this one.
Most likely... but you'd have significantly rewrite the current firmware, both to support the ESP32 and to interface and output to the matrix display. The current firmware will not do either one of those things, but the source code is available on Github if you want to use it as a starting point.
Not as the firmware is currently written. Different libraries are needed for the EP32. I most likely will not develop an ESP32 version as I personally don't see any advantage. The project runs fine on an ESP8266, so an ESP32 would really just be overkill and would result in spending extra money for something that really doesn't provide any additional benefits. Now, if somewhere done the road, I developed a new version that used a secondary side sensor to provide some sort of lateral left/right alignment, a move to the ESP32 might be needed. But I don't currently have any plans for that. Is there a particular reason that I've overlooked as to why you might want to use an ESP32 with this project?
I have no particular reason other than I had an extra WLED controller with an ESP32 chip and wondered if it would work. I thought I could make a second unit for a different vehicle bay. I appreciate your answering all my questions and being so helpful! Thank you!
I don't believe this would be possible for a couple of reasons. First, I think that the DigUno (ESP8266) makes both the RX/TX pins available but these are used for LED data and are level shifted, so you would not be able to connect the distance sensor. I also believe it does not expose GPIO12 (D6) that the parking system uses for the LED data line... although this last one could be changed if you edited the firmware and compiled your own. Finally, the firmware currently does not work with the ESP32 so you could not use the ESP32 version. I'm not up to date on the current revision of the DigUno, but from my own older version and the current info on Quindor's site, I just don't think that the DigUno could be made to work with this project... not without extensive modifications to both the DigUno and the firmware code.
I wanted to follow up on this, as another user, @HayMark, did figure out how to make this work with a DigUno... and without the need to modify the firmware. According to him, to make it work you need to: 1. LED data to Q3 on the Dig-Uno 2. TFMini RX into the GPIO3 on the Dig-Uno 3. TFMini TX into the L1 C port on the dig-uno 4. I combined the power/ground for the tfmini and the LED strip and plugged into the Dig-Uno. I probably don’t plan on keeping it this way but it works for testing. He also has some photos of the connections here: photos.app.goo.gl/fUdDYQVKkKSnwrkw9 So, my apologies... apparently it can be made to work with a DigUno! And a big thanks to @HayMark for figuring it out and sharing how he did it. But please note that this is the D1 Mini/ESP8266 version... the firmware will not work with the ESP32 if that's what you currently have with your DigUno.
There are a couple of things to check. First, assure that your device (e.g. phone, tablet, laptop, etc.) is on the same wifi network that you selected for the D1 Mini/controller. Next, assure you are using the right IP address, which you have to get from your router after joining the wifi network. This will not be the original 192.168.4.1 that you used to initially setup the wifi, but a different IP that is assigned via DHCP by your router or whatever device you are using for DNS on your network. Finally, check that the D1 Mini/controller is no longer broadcasting the original ESP_ParkingAsst hot spot. If you can still see this hotspot via your phone, that means that the controller did not successfully join your wifi. Try the initial setup again, assuring that you enter the wifi password correctly. Let me know if you continue to have issues.
thank you very much for the quick reply. i can see the esp in my router settings and its online but i am not able to communicate. i have no idea what else i can do. moreover i tryed differnt D1 mini. same issue
When you first power up the system, are you seeing the normal "boot" process... solid blue lights for a few seconds, followed by red & green lights for a few seconds? If you do not see these lights, then the boot isn't completing... and the web interface will not be available. This is most likely due to a problem with the TFMini-s connection. The TFMini must be connected and communicating on the serial port for the system to operate normally.
so, i'm not able to see the web interface and the start sequenz of the LED. But unfortunately thats it. There is no further reaction of the led stripe. The TF Mini light up a little. Did i do somthing wrong?
Ok... if you are not seeing the boot/start sequence with the LEDs, then you most likely have something wired incorrectly. Carefully check your wiring, being sure that you did not mix up the RX/TX wires from the TFMini to the D1Mini. RX should be connected to TX and TX should be connected to RX. If in doubt, use the connector that came with the TFMini to confirm the pin order on the TFMini and wire colors used. Sounds like things are almost functioning. Once you see that boot sequence on the LED strip (blue followed by red/green), you should be able to access the web interface.
As a couple of sharp-eyed viewers have noted, there is an error in my conversion from mm to inches when showing the minimum distance for the VL53L0X sensor. The correct value should be 50 mm ~ 2 inches. Sorry for the mistake!
50.8mm in fact.
Glad I came to the comments section to check before commenting! :D
I instantly saw that error when looking at the table, and I was also wondering why mixed units. Either put all in cm or all in mm. Basic science. I would make them all mm FWIW...
Well, pretty much for the same reason I went back and added mm as a display option for the web settings per request... to most non-US folks, inches have no meaning. For for most in the US, cm or mm have no real meaning. Many, myself included, would have no idea how long 48 cm is without using a converter... is that one foot, two feet, something in between? So, to try to appeal to everyone, I show distances both in the video and on the app's web page in both metric and imperial. But I can't make everyone happy all of the time. Internally within the code, everything IS done in millimeters.
@@ResinChemTech Ok, I'm still a bit confused... in your code when you retrieve the distance via tfmini.getData(distance), is the distance value in mm or cm?
This is a great project. Thanks for sharing. I made two minor modifications that improved my experience.
- The first is an update of the libraries and recompile to eliminate some pesky wifi issues. Wifi is rock solid now with no more misc broadcast of local AP.
- The second modification is to adjust the response time of the status bar. I found myself pulling into my garage and waiting for the bar to update. Many times as I was creeping forward to wait for the bar to change, I overshot the "ideal" range and had to backup. My fix is relatively simple. There is a delay(200) at the end of the MAIN LOOP, which I changed to delay(50). The response time of the status bar is much quicker.
Thanks again for this project!
I absolutely love the way you describe the project and show it BEFORE you start building or showing the components. So many bloggers do the opposite and I never know what they're talking about because they wait until the end to demo it. Also, you are spot on with the level of information and video walk through when constructing your components. Thank you. (Subscribed).
Wow... thanks! I know that most of my videos are much longer than the "average" project video, but I try to provide the 'why' as well as the 'what' so viewers might be able to take my project or idea and figure out how to adapt it for their own needs.
I appreciate the feedback. Showing the finished project at the start of the video is something that I've started doing more often recently. I'm glad you found it helpful. I will try to continue to do that in the future.
Thanks for taking time to leave a comment... and thanks for the sub!
I am genuinely impressed by the clarity and structure of your presentation, starting with a comprehensive overview of the project before diving into the construction and components. This approach is refreshingly clear and keeps me engaged from the very beginning, unlike others who leave the audience guessing until the very end. Your dedication to providing a detailed walkthrough and the meticulous attention to detail in your projects, such as the original parking assistant, is truly commendable. The effort you invest in each project shines through, making them not just informative, but also incredibly inspiring. Thank you for your hard work and for sharing your knowledge with us. ( I am a subscriber - Miguel)
👏👏👏👏👏👏👏👏👏
Wow... thank you so much! While it does tend to make my videos longer than others, I take the approach of trying to explain the 'why' as well as the 'how' with the goal that if I can share the concepts, others may be able to take my ideas and apply them to their own projects as opposed to just "cloning" what I did.
I greatly appreciate the time you took to post a comment (and the Super). It is comments like yours that inspire me to create more videos. Just as an FYI, I'm currently working on an update to this system that will make Home Assistant integration much easier, without the need to create any manual YAML.
Thanks again... for watching, the kind words and the sub. Welcome to the channel!
Your original parking assistant is one of my favorite DIY projects. You've done it again! As with all of your projects, including as much detail as you do is wonderful. Thank you
Thanks! I really appreciate the kind words. The original was one of my early projects, so while it works pretty well, it was a bit complicated to figure out (and to maintain since the settings can only be updated by editing the Python code). I wanted to try to make one that was both easier to build (not to mention Pis are hard to come by these days), but also had a way to change settings without editing any code.
Again, I do appreciate the comment. It's comments and feedback like your that encourage me to keep making videos!
This is so ingenious - and your detailed instructions are great. Unfortunately, we don't have a garage. We park two cars side by side in a wide driveway. Thus we have to pay attention to side-to-side position as well as positioning the left side car behind the other for easy driver's door access for the forward car. Sure would be great if we could figure out a sensor to mount on the house that would nail these two positions for the drivers.
Thanks... I appreciate the kind words. I've had numerous requests for something that provides lateral, or left/right, guidance. I'm considering a couple of different approaches... one that integrates lateral guidance into the existing system, or a separate system that would provide lateral guidance only. The second option may be of interest to you, but there are a few things that I think might still be a challenge for you. First, if this it going to be mounted outside and exposed to the elements, everything would have to be made waterproof... definitely not something that my current system has. Next, any sort of sensor that is going to detect lateral movement would likely have to be mounted to the side of the vehicle. If you just have an open driveway, I'm not sure where or how you would mount the sensor.
But I guess that's why I try to explain the "why" as well as the "how" in my videos. I hope that viewers may be able to take my ideas or concepts and adapt them to their own projects or needs. So, maybe if I do add some sort of lateral detection down the road, maybe you can find a way to adapt it to your needs.
Thanks for watching and taking the time to post a comment!
10:00 spot the mistake 😊, 2cm (20mm) is a lot less than 50mm (5cm), almost tempted to try something like this but will need a lot more accuracy than the LIDAR as i park outside and almost touch the garage door when parked, the reversing sensor on my van is not reliable so tend to go really slow and touch park.
Good catch... and you are 100% correct! In my effort to convert everything to inches and feet (since Americans mostly refuse to adopt the metric system), I advertently left a "0" out of the conversion calculator I was using... entering 5 millimeters instead of 50! Thanks for the correction! But the maximum range is correct and the ToF sensor quickly drops out of the testing ranges.
None of these, I believe, would work in a situation where you have to park within an inch or so of a wall or door. I wonder if something like a contact sensor on a flexible surface (or spring) might work better in that case? Maybe something that you would slowly approach until you make contact... and that contact would then flip an LED or other indicator on? Just a thought. But thanks again for spotting the mistake... and I'll see if I can post some sort of correction somehow.
Awesome tutorial. For now, I just use a piece of wood that I boltet to the floor. But this is a far more sophisticated solution. Also, no trip hazard due to the piece of wood - which may or may not be an issue depending on the circumstances.
Thanks! Yeah... there are a lot of "low tech" solutions. I had a tennis ball on a string from the ceiling initially. But when I would be working on a project in the garage, seems like I was always banging my head into the tennis ball.. or catching the string on a 2x4, etc.
Plus you really can't really integrate a tennis ball (or piece of wood!) into a home automation system to use it for something like vehicle detection.
Thanks for watching and taking time to post a comment!
Great Project, it's just what I needed for my garage. I don't have much room to play with, and this helped with getting my truck parked just right.
I was going to post on the Blog, but was having problems getting onto the comments. But FYI, I did have a problem at first with getting it set-up
I found that I had set the TFMini looking right at the front license plate, and would get inconsistent operation. Thinking that the reflective part of
the license plate might be interfering with the sensor. After moving the TFMini over 2' and resetting the distance, It worked like a charm.
Thanks.
Glad you got it working! We don't have front plates on our cars, so I obviously haven't experienced that. But I guess it is entirely possible that the plate reflectivity could scatter the signal and cause the issues that you were seeing. A good point for anyone else that might install the system and have a front plate on the car.
Thanks for taking time to share the issue (and resolution) and for letting me know that you successfully built the project.
That's great design with cost effective components. I appreciate the explanation of the more expensive TFMini-s and agree. You mentioned a car presence function. I immediately thought of car not present and garage door open possibly indicating someone drove off an left the door open. There would need to be some rules to go with that before taking some action and a way to disable it if you're working in the garage with the door open. But, could be useful for some.
Thanks... actually my parking sensor is used as a secondary presence sensor. There are two ultrasonic sensors mounted on the ceiling over each of the cars (connected to an ESP8266 running ESPHome... it also has a reed sensor for the overhead door connected) that also reports the presence (or absence) of either car and verifies the door position agrees with that reported by the smart garage door opener (Tailwind).
So, I can crosscheck both car presence detectors and both garage door sensor positions before I take any automation action, especially actions related to arming/disarming the alarm system (which also adds phone presence detection as well). When it comes with anything to do with home security, I definitely want more than one sensor reporting. The parking assistant simply added yet another way to assure a car is present or not when compared with other sensors. And as you mentioned, even if both cars are out of the garage (maybe because I'm working on a project in the garage), my phone would still be present, so the automation to arm the alarm system would not fire. Just one of many automations related to presence detection.
Thanks for watching... and taking time to post a comment!
Thanks for sharing this wonderful project. While I love all the features of this sensor, I build my sensors to give as gifts to friends. In doing this, I am conscious of cost and simplicity. I use the ultrasonic sensor mounted in a 3D printed enclosure along with the microcontroller. I then use a Cat 5 cable to transfer power to a conventional red and green LED mounted higher in its own tiny enclosure. I do not need a computer or phone to interact or set up my device once the microcontroller is flashed. The green LED is on unless the car is in the parked position. To program the parked position, just park the car in front of the sensor and push a momentary push button on the enclosure. The controller takes the reading at that moment and stores it in EEPROM so that the set point is not loosed during power outage. For my personal use, I will likely build your sensor. Thanks again for sharing.
You are welcome. Yeah... if I was building (or giving as a gift), I'd definitely pre-flash the controller. And I tried to add as many different options to mine to accommodate different use cases. But this does require onboarding to wifi and using the web interface... complicating things a bit for the end user.
I love the idea of a momentary push button to store parking locations though. That's a great idea that never occurred to me (I love it when I get new ideas from my viewers)! I could see even adding four small different colored push buttons to a controller box that would set the four different zones in my case. Hmmm....
And of course by only having two LEDs, you not only eliminate the need to specify the number of LEDs being used, but also substantially reduce the power requirements. All great ideas! I do know that my wife, however, does like the 'countdown' approach lights in both the Pi and the WS2812b version. But your version is definitely simpler to build and use (writing that web interface and onboarding process for the measly ESP8266 was a pain!).
Thanks for watching... and thanks again for sharing your build ideas.
Cool project. Have you given any thought about how to incorporate lateral alignment? My garage is pretty tight so getting the car aligned left and right is important too. Your original project has a display that looks like it could tell you to steer left or right. I have some ideas but they require a lot of ceiling-mounted sensors or a camera with some image processing (a sensor on a wall perpendicular to the front wall won't work for me). Anyway, I enjoy your projects, keep up the good work.
Actually, the original Raspberry Pi version did have a side/lateral sensor (another TFMini), but I could never get it to work consistently (yes, the matrix display actually has side arrows defined to help with that lateral distance... but I stripped that out of the project).
For this new version, I toyed with the idea of trying to do something for lateral alignment, but it would probably take a completely separate processor, LED strip, etc. as the D1 Mini only supports one serial device. But there are a lot of possibilities, including moving up to an ESP32 for multiple serial ports. But it sounds like your problem is made more difficult if you can't mount a sensor on a side/perpendicular wall. Just thinking "out loud", you could do something like two TFMini sensors on the ceiling (you'd need these for the narrow field of view), mounted just to the outside of the lateral "lane". Then if either trigger, it would like up a corresponding LED to indicate straying too far to one side or the other. That's just an "off-of-the-top-of-my-head" idea. There are probably other ways to tackle it.
For my situation, lateral distance wasn't as important... other than getting too far one way or the other also impacts the front reading due to the curved bumper. But the "parked" zone is wide enough to accommodate that in my case.
Thanks for watching... feel free to reach back out if you have any other questions or thoughts!
Here is a silly idea that is lower tech. Perhaps have the wake mode also turn on a simple visible laser pointed "dead center" of a perfectly parked car. Then, when your angle is wrong, you will see the laser reflection on the wall and can work it to point straight back.
Just hang a tennis ball and align it to your driver side mirror. Have it on a pulley so that the ball goes up when the garage is closed.
I’ve had a similar setup using ultrasonic sensor, Ws2812B and ESP8266 D1 mini in my garage for past four years. It works great. 🤓
Thanks for the hard work you put into this project! I opted to use a different esp8266 controller I had laying around and spent a few hours thinking I had wired something incorrectly as I could only get 1-2 pixels to light up when booting but finally realized I needed to use pin d6 and have a little more patience. Working great!
Glad you got it working. I tried to build as much flexibility into the system through the web interface as I could, but selection of the LED data pin wasn't one of the things I included... so it's pretty inflexible on that account. Well, unless you want to modify the source code and compile your own version.
But regardless, congrats on getting it up and running. My wife loves the one I built and it is a pretty big improvement (and cheaper) than the original Raspberry Pi version that it replaced. If you run into any questions or problems with the system, please don't hesitate to reach back out.
@@ResinChemTech my wife is a big fan and she LOVES not having a tennis ball hanging from the ceiling.
Great project and I loved seeing the comparison of the distance sensors. The vl53l0x sensors has a "long range" mode that might have helped cover the distance, but my guess is that it would do so to the detriment of close range readings (and since it's already so noisy...). I believe the vl53l0x has a bigger brother with great distance, but when I investigated it before, it didn't have ESPHome support, so I skipped it. Given the consistency of the readings and the small number of times you would need to use it, the TFMini absolutely sounds like the best choice.
Thanks... I probably spent too much time on the sensor test but I knew if I didn't, I'd get a lot of comments about using a $3 ultrasonic sensor instead. So I felt like it was important to show why I selected the TFMini. There may be other options out there that could work and might be cheaper, but I used ones that I had used in other projects (and had on hand!).
@@ResinChemTech The sensor test was very useful for me, personally. My guess is that the accuracy variances on the ToF (if not JUST noise) could be the increased field of view and the curved surfaces of your car. All of those distances could be correct at 25 degrees with the shape of the front of your car and the non-centered placement of the sensor. Placing the TFMini in the center might have given it a slight advantage, but it's largest advantage seems like the 2 degree view. I wonder what the variances would be with a flat, perpendicular board instead of the car's multi-curved surface?
That my friend is the most complete diy project I think I have ever seen on UA-cam! Wow.
I really appreciate the kind words. Many of my videos tend to be on the long side... and few people watch them all the way through, but I like to not only provide enough details for someone to recreate the project but also understand enough that they can take the concepts and maybe adapt them for their own projects.
Thanks again for watching... and taking time to post a very nice comment!
Looks great, and amazing balance between speed and details.
I never saw the Rasp.version video. If I did, I would have probably said the pie was overkill.😉
Oh, the Pi is definitely overkill and underutilized for this particular project! But I built it back in the very early days of my DIY/Home automation journey... and for me, it was more about learning the Pi, Python and if I could even get the matrix to work.
That's one of the reasons I decided to remake the video. With what I've learned over the years, I could apply that to make a much lower cost, easier-to-build and much more friendly to use version. My wife actually prefers the new version, so as an added bonus, I now have an extra Pi and LED matrix to play with or use in another project!
@@ResinChemTech Oh, I think we all have that type of experience, when you cannot imagine why you did something that complicated 10 years ago with the knowledge you have now.
But we have learned.
I needed a narrow field sensor and you have helped me decide on the TFMini. Much pricier than the high-value ultrasonic sensor though. Thanks for this great comparison video.
The narrow FOV was one of the reasons I used it as well... along with the range and better signal stability than the other options. Yes, it is a bit more expensive and I wouldn't use it for every use case, but for me it was the best solution for the parking assistant and my installation.
Thanks for watching and taking the time to comment.
Looks good, from the video I would say the only thing missing is a sleep mode to turn off the LEDs after no movement for a time period.
There is an option in the web settings to disable the sleep mode LEDs altogether so that they do not remain lit after the system goes to sleep. However, it wouldn't be too difficult to modify the code to turn off the sleep LEDs after 30 seconds or so. I currently don't have time with my current project load to make any modifications to the code, but if you are familiar with Arduino/C++ code, my version is out there on Github and you can freely clone or fork it and make those modifications ( github.com/Resinchem/ESP-Parking-Assistant ).
Let me know if you do make those changes and I can consider adding them back to my code if I ever have a chance to get back to this particular project. I have a number of other requests for modifications as well, but I have to find an opportunity to circle back to this build... and not sure when that might happen.
Thanks for watching and taking time to leave a comment and suggestion.
@@ResinChemTech Damn someone is quick today.
Would love to do this but no garage and car parks behind motorcycle on the drive so no line of sight from a fixed spot. I rely on a mark on the fence that lines up with my mirror.
Awesome project! Thanks for sharing!
Thanks Chris! I'm sure you could have done it better justice... as I'm jealous of how well you produce your videos! I spent too much time testing the sensors, creating the firmware and writing the blog and Github wiki to leave enough time to produce a decent video (or create a good thumbnail).
But thanks for watching and taking time to drop a comment!
Thanks! I was just thinking about building something like this earlier today, and your evaluation of the different sensors probably just saved me a lot of time!
Wow.. thank you so much! I'm glad I could help. I was curious about the sensors myself and I knew that if someone was going to spend $40 on a sensor, there better be a good reason over buying the $3 one!
I really appreciate the SuperThanks! Please reach out if you have any questions when you decide to build your own.
Gotta love how much work this guy does for his wife's driving 😂😂
Nice project but way more complex and expensive than necessary. I bought a laser that projects a large X pattern and mounted it on the ceiling. It is adjusted so that the X is centered on the dashboard when properly parked. You can see the X on the hood of the car as you pull in so it is foolproof! I powered the laser from the garage opener light socket so it turns on when the door opens. Cost was about $25 for all parts. No microcontroller, no code.
I guess it depends on what you are looking for. A tennis ball on a string cost next to nothing, doesn't require electricity at all, and basically does same thing as my system and yours.... help someone to park in the optimal position. There are many different ways to accomplish the same thing. For me, I also wanted a system that I could integrate into Home Assistant and use for vehicle detection and automations. Something the tennis ball could not do.
But I appreciate you sharing your project. It might be ideal for you and others that don't want to go to the level of of difficulty I did for my project.
Great project and great video explaining each part... I would very appreciate if you could include in your Github a document showing the wiring connections from the different components to the ESP32 board. The LED strip looks pretty straight forward but which pins you used on the ESP32 for the TFmini is not as clear to me.
The wiring diagrams, parts and more info are all in the related blog article, which is linked to both in the video description here and in the wiki within the Github repo: resinchemtech.blogspot.com/2022/11/esp-parking-assistant.html
Do note that the current firmware will NOT work with the ESP32. It is designed for the ESP8266 (and preferably the Wemos D1 Mini). You can find more info on that both in the blog above and in the Github Wiki.
@@ResinChemTech Thanks for the prompt reply... my mistake on the reference to ESP32. For my project, I'm going to use the ESP32 so fully prepared to make code changes. Also, my preference is to use I2C instead of UART, so I'm also looking to use the TFmini Plus since its default interface is I2C.
I'm using the VL53L0X for my parking distance sensor and it works great.
Sure, the max distance range is shorter than with the other options, but that's not a problem really. It starts detecting the car a good 5-6' away and is rock solid stable as the car is driven in and parked. I don't get the fluctuation in distance that you did. I'm using just RGB LED strip and it just changes from green to yellow to red to tell the driver when to stop.
That's great that you got the ToF sensor to work for you. Due to the entry door into my house, the sensor is placed pretty close to the side wall so the wider FOV of the VL53L0X could have posed an issue. And my wife really likes the LED "countdown" approach as her range for being in just the right spot is pretty narrow.
But like many DIY projects, there are multiple ways to accomplish a similar task. Thanks for taking time to share yours.
Very nice! I’m always looking for ways to use ESP32s or 8266 chips. I may do this. Thanks for sharing!
Same here! Seems like I always have a bin full of ESPs looking for a problem to solve! I will say that personally, learning Arduino/C++ code opened up a whole new world of things I could do with ESPs (like this parking assistant, my matrix clocks, etc.). Many of these projects simply wouldn't be possible using things like ESPHome alone. And by adding MQTT, it assures that I can always integrate the devices into Home Assistant as there wouldn't be any sort of native integration for these custom-built devices.
Thanks for watching and taking time to leave a comment. Let me know if you do end up building the parking assistant and how it works for you!
I'd keep both! :-) and also add "The Blue Danube" to automatically play when the garage door opens... 🙂
Happy wife, happy life! Great job, thank you!
Wow! Thank you so much... and yep, I have a t-shirt that says that exact same phrase (although the shirt itself does have a very high WAF!). I'm just really glad you got it to work and that the wife likes it. Thanks again for the donation. It is greatly appreciated and will go towards future projects.
Really cool project. Have you thought about a feature to align the vehicle with the garage opening? I have a two car garage, but there are two single garage doors. It's still one garage inside. Anyway, my wife has a large SUV and there are only a few inches of clearance on each side. She has already hit the side mirrors when not lined up correctly. In addition, she needs your project for depth. I wonder what the best way would be to add a couple more sensors with arrows left and right as she approaches. Any ideas?
I've had a couple of people ask about that. I think that a different side sensor (possibly ultrasonic) would be needed. The problem with the TFMini/LIDAR is the narrow field-of-view, which is ideal for the front sensor, but probably wouldn't work well as the side sensor. Someone else suggested something as simple as a laser on the ceiling that would put a dot on the hood of the car that the driver would line up with the center line.
I'm giving it some thought. But I think it would probably either be a separate system from this one, or this one would have to be upgraded to an ESP32. The ESP8266 is about maxed out as it currently stands... I'm not sure it would support a second sensor... at least not another TFMini/LIDAR or something the would require another serial connection. I might take a shot at coming up with something when my current project load permits.
Thanks for taking time to post a comment!
I know what I'm doing next week. $45 after tax is steep when we are used to -$10 but cheaper than a RPi. As always, great video! I look forward to seeing when you release new content.
Thanks! Yeah.. the LIDAR sensor is a bit expensive, but hopefully I showed why it is worth the extra money in this case (at least for me). And the final install could be much neater, but as I mentioned in another reply, this was just a temporary install for the purpose of making the video. Actually neither vehicle parks in the location where I mounted it for filming. So, it will be moved (or if the wife wants to stay with the Pi version, possibly stored away) and I'll definitely clean up the wiring if/when it gets remounted.
Thanks for watching... and taking time to post a comment. If you do build your own, feel free to let me know if you have questions... or shoot me a message if you do build it and let me know how well it works out for you!
@@ResinChemTech I am going to have to rethink the mounting as well. There is a fridge in front of my wife's spot, that may change in the near future though. I'll reach out for help or to share my build.
Thank you for this video. I have watched it multiple times. I have electronic background, but are quite new to Arduino / ESP boards and have no experience on MQTT. Home assistant is brand new to me too, but would like to set it up in the future. Would you maybe have the code for the Ultrasonic sensor instead of the serial coms code. I would like to try it out, but trying to navigate through the code and is very new to me. Code snippets and advice about the code will really help. You have an amazing project here. Thank you for this. Was looking all over for this. Not sure if someone already asked this question. Keep on doing the great work!
I don't have a version that works with the ultrasonic sensor. As I covered in the video, I didn't feel that the ultrasonic sensor was stable and precise enough for my needs so I have no plans to develop an ultrasonic version. However, I do believe that someone may have forked my code and rewrote it to use an ultrasonic sensor. I have not tested this forked version nor do I know if it has been kept up-to-date with changes made in my version. You can see my full code (and find any forks) in the Github repo: github.com/Resinchem/ESP-Parking-Assistant
I try to document within the code itself to help out with anyone trying to learn or for those that want to adapt my code. The wiki may also contain some useful information.
Note that MQTT/Home Assistant is optional and not required for the system to work. So you could build the system now and then add it to Home Assistant via MQTT at a later time.
I appreciate the kind words and interest. I've been asked numerous times about an ultrasonic version but feel that due to the noise, wider field of view and lower precision, I don't believe that it is a good choice for this project. It definitely would not work in my situation as my sensor needs to be near a side wall and the ultrasonic sensor would just measure the distance to that wall and not an approaching car. But it might work for others in situations where high precision is not needed and the sensor can be mounted far enough away from other walls and objects.
@@ResinChemTech Thank you for your quick reply. I can't find the sensor locally at the moment and I have the ultrasonic sensor. I appreciate it. Will do some more research. Thank you!
From a UI/UX perspective, the new system is way better, while being cheaper too!
Yeah... that was one of the biggest pains with the original Pi version. Once I had it it 'dialed in', I didn't have to mess with it much, but when first setting it up, it was a real pain... as the Python program had to be stopped, opened and edited and then restarted for each change in distance. So, I knew with this new version, I wanted a web interface where the settings could easily be tested and changed without stopping the system.... and without editing any code.
To be honest, development of the code was 95% of the effort (and a huge chunk of the time) in developing the new system. Thanks for watching and taking time to leave a comment!
This is a very cool project. Thank you for inspiration. Hence I need to fit bikes next to the vehicle, I think about extending by another sensor and also display lateral distance to the wall.
Thank you for your sensor comparison. For another project I tested ultrasonic senosrs. It was really disapointing (worse than your measurements). I expect that there were other ultrasonic sources in my test field... some cars passing at the road messed up the sensor toally... Might be that they had ultrasonic sensors... so be aware if you use ultrasonic and other cars passing by (or even your car has sensors).
Also be aware: Wind and floating air produce white noise, which also contain ultrasonic.
As I work with different sensors in my professional life, I also think about combining the two cheap (Ultrasonic and ToF)) ones for longitudinal measurement and the ToF for lateral... I guess this gives enough information, but will take some sensor data fusion. Now I'm really hyped by this idea... but I have some other projects which are more urgend. I guess this will take some time.
Thanks! And thanks for sharing your info on ultrasonic sensors. They have their place, but also their limitations.
Note that if you want to add additional TFMini sensors, you'll either have to move up to an ESP32 (since the D1 Mini only has one available serial port), or flip the TFMini over to I2C... which can be done by sending it a command over serial.
Thanks for watching... and for taking time to post a comment.
@@ResinChemTech 😀 Wow, thank you for your respond and the additional hints. They'll come handy. I have some D1Mini, RasperyPi PiCo (without WiFi) and some ESP32 waiting for projects... not sure if I might drom Wifi, keep verison with few pins or go for the big ESP32... so much possibilities those days ☺
This is a great project and may be my first foray into this platform. I'm curious if you have come up with a left/right corrector for narrow garages? ceiling mount would be best since walls are usually cluttered. That would be a useful upgrade.
I appreciate the kind words... and the suggestion. But please note that I've received a lot of different requests for 'upgrades' for the parking assistant, including use of an ultrasonic sensor, an ESP32 version and, yes, adding lateral left/right guidance (among others). While I would like to look into to some of these possibilities, it is a matter of time and priorities among other projects. I have given the lateral guidance some thought, and I have a couple of ideas... but I don't know when I'll have a chance to try them out and determine what, if any, might be the best path forward.
if you are interested in knowing when I release an upgrade to the parking assistant, you can place a 'watch' on the Github repository. I may or may not publish something on UA-cam if/when I implement some of the requested changes. Or you can just pop over to the repo or to the related blog article, as I do try to keep those up to date with all the latest changes and new features. Thanks again for watching and the recommendation.
Great video and instructions. I'm glad I found this. Did you consider wireless transmission from the sensor to the box?
Thanks! I think quite a few people have successfully duplicated the project for their own garages... at least based on the feedback I've received.
I didn't consider wireless and while I think it would be nice to eliminate the wiring and provide a little more flexibility in terms of where you could mount the controller and LEDs, it would also likely present a number of challenges. First, you would have to add a second ESP or other board to connect to the sensor. The sensor uses UART to communicate and doesn't have its own controller... it's just a sensor... so a second board would be needed to communicate with the sensor and then to transmit that data to the primary controller.
I also suspect it would introduce at least some latency. When you are approaching the final parking position and if you have a very tight tolerance, any latency could be a very bad thing!
Finally, if looking at using WiFi for communication between the sensor controller and primary controller, many people have weak WiFi in their garages (if any WiFi at all... I've already had requests to create a version that doesn't require or use WiFi). I suppose you could use something like Bluetooth or ESPNow, but that adds more complexity and my code definitely isn't designed to talk to another controller over any sort of protocol. So while a wireless sensor is an interesting idea, I don't think it would be practical with my current design.
But I appreciate the comment... and the thought on how to potentially improve the system.
You could use an ESP for your original project, or Pi for the new version. The Pi certainly can have a web interface. You don't have to use Python for the program language either.
But an ESP is the more logical choice, as the Pi is essentially a full PC in a single package with GPIO pins.
Yeah... I think my goal here was to make something that was significantly cheaper, since Pis are so hard to come by these days... and the LED matrix wasn't cheap either (at least compared to a short strip of WS2812b pixels). The matrix also requires 16 different wires/pins between the Pi and the display (not counting power), basically eliminating the possibility of using a D1 Mini.
Yes, a lot could be done to improve the original version... such as adding a web interface for the settings. But the new version is a much lower cost and an easier to build solution with significantly less wiring. My Pi version still works fine and I will likely keep it, but I wanted to share a system that basically offers the same features, but others could build without shelling out the extra money for a hard-to-obtain Pi or a matrix display.
As I mentioned, using a Pi is overkill anyway for this type of project.
As for your matrix, just use a WS2812b matrix which just like your new project would only require one channel wire, besides power and ground.
Great project and tutorial. I've built one so far for my wife's parking spot and she loves it. I'll hopefully get one built for my spot this weekend and then one for my Mom and my brother in law. One thought I had is that it might be nice if there was a way to configure it without connecting to a home network. I have a decent signal in my garage but I'm not so sure about my relatives. Could the captive portal have an option to just configure the device without on-boarding?
Also, I had to connect to my 2.4 GHz guest network vs my main network (2.4/5 GHz combined with a password with a % character). The device sees the main network but won't connect. Bout sure what the issue is.
Thanks! And glad your wife loves it (that's always a good thing!). First, just a quick note about installing the second device on your network. Be sure you are using at least v0.41 or later for the second device (or both). Versions prior to this had issues with duplicate names on the network (it never occurred to me originally that someone might want to build more than one). v0.41 and later added support for multiple devices on the same network.
Next, as far as your network.. yes, the ESP8266 boards only support 2.4GHz networks. I'm using a standard wifi library developed by someone else, and there have been some reports that either certain SSIDs or passwords have problems connecting (there are reports related to both length and special characters). In fact, I've had one user that could not connect more than once with a particular router, but another router with the same credentials worked fine. I am keeping an eye on the issues and fixes for this library and will update my firmware with any fixes that arrive. Not a whole lot I can do in the interim, other than write my own wifi library... which is beyond my current capabilities! I have an open issue on the situation here: github.com/Resinchem/ESP-Parking-Assistant/issues/13 so you might keep an eye on that as I'll post any updates to the situation there.
Finally, as the firmware is currently written, a wifi connection is required to access the web interface and to setup the device. The initial onboarding process (to connect to the wifi) isn't sophisticated enough to handle all the settings, like parking distances, etc. Now, you could use another device to provide a temporary hot spot for joining and doing the setup and once the system was running, wifi could go away. But as soon as the device reboots (or say loses power), it will try to rejoin the previous wifi... and if it fails, it will start broadcasting its own onboarding hot spot again and wait. But this is certainly something I can take a look at... either modifying or creating a version that would work without wifi. I have other requests as well, such as lateral guidance, so I do plan to circle back to this project when time allows.
Great build! Thanks so much for sharing this one!
Thanks! It's good to hear from you. And thanks for taking time to post a comment!
I made something very similar for my wife. But mine was built with just a 2x4. Yours is a little cooler.
There are a lot of different ways to take this same concept and reconfigure it for different needs and uses. There are numerous other projects out there that do a similar thing, but many of them use an Arduino and a simply 'stoplight'... green, yellow, red. I wanted to try to make something with an ESP8266, add a countdown effect (instead of just jumping from green to yellow to red) and to provide a web interface that allows a lot of different options and settings so the system could easily be configured for different purposes without needing to edit any code.
It won't be a fit for everyone, but it might work well for some as it is relatively easy to build (compared to some other projects) and doesn't require any coding to install or use. Thanks for watching and taking the time to leave a comment!
@@ResinChemTech I was being silly, of course, with the reference to a simple stop block on the floor. This is one of a million different projects i'd love to do, along with remaking my homemade CNC, connecting my irrigation and HVAC controls into a custom interface, constructing some ultra long battery life temp sensors, building a complete garage motor and sensors from scratch, etc. I may not need this exact thing you made (my garage is deeper, and has a workbench an other stuff that would prevent me from having a good mounting spot), but the components and design ideas are still relevant to thinking about other uses.
This is great, I'll make it my Christmas break garage project 2022!
I think it might be a great Christmas break project. It doesn't take a huge amount of time to build and won't break the bank in terms of buying parts.
Thanks for watching. If you do end up building the system, reach back out and let me know how it works out for you.
What a fantastic project! Thanks for such a detailed explanation. Between this video, your blog post, and the project documentation in your Github project's wiki I felt confident enough to build a couple of these on my own and I ordered the parts (using your affiliate links in your blog post) to make a pair of these.
I now have everything wired up on my bench but I've run into the same issue as "loggki" reported on your Github's "Issues" page. I'm also getting the standby lights on my LED strip but my MQTT receiver is showing that all I get from the sensor is the default "192" distance. Since I now have a pair of the TFMINI-s sensors I tried plugging in the other sensor but got the same result.
Doesn't the fact that the 8266 is booting up correctly and is going into standby mode mean that it's able to talk to the TFMINI-s? I'm assuming that if I had things wired incorrectly I wouldn't have gotten to that point but I could be wrong about that. I tried powering everything up without have the sensor connected and it wouldn't boot (just like you'd said in your article) so that's what makes me think that the sensor must be getting power and must be able to be seen by the 8266.
Would you like me to post this in the "Issues" area of your Github project instead of here?
Thanks! I appreciate the kind words... and the fact that you read all the documentation that took me forever to write!
But your comments did make me think of something that I might need to change in my firmware code. I guess I never really expected someone to build more than one of these. The hostname for joining the wifi is 'ESP_ParkAsst'. I did this to make it easier for folks to get the IP address in their router (as opposed to some generic ESPXXXXX). But I'm not actually sure what would happen if two devices with the same host name try to join the wifi network... I might ask for your assistance on that one to see what your router is showing. But I don't think that has anything to do with your current issue.
Would you mind reaching out to me via email? Some problems just aren't conducive to troubleshooting here in the comments (or via Github issues). If you are on Discord, once we connect via email, we can jump over there for more of a 'real-time' conversation if needed. You can get my email address by going to the 'About' page of my UA-cam channel. There will be a button to 'view email address'. Note that some folks that are on mobile devices (specifically iPads) apparently don't see this button, so you might need to use a full desktop view. I'd share my email here, but I don't like to do so because it gets picked up by the spam bots. If for some reason, you still can't get my email address, follow up to this comment and I'll find another way to share it.
@@ResinChemTech Thanks! Email sent!
Thank you for taking the time to make this very informative video. One question: Can this project be done with an ESP32??? Thanks again...
It certainly can, but the code would need to be updated with ESP32 specific libraries and calls. The code is freely available on my Github, so it can easily be modified to work with the ESP32 if that's what you'd like to do.
Just out of curiosity, what would you expect to gain by using an ESP32? For this particular project, an ESP8266 is perfectly capable of processing the sensor readings, lighting up a few LEDs and handling the web/MQTT requests. This is the reason I haven't seen the need to develop a version of the firmware for the ESP32 as I didn't feel that it would improve the system in any manner. But if you do have specific reasons, you should be able to update the code relatively easily.
Thanks for watching and taking the time to leave a comment. I do appreciate it.
Thanks for your reply. The only reason would be that I have a bunch of ESP32's hanging around. But since I'm not much a coder/programmer, I'll just stick to ESP8266 and the rest of the parts you have listed. Thanks again for all your efforts. @@ResinChemTech
After watching several videos about how to wire up LED light strips similar to the one you used, I've noticed the other videos used a resistor in-line between the ESP and light strip data line as well as a capacitor on the power line. I'm curious to know if you did not include these intentionally and if so, why?
I have found that with over two dozen LED projects, I have only needed a resistor in one situation and that was due to a very long data line run in parallel with the ground wire. You can certainly include a resistor and a capacitor to "smooth" out the voltage, but I've simply found that I don't need them.
It is similar to the debate about the logic level shifter (e.g. the I2C-compatible versions begin too slow). There is theoretical and then there is practicality and what I can see with my own eyes. On paper, you could/should add a resistor to "even out" the data line and a capacitor to even out the voltage. But again, with one rare exception, I simply haven't added either and have had no problems. I've also not heard from anyone that had an issue with the parking assistant that they built it based on my design. But like with most DIY projects, there are multiple methods and techniques. Since my projects are generally targeted towards beginners, I try to keep them as simple as possible... and that means not adding things like resistors or capacitors unless they are truly necessary for functionality.
@@ResinChemTech Much thanks for the clarification
I store bikes and such in front of the car so I can't really use this but I have been thinking about a simpler version with just two sensors on the ceiling. I'll just be limited to not present, OK and too far of course. The upside is that only the LEDs would be visible on the wall, the rest is on the ceiling on top of the garage opener.
I actually have two of the ultrasonic sensors on the ceiling of the garage, one over each of the cars that I use for my primary vehicle presence detection. Ultrasonic sensors are great in this case, because the distance between just car and no-car is pretty big and the noise level really doesn't matter. But you could extend that concept to turn on LEDs when the car enters the measuring angle range of the sensor and detects the car.
Thanks for watching... and taking the time to pass along a good alternate idea!
Is it really 28 degrees in your garage? burrr! Great project, I enjoyed your video.
Ha! Actually the matrix clock displays the outdoor temperature, but since the garage is unheated, it was still pretty chilly the day that I filmed this. But good eye on catching that.
Thanks for watching and taking time to post a comment!
I wonder if having a front license plate would help the ultrasonic sensor. It being a perpendicular flat surface. I would expect less variance, but have no clue if it would effect the range.
I don't think it would impact the range... unless it was bejeweled or something that would tend to scatter the signal. Honestly, the curved front end doesn't make a huge difference unless you get really far left or right of the sensor. Since I have the actual parked distance in Home Assistant, I've been able to watch the actual measured difference when my wife parks her car. It might vary by an inch or so if she is a little to the right of center... but the 1" still puts her well within an optimal parking spot.
I appreciate the suggestion.. and thanks for watching. I really just mentioned the curvature to explain why all 3 sensors in my testing didn't 'exactly' match the measured difference... and that you might see some slight variances as well.. but nothing that should have a major impact... unless you only have a couple of inches of clearance for your parked car.
In a two car garage set up, could you put each system in front of each car without issues? Or would there be a way to run it all on a single D1 mini with 2 separate sensors and 2 light strips? Perhaps, in a future version, you could have an audible sound (via bluetooth speakers) as you approach!
Yes, starting with version 0.41, multiple systems can be installed (e.g. one for each car... for as many total cars/parking spots you might have). You just need to assure each system is given a unique name when setting it up, and provide a unique MQTT topic for each if using MQTT. This is all covered in the Github wiki for the project.
As far as adding sound, I have numerous requests for enhancements to the system... and a buzzer or audible tone is among those. I did provide some updates and a couple of new versions a few weeks ago, but honestly I don't know if or when I might have time to consider additional requests. Of course all my code is available, so it could be cloned or forked and those other features could be added by you or someone else. I just can't make any promises as to when I might be able to provide any new features.
@@ResinChemTech For 2 cars, it requires 2 complete systems, correct? Or can any of the hardware be shared (ie. run it all off a single D1 mini)?
Correct. It would probably require an ESP32 and pretty much an entire rewrite of the code to be able to share one MCU between two sensors and two light strips. As written each system is independent, with its own web interface and settings. The only thing you might currently be able to share would be the 5V power supply (running separate leads to each system) as long as it was able to provide enough current to power both systems.
Nice project. I keep threatening my wife to hang a tennis ball in the garage because she always pulls in too far. She's very resistant to that idea. I tell her that mostly to tease her, but the WAF (wife approval factor) is a big part of projects like this.
I'm curious why you didn't put the LIDAR sensor in the box with the controller, and have it off to the side on a whip? Seems like it would be pretty easy to include it in the box, and would reduce the clutter on the wall.
Thanks! We used to have the tennis balls on a string too! But I hated them because it seemed like when I had the cars out of the garage to work on a project, they'd always get in the way. I'd either bump my head into them, or swing an 8' 2x4 around and catch the string, yanking them off the ceiling. And of course, you can't integrate a standard tennis ball into Home Assistant for vehicle presence!
To be honest, this was really just a temporary install that I did for the video. My wife is happy with the old Pi version, and there's no real reason to replace it, as it still works well. And that particular spot on the wall I used doesn't work for either of our vehicles either... again, it was just done for the video or my wiring runs would have been much neater (requirement for the WAF!). But the idea to include the sensor in the same enclosure to reduce wiring is a good one.. as long as the D1 Mini doesn't cause any sort of interference with the TFMini. Not likely, but I didn't test it either.... wifi and EMF can play havoc with some sensors. Finally, I already had an enclosure designed for the current controller and I was both too lazy and spent too much time on designing the firmware, testing distance sensors and writing both the blog and Github wiki pages to create a new case design! But the overall install could be made much neater in a number of different ways. This one will probably come down and the parts will be reused for some future project. I may actually mount it right over the Pi display for a while and see if the wife might like this version better, but she probably won't!
Thanks for watching and taking time to comment! For us, anything that got rid of the tennis balls yet still provided parking guidance was an improvement (and adding Home Assistant integration was a bonus for me!).
I'll play around with it, I'd really prefer the LIDAR sensor be built into the case. That'll be important for my WAF.
Great project! So. Very first time I have ever tried to put something together like this, I have followed the blog/vid instructions but since some of the steps are assumed I need some guidance please. I almost have all the connections soldered. I have some questions: on the following steps- "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. that connection" , this is a onboard connection and does not solder to anything else?" And Step 6. "There's one final onboard connection to make, and this is done on the underneath side of the board.- It looks like you have soldered all those 5v rail connection's together send then did the same with the Neg rail, is that correct? Last thing, you did not really explain how you put the ESP and the LS on the board- What I am asking is, Yes I can see you placed them then soldered each connection but am I supposed to connect any of the other wires I have soldered so far to those components or will the connections already made, make it all work? Thanks for any help. I assume since this is a "circuit" board that kinda answers my question (DUH) but I want to make sure :)
OK... I'll try to help out here as best that I can, but I'm not 100% sure I fully understand a couple of your questions... and I don't want to steer you wrong and have you connect something that results in smoking the ESP or something else! I'm guessing the step numbers you are referring to are from the blog article.
5 - Yes, you are correct. In this case, you are using an onboard connection, basically to connect the GPIO pin (D6) to the LV4 on the shifter. You can use any available hole in the ElectroCookie board for that is connected to the desired pin by the vertical traces on the underside of the board. Look at these traces and it is pretty obvious that they are electrically connected. For example, if you look at "column 5", any thing wired into rows A-E will be connected together. Same for column 5 and rows F-J. So, for this step, you just want to run a wire that connects the D1 Mini D6 pin to the logic level shifter LV4.
6 - What I am doing here is creating a voltage bridge to help with the higher current that the LEDs can draw. The traces on the ElectroCookie are pretty small and are not rated to carry much current. By adding some wire, I'm helping to deal with that higher current. Now, if you are not going to run the power from your LEDs through the board and are going to run 5V and GND in parallel to both the LEDs and the controller board, you do not need to add this extra wiring.
As far as your last question... see the answer to number 5. When you solder the D1 Mini and LLS to the board, they will be automatically connected to the wiring that is soldered to any of the other columns connected by the traces on the ElectroCookie board. This is exactly like a breadboard where things plugged into the same "column" (on each half of the board) are wired together.
I hope this helps. Let me know if you have any follow up questions... or when you get the project up and running!
@@ResinChemTech Thank you for the quick reply!! YES that helps greatly and I think I can move on now, you told me what I figured the answer was, I just am being over cautious since this is my first project!
radar based sensors may be consired as well
Thank you for the awesome video, by any chances adding a buzzer which will have intermittent beep when red while long beep when red flashing just a like a parking sonar？
That's an interesting idea! I added a buzzer to my matrix clock countdown timer that would work similar to this. I did find that I needed to add a 5V step-up converter to boost the 3.3V signal.. as the buzzer was too quiet and weak at 3.3V.
The code changes would be pretty trivial for this (although I'd probably want to add options in the web settings, which gets a little more involved). I will definitely add this to the list of feature requests for this project... but I can't say for sure when I'll have a chance to work on it based on other current projects.
But thanks for watching... and the suggestion. It is an interesting one that no one else has brought up.
@@ResinChemTech I am just order mostly similar BOM as per your blog, will diffinately try out without the buzzer version first! 🙂
This is great. thank you! 1 question: once you park and its turned to a solid red, when / how does it turn off?
The LEDs will automatically turn off and the system will go into sleep/standby mode after the active parking time expires. The active parking time is a time that you specify in the options. You can see all the available options and settings here: github.com/Resinchem/ESP-Parking-Assistant/wiki/05-Using-the-Web-Interface
I tried to build the system to allow it to be customizable via its web interface so you can tailor it to your particular needs.
@@ResinChemTech Fantastic. You thought of everything, well done! It’s good to see practical / useful arduino projects 👍🏻
Wonderful idea, thank you for all of your hard work! I built the project hardware, but when I load the FW, I get this behavior: I can connect via Wifi on the ESP_ParkingAsst SSID, and then set the local network SSID normally. After that, a reset causes the the device to show up in the local SSID network on my router's list for exactly 1 minute, then drop off and go back to creating it's own SSID. During that 1 minute, the device does not respond to HTTP requests or PINGS on the IP address my router shows it has. I bought the Wemos D1 Mini's off EBay, and assumed that this was the problem, so I bought more directly off of the Amazon link above, but get the same behavior on all devices I try. I tried loading the libraries to debug myself, but am getting a ton of warnings and an error. I am using "Generic ESP8266 Module" and loaded WifiManager, ArduinoOTA, ArduinoJson, TFMini-Plus libraries from the locations / authors you referenced. I also added FastLED from Dan Garcia and PubSubClient from Nick O'Leary (my best guess). Anyway, the errors are not missing *.h files, but mostly warnings about using the keyword Register. Here is the Error where is stops compiling: Compilation error: 'D6' was not declared in this scope. Thanks in advance btw!
Sorry for the delay.. for some reason UA-cam threw this in the "held for review" bucket due to 'blocked words'... no idea why, but I just now saw your message.
Well, one think I know for sure is that if you are compiling for 'generic ESP8266', then you cannot use "D" numbers for the pins... you must use the actual GPIO number. Are you using the latest version of the firmware (v0.43), because I believe I changed the pin numbering to no longer use the "D" numbers to give greater compatibility with ESP8266 boards... other than the D1 mini. I know you said you were using the D1 Mini, but it you are using the D pin designations, then you must select the D1 Mini board for the compile.
My gut tells me that the board is bootlooping due to this 'invalid' pin number (even though it compiles). Let me know what version of firmware you are using... and try the latest versions... 0.42 or 0.43 (you might try both) and see if that resolves the issue. If not, drop me another comment here and we'll troubleshoot a bit more.
@ResinChem Tech I really appreciate the reply, I have tried the .42 and .43 bins with the same result. I have not gotten the compiler to work yet, I'll look for the D1 Mini option. There are small differences in thr board silkscreens, and I suspect even the ones I got off Amazon may be an off brand. The parts report ESP8266EX when loading the bins, but from what I have read all but the very first run say this, so I don't think the EX has any significance.
If want to try compiling with the D1 Mini, I originally used the LOLIN(WEMOS) D1 R2 & mini board option in Arduino. But if you are using .42/.43 then there should not be any references to "D" pins anymore... just the GPIO number.
I don't think the "EX" has any affect here, as I'm pretty sure that's what mine say as well. There is a possibility that you do have some sort of bad clone or batch of boards... but I'd like to rule out some other things before assuming that's the issue.
If you like, could you reach out to me via email? There's only so much troubleshooting that we can do here in the comments. You can get my email address from the "About" page on my UA-cam channel. I don't put it here in the comments to avoid the spam bots from picking it up. I'll do my best to help you figure out what's going on... but we are just somewhat limited here in the comment section. Sorry you are having the issue. I do know that many people have successfully built the system, so something different must be going on here.
@@ResinChemTech Ok, progress! I got it to compile and turned on SERIAL_DEBUG. The behavior causing the problem is that, for some reason, wifiManager.autoConnect is returning FALSE even though my router is showing the device is connected to my home SSID clear as day. One time I did get "connected to your wifi...yay!" and everything including the web page worked perfectly for one glorius run! Then back to the old behavior upon restart :( All the parameters I set on the web page are stored perfectly still on boot. Wife is fussing, will investigate more later!
There must be some goofy interaction between my router (a really nice new Asus RT-AX86S) and the Wemos D1. The D1 connects about once every 20 times to my home SSID which is very close in proximity. It actually connects every time according to my router, but the autoconnect returns fail after a timeout. I disabled the wifi and the device works perfectly, my wife is very happy and so am I, thank you again!
Considering all, price included, TF mini is wrong choice. Ultrasonic is way to go. Heck, even ultrasonic and ToF TOGETHER and while averaging out distance is WAY better and safer because you can have redundancy for way less cost...
As I've mentioned to others, my source code is freely available and you can swap out the TFMini and related libraries for an ultrasonic or ToF sensor if you prefer to use those sensors instead. For me, neither of those other sensors work due to the fact that the sensor has to be placed very close to side wall due to an entry door. The FOV for both of the other sensors are too wide and the simply just report a consistent distance of the side wall. I choose to spend the extra $30 or so for what I consider a better and more reliable sensor, at least in my case.
But you are free to substitute your own preferred sensor and modify the code (or write your own).
This a great update to the original version and I would love to build a couple of these. Do you have a ESP32 version of the code? Also maybe add a metric/US units switch on the interface for the rest of us?
I might consider an ESP32 version at some point if I have the time, but I can't promise when that might be. From my end, it then means I have to maintain and support two different versions of the code (the ESP32 requires different libraries and uses a different file structure, so it's not really feasible to have one code set for both ESP types). Just out of curiosity, why do you want to use an ESP32 when an ESP8266 has plenty of 'horsepower' for this particular project... and costs more as well?
As far as the metric vs. imperial units... internally within the code, everything is done using millimeters... the values are simply converted to inches for displaying on the web interface, as the majority of my subscribers are in the U.S. It's really just a matter of taking out the conversions (divide by 25.4 to display on web, then multiply by 25.4 when taking the web entries and converting back to values for the code) and changing the labels on the web page. I could consider adding some sort of switch or option like you mentioned.. and I may do that at some point. But the source code is available in the repository, so you could easily fork the repository and modify just a few lines related to the web page to make everything millimeters or centimeters if you like. Or honestly, since you will only setup the distances one time and won't change them (unless you change vehicles), it might just be easier to take your measurements in centimeters and use an online calculator to convert to inches the one time you have to set up the zone distances. That's how I initially testing the program... I measured in inches, used an online calculator to convert to millimeters and entered that into the code. I would understand if you were having to enter distances all the time... but it's really just when you are initially setting up the system that you need to enter the distances and would need to do the conversions.
But I appreciate the feedback... and will certainly consider both of your recommendations. But when I might have a chance to do so depends on my other project loads and finding the time to make those changes, so I do not know when I might be able to make these kind of requested updates.
I have started to get parts for this project. but i see some newer models of the lidar?MIni-I , worth the extra money? you should do a video and test them heh..also is there a diference in v3 and v4 of d1 mini? thanks.
I'm not familiar with any newer versions of the actual TFMini-s. I can tell you that the firmware has been tested and should work with boards that have either v1.4 or v1.8.1 printed on the back. It should theoretically work with the TFMini-Plus, but I haven't tested it.
The Arudino library used is pretty specific to the TFMini (and the communication format for the TFMini is pretty specific too), so it is highly unlikely the existing firmware would work with any other type of LIDAR sensor... at least not without updating the libraries and possibly the function calls to get distance. Unfortunately, I don't believe there is a library that would work with all LIDAR sensors... so in my case, I opted to use the TFMini-s. You can always try another sensor (like the TF Luna... or one from a different manufacturer), but I almost guarantee that you will need to modify the firmware to make those work.
As far as the v3 vs. v4 of the D1 Mini... I believe the code should still work, but again haven't tested the newer v4. I have quite an inventory of D1 Minis, so probably won't pick any of the v4 up until I've exhausted my current supply. Yes, there are some minor hardware changes (beyond the USB C), but I don't believe there is anything that would cause the code to not run. If you try one and find out that it does or doesn't work, please drop me a note to let me know what you find... and I can share that info with others in the Github repo.
I had a setup like this many years ago: tennis ball on string suspended from the ceiling...
Yeah... me too. Which is why the very first line of the video description says: "Get rid of that old tennis ball hanging from a string in your garage". The tennis ball is definitely an easy low-tech way to accomplish basically the same thing. But what fun is that?
For me, I got tired of banging my head into that tennis ball... or catching a 2x4 on the string when working on a project in the garage. And of course you can't integrate a tennis ball on a string into your home automation system to use as a vehicle presence detector. But it is cheaper to make and easier to install!
I also need a l/r guidance as my parking spot in the garage is tight on both sides
Very nice, thanks for sharing
You are most welcome. This has been one of my more popular projects and I've heard from a lot of folks that have built one for their own garage. It is definitely one of my wife's favorites!
Thanks for watching and taking time to post a comment.
Super project 👍 short question: do you have to connect (+) and (-) left and right on the breadboard (loop through)❓Am Wemos D1 gets but then the connection 3V3 also then 5 volts from the power supply or ?
Thanks. Well, it's probably easier for you to look at the wiring diagram in the related blog article ( resinchemtech.blogspot.com/2022/11/esp-parking-assistant.html ) than for me to try to describe it here in text, because I can't post images in the UA-cam comments. But if I understand what you are asking correctly:
5V is fed to the power rail on one side and the D1 Mini 5V and GRN connect to this to get its power. The other power rail is 3.3V and is fed by the 3V3 pin from the D1 Mini. Only the ground is connected between the two power rails. The 3.3V on the one side is only there to power the LV side of the logic level shifter. Do not connect 5V to this second rail or you will likely destroy the D1 Mini. Again, it will probably make more sense when you look at the wiring diagram in the blog article. But if you have additional questions after reviewing that, just let me know.
@@ResinChemTech One more question: is it not necessary to install a code on the Wemos D1 ?
Yes. The code, along with all the details on how to install it and use the web interface is found in the Github repo, which is linked both in the video description and in the related blog article which I linked to above.
@@ResinChemTech Hi ich finde den Code (Firmware) nicht wo ich auf den Wemos D1 aufspielen / installieren muss ❓
Es befindet sich in diesem Github-Repository: github.com/Resinchem/ESP-Parking-Assistant
Bitte lesen Sie das Wiki für Anweisungen zur Installation.
Danke für dieses Projekt ich habe schon länger danach gesucht. Ich hoffe das es auch mit dem ESP32 funktioniert. LG Paul
Ich hoffe, in Zukunft eine Version für ESP32 zu erstellen, aber ich weiß nicht wann.
@@ResinChemTech Danke für die schnelle Antwort. LG
Can I ask why you'd like to see this on an ESP32, when the firmware runs just fine on the ESP8266? What benefits do you expect to get from the ESP32? I suspect it would function exactly the same.
I only ask this because to create a version for the ESP32, I would have to change multiple libraries and rewrite a good portion of the code. It would also mean that I would have to maintain two separate versions of the code moving forward (an ESP8266 and an ESP32 version). That is a fair amount of work, so I'm trying to understand what benefits an ESP32 would actually offer.
I enjoyed the video, but I loved the chicken sound effect! 😂
Thanks! Long story behind the chicken and why I use it for my channel... but I appreciate the kind words. Funny, but no one has every really mentioned the chicken or asked about it before.
what a really smart idea
Well, it's not quite as cheap and easy as a tennis ball on a string. But I won't bump my head on it all the time when working on projects in the garage! And I can't integrate a tennis ball into Home Assistant.
Thanks for watching and taking time to leave a comment!
The wake distance has a max of 192 inches. It seems to be hard-coded to that. Is there a reason you made it max out at 192? I would like to make it around 250 but do not see an easy config value to change.
The issue is that when the TF-Mini is 'out of range' it returns an error code instead of a distance value.... which would cause all sorts of issues with the logic (and safety). I found the maximum reliable distance in my testing was around 200" (16.6'). To be sure that an error code wasn't returned, I set the maximum distance to 192", or an even 16 feet. If you are using MQTT, you'll also see the max distance reported as 200" when no car is present. This basically means the measurement is 'out of range' of the TF-MIni and it returned an error code instead of distance.
You can certainly try increasing the maximum by removing the limitation on the web page in the code. But you would also have to take steps to handle error return values of something like 32,156 (I don't remember the actual code). You might get away with increasing the limit to 200 (but may still get occasional error), but I think you will have issues with error codes if you try to increase it all the way to 250.
I decided to limit the max to 192 (16') as a safety precaution and to assure the application was reliable. But the source code is freely available if you'd like to try increasing the maximum value.
You should join Mensa
Fabulous job
Thanks! I appreciate it!
Interesting. Course my grandfather hung a tennis ball from the roof so his wife could park perfectly by just stopping when the ball touches the window.
Yeah.. I mention the tennis ball on a string in the very first line of the video description... and it has been brought up by others, along with numerous other "simple" ways to park a car. I used to have a tennis ball on a string in the garage. But I wanted something that was out of the way when working on projects (and not bumping my head into it.. or catching the string on a 2x4). Plus I wanted to integrate it into Home Assistant so that I could use car presence as part of other automations. That's something you really can't do with a tennis ball on a string. And for me, I already had all the parts left over from other projects, so why not!
But it's not for everyone... and that's fine. For some, a tennis ball on a string is a very low cost and reliable way to go.
Oh my, why use a stick the floor, if you can totally overdo it with electronics?
Is this also available in Centimeters? For worldwide replicas except US.
Feet, inches and so on have no meaning for me.
I think if I replaced 25.4 with 10 everywhere it would have to be cm. "# define" can be used for this.
As I mention in the Github wiki, internally the application actually uses millimeters. The distances are simply converted to inches only for the web interface display (and they are converted back to millimeters when the settings are updated from the web page).
Removing those conversions and changing the labels on the web page are pretty trivial matters and I can consider releasing a "metric" version if and when I have the time and opportunity. Or, of course since the source code is available, you are also free to fork the repo and make those changes yourself. To be honest, since the distance settings would rarely change after initial setup (unless you move or get a new car), it would generally just be an simple one time use of an online calculator to do your measurements in cm or mm and convert them to inches for entry in the web app. I wouldn't mind offering a metric version, but it then gives me two different code sets that I have to maintain and update every time I make a fix or add a new feature... the imperial version and the metric version.
Honestly, I wish the US was officially on the metric system like most of the rest of the world. But unfortunately that isn't the case. And since the majority of my UA-cam viewers are US-based, I opted to use the more familiar inches for the application. But I will certainly add a metric version to the list of requested features. I just can't make any guarantees when I will get to it with other current project loads.
I just wanted to follow up on this. After your request (and a few others), the latest release (v0.41) now has the option to show and enter all parking zone distances in either inches or millimeters. The setting can be toggled on the main web settings page and saved as a boot default so that the web application will always use your default unit of measure preference.
Is it possible to build this with a normal HC-SR04 sensor? I have tried different ones and different D1 mini's, but cannot get it to work. The system starts and the LED goes full blue, then the red/green alternate, followed by the outer most LEDs being blue, but no matter what, it is like the sensor is not even connected? I have the HC-04SR Trig connected to TX on D1 mini and Echo connected to RX on the D1 mini.
You'd have to modify the firmware. The firmware is written to work with the TFMini. Using any other type of sensor would require changing the libraries and logic to get a distance reading. The system is going straight into sleep mode (two blue lights) because it is not getting a valid distance reading.
@@ResinChemTech I ended up getting a TFMini and it works perfectly, thank you!
Yeah... the TF Mini does cost quite a bit more, but as I covered in the video, I think it is worth it in this case... both for range and signal stability. I think someone may have forked my code and made it work for the HC-SR04, but I really didn't want to maintain two different versions of the firmware, so I'm only going to continue to provide updates and fixes for the TF Mini version. Glad you got it working... and thanks for letting me know!
How do you get an MQTT device created for this in Home Assistant? I entered all the relative MQTT info in the webpage setup for the parking assistant but I don’t see a device on my MQTT page in HA. If I use MQTT Explorer I can see the device there, so it is communicating properly.
Did you create the MQTT sensors in Home Assistant? These are not automatically created (yet... it's something I'd like to add if/when I get the time). Currently, you must manually create the sensors. See the examples here for how to create the sensors: github.com/Resinchem/ESP-Parking-Assistant/tree/main/examples
@@ResinChemTech I had added the YAML code but it turns out I put it in the wrong file. All good now. Thanks.
I like this project, will keep wife from banging into wall or leaving car too far out and getting hit by garage door when it closes.
Now, if only I can have something guiding her out so she doesn't rip Sideview mirror off car when backing out or in. Haven't had a car in a while that has both Sideview mirrors.
She's not allowed to drive new car into or out of garage.
Ahem. at 9:50, 50 mm is 5 cm, which is about 2 inches, not 0.2 inches... 🙂 I suppose you meant 5 mm?
Yeah... another viewer caught that as well. It was a mistake when I was converting from mm to inches. The minimum is 50 mm and should be listed as ~ 2". I'm in the process of posting a correction on the video now.
Thanks for catching the mistake.
Maybe it was already covered/mentioned but with where the antenna is on this build have you had any Wi-Fi connectivity issues?
The antenna is integrated on the D1 Mini PCB. I have the controller in a 3D printed (aka plastic) enclosure, so it should not interfere with wifi reception. As long as you have a decent wifi signal in your garage, the controller should not have any problem using the built-in antenna. In my case, I do happen to have a Unifi PoE access point in the garage, so wifi signal strength is not an issue. But if you have any other wifi devices in your garage (like a smart garage door opener) that are able to receive a wifi signal, then this device should not have any issues connecting.
@@ResinChemTech Thanks. like you I have a AP in the garage so I was more curious than concerned.
I was considering something like this myself, even though I have sensors front and back on the car, they're too conservative in the car for the required distance I need to be from the garage wall. Do you think the ultrasonic sensor would interfere with the cars sensors, or vice versa?
My wife also has the front sensors and I haven't noticed any interference with the TFMini LIDAR sensor. I have not tried ultrasonic sensors, basically for the reason I cover in the video. The nice thing about the TFMini/LIDAR is that the field of view is very narrow. So, if for some reason there was unforeseen interference, it should be possible to place the TFMini sensor in such a way as it is pointing an area of the front of the car without the sensors.
Again, I haven't tested with ultrasonic, but I haven't seen any sign of interference using the TFMini/LIDAR (and the original Pi version uses the same sensor and has been in use for over 3 years).
Love the project wonder if it would work with a long range ultrasonic and a short range to 20$ in parts vs 40$ I may download and tweak if you don’t mind another fork?
Go for it! I have numerous reasons why I don't want to add an ultrasonic version to my project. Personally, I'm very happy with the TFMini and need its narrow FOV due to the sensor placement in my garage. But mostly, I plan on further enhancing this project when I have time, possibly adding lateral guidance as well... and I just don't want to have to update and maintain multiple versions of the project. So, while I might add something like ultrasonic for a side sensor for providing lateral guidance (not sure yet), I have no plans to modify the current version... or create a new version... that replaces the TFMini primary front sensor with any other type of sensor.
But if someone else wants to fork and make a version that works with ultrasonic, or some other sensor or combination of sensors, that's fine by me. In fact, if you get a working version, I'll happily provide a link to it on my page pointing folks that feel they need or want to use ultrasonic to that repo.
@@ResinChemTech love that idea.
Is there any reason for not using a resistor in the data line to the ledstrip, and a capacitor over the voltage supply to the ledstrip?
Great project BTW, just build it and works fantastic.
You could certainly add either. I've used both a 1000uF capacitor on the 5V supply and have also added a resistor on the data line (mostly with a long parallel run next to the ground), but I also have a lot of LED installs where I've used neither without any impact. So, it is somewhat of a personal choice. You can add either or both if desired without impacting the project.... but it generally also works fine without either option, especially for a project like this one.
I would love to do something liket this but then i have never done anything like this so I would assume it's not a great project to sort of jump into eh ;)
Actually, it's really a pretty simple build and isn't a terrible first time project to try. My related blog article ( resinchemtech.blogspot.com/2022/11/esp-parking-assistant.html ) has wiring diagrams and step-by-step build instructions. Then the Github repository wiki where you get the firmware code ( github.com/Resinchem/ESP-Parking-Assistant/wiki ) has full details on installing the software and how to use it.
The only challenging part might be soldering if you've not done much before. But you can even try creating a version on a breadboard first with just jumper wires (the blog shows an example). Then the only thing you'd have to solder are the leads to the LED strips. And if it helps, check out my channel and I also have an introductory video on using LED strips that could be helpful with that step. But this project would be both a good introduction to using LED strips and microcontrollers. And, as always, I'm here to help and offer any assistance that I can if you have questions!
Is it always on? An improvement may be to add a RF reader and a timer to turn it on only when the garage door is opened
The ESP8266 is always on... but the LEDs can be set to turn off completely when in standby. The idea to only turn on when the door opens is a good one... but there is some delay in the boot up process for the controller to join wifi, setup OTA updates, spin up the web server, etc. It could be anywhere from just a second or two... to 10 seconds or more depending on your wifi and how quickly the controller is able to join.
But it probably takes at least that long for the overhead door to open anyway, so it is a viable option. Of course, if the controller is "off" it won't be available to respond to a "wake up" command. It would probably require an ESP32 running deep sleep and some kind of switch connected to a GPIO pin to wake it. The other option is a smart outlet or switch that would supply power to the controller... and automation would turn on the outlet when the door opens. This could be done with the current firmware. Any other options would likely require mods to the firmware.
For me anyway, the ESP controller and the two pixels lit at the end of the strip (which again, can be disabled via the web options) draw such little power, I'm not sure much would be gained by the time you add other components like an RF reader, reed switch and some sort of controller for the overhead door, etc. In fact, the external components required to turn off the parking assistant might end up using more power than the parking assistant does when it is in standby mode.
Lots of ways to tackle it if you truly want to power down the system when not actively in use. I appreciate you sharing the idea.
The average power usage of the tf mini s is 700mw. Is there a stand by function? For my use case it would be nice if there were a option to activate the tf mini over mqtt when the garage opens and deactivate when closed.
To my knowledge, the TFMini does not have any command to turn it off or to put it into any sort of low power or standby mode. A possible solution would be to add a DC relay to the controller that would kill the 5V feed to the TFMini and use a pin on the ESP to control that relay... enabling it when the door opens, then disabling (or shut off) the relay after whatever time or other event you determine.
But to be completely honest, at 700 mw, that works out to about 0.0168 kWh per day, running 24 hours a day, if my math is correct. That's around 6.1 kWh for an entire year. I know energy costs are different in different areas, but here in Indiana it is about $0.12 / kWh. That means the TFMini, running 24 hours a day for a full year would cost about $0.75... yeah, 75 cents for the year. It would probably take you 6-8 years to recoup the cost in savings that you'd spend for a relay to shut it off.
it would be necessary to add the cost of turning on the leds every time someone activates the proximity sensor (in case it is a transit site)
Yes... and the cost of the ESP8266, which also runs continuously at an average of a few hundred milliamps as well. Then the LED power is very dependent upon both the number of LEDs and the brightness level they are set to. But even with these, I would still say that the entire system, operating under "normal" conditions, such as a car departing and arrive a few times each day, would not cost more than a few dollars a year to operate.
If overly concerned about energy usage of the system, then you might consider a different option, such as a tennis ball hanging from a string, which provides the same basic parking guidance and uses no electricity at all.
Quite the drinker, eh?
So I got all your stuff working on a breadboard but hes my problem. My wife backs up. So I want the lidar on the wall in the "back" of the garage, but the light strip on the wall in the "front" of the garage (so she can see if if she looks out the windshield as shes backing up). Any way to modify it to be one D1 mini connected to the tf mini and another one connected to the light strips? I'm assuming running data wires 30 feet from the front of the garage to the back would be too far.
Also, is there anyway to get deeper integration into HA? Cause I work in the garage, so I dont want the lights blinking everytime I walk in front of them. I was thinking I could put in logic to say if the garage door is closed, then dont turn on. ONLY turn on when the garage door is open. I see your have MQTT settings in there, but I dont see a way I could actually "control" the D1 mini from HA.
Well, there are a number of possibilities, but some would require that you make pretty substantial changes to the code. To use 2 D1 minis, there has to be some way for the one connected to the LIDAR to communicate to the one connected to the LEDs to tell it which LEDs to light up. MQTT would be one option, but it would need to update rapidly and the LED D1 mini code would have to be rewritten to subscribe to the MQTT topics (currently the code only publishes MQTT).
It might be possible to use Home Assistant and automations as a "middle man" for communications between the pair... but again, significant code changes would be needed on both ends. As above, you can't afford any significant delay in the communication or the driver would risk overshooting the parking spot because the LED strip didn't update fast enough.
You might try a bench test and see if you can get a decent signal to the LEDs from the controller at 30 ft or so. With the logic level shifter on board, the data signal may be OK (I'd use larger wire, like 16 or 18 gauge to minimize voltage drop). Similarly, you'd probably want to run the power wires for the LED (+5V, GND) directly from the power supply and not via the board (so run 5V in parallel, with one run going to the controller and the other running straight to the LED strip)... again using the larger gauge wire. Run the long wires between the controller/power supply and LED strip... not between the controller and LIDAR (in other words, keep the controller at the back with the LIDAR). I've had run lengths of around 20 ft. between the controller and LEDs work. If needed, there are signal boosters you can install along the run to the LEDs to up the voltage back up to 5V if needed. Quindor over at QuinLED sells one: quinled.info/quinled-data-booster-for-sale/ You could also use a couple of sacrificial LED pixels along the line to boost the signal, but you'd have to slightly modify the code to not include these pixels in the count process.... this would be a more minor code change than the other options.
If you can get a successful wiring run between the controller at the back and the LEDs at the front, that's going to be the easiest solution. Anything else will require pretty substantial modifications/rewrites to the the current firmware code. Let me know if I can help out any further.. or if you do get it to work with a long wire run.
@@ResinChemTech Thanks for the thorough response. Couple comments/questions...
1. I tested with 36ft of 18 AWG stranded. It seemed to work OK, but when I had the LED's on solid red, they would flicker once in a while. I checked out those boosters but they are sold out. How would I use sacraficial pixels? Would I say, put one pixel between the 36ft run, so at 18 ft, connected +,- and data wire to each end of the pixel? Or would i just need to connect data wire?
2. What are your thought on splitting the difference between the LIDAR and the LED's? So put the box with the D1 somewhere in the middle, run say 10ft of cable to the LIDAR and then 26ft to the LED's?
3. If I went the sacraficial pixel route, but you be able to assist changing the code for however many pixels I needed to use? I guess thats gonna determine if I do that, or wait for the boosers to come back in stock.
As to #1, you are correct.... you would connect all three wires (+5V, gnd and data to the single pixel on each end). Each pixel automatically boosts the data line to 5V before passing down the line to the next pixel... so it acts just like a logic level shifter. Just be sure to observe the data direction (data arrow) on the pixel. If you try to pass the data signal through the sacrificial pixel in reverse, the signal won't be passed on at all.
2. You could certainly try putting the controller in the middle, but I have no idea how sensitive the LIDAR module might be to voltage drop... with either the power or the I2C signal. The spec calls for a voltage of 5V +/- 0.1V. But I'd probably be more concerned about the data signal. All I can say is to try it and see if you still get consistent results.
3. If you just need one sacrificial pixel, you might be able to get away with the code as it is... just include that pixel in the total LED count. It might mean that the 'center' of the LED strip would be off by one pixel. The sacrificial pixel will light up as part of the motion... but you may be able to live with that... and if using the 'standby' feature where the first and last pixel are lit when in standby, the sacrificial pixel will be lit (since it is technically the first pixel), but that feature can also be turned off via the web app. Again.. try it and see if it is acceptable for your use case. Having one pixel on the ceiling (or along the wall depending on how you are running the wiring) that lights up when the system activates may be OK if you can live with it.
I'm just not sure if or when I might have time to modify the code for you, if you are unable to do it yourself. It's not that I'm unwilling, I just a number of my own projects that I'm working on... and I'd also have to build a system using a sacrificial pixel that I could use to test the code changes, as I currently don't have a system built like that. But I'd definitely try the sacrificial route and see if you make it work acceptably, as opposed to waiting on if/when they might be back in stock and paying the extra money. Let me know how it goes... and if you get the sacrificial pixel to work if you go that route.
@@ResinChemTech Added a Falcon F-amp in the middle of a 45ft run. Works good. ua-cam.com/video/YfOawtseR9s/v-deo.html
Thanks for sharing the video! I love to see how others implement some of my projects. Although I am a bit jealous of how clean your garage is... but you can keep all that snow! And thanks for the shout-out and credit!
I haven't used one of those Falcon F-amps before. In fact, I wasn't even aware of them. But it's good to know about them since the Quindor version I recommend is often out of stock. I can throw these out as an alternative now as well.
As a side note, I wanted to ask if you have a Discord account. I started a Resinchem Tech Discord server a few months ago, but right now it is a small group of folks by invite only (I'm not ready to open it up to everyone yet). But there is a good mix of some beginners (to Home Assistant and DIY electronics) to one or two that are pretty advanced. We chat about various projects (or sometimes just misc topics), help each other out when needed and I will often ask for feedback about upcoming videos. If you have a Discord account and are interested, I'd love to invite you into the group. I would just need to get your full Discord handle (e.g. name#nnnn). If you prefer not to post it here in the comments, you can send it to me via email, which you can find on the 'About' page of my channel. Once I have that, I can send you an invite. No big deal if you aren't interested, but I think you'd be a good fit with the folks that are a part of my server.
is there any interference from a cars lidar to the systems lidar? Would they cause crosstalk?
Not that I've noticed. My wife's vehicle has the front end sensors on her car and they have yet to cause any issues as far as I am aware.
Any thoughts about a location where you can't mount them directly in front? The upper corner of the room is an option, but that obviously creates some issues
About the only thing I can think of if the sensor has to be mounted to the side or overhead would be a simple "stop" style for the LEDs. There wouldn't be any approach or countdown, but when the car reached the spot where the sensor sees a drop in distance, it could turn the LEDs on. There would also be no backup... in essence, you'd be reduced to a single "zone"... the park zone, as opposed to the 4 different zones when the car is approaching the sensor straight on.
This particular system would work in that manner (I think), but it would simply go from the standby mode directly to the parked zone, with no wake or approach along the way.
@@ResinChemTech yeah. That's what I was thinking. Unfortunately there is just no practical way to mount a sensor on the opposing wall in my garage. Thanks for the feedback
You can get reasonable ToF devices that go to 4m (call it 3m in reality). That is enough and they are still ca. $6.
The question is whether the ToF would have a stable enough signal. As shown in my testing, the ToF was already the noisiest signal, bouncing around by up to a half inch even when only 12" from the source. I've noticed that as well with the ToF sensors I use on my stair project (although the noise isn't an issue for that particular project). So, it's not just the range, but the stability of the signal... you don't want the signal bouncing around as you approach the final parking zone. The TFMini-s/LIDAR sensor was by far the most steady, consistent signal at all the tested distances when compared to both ToF and ultrasonic.
And of course a ToF sensor would not work with my firmware, as it is specifically written for the TFMini-s using the serial port. But my code is available on Github, so if someone wanted to modify it to work with a ToF sensor/I2C, they are certainly free to do so.
@@ResinChemTech You are right - they can be a bit noisy. However there are two things that are relevant but maybe not considered. 1) use a running average to increase the SNR or even use two ToF sensors (that clears up the visual feedback noise) 2) half an inch is insignificant on something with the physical characteristics of a car. It moves too fast with too much momentum / poor contrrol feedback and the front isn't completely flat. Do you really need to position it to less than half an inch? I would suggest that almost no-one does. So my comment is some thoughts for people to minimise the cost. I always try to minimise the energy usage - just because it is part of the mental challenge of my projects. What might be quite fun is to use the "new" microwave presense detectors that are a few $. Nice project, BTW!
Hey... no problem. I always appreciate ideas and recommendations. I guess I just said what I said because I wanted to state why I picked the sensor I did (my wife's final parking spot is almost 3 ft from the sensor... don't know how much noisier the ToF might be at that distance) and she actually does have a pretty short range for her car to fit just right... (but it is more than an inch!). And my sensor is placed relatively close to a side wall and the larger FOV of the ToF might be an issue (but I didn't test). I also didn't want anyone to think they could just drop in a different sensor or sensor type and get my code to work (and yes... I've gotten comments from those that have actually thought they could). Others have said they built something similar with an ultrasonic sensor and it worked fine. That's the great thing about DIY... more than one way to tackle a project. For me in my situation, the TFMini was the best choice.
And like you, I'm always looking to minimize costs. I've received requests for this project, and others, to create an ESP32 version. And my point is always, why? If the ESP8266 is adequate for the job, then the ESP32 is overkill and you are spending extra money for basically nothing. No one has given me a good reason other than they already have an ESP32 and don't have an ESP8266.
But I do appreciate your comment and recommendation. If folks can build a similar system with a ToF sensor... or even ultrasonic and save some money, then that's great. I just didn't want someone else to see the comment and think they could just swap out the TFMini sensor and still use my firmware. Sorry if I came across as a bit defensive!
I don't have a garage, but now I want one..
I’d be interested in modifying this to be installed on the rear bumper of my old truck. Then it could be something usable even if I park outside of the garage. Would it be reasonable to think that it would work in a mobile application?
I think there are a number of challenges to something like that. First is power... a standalone battery would not last long, but I suppose you could power it off of the 12V truck battery, assuming you stepped down the voltage to 5V for both the controller and LEDs via a buck converter or something. You could use 12V LEDs, but you'd still need 5V for the controller.
The next challenge would be to make everything waterproof. Nothing that I used, from the LED strips to the enclosure (or the sensor for that matter) is waterproof and would not stand up to rain, snow, etc.
Finally, the system is only designed to work with WiFi... not cellular data. That means it would only be possible to access the settings when at home and the wifi is available to both the device and your phone/laptop, etc. While the system should technically work without wifi once configured, I actually haven't tested what would happen if wifi was suddenly removed after it was running. I don't think the code would crash... but again I haven't tested it.
I also don't know how the sensor would work or be impacted in various environmental conditions... rain, fog, direct sunlight, etc. Not the kind of things that it would experience inside a garage. I think all in all, it would probably be better to take the general concept of what I've done and build something more suited for mobile use... as opposed to taking what I have shown and trying to make it work on a truck or car.
@@ResinChemTech Thank you for the thoughtful response. I’ll start with building the garage version and see what ideas it sparks in the process. You’ve done a really nice job with this project. Well done.
Thanks! My video "production" really didn't do it justice. But let me know if you run into any questions or problems during your build. Good luck... and let me know if/when you get it done!
Good Job.👌
My garage is not heated. Do you think that this would be an issue? Sub zero for extended periods.
As a general rule, heat is a bigger problem for electronics than cold. But all components list a temperature operating range. Just from a quick glance online, the TFMini sensor shows a working temperature range between 0°C and 60°C. The D1 Mini lists its minimum operating range as -40°C and WS2812b LEDs show a minimum operating temperature of -25°C (for the LED pixel, not necessarily the strip). You can find the minimum operating temperature for the rest of the components online, but it looks like the TFMini sensor is probably the limiting factor at 0°C. It might continue to work below this temperature, but may not be reliable.
If your garage or parking area is subzero for extended periods, I don't think you could rely on this system to operate normally and consistently, primarily due to sensor limitations.
Great project. Made one too, connected everything, can open the web interface but can't save the wifi setup and connect to my router. Can you help me please? Tfmini S is connected.
By web interface, are you speaking about the wifi onboarding app via your mobile phone, or the settings web page? The settings web page is only accessible if you have completed the onboarding via your phone. Just to verify, have you followed the steps in the 'First Time Setup' section of the Github wiki? ( github.com/Resinchem/ESP-Parking-Assistant/wiki/03-First-Time-Setup ). There is also a troubleshooting section in the wiki that has some steps to follow if you have issues with the web/wifi setup.
Do note that there is one open issue as well that has to do with wifi. There can sometimes be an issue if your wifi SSID has special characters. This is a limitation of the wifi library (not mine) that is used. You might also check out that discussion about wifi in the Github issues and see if it appears this might also apply to you.
It's hard for me to provide much more assistance based on the information you provided. However, if you continue to have problems after reviewing and following the steps above, could you post more details in the 'Discussion' area of the wiki? There is a Troubleshooting and Assistance category available. It is easier to provide help there, since the UA-cam comments prohibits posting of things like images, diagrams, code blocks, etc. I'll do what I can to help.
Thanks for your fast reaction. It's the onboarding app on the phone. After I select the ssid and fill in the password and save, the board does not reboot and does not connect to the router. My password contains some special signs.
Hello. Did some extra testing. It is the ssid name that causes the problem and not the password. I set up a guest network with the same password and it works, I could connect without any problem. My ssid has 12 caracters what seems to be the problem. I'm able to set up the parkassist but can't integrate it in homeassistant. Hope this problem can be resolved.
Well, I'm glad you were at least able to locate the issue (and thanks for updating me). As you probably saw from the Github issue, this is an underlying issue with the wifi library used. This is not something that I developed or control and I'm not smart enough to create my own! The issue has also been posted in the Github for the wifi library and I am watching closely for a fix. As soon as a confirmed fixed is released, I'll update my code to include the fixed library.
But unfortunately, there isn't much I can do on my end until the developers of the wifi library repair the issue on their end. If/when that happens, you'll see a new release for the parking assistant published in my Github, and it will state that the wifi SSID problem has been fixed.
Thank you for sharing this project! I used esp flasher and put your latest bin file on a node mcu. I have the node mcu on a development board. The node mcu has a esp8266 chip. I am able to join the AP and enter 192.168.4.1 and then enter my wifi network information and enter that I have 36 pixels. The node mcu then reboots and I can't ever find it again... My router doesn't see it either. I do have the TF Mini installed as well. Any ideas?
There could be a lot of potential causes here. First, do you have the latest firmware (v0.41)? Versions of the firmware prior to v0.40 had issues with some of the newer versions of the TFMini-s sensor... but this has been fixed.
If you no longer see the device in your router, can you see if it is broadcasting the hotspot again (ESP_ParkAssist) when this occurs? This most likely means it is not joining your wifi network successfully. Your SSID and password must be exactly correct. If, after entering your wifi information, the board restarts but cannot join your wifi, it will not be seen in the router and will start rebroadcasting the hotspot. Also assure you don't have any firewall or other network settings that might prevent the device from joining your wifi. Based on what you describe, failing to join your wifi seems to be the most likely cause.
Next, you might want to try reflashing the firmware again (using the latest v0.41), assuring you use the option to erase the current flash if your flashing software has the option. I did have a couple of situations that the controller went into a boot loop after flashing, but flashing again (with the same firmware) solved the issue. I don't believe this is your problem, as it would happen right when the board powers up and not after entering wifi information, but it is worth a try, as occasionally a flash doesn't work quite right. It's also a remote possibility the board you are using is bad. Assure the board has at least 4Mb of flash memory.
Assure you have the TFmini wired correctly. TX goes to RX and RX to TX. Reversing these will cause all sorts of issue.
Finally, while I have not tested with a NodeMCU (just the D1 Mini), it is at least possible that your board doesn't match up to the same GPIO pins. For the D1 Mini, TX is GPIO1, RX is GPIO3 and D6 is GPIO12. Make sure these match with the pins you are using. Try out the above suggestions and let me know. If I get the chance, I'll also see if I can try hooking up a NodeMCU and make sure it works correctly for me. But I do know that a number of others have successfully built the system using the D1 Mini.
I wanted to follow up and let you know that I just released a new firmware version (v0.42) that attempts to improve the compatibility with some generic ESP8266 boards and I also opened up a Github issue related to what appears to be an incompatibility with some NodeMCU boards. You might try this new firmware as well as the other suggestions I made. I do know that the D1 Mini works well and multiple others have reported success using that board.
@@ResinChemTech It works! I reflashed with your update v0.42 everything works on the software side. Now I will install!
Great! Glad that fixed it. Thanks for letting me know.
It’s a perfect project as I have left over Node MCUs, ws2812 remnants, and aluminum strips, and diffusers, and wiring from Christmas lights and ambient TV lighting projects.
Thanks!
Wow! Thank you so much! I'm glad you liked the video and the project. I really appreciate the support and it will go towards funding additional project like this one.
can someone give me this project working with ultrasonic sensor?
10 out 10 bro
Thanks! Much appreciated!
I am going to install it in my BMW.
can i do this with esp32 and a hub75 matrix ?
Most likely... but you'd have significantly rewrite the current firmware, both to support the ESP32 and to interface and output to the matrix display. The current firmware will not do either one of those things, but the source code is available on Github if you want to use it as a starting point.
Would this work with an ESP32 chip?
Not as the firmware is currently written. Different libraries are needed for the EP32. I most likely will not develop an ESP32 version as I personally don't see any advantage. The project runs fine on an ESP8266, so an ESP32 would really just be overkill and would result in spending extra money for something that really doesn't provide any additional benefits.
Now, if somewhere done the road, I developed a new version that used a secondary side sensor to provide some sort of lateral left/right alignment, a move to the ESP32 might be needed. But I don't currently have any plans for that. Is there a particular reason that I've overlooked as to why you might want to use an ESP32 with this project?
I have no particular reason other than I had an extra WLED controller with an ESP32 chip and wondered if it would work. I thought I could make a second unit for a different vehicle bay. I appreciate your answering all my questions and being so helpful! Thank you!
Would you be able to use a dig uno to build this?
I don't believe this would be possible for a couple of reasons. First, I think that the DigUno (ESP8266) makes both the RX/TX pins available but these are used for LED data and are level shifted, so you would not be able to connect the distance sensor. I also believe it does not expose GPIO12 (D6) that the parking system uses for the LED data line... although this last one could be changed if you edited the firmware and compiled your own.
Finally, the firmware currently does not work with the ESP32 so you could not use the ESP32 version. I'm not up to date on the current revision of the DigUno, but from my own older version and the current info on Quindor's site, I just don't think that the DigUno could be made to work with this project... not without extensive modifications to both the DigUno and the firmware code.
I wanted to follow up on this, as another user, @HayMark, did figure out how to make this work with a DigUno... and without the need to modify the firmware. According to him, to make it work you need to:
1. LED data to Q3 on the Dig-Uno
2. TFMini RX into the GPIO3 on the Dig-Uno
3. TFMini TX into the L1 C port on the dig-uno
4. I combined the power/ground for the tfmini and the LED strip and plugged into the Dig-Uno. I probably don’t plan on keeping it this way but it works for testing.
He also has some photos of the connections here: photos.app.goo.gl/fUdDYQVKkKSnwrkw9
So, my apologies... apparently it can be made to work with a DigUno! And a big thanks to @HayMark for figuring it out and sharing how he did it. But please note that this is the D1 Mini/ESP8266 version... the firmware will not work with the ESP32 if that's what you currently have with your DigUno.
I need something that get's the wife able to back into the garage. Got anything?
After i connected the D1 Mini to my WIFI i am n ot abel to reach the webinterface. what could the problem here? thank you in advance for your help
There are a couple of things to check. First, assure that your device (e.g. phone, tablet, laptop, etc.) is on the same wifi network that you selected for the D1 Mini/controller.
Next, assure you are using the right IP address, which you have to get from your router after joining the wifi network. This will not be the original 192.168.4.1 that you used to initially setup the wifi, but a different IP that is assigned via DHCP by your router or whatever device you are using for DNS on your network.
Finally, check that the D1 Mini/controller is no longer broadcasting the original ESP_ParkingAsst hot spot. If you can still see this hotspot via your phone, that means that the controller did not successfully join your wifi. Try the initial setup again, assuring that you enter the wifi password correctly.
Let me know if you continue to have issues.
thank you very much for the quick reply. i can see the esp in my router settings and its online but i am not able to communicate. i have no idea what else i can do.
moreover i tryed differnt D1 mini. same issue
When you first power up the system, are you seeing the normal "boot" process... solid blue lights for a few seconds, followed by red & green lights for a few seconds? If you do not see these lights, then the boot isn't completing... and the web interface will not be available. This is most likely due to a problem with the TFMini-s connection. The TFMini must be connected and communicating on the serial port for the system to operate normally.
so, i'm not able to see the web interface and the start sequenz of the LED. But unfortunately thats it. There is no further reaction of the led stripe. The TF Mini light up a little. Did i do somthing wrong?
Ok... if you are not seeing the boot/start sequence with the LEDs, then you most likely have something wired incorrectly. Carefully check your wiring, being sure that you did not mix up the RX/TX wires from the TFMini to the D1Mini. RX should be connected to TX and TX should be connected to RX. If in doubt, use the connector that came with the TFMini to confirm the pin order on the TFMini and wire colors used.
Sounds like things are almost functioning. Once you see that boot sequence on the LED strip (blue followed by red/green), you should be able to access the web interface.
hi, I can't find the code for esp. I can't open the page :(
I verified that the link in the video description is correct, but here it is again: github.com/Resinchem/ESP-Parking-Assistant
@@ResinChemTech Oh thanks. this is a very interesting project.