After having problems using an WemoMaker i changed my garage door opener to a wemos D1 mini esp8266 dev board with a relais shield. I documented the project, the OH2 config and the firmware here: https://github.com/kohlsalem/GARAGE
SInce I’m still quite new in the OH business i would be happy for any improvement ideas. I’m already aware of:
I could have commented the Firmware better
I could have made IP of openhab configurable in the firmware.
Both is on ToDo.
As well I’m aware of
Use MQTT. I do not see real reason to add this complexity.
Nice project. Always fun to make something work better than it did and it’s very satisfying to produce code to do it.
I implemented my own garage door opener on a old Craftsman that operated with a remote or a wall button. I used a Wemo switch and a Digital logger AC sense relay. Using the Wemo and Expire bindings I created a virtual momentary switch item for control. Very simple mod with no code and no custom case required. Total cost > US30. The positive is that it really only required a couple of minutes to connect the hardware and a few minutes to set up the item in OH. The downside is that an alternate software solution will be required if I move away from OH in the future. It would work with the Wemo app only, but you’d have to manually turn the switch on/off to activate the opener.
I’m going to add one or two reed switches connected to an ESP8266 for a separate door status monitor, independent of the opener, with its own item. Safety sensors connected to opener already prevent closure in case of an obstacle, so the primary concern is security.
Of course, with a single switch, one can only tell OPEN/NOT OPEN or CLOSED/NOT CLOSED and all other states are a guess. Adding a second reed switch could provide the ability to have 3 definitive states, FULLY OPEN, PARTIALLY OPEN or CLOSED. Using 2 switches, you would only have to worry about the PARTIALLY OPEN case. Save the previous known state. Then you can easily indicate CLOSING or OPENING. If either of these states persist longer than a known required time, perform error handling using the saved prior state.
If I use only one reed switch, it will definitely be to monitor CLOSED/NOT CLOSED and I wouldn’t try to determine any other state. I currently monitor the door with an IP camera, so I’ll have 2 methods of verification once I add the reed switch(es).
It is absolutely true, a second switch gives more clarity. However, in reality i had no negative impact so far. I can easily ENSURE that the door is closed while beeing remote (or open from the inside), I can solve any intermediate state (only loosing up to 20 seconds) and i can close the door - unless nothing blocks the door.
So, to my own biggest surprise the state machine has already most of the benefits of a separate hardware.
I can never ensure “IS IT REALLY FULLY OPEN!” - but this is not a real issue of mine…
therefore…
I wonder myself if there is a smarter way of configuring items and so on…
