Hi @SteveZed
I wanted to ask if at all possible, do you have any issues with the readings of your system, not working. I have mine setup on my garage roof, very similar to yours and I am having a strange issue. When my car is in the garage the reading from device to car roof is between 98cm and 118cm (not sure why it hops around) , then today when I left I checked the logs and I saw one reading of 212cm, which is correct as there is no car in the garage. then about 2 minutes later the reading went to 98cm and says the car is present and has stayed that way, but the car is not in the garage???
These are my readings in an empty garage over +_8 min
Mine does jump periodically, but for just one cycle of readings. I am using mine for a condition, not a trigger so it's not much of an issue for me although I was wondering what the root cause is. Could be a component quality issue as people use these types of sensors for robotics and they would have to be more accurate than this. It may also be that the Wemos runs at 3.3v and the sensor at 5v; I am going to try putting a signal level shifter in to see if it helps.
Thanks for the reply, please let me know if you have any success and what would need to be changed, I would really appreciate that. Also wanted to ask, I was looking online and one site suggested that the accuracy is up to 1.2m? My Garage height is 2.2M could this also cause a problem or are these more accurate than 1.2m height (Sorry I know you work in inches)
I have thought about this and I see 2 ways to possibly improve the results:
Get a better ultrasonic sensor. Apparently there are several sensors that are supposed to be more accurate than the HC-S04, like the US-100 and HC-SR05. The US-100 also works on 3.3V or 5V logic. I am going to order a US-100 and try it.
Improve the child driver to do better range checking and/or software debouncing. In my case, I only get false presence when the car is not present because the strange readings are only ever less than the actual measurement. Right now, the driver only has a threshold for present/non present. If we said that the present and non-present measurements had to be in a specific narrow range, the driver would not generate presence changes from non-valid distance readings. Coupling that with logic which says that you need two in-range readings in a row before changing the presence status should eliminate the false status changes.
My review of the specs on these modules show that they are supposed to be accurate within 3mm. They are, however affected by temperature which impacts the speed of sound on which the measurements are based. I think the US-100 has a temperature sensor and compensates.
Hi @SteveZed
I have the HY-SRF05 sensor, and this is the one giving me bad reading when over 200 cm. I have read about a library called NewPing which can be used with the Arduino and the ultrasonic sensors, it then does iterations (takes 5 readings so 1 dodgy one wont cause issues) . I even just tried this software and I still don't get good readings over 200 cm. I have looked on may sites online and they all say the my sensor should be good up to 450 cm ?????
I have been away for a bit but have come back to this. I looked at the NewPing library and modified the Hubduino PS_Ultrasonic sketch to include it. When I set the number of readings to 10 for averaging, I get fairly consistent results over time (a variation of only 1 centimeter), and sometimes several hours between changes when the car is stationary.
I also found out what I think was causing my issues is the 5v power supply's. When I measure these the actual volatge at the ultrasonic sensor is only 4.55v. I found a 5.3v power supply and this sorted out the erratic readings.
The power supply being a culprit makes alot of sense, and had not occurred to me. I will have to take a look at mine and see what voltage is being put out.
Sorry if it's a noob question, but I have some basic EE skills and a few ultrasonic sensors lying around. do you have the design diagram and component list? especially the case you got and breadboard that fit in it?
thanks in advance, and apologies if I missed it posted elsewhere
I posted this a while ago but think it' worth a repost because it works so well and was so easy to do. The infrared sensor is ridiculously sensitive...no fobs in car, just simple beam-crossing
a Seco-Larm E-931-S35RRQ Enforcer Indoor/Outdoor Wall Mounted Photoelectric Beam Sensor with 35 Foot Range https://smile.amazon.com/gp/product/B001LFPB0M and you can mount it any which way you want with the provided mount. And with the lights, I can just look up from the car and know when to stop (red light).
I have wanted a garage car presence device for a long time and I have been looking for a device to buy to do the job. Couldn’t find a device reasonable priced that I thought would do the job.
I recently installed HA on a RPi (again) to be able to add my Verisure alarm and Ngenic climate control. While doing that I looked into ESPHome and decided to try a D1 mini and a HC-SR04.
Those two boards are like 15€ so even if i couldn’t get it to work, it’s nothing to cry over.
HA has become a lot better and easier to use since I last used HA by the way…
I was really easy to get ESPHome onto the D1 mini and get the ultrasonic sensor working was a walk in the park.
It works very well and I love that I don’t have to close my garage door when backing out of my garage. I have also made a rule that close the garage door and arm the alarm when the car is out of the garage.
I did modify the Hubduino driver to accept a range of distance values because the ultrasonic sensor is prone to jittering. I added them as preferences:
I pretty much never get false readings now. I think I also changed the Arduino ultrasonic library to one called NewPing which did averaging on the readings before reporting them.
Here it is: Dropbox - user_driver_ogiewon_Child_Ultrasonic_Sensor_705.groovy - Simplify your life
I haven't bothered to change all the comments in the header. Just be aware that if you refresh your Hubduino drivers from the source, this driver will be overwritten; it uses the same name as the existing Ultrasonic driver to keep the dependency changes down.
