I’ve built a 1.x binding for Garadget - garage door futurizer, a clever device that brings your non-IoT garage door into the future. The device measures reflected light to have positive feedback that the door is closed. From the Kickstarter:
Cloud-enabled controller for existing garage doors: monitor and operate your garage doors from smartphones, wearables and other devices
I think it’s a great device for modifying all those existing garage doors so they can be controlled remotely. It does use the particle.io cloud API, but if you keep your login credentials safe from prying eyes and your Internet connection is reliable, I think your case of cloudophobia will clear up quickly.
Seriously, I rely on both Nest and Ecobee cloud services to control very remote heating systems, and they’ve never let me down in terms of security or availability. And connecting to devices that are somewhere else on the Internet from where your openHAB server is, cloud access is much more convenient, and possibly more secure, than relying on your own VPN or punching holes in routers.
The binding has the side benefit of allowing access/control for any Particle devices anywhere in the world (using wi-fi or cellular networks), so it’s not just for garage door devices. I will be writing an openHAB 2 Particle binding that adds discovery of devices and their variables and functions, so you could deploy your own devices anywhere and monitor and control them from openHAB.
I’m not certain that’s true, but it might be. You can send a “stop” command to the device, but it may still report the door “open” – I can’t tell for certain what status is reported after a “stop” command. I bet @garadget might be able to say. If there is a state between “open” and “closed,” the binding could represent it as 50% using a Rollershutter item.
In the configuration you specify the duration of the door motion along few other settings. Based on that the UI displays the estimated door position.
LAN only option is one on our todo list and we’ll send out surveys to our backers to ask which of the features from that list we should be working on first. I can not predict what the choice will be so it’s hard to tell when it will become supported. This feature may come from the community before official version thanks to Garadget being open to developers
Thanks, with regards to the door position, if the door is manually stopped at 60% then the Garadget isn’t able to sense that. Is that correct?
I assume with the laser/reflective tag ir would be able to sense closed or not closed.
If the door is stopped manually while opening, Garadget will assume that it opened completely. If door is stopped manually while closing, Garadget will show it as stopped half-way after not receiving confirmation from the sensor at expected time.
Garadget has one sensor for closed state so the physically confirmed states are “closed” and “not closed”. Additionally there’s a configurable parameter that specifies the time it takes for the door to go from fully closed to fully opened state (T). With this in mind Garadget reports:
closed state when sensor confirms the closed state
opening state for T seconds after sensor detected transition from “closed” to “not closed”
open after T seconds from beginning of opening state
closing after ‘close’ command is received in any state but closed
stopped if closed state is not confirmed within T seconds from ‘close’ command
stopped if ‘stop’ command is received while closing or opening
It is possible to add sensors for all the states, but added complexity is not worth the benefit. Real life day-to-day use has proven that Garadget’s approach works beautifully.
LAN only feature is frequently requested and is on todo list. However when implemented, it will not be enabled by default because of security concerns. As implemented, Garadget doesn’t talk to strangers, so no amount of network sniffing and man-in-the middle attacks will make it pay attention to anything other than its securely authenticated cloud server.
Thanks, Denis. The binding is already handling the different states properly, because when those five states are mapped to binary types in openHAB, the intermediate states will come back as “Uninitialized”, but when they are mapped to the percentage type that the Rollershutter items use, the intermediate states all come back as 50%. And when the state shows in a String item, it comes through exactly as you sent it via the API.
Thanks Denis G, That was my understanding. I’ll think about backing this, the AUD is weak against the USD at the moment so it’s costly at the moment but it’s probably one of the better garage door solutions I see at the moment.
I’d like to see one like the below, where the red sensor can distance measure (green line) the red sticker/marker. That would provide better information about the state of the garage door.
I authored the integration with Smartthings, the reflective sensor in which the laser reflects of to confirm closed states also shows varying levels of reflectivity during the open cycle, so for example if the door is partially open the amount of reflectivity could essentially be assessed as you get this info from the Garadget device, you only need to tailor a wrapper around what state to set based on the reflectivity. the problem here is that it would most likely have to be very tailored to each installation.
as for measuring the distance as per your pic the easiest would be a motor with an integrated tachometer and a peice of string…never underestimate the power of a piece of string
Thanks, Stuart, and your Smartthings integration looks very nice, too. I wrote two Vera plugins (Nest and Ecobee), but I found the company so uninterested in third-party developers that I only keep my Veras running to support those plugins. If you want to dissect either of my Vera plugins to create one for Garadget, be my guest!