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
…and now, openHAB!
This looks like a really cool device! Is your binding able to speak to the device directly, or do you need to go via the cloud service? I must admit I have just a tiny bit of cloudophobia, 
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.
For anyone who would like to futurize your existing garage door opener, please see the new wiki page.
Was interested in getting some but now that you have a binding, even more so…
Main thing that was holding me back was that it will still only detect open or closed, nothing in between.
Most garage doors when they open have a central track/chain. I’m waiting for a sensor that can measure distance, maybe from the an attached reflective plate to the sensor to tell if a door is % open.
Josh
There is a local LAN option mentioned on the page.
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.
I did ask a question a while ago but from memory (mines average) the sensor can only tell closed if the reflective patch lines up. If it’s not there then it’s open.
The app shows a percentage as I think it times when the close button is hit and when the reflective patch appears so a stop command can give a percentage… I think… he did say something about timing.
The bit it can’t tell if someone still uses the usual button to open/stop etc. Just trying to make things wife proof who will use the usual buttons.
Josh
Here, I found there reply:
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.
Thanks Josh
Softcomplex
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:
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.
Addition of Garadget doesn’t affect the traditional operation including use of wall button, wireless remotes, safety features etc
So to confirm, Denis, the different status= values are “opening”, “open”, “closing”, “closed”, and “stopped”? Is that the complete list?
yes, there’s also unknown state which I reserved, but have not used yet.
Below is Garadget’s firmware C++ source gragment:
enum doorState {
STATE_CLOSED,
STATE_OPEN,
STATE_CLOSING,
STATE_OPENING,
STATE_STOPPED,
STATE_UNKNOWN
};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.
Would love to get some testers for the binding, but in the meantime, hopefully some openHAB users will consider backing the Kickstarter campaign!
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.
Josh
Funding got up. Decided to jump on board for two of them as it’s probably still the best one I’ve seen so far and thanks to watou for the binding made this an easier decision.
Lets hope it all goes through and we get our openers!
Josh
Great! Seems like a smart little device. I’m looking forward to your impressions when you’ve got them hooked up and running.
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 
Hi Stuart, great ideas!
About using reflectivity, an openHAB user could use this item as described here:
Number doorStatus_sensor "Reflection [%d %%]" { garadget="<[270041234567343432313031#doorStatus_sensor]" }
and write a rule or SCALE transform to compute distance based on percentage of reflection. You’re right that it would probably be installation-specific.
yeah, options for people anyway.
anyway @watou great work with your implementation. i am pleased @garadget is getting the integration with multiple platforms. but he doesn’t seem to have had any luck with the Vera guys getting implementation done
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!