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