The Real Reason KNX Doesn't Need A Yearly Product Launch

Every September brings a fresh crop of smart home hub launches. New hub, new AI assistant, new "local-first" promise, all built and owned by one company. I've written about a few of them this month already. KNX Association put out something different this week, and it's worth more attention than it probably got. It wasn't a product announcement. It was closer to an explanation of how the standard behind everything I install actually keeps itself current, and it's a much bigger deal than the headline suggests.

Innovation without a single company carrying the risk

Here's the part that stood out to me. KNX Association now has over 500 member companies (Hager and Ekinex, the brands I supply, sit inside that number, alongside hundreds of others I don't). Instead of every one of those manufacturers separately solving the same problems (security, compliance, protocol updates, new device categories), the standard is developed collectively through a set of Working Groups, with a KNX Technical Board coordinating the technical direction across all of them.

That's a genuinely different model from how a single-vendor smart home platform has to operate. When one company owns the whole stack, one company also owns the entire cost of keeping it secure, compliant, and current, on its own budget, on its own timeline, answerable to its own shareholders. If that company's priorities shift, or the division gets sold off, or the roadmap gets deprioritised, everyone using that platform inherits the consequences. I've made this point before about platforms that get discontinued or repriced overnight. This is the structural reason KNX doesn't have that failure mode built in: no single company can quietly decide the standard isn't worth maintaining anymore, because no single company owns it.

Two things in it are worth digging into properly

Most of what's in the KNX Association's piece is strategic language you could apply to any standards body. Two specific things in it are concrete enough to matter on a real project.

The first is an open-source stack for KNX IoT. KNX IoT is a separate, newer part of the standard: an IP-based way for KNX to talk to smart devices over wireless protocols like Thread, distinct from the wired twisted-pair bus I specify on every job. Building support for a new protocol from scratch is expensive, and that expense used to sit entirely with whichever manufacturer wanted to build a KNX IoT device. Now there's a certified, open-source software stack, developed with a company called Cascoda, already ported to real Thread-based hardware with its own development board, and NXP is working on a parallel version, that a manufacturer can build on instead of writing the whole thing themselves. That lowers the cost of entry for smaller and newer manufacturers specifically. For a client, that eventually means more device choice inside the same open standard, not a new closed ecosystem to evaluate from scratch every time a new category of device shows up.

The second is Semantic Import in ETS 6.4, and it's easy to undersell if you've never sat through a commissioning session. KNX has its own structured data model, called the KNX Information Model, that describes what a KNX installation consists of and how its parts relate to each other, not just as a spreadsheet of group addresses but as something software can reason about. Semantic Import uses that model to pull structured project data into ETS automatically instead of requiring it to be entered by hand, group address by group address. Fewer manual entries means fewer transcription errors in a project file, and a project file is the thing every future service call, fault-find, and additional-circuit job depends on being accurate. It's not a flashy feature. It quietly makes a system more maintainable ten years after handover, right around the point most proprietary platforms have already been discontinued twice.

This is a design-decision question, not an engineering footnote

The Association's piece also touches on something worth pulling out on its own: KNX says it already meets the requirements of the EU's Cyber Resilience Act, ahead of the law being fully in force. I've covered the CRA itself in detail before, so I won't re-explain it here, but the timing is the point. The standard was built to anticipate a compliance requirement years before it became mandatory, rather than scrambling to retrofit it once regulators forced the issue. That timing isn't an accident. A collectively maintained, non-proprietary standard can spread the cost of getting ahead of a problem across 500 companies, instead of leaving each one to gamble on guessing right alone.

None of this shows up in a walkthrough of a finished house. Nobody notices a semantic data model or an open-source protocol stack while they're standing in their new kitchen. But it's exactly the kind of thing worth asking about at the point you're choosing what to specify, not after the walls are closed and the system is already locked into one vendor's roadmap. When an architect or a client asks me why I don't work with a single proprietary ecosystem instead of an open standard, this is most of the answer. It's not that KNX has better marketing. It doesn't, most people have never heard of it outside the trade. What it has is 36 years of the people maintaining it sharing the cost of staying current, instead of betting an entire house on one company's ability to keep doing that alone.

If you're scoping a project with an architect or an installer and want to understand what "open standard" actually buys you beyond a talking point, it's worth a proper conversation before the spec gets locked in.

Just a conversation about what the project needs.

wayne@knxlogic.co.za | 082 564 3982 | www.knxlogic.co.za