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.

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