We need an operating system for the places we live in

The automation industry has drifted to the point it’s bonkers… How is it 2026 and we still need a thousand different protocols, platforms and apps to talk to the places we live in?

A house, a cabin, an RV and a recreational boat may look completely different. But from an automation point of view, they are remarkably similar.

They all need energy, climate, lighting, sensors, cameras, security, access, water and appliances. They increasingly want the same interfaces too: a central touchscreen, a phone and voice control.

Yet the industries serving them have evolved almost completely separately.

Same needs, different worlds

In homes, we have KNX, Matter, Zigbee, Z-Wave, Thread, Modbus and BACnet, alongside proprietary ecosystems from companies such as Lutron and Schneider Electric.

In RVs, there is RV-C and CAN, with ecosystems built around companies such as Victron, Dometic, Lippert and Garmin. Garmin's SERV/EmpirBus is a good example of a sophisticated central control system for lighting, HVAC, energy and other RV functions.

In boats, we get NMEA 2000, CAN, CZone, EmpirBus, SeaTalkng and marine Ethernet, with ecosystems from Garmin, Raymarine and B&G/Simrad.

And underneath much of this sits something remarkably common: CAN, Ethernet, IP and ordinary electrical systems.

Of course there are differences: A boat needs navigation and has to survive salt water. An RV has an engine, batteries and shore power. A house has a different electrical infrastructure. But those differences mostly belong at the hardware and integration layer.

The user shouldn't have to care. And most importantly: we shouldn’t have to use a thousand different apps and devices to care.

Open standards, proprietary islands

There is also a huge difference in openness.

Ethernet, IP, CAN, MQTT and Modbus are widely accessible technologies with large open-source ecosystems. Matter, KNX, NMEA 2000 and RV-C are industry standards, although they differ considerably in how open their specifications and ecosystems are.

Then there are proprietary systems such as EmpirBus, CZone and SeaTalkng, along with countless vendor-specific APIs, configuration tools and cloud platforms.

The result is strange: we have extremely sophisticated technology for automating physical spaces, but no common software layer that treats those spaces as what they fundamentally are: a place to live in.

We need an “habitat OS”

Maybe the missing piece isn't another protocol or another hardware company, but an OS for physical places.

A common architecture for the whole stack. Apply (or invent) open standards and open-source technologies wherever possible instead of creating yet another proprietary protocol.

The goal would be true interoperability. A climate unit, light, battery, pump or sensor shouldn't become a fundamentally different thing because it happens to be installed in a house, cabin, RV or boat. Appliances could be replaced or upgraded independently, while the habitat OS would discover their capabilities and expose them through the same model, automation engine and interface.

The technology to do much of this already exists: CAN, Matter, Modbus, MQTT, Ethernet and a huge ecosystem of open-source software (HomeAssistant) and hardware.

The pieces are already on the table. We just need to stop building walls and start compiling an open-source ecosystem.