Hey HN! We're building Seam (<a href="https://www.seam.co">https://www.seam.co</a>), a universal API for controlling IoT devices such as smart locks, thermostats, sensors, and (soon) cameras. Our hope is to make device integration simple, with a Plaid-like UI flow for obtaining device authorization and standardized API/SDKs for device control.<p>We started Seam out of our frustration with the challenges of integrating IoT devices with software apps.<p>For example, my co-founder Dawn led Sonder's efforts to integrate smartlocks with their reservation systems in order to automate access for guests. She struggled with poorly documented and unreliable device APIs along the way. Our founding engineer Max authored the popular TuyAPI library and has spent countless hours trying to build sensible interfaces on top of unreliable devices.<p>For my part, I was an early engineer at Nest and saw firsthand how manufacturers often lack the resources and motivation to support third-party developers.<p>As a result, most devices lack public APIs, and getting access to the private ones (if they exist) requires lengthy negotiations with manufacturers. This task grows in complexity with each additional device brand a developer may need to integrate.<p>Seam serves as a single API that works across dozens of brands and hundreds of devices.<p>We start by testing each device in our hardware lab in San Francisco. We study their behaviors & quirks, and faithfully reproduce those in our development sandbox. We take time to craft custom client libraries that maximize developer ergonomics while accounting for the asynchronous nature of the devices. We offer pre-built UI components (React, Web-native…etc) to let developers rapidly assemble complex UIs that can manage large fleets of devices. And we even have a small hardware gateway to connect on-prem and legacy devices.<p>A few app developers like Guesty (YC S14) already use Seam to connect to their end users’ devices. We have a generous free tier and charge a small fee for additional devices. We work closely with manufacturers to improve device reliability, add OAuth support, and patch security holes. We also spend time educating them on the importance of supporting open source projects like Home Assistant, OpenHab...etc and we will be contributing some of our own integrations to those ecosystems.<p>Seam is still very much a work in progress with many aspects that need to be improved. But our hope is that it will help push IoT devices from being (mostly) point solutions, to becoming a set of API endpoints software engineers can tap to interact with the physical world.
I was formerly at Stringify, which was a home automation app with 70+ integrations supporting 600+ devices. We were acqui-hired and decommissioned.<p>In my current role, I have met with several large tech companies over the past few months - and this seems to be exactly what they want - an easy way to integrate lots of third party devices into their own app(s). I guess Stringify was just a bit too early (2014-2017).<p>The consumer IoT space has been getting worse in the past 5 years. Companies used to provide open APIs. Then, just an IFTTT integration instead. Then, just an Alexa/GH integration instead.<p>Neat product and I wish you the best of luck!
I know firsthand just how difficult it is to work with all the disparate APIs for the different hardware providers, particularly with smartlocks. How do you deal with providing an ergonomic API on top of the access management and key/credential granting itself? Each of the APIs has different concepts, e.g. Salto's API has "binary keys", "zones", "access groups", "audit trails", etc...whereas SMARTair has "sites", "locking plans", etc. How do you deal with all of this? In other words, does your API abstract over all the APIs for purposes of setting up access? How would I, for example, given any type of lock, grant keys to a visitor which should expire in one week?
This is really cool, and something I’ve thought about a lot from various perspectives. This space badly needs some source of cohesion.<p>You don’t need my advice but I noticed you said:<p>> Our hope is to make device integration simple…<p>I think you should use more assertive language! You know it can be done so you don’t need to hope — it’s what you’re going to do!<p>Do or do not, there is no try!<p>I love this idea in any case. I would echo others in asking why this won’t be more open, though.<p>This reminds me a bit of Viam (<a href="https://www.viam.com/" rel="nofollow">https://www.viam.com/</a>). Different, but exciting to see APIs geared towards making IoT and robotics more accessible and efficient to interface with.
> We also spend time educating them on the importance of supporting open source projects like Home Assistan, OpenHab...etc and we will be contributing some of our own integrations to those ecosystems.<p>Can you elaborate on this? And, more importantly, why isn't seam itself open?
Hey, I just wanted to say thanks for the TuyaAPI library. I'm not using it directly - not trusting that hardware to ever talk to anything on the Internet, but I'm happily running my own server substitute (using a patched firmware that replaces TLS certificates, so of no practical use for you folks) for my cats feeder and your particular library had helped me a lot with understanding the overall HTTP API structure and their DIY encryption stuff - so I was much better prepared when I've started to dissect the binaries. Initial understanding saved me a lot of time.<p>And if you have a contact at Tuya, can you possibly please tell them that encrypting only I-frames in H.264 stream is a really bad idea? P-frames may not have all the pixels needed to get a clear picture, but they leak a lot - and Tuya is saving that stuff to the cloud, unprotected.<p>And good luck with the company! Must be extremely daunting task to get with all those IoT shenanigans. It's a very noble goal to bring some sanity into that crazy world.
Congratulations on the launch!<p>I work at Siemens and we need to integrate lots of brownfield devices. We use the W3C Web of Things standard for representing devices: <a href="https://www.w3.org/TR/wot-thing-description11/" rel="nofollow">https://www.w3.org/TR/wot-thing-description11/</a><p>Would love to hear your thoughts on this.<p>An example from Deutsche Telekom:
<a href="https://github.com/w3c/wot-cg/blob/main/Presentations/2022/2022-08-WoTCG-Meetup2-MagentaZuhauseApp-Winkler.pdf">https://github.com/w3c/wot-cg/blob/main/Presentations/2022/2...</a><p>I think the author of OpenHAB is on that team.
Sounds like what the App "Home Connect Plus" (developed by Bosch) aimed to achieve, however they partnered with the device manufacturers.
As a business case however did not appear, the development and also the ability to use the App and the cross vendor integrations was shut down.<p>From a technical perspective, their approach however was interesting. They provided a separate adapter for each device they integrated and all of these adapters communicated with "Eclipse Ditto" via Amqp1.0 Protocol (other protocol like Mqtt or Apache Kafka would also be an option).<p>Eclipse Ditto, an open source digital twin Middleware, then provided an harmonized API for all integrated devices.
The mobile App would connect via WebSocket to Ditto and interact with devices of various vendors.<p>Technically, this worked well. Maybe something to learn from.
One API to connect with the hundreds of IoT devices is brilliant.<p>How long do you think you'll have to write the integration code, versus having people look to integrate with your platform proactively?
What's the primary difference compared to Home Assistant's programmatic interface (with each device plugging in their own API to a unified description format) or Matter?
Hey Sy, congrats on the launch! Speaking from experience it’s no easy task to integrate all these services. Excited to use this in my next smart home build!
Love this!<p>I have built a small business to solve a similar problem for Property Managers: to manage all their phone-based intercoms (Doorking, LiftMaster, etc.) in one easy-to-use (and patented) SAAS UI. I did work with a similar integrators like RemoteLock.com (but love your approach a lot more).<p>Would love to work with you, check it out at www.DropBy.io and feel free to reach out to me at camille@dropby.io<p>Again, great great idea!
This is pretty neat! Is the intent to serve small consumers (e.g. people who want to incorporate IoT devices into a smart home), or larger companies (e.g. the IoT manufacturers themselves)?<p>Would love to get to a place where I could "terraform apply" my IoT devices configuration. Any plans to build this? It's only a small jump from a well-documented API in an OpenAPI spec to a terraform provider.
This is awesome. The lack of common API in IoT can be quite frustrating. I see this similarly to Twilio abstracting away the nuances of every Telco and making it all API accessible. You would have guessed that IoT vendors would have figured this out, but alas, we are here.
Thank you for building this!
How does this compare to what Tuya offers as well as Amazon's and Microsoft's IoT device solution? To me, it seems like higher level interface to ready made commercial devices that you can then perhaps plumb back into a building management system or something.
Congrats on the launch! The landing page looks pretty great and it's definitely a real problem. I've struggled to automate my house with a myriad of devices.<p>Wish you all the best in your endeavour!