That's great news. I suppose that the unused attributes (for example, the battery level for what seems like a non-existent tilt sensor in your particular setup) are just reported as some default values, like "0" for battery level. Hopefully those aren't too confusing for someone with a slightly different setup. thanks for your help tracking it down, @craigspree
1 Like
Yeah, I thought that the battery would represent what the battery percentage of the battery backup would be on my model but that should always be 100% since it is always plugged in ready for a power outage. Didn't even think of a different model/setup with these things 
1 Like
How “fast” is this integration? Fast enough to use a pico as a car garage remote?
I heard from @craigspree that it might be a little bit laggy (presumably due to the cloud interaction), but maybe he could help quantify its responsiveness. How fast from button press to operation is fast enough, @frmWink2Hubitat?
2 Likes
Thx
Speed: it’s about 5-20 seconds on average from initiating the command to the open/close starting.
It is an awesome integration, but no where close to the speed of an RF remote.
Here’s how I use it:
- Coming Home from a bike ride and asking Siri (via Apple Watch & Home Bridge) to open the garage when about a block away. I can then ride right into the garage. If I forget to use Siri, it’s faster to use the RF keypad on the door itself.
- Coming home from a car ride, same as bike - initiating the open a block away. If I forget, then I use my RF remote when pulling up.
- Siri initiated rule that closes the door and unlocks the door to the house after I pull in the garage.
- Rule that auto closes the door if it’s been open longer than an hour, with 3 warning notifications. Makes sure the door is closed if left open accidentally - but the alert notifications give me time to pause the rule if I’m just working in the garage and want the door left open.
Summary : not fast enough to replace the RF remote, but still very useful for me. The slow speed is entirely Genie cloud related - sometimes it’s almost instant and others it’s 20 seconds.
2 Likes
Thanks
@tomw Just discovered your Aladdin Connect drivers and got them up and running successfully in a flash. Thanks for writing these and sharing them with good documentation.
2 Likes
Thanks for this integration. Got it working well. Would you be able to easily add switch capability that follows the door status? I think switch capability is needed for me to add to Sharptools - maybe @josh can confirm but I suspect that’s the case.
1 Like
The device needs to have at least one capability from the authorization list. For garage doors, that's most commonly 'Contact Sensor', but as you alluded to 'Switch' and 'Pushable Button' are often seen too.
Alternatively, if the device at least implements the 'Actuator' or 'Sensor' capability, it can be authorized manually.
1 Like
Ah, right - that would be the better choice. Thanks!
Here's a proposed version that would mirror the 'door' state to the 'contact' attribute as a compatibility shim:
(I did this directly from the GitHub editor without testing, so test accordingly. If it works well, I can submit a PR for Tom's consideration. 
)
Thanks for the look! Is there a major advantage to the Contact shim compared to just using Actuator or Sensor? I prefer Actuator because it's basically invisible to the user, compared to something like a Contact emulation where there's room for confusion on attribute naming or weirdness from the cloud lag for states that correspond to a moving door.
Historically a lot of garage door drivers included the contact sensor capability. Certain apps might support the open/closed state of a contact even if they don't support the door attribute and its various in-between states so it can be a helpful attribute to mirror the state to.
--
A more niche issue (and my memory is a bit foggy at this point), but SmartThings (and maybe Hubitat at one point) would drop the 'extra' authorizations that were only configurable directly from the app if you went through the app's OAuth process after you manually configured the app with extra devices.
I just tested on Hubitat 2.2.9 (beta) and it seems to remember the extra configurations just fine even when reauthorizing through OAuth though, so maybe that point is a non-issue. 
1 Like
Did something recent break this? I'd been using it with a C5 hub, and just upgraded to a C7. Started from scratch with this integration, and it's not picking up the opener. Authorization seems OK.
I'm wondering if the empty devices:[] is what's wrong? (I think I xxx'd any security stuff)
dev:580 2021-11-28 11:37:37.085 am debug resp.data = [devices:[], id:1840118514, info:[aliases:[], basic:[modified:1590275731, subscribers:0, type:client, status:activated], description:[limits:[client:64, dataport:6400, datarule:6400, disk:inherit, dispatch:6400, email:100, email_bucket:inherit, http:6400, http_bucket:inherit, share:6400, sms:5, sms_bucket:inherit, xmpp:100, xmpp_bucket:inherit], locked:false, meta:, name:New Portal@2020-05-23T23:15:31+00:00 1590275731.9558, public:false], key:xxx, shares:[], subscribers:[], tagged:[], tags:[]]]
dev:580 2021-11-28 11:37:36.436 am debug httpGetExec([uri:https://genie.exosite.com/api/portals/v1/portals/1840118514, headers:[AppVersion:2.10.1, BundleName:com.geniecompany.AladdinConnect, User-Agent:Aladdin Connect Android v2.10.1, BuildVersion:131, Authorization:Token: xxx]])
dev:580 2021-11-28 11:37:36.431 am debug resp.data = [[PortalName:New Portal@2020-05-23T23:15:31+00:00 1590275731.9558, PortalID:1840118514, PortalRID:xxx, UserEmail:foo@example.com, Description:New Portal@2020-05-23T23:15:31+00:00 1590275731.9558, Permissions:[[access:___admin]]]]
dev:580 2021-11-28 11:37:35.853 am debug httpGetExec([uri:https://genie.exosite.com/api/portals/v1/users/2174044354/portals, headers:[AppVersion:2.10.1, BundleName:com.geniecompany.AladdinConnect, User-Agent:Aladdin Connect Android v2.10.1, BuildVersion:131, Authorization:Token: xxx]])If you use this integration, please give your input on this poll: Aladdin Connect (garage door) driver - #28 by tomw
I just merged in v2.0.0 on GitHub and in my HPM listing. This version supports the new APIs, since it seemed like the bulk of users' systems were no longer working with the 1.x versions of my driver.
Note: if you are currently using version 1.x version of this driver, you will need to delete and re-create your virtual devices after upgrading to version 2.0 or later.
It was a fun project updating this and working out the kinks again.
Kudos to @mikes for figuring out the real-time events API, which means version 2.0 no longer requires polling and will be much more responsive to door state changes.
2 Likes
Hi @user1320
I saw your post here: Aladdin Connect (garage door) driver - #38 by user1320
Your debug logs helped a lot. It looks like your system has data in a slightly different format than what my code assumed. I'll take a stab at adding support for the style of yours and will PM you some code to try.
