I saw that, I was wondering if there was a header on the board or if needs to be soldered to the ESP module. I can’t seem to find a high resolution image of a board to see what the labels are.
im sorry, but i have no idea. the thing is, i had designed my own board and flashed it with the firmware. My design look like this
2 Likes
I’m actually in the process of planning to do something like this in my garage. I don’t quite have the same space beside the garage door you have, so I am opting for a (slim) 12v battery (I’ll run a solar charger to it), driving a RF controller which can be FOB operated, or via my RPi in the garage…to a linear actuator. It will push/pull the handle on the deadbolt.
The RPi takes care of opening/(auto)closing the garage door for those senior moments I have, and is part of the alarm system (door is sensored). I will then have the garage automagically go into lockdown mode if we are not home (and armed alarm mode).
I’m also dreaming of some sort of RF or Bluetooth beacon inside the car (ideally would only be powered on when car is on) which is set to a very short range, and will detect arrival at the garage and will bring the garage motor online (I remote disable it), unlock the deadbolt, and open the door.
Never seen a deadbolt on a garage door before!
1 Like
Did you ever happen to throw this up onto thingverse? Would love to have it if you could!
Has anybody tried using more than one HC-SR04 sensor to keep track of multiple cars?
1 Like
I ordered the passive buzzer, but mine is still running at all times. This is the one I purchased: https://www.amazon.com/gp/product/B0777P6FN5. It looks exactly like the one Dave said he is using that works. Is there something I’m missing?
Anyone using this in Homekit? I’m running into a problem of false notifications.
In the Home app, if I press the garage door button to open the door, the button status quickly changes to “opening” and then almost immediately reverts back to “closed” status which triggers a notification on my phone “Garage door was closed” even though it’s still in the process of opening the door. After about 12 seconds once the garage door is finished opening, I receive another notification saying “Garage door was opened”. The opposite happens whenever I close the door. However, in HA the states are reported perfectly.
Just trying to make the wife happy with my new gadget but she’s not loving it.
To add, my current setup is connecting OpenGarage to HA using the native platform and example config, then pushing this out to HomeKit for use on the Home App with iPhone and CarPlay.
I was able to solve my issues by using MQTT instead of the built-in component. If anyone is interested in going this route here’s the code I used to get it working:
Add to your configuration.yaml
cover:
- platform: mqtt
name: "Garage Door"
command_topic: "youropengaragedevicename/IN/STATE"
state_topic: "youropengaragedevicename/OUT/STATE"
state_open: "OPEN"
state_closed: "CLOSED"
payload_open: "open"
payload_close: "close"
device_class: "garage"
sensor:
- platform: template
sensors:
garage_door_status:
friendly_name: 'Garage Door Status'
value_template: '{{states.cover.garage_door.state}}'
Add to groups.yaml
garage:
name: Garage
entities:
- cover.garage_door
- sensor.garage_door_status
3 Likes
Hi,
Are you able to open/close the garage using this? when i press open/close nothing happens with the garage. I see the values publishing in mqtt topics. Doesnt it need the devicekey to open/close the garage door?
./Sooraj
For even more fun here is another MQTT (yay for no polling!) example with a vehicle state entity and distance entity. This requires a version of the firmware that reports the distance to the /OUT/DIST MQTT topic.
- 80 is my door threshold
- 150 is my vehicle threshold
- a compatible firmware can be found here (thanks @gabe565)
- platform: template
sensors:
garage_door_status:
friendly_name: 'Garage Door Status'
value_template: '{{states.cover.garage_door.state}}'
garage_vehicle_state:
friendly_name: "Vehicle State"
value_template: >-
{% if states.sensor.opengarage_distance.state | int == 0 %}
Disabled
{% elif (states.sensor.opengarage_distance.state | int > 0) and (states.sensor.opengarage_distance.state | int <= 80) %}
Unknown (Door Open)
{% elif (states.sensor.opengarage_distance.state | int > 80) and (states.sensor.opengarage_distance.state | int <= 150) %}
Present
{% else %}
Absent
{% endif %}
- platform: mqtt
name: "OpenGarage Distance"
state_topic: "OpenGarage/OUT/DIST"
unit_of_measurement: "cm"
cover:
- platform: mqtt
name: "Garage Door"
command_topic: "OpenGarage/IN/STATE"
state_topic: "OpenGarage/OUT/STATE"
state_open: "OPEN"
state_closed: "CLOSED"
payload_open: "open"
payload_close: "close"
device_class: "garage"
Then groups.yaml can have this or whatever:
garage:
name: Garage Door
entities:
- cover.garage_door
- sensor.garage_door_status
- sensor.garage_vehicle_state
- sensor.opengarage_distance
1 Like
Yes, the OpenGarage always requires a key to actuate its relay.
Apologies for the stupid question, but do I need to bespoke the code at all? I saved the file into HA following the instructions and rebooted HA but I still have the issue than the “Opening” state remains in HA despite the door being “Opened” or “Closed” within the Opengarage local network interface. Only a reboot of HA solved it this morning.
Thank you, I hadn’t appreciated that (clearly!). So I can remove the file by the sounds of it. I’ve had greater reliability today as a result of increasing the the door threshold distance - I think the ultrasonic sensor is rather inaccurate in this weather and allowing for a significant margin of error seems, at least today, to have resolved my issue.
I think they can be temp dependent, but I am not sure what weather you have. Beautiful summer day here 
One other thing to check is the usb charger you are using to supply power. I had issues with mine varying by about a 1m over subsequent reads, which would cause the car in garage reading to go in and out constantly.
My 1A usb charger was not providing stable/clean/sufficient power to the unit and it was causing the problem. Replacing it with a 2A charger (despite their webpage saying 1A is fine), it fixed it straight away.
Thank-you for sharing - got this working tonight. Great to migrate to MQTT.
is moving to MQTT better for the hardware (ie. loss polling) ? If so, I would like to try to get this working.