Launch HN: Seam (YC S20) – API for IoT Devices

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.

"Our mission is to make device integration simple..." would be more appropriate

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.

>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 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?

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.

Thanks! btw I don't know if you recall this, but very early on in Seam, you took the time to give us some advice. That was really kind and thoughtful. Thank You!

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 sy@seam.co if you guys need help with various integrations.

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

this is awesome! Not sure if you saw our hardware bridge, but it's custom built specifically for DoorKing units to bring them online and what not. I'll drop you a note now.

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 (sy@seam.co)?

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!

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.

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".

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.

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.

Thank You!

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 sy@seam.co with an example configuration, I'd like to discuss it internally.

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.

Happy to help. Have you tried Home Assistant as well? It's pretty good for personal use cases and such.

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.

Thank You!

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.

What if I told you that before Thread, the original comm protocol layer at Nest was called—wait for it—WEAVE!

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 bwebb@homealerts.app