top | item 47086335

(no title)

arjunbajaj | 10 days ago

The core issue is the user/developer experience of Industrial IoT is nowhere near where it should be. I understand where you're coming from, and I feel the same way too. Building a great developer experience is something we deeply care about. Exactly for that reason, we started building our own Device SDKs.

We also have support for open protocols such as MQTT and HTTP+SSE, but the Device SDKs enable us to provide a richer set of capabilities. Our SDKs actually speak a custom protocol we developed for higher efficiency. We're also going to add many more features such as automatic telemetry collection and tracing support, which is more feasible with a plug-and-play SDK.

Another big issue you pointed out is with documentation, a key part of Developer Experience is always great docs. A compelling model might be standalone open source tooling that works independently, with an integrated platform that ties it all together, creating a strong ecosystem.

I've been using Home Assistant with a bunch of Zigbee and Wifi devices at home, and it's been pretty stable. However, for an industrial context, there are already many other hurdles, having a platform handle a lot of the cloud infra and connectivity & monitoring is really helpful.

discuss

order

igor47|6 days ago

The problem with custom protocols and SDKs is vendor dependence. When you go out of business or pivot, what happens to my product? I was already burned once by Google cloud IoT...

siddhantdhaware|5 days ago

You’re completely right. Vendor lock-in and platforms shutting down are real risks. We also used Google IoT Core in our previous startup and would have been burned by its shutdown as well.

In fact, the idea for a unified IoT platform came from dealing with the complexity of setting up so many different Google Cloud services just to get data ingestion working.

I think a healthy balance between open source and commercial platforms is possible. We want to compete on reliability, UX, and features while building open device-side tooling and protocols that give users the ability to switch or self-host if they choose. We’re far from that today, but it’s the direction we want to pursue.

-- Sid, Fostrom Co-Founder