[HN Gopher] Launch HN: Seam (YC S20) - API for IoT Devices
___________________________________________________________________
Launch HN: Seam (YC S20) - API for IoT Devices
Hey HN! We're building Seam (https://www.seam.co), 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. 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.
Author : __sy__
Score : 104 points
Date : 2023-06-06 14:00 UTC (9 hours ago)
| Terretta wrote:
| Thread ... Seam. Thread ... Seam.
|
| OK, I'm off to kickstart (re)Ravel.
| __sy__ wrote:
| What if I told you that before Thread, the original comm
| protocol layer at Nest was called--wait for it--WEAVE!
| SCUSKU wrote:
| Congrats on the launch! Beautiful landing page by the way!
| Wishing Seam all the best :)
| __sy__ wrote:
| 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.
| ThomasRooney wrote:
| 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.
| __sy__ wrote:
| 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.
| mikeryan wrote:
| So shouldn't "Matter" take care of this in a standard and open
| way moving forward?
| __sy__ wrote:
| 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.
| sim_123 wrote:
| Congratulations on the launch, Sy. Brilliant idea!
| candiddevmike wrote:
| Would you offer a way to jailbreak devices so they don't become
| e-waste?
| __sy__ wrote:
| 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.
| samtho wrote:
| 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.
| dawnho wrote:
| we are! can you email kat@seam.co? 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.
| frenchie4111 wrote:
| Excited for the launch! Looks like you've built something cool.
| Excited to try it out
| __sy__ wrote:
| Thank You!
| steve_adams_86 wrote:
| 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.
| __sy__ wrote:
| 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.
| samtho wrote:
| 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.
| comprev wrote:
| "Our mission is to make device integration simple..." would be
| more appropriate
| treesciencebot wrote:
| 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?
| vdfs wrote:
| 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
| __sy__ wrote:
| 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.
| kposehn wrote:
| Fantastic! I've been wanting this for some time.
|
| Any plans for integrating ubiquiti cameras and access systems?
| __sy__ wrote:
| 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)?
| kposehn wrote:
| 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)
| ahstilde wrote:
| 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?
| dawnho wrote:
| 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.
| paulgerhardt wrote:
| 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!
| internetter wrote:
| > 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?
| __sy__ wrote:
| 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.
| comprev wrote:
| >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.
| entropie wrote:
| > 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.
| __sy__ wrote:
| 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.
| internetter wrote:
| > 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
| ZubairAhsan wrote:
| Any notable use cases live you can share?
| hadjian wrote:
| 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.
| __sy__ wrote:
| 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.
| hadjian wrote:
| 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
| __sy__ wrote:
| 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 Aurelien Geron
| (https://github.com/ageron) Hands-On Machine Learning books
| into French.
| michaelmior wrote:
| Can I use the API _without_ going through Seam servers at all?
| That is, communicate directly with the device (or the
| manufacturer 's cloud)?
| __sy__ wrote:
| 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.
| michaelmior wrote:
| 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.
| internetter wrote:
| 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?
| __sy__ wrote:
| 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.
| mountainofdeath wrote:
| 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.
| __sy__ wrote:
| 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.
| klinquist wrote:
| 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!
| __sy__ wrote:
| 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!
| klinquist wrote:
| haha - I do not recall! But you're welcome :).
___________________________________________________________________
(page generated 2023-06-06 23:00 UTC)