KNX Standard v3.0.5 Explained

Yesterday, KNX Association pushed Standard v3.0.5 out to its manufacturer members through MyKNX. Nobody’s light switch changed behaviour overnight, and nothing on any bus I look after did either. That’s normal. A protocol update like this ships to the people who build the devices first, and it takes a year or two to show up on a wall near you.

But I read through what’s actually in this one, and four parts of it are worth knowing about now, before they turn into a product on a shelf and a salesperson tells you it’s brand new.

Colour stops needing a workaround

Up to now, getting proper hue, saturation and brightness control out of a KNX lighting device usually meant a manufacturer building their own logic on top of the standard, converting RGB values into something usable, each one solving it slightly differently. v3.0.5 adds HSV-based colour processing directly into the KNX framework. A manufacturer can now build a device that speaks hue, saturation and brightness natively, without inventing their own conversion layer.

Practically, that means colour-capable KNX devices from different manufacturers should start behaving more consistently with each other, the same three values doing the same thing regardless of who built the actuator. The standard also adds proper identification, measurement, diagnostic and maintenance functions for lighting devices specifically, which matters more than it sounds. A lighting scene with a dozen colour-capable fixtures is a nightmare to fault-find if half of them can’t report their own state cleanly. This closes that gap at the protocol level instead of leaving it to whoever wrote the best documentation.

Remote access without a VPN, once someone actually builds it

This is the part getting the most attention, and it’s also the part I’d flag hardest as “wait and see.” The standard now includes a cloud interface for KNXnet/IP installations, aimed at secure remote access without a VPN tunnel. The stated use cases are the obvious ones: commissioning, diagnostics, service access from off-site.

Right now this is a specification, not a product. Nothing I can point you to today implements it. What it does mean is that remote access stops being something every manufacturer bolts on with their own proprietary app and their own security assumptions, and starts being something the standard itself defines a correct way to do. That’s worth wanting, carefully. VPN-free remote access is only as good as how it’s implemented, and I’d want to see how the first real products handle authentication before recommending anyone rely on it for a live security or access-control installation.

One firmware update method instead of a dozen

KNX devices from different manufacturers have handled firmware updates in different, mostly manufacturer-specific ways for years. v3.0.5 defines a standardised method for secure firmware updates across devices, regardless of who made them.

KNX Association is explicit that this is partly about the EU’s Cyber Resilience Act, which puts new obligations on connected-product manufacturers around vulnerability handling and updates. A standardised update mechanism gives manufacturers a documented, common way to meet that requirement instead of each one building and defending their own. It doesn’t automatically make any specific product CRA-compliant, that’s still down to the manufacturer, but it removes one of the excuses for skipping firmware support altogether. For an installation you’re expecting to still be working in fifteen years, a documented update path baked into the standard itself is a better guarantee than a manufacturer’s current goodwill.

KNX Classic and KNX IoT learning to share a project properly

The fourth change is quieter but matters for anyone running a mixed installation, KNX Classic devices on a bus alongside newer KNX IoT components. KNX Association has rewritten the KNX IoT test specifications to match the current KNX IoT architecture, naming the third-party API, the Point API and the KNX IoT router specifically. That gives manufacturers a proper, current basis to test and certify KNX IoT devices against, and the point of it is blunt: Classic and IoT devices should interoperate reliably in the same project, not just technically coexist while quietly failing to talk to each other properly.

Why this is the part of the story worth telling

None of this is flashy. There’s no press event, no product launch, no reason for it to show up in your feed. But it’s the actual mechanism behind a claim I make to clients often: KNX isn’t a fixed product that gets replaced when a company changes strategy, it’s a standard that keeps getting extended by the same body, backward compatible, twenty, thirty years in. A 36-year-old standard adding native colour handling, a proper remote access story, and a shared firmware update mechanism in 2026 is what that actually looks like in practice, not just a line in a sales pitch.

It’ll be a while before any of this reaches a device on your wall. When it does, I’ll know exactly what changed and why, instead of reading a manufacturer’s marketing copy and taking their word for it.

If you’re at brief stage on a project and want to talk through what any of this means for your build, get in touch. Just a conversation about what the project needs.

Wayne

KNX Logic

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