Yes this would be great @Frank. The only thing holding me back is a closed APIā¦ I assume Iām not alone. There are many enthusiasts that would drop whatever lock they currently have for a lock like this if they had full control as well.
No, not yet. I also sent an email a few days ago, but since itās a holiday, it might take a while to hear back. I also contacted someone managing the beta testing group for contact info for other product owners who manage the API. Fingers crossed!
Yes, we are now considering selling our 3 Ultraloqs and 2 others that we just ordered, in favor of August/Yaleā¦
This is really disheartening b/c I donāt love their actual products as much as I do Ultraloqā¦ but these integrations allow us to do so much with their locksā¦
Even if U-tec came on here and said āYes, weāre going to do thisā¦ā I canāt imagine how long this is going take before it would be releasedā¦ esp considering itās not even a small priority or on their backlog right now!
I think looking elsewhere is our only option!
Itās not that easy, unfortunately. When you build internal APIs you donāt have to think about building it to scale. Enforcing things like rate limiting to not overwhelm the server and bring down the service for everyone. I am working on moving internal APIs to make them public for the company where I work and am learning the entire process.
The API ideally would be local, and not be reliant on the cloud. In that case rate limiting is less of an issue.
Now that you mention it. The topic is open API but not necessarily open local API. I hope they are looking at a local API as I doubt anyone is looking for a cloud API. A cloud API open or not would be useless to me as I would deem it unreliable because itās cloud based.
Yes ideally I think consumers all want a local API. The moment your internet goes out your smart home looks pretty dumb when reliant on clouds.
OpenAPI is an API standard. So in this case itās not open or closed API but the ask is that the API specs are written to conform to the OpenAPI 3.x standard.
At this point I donāt care if itās a cloud or local API, I will take anything as a starting point.
Another issue with a cloud API is the moment the cloud goes out your smart home is dumb. Or the worst of allā¦ The moment the servers are shut down because of a multitude of reasons then itās dumb forever unless someone hacks it but thatās not something your average consumer would be able to pull off even with instructions.
For the best of both worlds for the non tech savvy users they could have an Open API for the cloud and local. That way developers of other smart home platforms can integrate either one into their platforms. While those who are tech savvy can use the platforms that prioritize local control such as home assistant.
Another plus for home assistant would be for utec to create a home assistant Bluetooth integration as home assistant can integrate with Bluetooth devices now either through Bluetooth hardware on the server or through Bluetooth proxy via esp32s. That way thereās local control over wifi and Bluetooth.
Iām also looking for a local API as Iām using Hubitat and having local control would be ideal as the existing IFTTT integration is hit or miss at best
I emailed the product manager a few months ago about it and he said they werenāt interested and now he emailed me out of nowhere to let me know they just set it up and itās available.
I chose a different brand for my upgrades due to non-existent API from U-tec and requiring the ability to remote control while offlineā¦ for security reasons, it had to be accessible in a way only APi would allow. I really like U-tecā¦ iāve had one at my residence for 3+ years and its still going strong and much better/cost effective than the other company we went with. Alredy 6 dead after the 1st year. U-tec isnāt really into taking risks I guess. Well, I guess API must be considered a risk to them lol. Donāt make too much money, right:/ Maybe someone should tell them itās actually a thing, literally everyone is doing itā¦ all the cool kids:D
@Frank are you following this thread still?
Sounds like @Negron is willing to be an asset to help yāall move this along. Iād gladly chip in to help fund the development of an open API with Ulatraloq devices.
The cloud option is most interesting to us b/c we have rental homes, and also rent out some athletic courts, and training equipmentā¦ all behind different doors with Ultraloq Wi-Fi locks. Opening up direct integrations with other common apps or ideally trigger/action webhooks that could allow us to provision a new code when we get a new booking, and allow us to also set the time the code is available, when it expires, etc. and also be able to push access trigger dataā¦ ācode was usedā and then we could push that data to other applications easily, via Zapier, Make/Integromat, Pabbly Connect, Integrately, etc.
This could open up some completely new streams of revenue and lines of business for U-tec!
Just one exampleā¦ There are over 150 million users worldwide, on Airbnb. I donāt know how many property/listings that is, but imagine the marketing campaign that you could do to target Airbnb hosts, showing them how your affordable, automated locks does all the work for creating new codes for new guests, automatically emailing them, and then deactivating the code at the end of their stay.
This is just one example. But my point isā¦ Well it seems like there are just a few passionate people on this thread who are interested in this feature, the reality is that if you are smart about it, U-Tec could really blow up there Sales, with strategic marketing campaigns based on what this new feature would allow!
100% agreement. The ability for the community to expand on these use cases and drill into specific needs would be a game-changer. I was just thinking this morning how Iād like to be able to build a service that automatically connects AirBnB reservations to temp users. Would be amazing, but not likely something u-tec would take oin directly.