- This topic has 4 replies, 3 voices, and was last updated 3 years, 8 months ago by
.
-
Posts
-
Hello everyone!
I have just received the opengarage module (amazingly fast delivery to Czech Republic, wow :)) and am wondering how to do some modifications. I would like to use the magnetic switch for detecting the garage door state and still use the ultrasound detection for a car presence. And also would like to add infrared beam to detect, if there is anything blocking the door (For example the car parked half way to the garage). Any tips, ideas or suggestions? I may be not the only one interested…
Right now I have some basic garage door monitoring using UBNT mFi door sensor and motion sensor detecting movement in the garage so I am not being notified about open door when there is anyone inside. But I wanted to add auto-close feature, just a little more intelligent.
Thanks for any responses
Support for magnetic switch has already been added a while back:
https://github.com/OpenGarage/OpenGarage-Firmware/releases
In Options->Basic tab, Sensor Type, you can see options for switch sensor. It should be wired to GPIO4 and GND. Please note that in some early versions of OpenGarage, GPIO4 and GPIO5 are mistakenly reversed. So in case GPIO4 doesn’t work, try GPIO5. These pins are located above the distance sensor, marked GP4 and GP5.If you want to add other sensors, you will need to modify the firmware to support those.
Thanks for the reply. I have noticed the support for magnetic switch has been added already, but this seems to disable the ultrasound distance sensor. So I’ll need to modify the firmware and web interface anyway. Unfortunately I don’t have any programming skills yet, so this will be a learning lesson 🙂
I have few points for the firmware improvement:
1) the ultrasound sensor would report the door being closed, even if they will not close fully (ie. something is blocking the door to fully close) and will report as closed even they are not. Not sure how the motor handles that – did not try yet and could be different for each vendor. Will the door fully open when something is blocking from full closure or will they eventually just stop and keep half way open? The magnetic switch could report the door is fully closed – so would be nice to be able to have a combination with ultrasound sensor and also monitor the car presence.
2) IR beam to check if the car (or anything else) is not in between the door way. This will work the same way like magnetic switch, so pretty easy to implement
3) PIR motion sensor. When I am working around the car with the door open, I don’t want it to close automatically.So according to the below I have only GPIO4 and GPIO5 available for custom sensors and one analogue PIN. GPIO0 is not available? I have seen it on the PCB. What button is this mapped to? There is only one reset button mapped to GPIO16
GPIO 0: BUTTON
GPIO 2: LED
GPIO 4: SDA (spare)
GPIO 5: SCL (spare)
GPIO12: SENSOR TRIGGER
GPIO13: BUZZER
GPIO14: SENSOR ECHO
GPIO15: RELAY
GPIO16: RESET (tied to reset to trigger hardware reset)
A0 : ANALOG PIN (spare)“but this seems to disable the ultrasound distance sensor” — that’s correct, it assumes that you are using one or another, not both, since if you are using both, then it needs to know the logic of the two difference sensor results (AND, OR, or something else).
About your suggestions:
1. Because the ultrasonic distance sensor only senses distance at one spot, you are right that when it’s reporting closed the door may not be fully closed. The solution is to move it close to the door so that as soon as the door is up a little bit, it can sense the distance change. In most cases, the door is fully closed or fully open (unless if there is a power break, or if someone manually stopped the door from closing).2/3. You can add more sensors but the ESP8266 microcontroller has quite limited number of GPIO pins. You have correctly labeled the pins that are used and are spare. GPIO0 and GPIO2 are not usable for sensors: for one, GPIO0 is connected to button, and GPIO2 is the built-in LED, so they are not spare pins; in addition, these two pins must be remain HIGH during booting, otherwise ESP8266 will not boot successfully, for that reason, they should not be used for general purpose sensors since we don’t know the sensor status at booting time.
GPIO16, however, is a spare pin — in the original design it’s tied to RESET to allow hardware reboot, but since then I’ve found that this is not necessary as we can use software reboot. So if you cut the trace of it from RESET pin, then it becomes a spare pin.
GPIO4 and 5 are spare pins and they are also the default I2C pins so they are useful for connecting to I2C sensors or I2C io expanders if you need a lot of more spare pins.
- You must be logged in to reply to this topic.