Launch HN: Seam (YC S20) – API for IoT Devices
73 comments
I was formerly at Stringify, which was a home automation app with 70+ integrations supporting 600+ devices. We were acqui-hired and decommissioned.
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).
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.
Neat product and I wish you the best of luck!
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).
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.
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?
Ohhh, this is such a great question! Also, it's quite clear you’ve seen these systems & their APIs up close, and can appreciate the mess… :)
So I’d say there are two approaches to doing these abstractions. We sort of support both and let the API client decide which way they want to roll.
The first approach consists of stripping away all the “stuff” that stands in the way of controlling a device. We basically just boil everything down to atomic operations on a single device. For example on SaltoKS locks, we let you create access codes directly on a door devices without having to worry about creating users, access groups, schedules…etc. Of course, we have to create these behind the scenes, but we don’t expose them to the API client. Instead we give you simple methods such seam.access_code.create(device_id…etc) that you can use against either an August device or one that’s part of a larger system such as SaltoKS.
The second approach consists of reintroducing the concept of users, access groups, and assigned credentials…etc and to lift the abstraction to entire systems vs just individual devices/nodes. You frankly need to do this if the site owner wants to continue to use their system in a sensible manner (e.g. see list of employees who badged in) or if you want to support more complex forms of credentials (e.g. Google/Apple Wallet).
I think the important thing to recognize is that, at the end of the day, whether you choose abstraction 1 or abstraction 2, these devices/systems all more or less do the same thing. The manufacturer may use slightly different terminology but you can create abstractions from that.
ps: btw for a long-time we made the mistake of spending too much time trying to nail the abstraction on every dimension imaginable. This included features of certain systems that no developers were asking us about. Now we just focus on solving what devs are asking for. That reduces the surface area of how much "stuff" we have to deal with when creating these API interfaces. This is a textbook example of going back to the YC basics of "talk to users" and "build something people want".
So I’d say there are two approaches to doing these abstractions. We sort of support both and let the API client decide which way they want to roll.
The first approach consists of stripping away all the “stuff” that stands in the way of controlling a device. We basically just boil everything down to atomic operations on a single device. For example on SaltoKS locks, we let you create access codes directly on a door devices without having to worry about creating users, access groups, schedules…etc. Of course, we have to create these behind the scenes, but we don’t expose them to the API client. Instead we give you simple methods such seam.access_code.create(device_id…etc) that you can use against either an August device or one that’s part of a larger system such as SaltoKS.
The second approach consists of reintroducing the concept of users, access groups, and assigned credentials…etc and to lift the abstraction to entire systems vs just individual devices/nodes. You frankly need to do this if the site owner wants to continue to use their system in a sensible manner (e.g. see list of employees who badged in) or if you want to support more complex forms of credentials (e.g. Google/Apple Wallet).
I think the important thing to recognize is that, at the end of the day, whether you choose abstraction 1 or abstraction 2, these devices/systems all more or less do the same thing. The manufacturer may use slightly different terminology but you can create abstractions from that.
ps: btw for a long-time we made the mistake of spending too much time trying to nail the abstraction on every dimension imaginable. This included features of certain systems that no developers were asking us about. Now we just focus on solving what devs are asking for. That reduces the surface area of how much "stuff" we have to deal with when creating these API interfaces. This is a textbook example of going back to the YC basics of "talk to users" and "build something people want".
This is really cool, and something I’ve thought about a lot from various perspectives. This space badly needs some source of cohesion.
You don’t need my advice but I noticed you said:
> Our hope is to make device integration simple…
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!
Do or do not, there is no try!
I love this idea in any case. I would echo others in asking why this won’t be more open, though.
This reminds me a bit of Viam (https://www.viam.com/). Different, but exciting to see APIs geared towards making IoT and robotics more accessible and efficient to interface with.
You don’t need my advice but I noticed you said:
> Our hope is to make device integration simple…
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!
Do or do not, there is no try!
I love this idea in any case. I would echo others in asking why this won’t be more open, though.
This reminds me a bit of Viam (https://www.viam.com/). Different, but exciting to see APIs geared towards making IoT and robotics more accessible and efficient to interface with.
Duly noted on using more assertive language! I appreciate the advice :)
Viam looks really cool! We didn't know about it.
On making Seam more open, it's definitely not off the table. We'll have to balance this with device manufacturers' general preference to have "somebody they can call" if/when their servers get pounded. Admittedly, we've also been focused on making sure Seam becomes a sustainable business. Spending time open sourcing our stuff, making it runable elsewhere...etc takes time away from making sure we get to "default alive" quickly.
On making Seam more open, it's definitely not off the table. We'll have to balance this with device manufacturers' general preference to have "somebody they can call" if/when their servers get pounded. Admittedly, we've also been focused on making sure Seam becomes a sustainable business. Spending time open sourcing our stuff, making it runable elsewhere...etc takes time away from making sure we get to "default alive" quickly.
I (personally) think the value towards openness of platform and source is rooted in the fact that a lot of inbound leads come from direct recommendations from independent developers that work for the companies looking to buy. In other words, the weekend hacker/home automation geek gets their company to use the enterprise offering of the ecosystem or platform they discovered.
Additionally, as a new company, it’s hard to convince someone that you will be around for the 5 years of a contract term when you’re not even 5 years old yet. Having a lot of your stuff open source gives them the off-ramp they would need to feel comfortable signing a deal with a younger company.
This works as long as the value you bring is with the team and a breadth of knowledge and experience behind it along with the incentives to continue to improve upon the product. Considering the amount of IoT devices there are and how much of it lacks interoperability, I’d say there’s plenty of value to be sold yet.
Additionally, as a new company, it’s hard to convince someone that you will be around for the 5 years of a contract term when you’re not even 5 years old yet. Having a lot of your stuff open source gives them the off-ramp they would need to feel comfortable signing a deal with a younger company.
This works as long as the value you bring is with the team and a breadth of knowledge and experience behind it along with the incentives to continue to improve upon the product. Considering the amount of IoT devices there are and how much of it lacks interoperability, I’d say there’s plenty of value to be sold yet.
Early in the Seam journey, Dawn and I got a chance to speak with Jeff Lawson at Twilio. Jeff mentioned that exact dynamic, "the dev who's hacking on the weekend with Twilio and brings into work Monday morning" was a pretty powerful GTM force for them. But I don't think anyone would describe Twilio as open source. So being open-source doesn't appear to be a necessary condition for this dynamic to take place. What Jeff insisted on was the need for solid overlap between "i'm hacking with this API" and "i could use this for a business use case." That is, make the API product dead simple to get started with, and make sure it's easy to grasp how you could use this in a business context.
With respect to having an off-ramp by being open-source, I definitely agree that it does the psychological trick to convince a buyer. But in practically, most corporate-led open source projects are pretty hard to run end-to-end on your own infra. They also have limited outside contributors that really know how the stuff works.
With respect to Seam, I'd say being open-source wouldn't really move the needle for us in conversations with large enterprise customers. They're generally more interested in how much funding we have, how much runway that buys us, and how we're trending as far as building a sustainable business on which they will depend. Their tolerance for risk related to these questions is inversely proportional to their size. I suppose this is also why, in infrastructure sales, your next customer won't be significantly larger than the last one you closed.
With respect to having an off-ramp by being open-source, I definitely agree that it does the psychological trick to convince a buyer. But in practically, most corporate-led open source projects are pretty hard to run end-to-end on your own infra. They also have limited outside contributors that really know how the stuff works.
With respect to Seam, I'd say being open-source wouldn't really move the needle for us in conversations with large enterprise customers. They're generally more interested in how much funding we have, how much runway that buys us, and how we're trending as far as building a sustainable business on which they will depend. Their tolerance for risk related to these questions is inversely proportional to their size. I suppose this is also why, in infrastructure sales, your next customer won't be significantly larger than the last one you closed.
This all makes sense. I've been there. Open source is a nice-to-have when you don't have the revenue you need, and I'm personally guilty of pursuing revenue first on virtually every project I've been on. It's hard not to when you don't have a safety net yet.
> I appreciate the advice
I'm glad it wasn't annoying!
> I appreciate the advice
I'm glad it wasn't annoying!
"Our mission is to make device integration simple..." would be more appropriate
> 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.
Can you elaborate on this? And, more importantly, why isn't seam itself open?
Can you elaborate on this? And, more importantly, why isn't seam itself open?
Many of the integrations you'll see in Home Assistant are reversed-engineered. Usually this is done by looking at the mobile apps of many of these devices and extracting credentials, certs...etc. A few manufacturers don't love this for various reasons and try to shut it down. We end up spending time explaining to them why it will just result in a cat-and-mouse game and hurts them in the long-run.
On Seam being open source, we've debated this back and forth internally, especially given most of us came from various OSS projects. Tbh, there's already a ton of options for open sourced integrations. When/where we see one that's lacking, we may contribute ours back...etc. fwiw I don't think it's a done deal that we won't fully open source more of our infra down the line. We'll see.
On Seam being open source, we've debated this back and forth internally, especially given most of us came from various OSS projects. Tbh, there's already a ton of options for open sourced integrations. When/where we see one that's lacking, we may contribute ours back...etc. fwiw I don't think it's a done deal that we won't fully open source more of our infra down the line. We'll see.
>why isn't seam itself open?
I'd say primarily because making money with an open product is very very difficult, regardless of the industry you build for.
It sounds like it would be difficult to "open core" the product too.
I'd say primarily because making money with an open product is very very difficult, regardless of the industry you build for.
It sounds like it would be difficult to "open core" the product too.
This too. It's pretty important we focus on building a viable business (see current funding environment). Contrary to popular belief, building open source isn't free and takes time away from that effort. You have to make sure your stuff runs on the various platforms, you gotta triage issues...etc.
Now for certain products, such as databases, not being open is borderline a non-starter. But for many other infra categories, the customer doesn't purchase your product based on whether it is open source or not. For example, no one cares that Stripe, Twilio, or Plaid aren't fully open source. Customers just want the API to work.
Personally, I'd like to see Seam go more open as we get more resources/bandwidth. We've already published a few things (https://github.com/seamapi) and I'd like to do more over time such as publishing firmware, open connectors, backends you can run anywhere...etc.
Now for certain products, such as databases, not being open is borderline a non-starter. But for many other infra categories, the customer doesn't purchase your product based on whether it is open source or not. For example, no one cares that Stripe, Twilio, or Plaid aren't fully open source. Customers just want the API to work.
Personally, I'd like to see Seam go more open as we get more resources/bandwidth. We've already published a few things (https://github.com/seamapi) and I'd like to do more over time such as publishing firmware, open connectors, backends you can run anywhere...etc.
> no one cares that Stripe, Twilio, or Plaid aren't fully open source
You keep drawing parallels to fintech
> Tbh, it's pretty much the same reason that made Plaid popular with the fintech ecosystem.
But it's not the same thing. It's impossible to legally implement this yourself. You can't just make a library (I, naively, did try). All that being said, I understand the product now. It's not for me, but that's ok. Thanks for being so responsive
You keep drawing parallels to fintech
> Tbh, it's pretty much the same reason that made Plaid popular with the fintech ecosystem.
But it's not the same thing. It's impossible to legally implement this yourself. You can't just make a library (I, naively, did try). All that being said, I understand the product now. It's not for me, but that's ok. Thanks for being so responsive
> I'd say primarily because making money with an open product is very very difficult
Well - Home assistant makes money in a transparent way and lots of people pay for cloud access without even using/needing it just to support the devs.
Well - Home assistant makes money in a transparent way and lots of people pay for cloud access without even using/needing it just to support the devs.
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.
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.
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.
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.
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!
I work at Siemens and we need to integrate lots of brownfield devices. We use the W3C Web of Things standard for representing devices: https://www.w3.org/TR/wot-thing-description11/
Would love to hear your thoughts on this.
An example from Deutsche Telekom: https://github.com/w3c/wot-cg/blob/main/Presentations/2022/2...
I think the author of OpenHAB is on that team.
I work at Siemens and we need to integrate lots of brownfield devices. We use the W3C Web of Things standard for representing devices: https://www.w3.org/TR/wot-thing-description11/
Would love to hear your thoughts on this.
An example from Deutsche Telekom: https://github.com/w3c/wot-cg/blob/main/Presentations/2022/2...
I think the author of OpenHAB is on that team.
oh! I have many, many thoughts on the W3C WoT :)
At the start of Seam, we spent a lot of time reading those specs and absorbing some of the key ideas expressing in its core documents. As a result, you'll see a lot of W3C WoT terminology throughout our API and its docs ("capabilities", "events, properties, actions", "affordances"...etc). My mom (of all people!) is the one who pushed us to really spend time in those docs and understand where the designs were coming from.
I think ultimately we began diverging a bit from those specs when it came time to solve customer needs, such as device-category standardization, async handling of access codes...etc. But I have fond memories of going over those docs with my mom, highlighting certain passages of their docs on paper printouts, and debating the merits of different approaches.
Also feel free to ping me [email protected] if you guys need help with various integrations.
At the start of Seam, we spent a lot of time reading those specs and absorbing some of the key ideas expressing in its core documents. As a result, you'll see a lot of W3C WoT terminology throughout our API and its docs ("capabilities", "events, properties, actions", "affordances"...etc). My mom (of all people!) is the one who pushed us to really spend time in those docs and understand where the designs were coming from.
I think ultimately we began diverging a bit from those specs when it came time to solve customer needs, such as device-category standardization, async handling of access codes...etc. But I have fond memories of going over those docs with my mom, highlighting certain passages of their docs on paper printouts, and debating the merits of different approaches.
Also feel free to ping me [email protected] if you guys need help with various integrations.
That’s great to hear. I will take you up on your offer.
Also I’ll check out your product in more depth.
BTW, what’s your mom‘s background? Sounds like awesome parenting
Also I’ll check out your product in more depth.
BTW, what’s your mom‘s background? Sounds like awesome parenting
She's pretty cool! She's former math teacher, then PhD in stats, reconverted to scientific computing programmer (CERN, Astronomy Labs...etc), and then eventually moved over to large system / mainframe stuff. She also spent a lot of time writing docs (she wrote some of the Seam API docs!) and has a knack for going deep on technical stuff. Lately she's been translating Aurélien Geron (https://github.com/ageron) Hands-On Machine Learning books into French.
Wow. Your mom is a wizard.
Thanks for the hint, that Geron has books on machine learning. I know him from a YouTube video, where he explains how they use the google knowledge graph for YouTube: https://youtu.be/ywfYMQD6yYk
He explains it so well. Then his books are worth a read.
Thanks for the hint, that Geron has books on machine learning. I know him from a YouTube video, where he explains how they use the google knowledge graph for YouTube: https://youtu.be/ywfYMQD6yYk
He explains it so well. Then his books are worth a read.
[deleted]
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.
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).
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.
Technically, this worked well. Maybe something to learn from.
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).
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.
Technically, this worked well. Maybe something to learn from.
Congrats on the launch! Beautiful landing page by the way! Wishing Seam all the best :)
awh thanks! that actually means a lot! tbh we put a lot of personal efforts into it but it's still pretty rough. We don't have a marketing or visual-design person so we kind of had to think and execute through stuff ourselves. We wanted something with a bit of depth/3D to it to keep in line with the theme of "an API for the physical world." Using 3D stuff always makes the design job harder.
One API to connect with the hundreds of IoT devices is brilliant.
How long do you think you'll have to write the integration code, versus having people look to integrate with your platform proactively?
How long do you think you'll have to write the integration code, versus having people look to integrate with your platform proactively?
hard to say. We always get manufacturers asking us how they can get integrated into Seam. Generally we find that it's faster for us to do the integration versus the other way around. We've internally discussed fully open sourcing our connectors, like Airbyte, but we'd need to make sure the integrations are rock solid and the virtual device in our sandbox are accurately modeling the behavior of the real ones.
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?
Combining Home Assistant with ESPHome/Tasmota is really something impressive, i guess this product is a more polished/high level version of HomeAssistant-like with obsessions for locks
Home Assistant (which I personally use) is solid for personal use cases. But our customers generally aren't trying to connect to their own devices. They're trying to connect to their end users devices (e.g. Ecobee thermostat) and you don't need Home Assistant for that.
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!
Thank You!
Love this!
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).
Would love to work with you, check it out at www.DropBy.io and feel free to reach out to me at [email protected]
Again, great great idea!
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).
Would love to work with you, check it out at www.DropBy.io and feel free to reach out to me at [email protected]
Again, great great idea!
Can I use the API without going through Seam servers at all? That is, communicate directly with the device (or the manufacturer's cloud)?
I don't think so. It's proprietary. I don't understand why it can't just be a nice library. I suppose you can't launch a startup off a library
Actually, I'm kinda confused on the whole proposition. Why can't I use existing libraries? Why the middleman?
Actually, I'm kinda confused on the whole proposition. Why can't I use existing libraries? Why the middleman?
We build a lot of infra/async logic to make controlling devices more reliable, handle long-running jobs...etc. So a simple library wouldn't quite work.
With respect to the value prop, most of our API customers are software apps that need to connect to their users' devices. They can't, or don't want, to handle build auth flows, deal with device disconnection, unreliable cloud APIs, doing BD with device manufacturer...etc. Tbh, it's pretty much the same reason that made Plaid popular with the fintech ecosystem.
With respect to the value prop, most of our API customers are software apps that need to connect to their users' devices. They can't, or don't want, to handle build auth flows, deal with device disconnection, unreliable cloud APIs, doing BD with device manufacturer...etc. Tbh, it's pretty much the same reason that made Plaid popular with the fintech ecosystem.
Depends on the device/brands. Z-Wave/Zigbee...etc devices will let you communicate directly with them locally. We contributed a bunch to ZWave-js and it's a great library for doing exactly that. For manufacturers' clouds, a handful offer public API but it's usually the exception, not the rule. There are a handful of opensource libraries out there but otherwise most manufacturers aren't setup to support third-party devs. It takes quite a bit of business development to get access to their APIs. With respect to Seam, we may open source some of our connectors but it's still going to depend a bit on the manufacturers. I think they conceptually like to have someone they can call vs not exactly being sure who's hitting their infra.
I'm not talking about whether or not the device supports local access. Obviously if it doesn't, Seam can't magically give local access. I'm wondering if using Seam forces me to go through some Seam cloud service when I have a device that does support local communication.
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)?
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.
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.
Most of our customers today are startups and a handful of large enterprise customers. Generally they're trying to connect and control their app users' devices. A common use case is smartlock & thermostat control for Airbnb reservation software. But some of the customers are actually controlling their own devices. This is usually the case for the large ones. Think real-estate group spanning multiple states with hundreds of buildings. They have fragmented fleets of devices and can't integrate them all.
Ultimately you can definitely use Seam as a hobbyist. A few people do. I have it running in my house alongside Home Assistant. But we're not ever planning on monetizing that segment.
The terraform is pretty interesting. If you could drop me a note [email protected] with an example configuration, I'd like to discuss it internally.
Ultimately you can definitely use Seam as a hobbyist. A few people do. I have it running in my house alongside Home Assistant. But we're not ever planning on monetizing that segment.
The terraform is pretty interesting. If you could drop me a note [email protected] with an example configuration, I'd like to discuss it internally.
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.
That's a pretty accurate take.
Amazon/Azure's IoT solutions are intended for device manufacturers who need to move data back-and-forth between devices and cloud infra. We don't play at all in this space, but a friend of ours, Jonathan Berry, has a company doing exactly that (https://golioth.io/). Many hardware manufacturers need help/tools to connect their devices and some very interesting companies will be built in that part of the stack.
Tuya is trickier to explain. It's... a lot of different things, really. It can be just a firmware + cloud if that's what you want (see countless devices on Alibaba with Tuya built-in). It can also be an entire white-labeled device that you can brand to whatever you'd like. They'll even give you a mobile app to go with it.
Seam is much higher up the stack for now. We mostly focus on device cloud integrations and occasionally a few on-prem systems.
Amazon/Azure's IoT solutions are intended for device manufacturers who need to move data back-and-forth between devices and cloud infra. We don't play at all in this space, but a friend of ours, Jonathan Berry, has a company doing exactly that (https://golioth.io/). Many hardware manufacturers need help/tools to connect their devices and some very interesting companies will be built in that part of the stack.
Tuya is trickier to explain. It's... a lot of different things, really. It can be just a firmware + cloud if that's what you want (see countless devices on Alibaba with Tuya built-in). It can also be an entire white-labeled device that you can brand to whatever you'd like. They'll even give you a mobile app to go with it.
Seam is much higher up the stack for now. We mostly focus on device cloud integrations and occasionally a few on-prem systems.
Fantastic! I’ve been wanting this for some time.
Any plans for integrating ubiquiti cameras and access systems?
Any plans for integrating ubiquiti cameras and access systems?
yep! It's actually on my desk right now! (https://imgur.com/a/3pAYfnx).
Colin, EE on our team, is building a test fixture for it in order to correctly simulate certain scenarios on it. I think we'll have the access system integrated in the next 4-5 weeks. The camera stuff, we're still toying with the exact API & use cases. If you have specific camera features you want supported, could you post them here or email me ([email protected])?
Colin, EE on our team, is building a test fixture for it in order to correctly simulate certain scenarios on it. I think we'll have the access system integrated in the next 4-5 weeks. The camera stuff, we're still toying with the exact API & use cases. If you have specific camera features you want supported, could you post them here or email me ([email protected])?
Woot! I can't wait to try out Unifi Access with your platform.
For cameras, my initial ideas are relatively simple:
- If someone uses an access key card and is allowed entry through Unifi Access, record a clip on nearby cameras and unlock the door using connected lock.
- Once the person is verified inside by camera, auto-lock the door.
- Unlock door using HKSV (or similar platforms) facial recognition.
- Using an image recognition system to track an animal across multiple cameras and build an automatic reel of movement through an area (for wildlife cameras)
For cameras, my initial ideas are relatively simple:
- If someone uses an access key card and is allowed entry through Unifi Access, record a clip on nearby cameras and unlock the door using connected lock.
- Once the person is verified inside by camera, auto-lock the door.
- Unlock door using HKSV (or similar platforms) facial recognition.
- Using an image recognition system to track an animal across multiple cameras and build an automatic reel of movement through an area (for wildlife cameras)
Congrats on your launch! That hardware lab must've been a blast to build out.
it's messy! but we've got all sorts of fun stuff + a 3D printer. We also have all these shelves around the office for storing devices. Here's one: https://imgur.com/a/UGhCIxg
We're in the SF Mission. You're more than welcome to swing by for lunch/coffee to check it out.
ps: PrintNanny looks awesome!
We're in the SF Mission. You're more than welcome to swing by for lunch/coffee to check it out.
ps: PrintNanny looks awesome!
That setup is freakin' awesome! I love the "get it done" energy behind going out and getting more than a dozen smart locks to test your work. None of these smart lock vendors would be motivated to build an API + test against their competitors' products.
Also, thank you! What kind of 3D printer are you running? If you ever want to try the PrintNanny Raspberry Pi 4 kit, I'll take you up on that coffee and help with the install. =)
Also, thank you! What kind of 3D printer are you running? If you ever want to try the PrintNanny Raspberry Pi 4 kit, I'll take you up on that coffee and help with the install. =)
QIDI X-MAXⅡ. We mostly use it to print device test fixtures. For example, we have a fixture for thermostats, ie before you can test a smart thermostat, you have to trick it into thinking it is connected to an actual HVAC system. So we have a shape that we print out; it takes about 12 hours. We are not printing thousands of them, but we print often enough that PrintNanny would be useful. I sent it internally to our team. I will most likely email you directly.
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.
Wish you all the best in your endeavour!
Wish you all the best in your endeavour!
Happy to help. Have you tried Home Assistant as well? It's pretty good for personal use cases and such.
We use Seam, it's the best thing that is happening for the messy IoT integrations.
Do most of the authorization flows require the user to provide their password for their lock manufacturer?
Many, yes. We have a page (https://www.seam.co/security-and-privacy) detailing this. One of the area of collaboration with manufacturers is helping them implement proper OAuth so that we never have to do this.
Excited for the launch! Looks like you've built something cool. Excited to try it out
Thank You!
So shouldn’t “Matter” take care of this in a standard and open way moving forward?
Tbh, probably not. I'll give you a few thoughts for consideration.
Matter is a device-to-device protocol within a local Thread network. It's solid for getting one device to tell another device on the same Thread network to perform an action, retrieve data...etc. Since Matter is pretty consumer-centric, those devices are generally all contained within a home.
To remotely control those devices (i.e. what our API customers want to do), you sort of need a Thread border router to serve as an internet gateway. You can think of Google Home or Amazon Alexa as one of those. So in theory, you could get a reasonably standardized API to speak to devices via those smart home platforms, but you'll still have to deal with the fragmentation of various smart home platforms.
More problematic, you're still constrained by whatever APIs Google Home / Alexa...etc decide to make available and whatever device operations the Matter protocol also exposes. You could bypass the first problem by installing your own Matter-compatible device hub, but the goal of many of our API customers is to NOT have to deploy any new hardware.
Lastly, a lot of Seam customers need to integrate devices that are not covered by the Matter standard and probably never will (e.g. Access Control Systems).
context: I sat next to Grant Erickson and the Nest team that initially worked on Weave, which eventually became Thread. I still have close friends working on Matter implementation at Google/Amazon/Apple.
Matter is a device-to-device protocol within a local Thread network. It's solid for getting one device to tell another device on the same Thread network to perform an action, retrieve data...etc. Since Matter is pretty consumer-centric, those devices are generally all contained within a home.
To remotely control those devices (i.e. what our API customers want to do), you sort of need a Thread border router to serve as an internet gateway. You can think of Google Home or Amazon Alexa as one of those. So in theory, you could get a reasonably standardized API to speak to devices via those smart home platforms, but you'll still have to deal with the fragmentation of various smart home platforms.
More problematic, you're still constrained by whatever APIs Google Home / Alexa...etc decide to make available and whatever device operations the Matter protocol also exposes. You could bypass the first problem by installing your own Matter-compatible device hub, but the goal of many of our API customers is to NOT have to deploy any new hardware.
Lastly, a lot of Seam customers need to integrate devices that are not covered by the Matter standard and probably never will (e.g. Access Control Systems).
context: I sat next to Grant Erickson and the Nest team that initially worked on Weave, which eventually became Thread. I still have close friends working on Matter implementation at Google/Amazon/Apple.
Would you offer a way to jailbreak devices so they don't become e-waste?
yes! I was discussing this exact idea yesterday with a customer with a bunch of devices locked into an old software platform. Ideally we'd want to provide both open firmware and an open backend.
I haven’t checked if you guys are hiring, but I would immediately want to be part of this. I do a lot of reverse engineering these days as well as hardware fabrication to create “bridges” from one device to another.
we are! can you email [email protected]? We have a couple of hardware projects in development/beta (https://www.seam.co/seam-bridge). We're also interested in providing guides for flashing your own device with some open Yocto-based firmware that we've worked on in the past.
Congratulations on the launch, Sy. Brilliant idea!
Any notable use cases live you can share?
I'm a developer that recently discovered Seam (credit to a stack overflow thread). For my app Home Alerts, Seam is a bridge to device manufactures that do not offer a pubic API. The expensive alternative requires persistence through unanswered linkedIn msgs, cold calls, and the common "interested in integrating" web forms that seem to go nowhere. Even when achieving a direct manufacture affiliation, I'm then tasked with integrating with the their unique authorization-workflow and often clunky APIs.
Seam solves that problem. Utilizing Seam's existing partnerships and common APIs, I can add support for 20+ new devices within just a few days (vs months). My current customers include BnB hosts, and residential users seeking remote monitoring/control. We're making the push into the PMS market in Q4, which became achievable due to our new Seam partnership.
If anyone is interested in a demo of our current seam-powered integrations please reach out [email protected]
Seam solves that problem. Utilizing Seam's existing partnerships and common APIs, I can add support for 20+ new devices within just a few days (vs months). My current customers include BnB hosts, and residential users seeking remote monitoring/control. We're making the push into the PMS market in Q4, which became achievable due to our new Seam partnership.
If anyone is interested in a demo of our current seam-powered integrations please reach out [email protected]
We started Seam out of our frustration with the challenges of integrating IoT devices with software apps.
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.
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.
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.
Seam serves as a single API that works across dozens of brands and hundreds of devices.
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.
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.
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.