Garage Car Presence Sensor & Button Recommendation

why not use your phone as the presence device?

I only want it to open when I’m returning with my car. If I’m coming back from say a walk, I don’t want the presence detection on my phone triggering the garage to open. Would just result in an unnecessary open/close of the door.

1 Like

That sounds pretty interesting @SteveZed! Sounds like something worthy of a write up!

1 Like

trouble with phones is if they take an update or reboot or just lose connection and reconnect they could open your garage door in the middle of the night.
Powering a device off until you need it is more secure.

1 Like

Basically, I took one of these and mounted it in a box connected to one of these and mounted it to the ceiling above the car (note that the opener is plugged into a Zwave module which shuts off the opener at night or when we are away):


I did it that way instead of measuring from the front of the car to the back wall so that the sensor wouldn't get crushed if someone pulled in to far, or get a wrong reading is someone leaned something against the sensor. A close up view of the sensor :
.

I used the Hubduino ultrasonic sensor code for the Wemos, but changed the HE child driver so that it just showed the distance to the car (the original driver calculated how many gallons are in a tank by the height of the liquid inside.) I added a variable for the maximum distance to detect the car since we change cars every so often:

5 Likes

Hi @SteveZed
I am going to try this setup you have, I have never worked with or on any Arduino hardware or software before so could be interesting. Do you have any tips or links I could follow to get this working. Also what Hubitat drivers did you use to integrate this. Sorry very green with all this.

Thanks

Okay, have managed to add the D1 mini and ultrasonic sensor to the Hubitat, @SteveZed please could I ask you for the HE child driver you modified as mine also shows the number of liters and I just want it to do what yours does with the distance in centimetres if possible. I would be very grateful.

Check out my reply to your other post in the HubDuino thread. The built in HubDuino Child Presence driver will allow for a numeric ‘level’/‘distance’ value to trigger a presence status change.

As an update I ended up getting both the Nanomote and an Xbee. Nanomote works well and the Xbee setup as an arrival sensor is even better. Appreciate the suggestions!

Now I just need to find some sort of box to put the Xbee in, it’s just in a plastic bag, in my center console, at the moment, and that’s not ideal.

If there’s a suggestion on an appropriately sized project box for those that are using an Xbee I’ll take that feedback as well. (@NoWon @rsjaffe)

In my post (link follows) I describe the project box I used and the drilling pattern:

1 Like

I have included my modifications below.
https://github.com/zedly99/Hubitat/blob/master/child-ultrasonic-distance.groovy
(How do you get a preview of a hyperlink to show?)
I actually altered the Arduino code to show the distance in inches, but that's not necessary and forks too any different pieces of code. The distance in this driver is in CM.

1 Like

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

level 104.84 DEVICE 2020-07-07 15:32:41.061 SAST
level 97.83 DEVICE 2020-07-07 15:32:32.696 SAST
level 104.84 DEVICE 2020-07-07 15:31:35.617 SAST
level 97.75 DEVICE 2020-07-07 15:30:30.778 SAST
level 92.04 DEVICE 2020-07-07 15:29:26.106 SAST
level 95.20 DEVICE 2020-07-07 15:28:21.486 SAST
level 125.92 DEVICE 2020-07-07 15:27:35.006 SAST
level 95.88 DEVICE 2020-07-07 15:27:16.749 SAST
level 103.75 DEVICE 2020-07-07 15:26:12.055 SAST
level 99.93 DEVICE 2020-07-07 15:25:07.506 SAST

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.

1 Like

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)

Please could you post your sketch you used for your mini. I would like to try yours on my D1 mini and see if it is any better.

I have thought about this and I see 2 ways to possibly improve the results:

  1. 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.
  2. 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 think the biggest impact came from changing the device handler to indicate Presence or non_presence based on a narrow range:

This has kept the outlier values from impacting the status.

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.

1 Like

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.