Daniel sent us this one, and it's a good follow-up. He's been thinking about the hotel automation episode, and he's got a practical question. If you're building a house, and you're technically minded, and you're already doing the electrical work anyway, can you deploy the kind of industrial-grade wired automation that hotels use, instead of consumer Wi-Fi and Zigbee stuff? And specifically, where do you buy it, what does it cost, and can you actually connect it to Home Assistant?
Oh, this is the good stuff. This is where we get to talk about the parallel universe.
The parallel universe of things that actually work.
And Daniel's framing is spot on. He mentioned that his Wi-Fi Tuya switches are the most brittle part of his setup, and that's not a coincidence. The fundamental insight here is that consumer IoT and professional building automation evolved completely separately. They're solving different problems with different assumptions about what "reliable" means.
Before we dive into that, quick note. Today's episode is being scripted by DeepSeek V four Pro. Don't mess this up.
So, the professional universe. Daniel mentioned Modbus, KNX, and he name-dropped Loxone. These are not household names unless your household is a forty-story office tower. But they're not exotic either. KNX, for example, is an open standard that's been around since 1999. It grew out of earlier European installation bus standards, and it's ratified as both a European standard, EN 50090, and an international standard, ISO slash IEC 14543. This is not some startup's proprietary protocol that might vanish in three years.
So this predates the entire consumer smart home wave by a solid fifteen years.
And that matters because the design philosophy is completely different. In the consumer world, you've got this assumption that everything talks over IP, everything connects to a router, and if something goes wrong you reboot it or fiddle with an app. In the KNX world, the bus is the network. It's a dedicated twisted-pair cable, usually green, that carries both power and data to every device on the bus. You don't need IP addresses, you don't need Wi-Fi, you don't need a router. The bus is self-contained.
Daniel's point about buying yourself a long cable is literally the founding principle of KNX.
And because it's a dedicated bus, you don't have to worry about your neighbor's Wi-Fi blasting through your walls, or your microwave oven knocking out your light switches. The bus operates at a very low data rate, something like 9600 bits per second, which sounds laughable by modern standards, but it's more than enough for sending "turn on the lights" or "the temperature is twenty-two degrees." And that low data rate makes it incredibly robust over long distances.
Let's get concrete. Daniel's hypothetical. He's building a house. He's got Home Assistant running on a server somewhere. He wants to put in wired switches, wired sensors, wired everything. Where does he actually start with KNX?
He needs three things. A KNX power supply, a KNX bus cable, and KNX devices. The power supply is a little DIN-rail module that provides thirty volts DC to the bus. It's specifically designed to decouple the bus from mains power. You need one per bus segment, and a segment can handle up to sixty-four devices. For a house, one segment is usually plenty.
KNX bus cable. It's a specific type, usually designated YCYM two by two by zero point eight. It's a twisted pair, shielded, and it's rated for running alongside mains voltage cable in the same conduit, which is a huge practical advantage. An electrician can pull the KNX cable right alongside the power cables, and the shielding handles the interference. Cost-wise, you're looking at somewhere around fifty to eighty cents per meter. So for a whole house, you might spend a few hundred dollars on cable. It's not a major line item.
Then the devices themselves. What does a KNX light switch cost, compared to a consumer Zigbee switch?
This is where the sticker shock hits. A basic KNX push-button switch from a manufacturer like Gira or Jung is going to run you somewhere between eighty and a hundred and fifty euros. That's per switch. A KNX dimming actuator that sits in your electrical panel and actually controls the lights is another hundred and fifty to three hundred euros. And you need one actuator channel per lighting circuit. So if you've got ten lighting circuits in your house, you're looking at a couple thousand euros just in actuators.
We're talking about a system that costs, what, five to ten times what a consumer setup costs?
But here's the thing. That KNX switch will still be working in twenty years. The company that made it, Gira or Jung or Siemens, has been in business for decades and will probably be in business for decades more. The protocol is backward-compatible all the way to 1999. When you install KNX, you're installing infrastructure, not gadgets.
There's a philosophical difference there that I think is worth underlining. In consumer IoT, you're buying products. In KNX, you're buying a system. The products are components of the system, and they're designed to be replaced individually over decades without breaking the whole thing.
And that's why hotels and airports and museums use this stuff. They can't afford to have a light switch stop working because a cloud server went down or a company went out of business. The bus runs locally, with no internet dependency whatsoever. Every device has its own little microcontroller that runs its own logic. If the KNX bus is up, the system works, even if your Home Assistant server is on fire.
Let's talk about the other protocol Daniel mentioned.
Modbus is even older than KNX. It dates back to 1979, developed by Modicon for industrial programmable logic controllers. It's dead simple. It's a serial protocol, originally running over RS-232 or RS-485, and it basically just reads and writes registers. A register might hold the state of a relay, or a temperature reading, or a setpoint. The elegance of Modbus is that it's so simple you can implement it on anything. It's still widely used in industrial automation, HVAC systems, power meters, that kind of thing.
In a residential context?
Less common for light switches, but very common for things like energy monitoring, heat pump control, ventilation systems. If you're installing a serious HVAC system in your house, there's a good chance the controller speaks Modbus. And the nice thing is that Modbus is so simple that integrating it with Home Assistant is trivial. You can buy a Modbus to Ethernet gateway for fifty bucks, plug it into your network, and Home Assistant can read and write registers directly.
You might end up with a hybrid. KNX for lighting and blinds and basic switching, Modbus for HVAC and energy, and then Home Assistant sitting on top tying it all together with Zigbee for the more consumer-y stuff like door sensors and motion detectors.
That's a very sensible architecture. And it's exactly what a lot of high-end residential installers do. They're not using one protocol for everything. They're picking the right tool for each job.
Now Daniel also name-dropped Loxone, which is a bit different from KNX. What's their deal?
Loxone is an Austrian company, founded in 2009, and they're kind of the bridge between the professional world and the prosumer world. They sell a complete smart home system that's based around their Miniserver, which is a little DIN-rail computer that runs everything. Their devices communicate over a proprietary protocol called Loxone Link, which uses standard Cat7 cable. So you're wiring your house with ethernet cable, not a special bus cable.
Which is appealing because Cat7 is cheap and every electrician knows how to terminate it.
Loxone's whole pitch is simplicity through vertical integration. They make the server, they make the switches, they make the actuators, they make the sensors. It all works together out of the box. And their programming environment, Loxone Config, is designed to be used by electricians and installers, not software engineers. It's a graphical flow-based programming system where you drag blocks around and connect them.
It's like the Apple of building automation.
That's a really good comparison. It's more expensive than a DIY KNX setup, but you're paying for the integration and the simplicity. A typical Loxone Miniserver is around six hundred euros. Their switches, the Loxone Touch, are about two hundred euros each. Their actuators are similarly priced to KNX actuators. For a whole-house system, you might be looking at five to ten thousand euros in hardware, plus installation.
The big question Daniel's asking. Can these things talk to Home Assistant?
Yes, and this is where things have gotten really interesting in the last few years. KNX has a native integration in Home Assistant. It's been there for years, it's mature, and it works over IP. You need a KNX IP interface, which is a little device that bridges the KNX bus to your ethernet network. That costs about two to three hundred euros. Once that's in place, Home Assistant can see every KNX device on the bus, read their states, and send commands. It's bidirectional and it's local. No cloud, no middleman.
Loxone is a bit more complicated. There's no official Home Assistant integration, but there's a very active community integration that works through Loxone's web API. It's not as seamless as the KNX integration, but it's functional. You can read sensor values and control outputs. The bigger question with Loxone is whether you even need Home Assistant. Loxone's own automation engine is quite capable. You might use Home Assistant just as a frontend, or for integrating non-Loxone devices.
That raises an interesting question. If you go all-in on KNX or Loxone, what's the role of Home Assistant? Is it still the brain, or does it become more of a supervisory layer?
In a well-designed KNX system, Home Assistant is not the brain. The brain is distributed across the KNX devices themselves. A KNX switch talks directly to a KNX actuator on the bus. That communication happens in milliseconds and doesn't touch Home Assistant at all. Home Assistant is the integration hub and the user interface. It's what lets you control your KNX lights from your phone, or create automations that involve non-KNX devices, or view your energy dashboard.
Which is exactly the architecture Daniel described from the hotel episode. Distributed intelligence at the edge, with a central coordinator for cross-system logic and user access.
And this is the thing that consumer IoT gets wrong, in my opinion. Everything is star-topology back to a hub or a cloud server. If the hub goes down, nothing works. In a proper distributed bus system, the hub is optional for basic operation. The lights still turn on when you press the switch, even if your server is a smoking crater.
Let's talk about cost more concretely. Daniel asked what this actually looks like for a real house. Let's say a two-thousand-square-foot house, three bedrooms, open-plan living area. Maybe twenty lighting circuits, ten switch locations, some blinds, a few heating zones.
For a KNX system, you're looking at roughly. Twenty lighting circuits means you need a twenty-channel actuator, or a couple of smaller actuators. That's about fifteen hundred to two thousand euros. Ten switch locations, each with a four-button KNX switch. At a hundred euros per switch, that's a thousand euros. You need a KNX power supply, about two hundred euros. A KNX IP interface, another two hundred fifty. A few hundred meters of bus cable, call it three hundred euros. You're at around thirty-five hundred to four thousand euros just for the core lighting control. That doesn't include the actual light fixtures, just the control system.
If you add blinds?
KNX blind actuators are another few hundred euros per blind. Plus the motors themselves, which are a separate cost. Heating control, you'd add KNX thermostats or use Modbus to talk to your heat pump. That's another thousand or so. All in, you're probably at six to eight thousand euros for a comprehensive KNX system in that house.
The consumer equivalent? Zigbee switches and relays?
A Zigbee in-wall relay is about fifteen to twenty euros. A Zigbee switch is thirty to fifty euros. For the same twenty circuits and ten switches, you're looking at maybe eight hundred to a thousand euros total. So KNX is roughly five to eight times more expensive. But again, you're comparing a twenty-year infrastructure investment to consumer electronics that might be obsolete in five years.
There's also the labor question. Daniel said he's DIY-friendly and would do the wiring himself. Is KNX something a competent DIYer can actually install?
Yes, with some caveats. The physical installation is straightforward. The bus cable is low-voltage, so in most jurisdictions you don't even need an electrician's license to pull it, though you do need an electrician for the mains voltage side of things. The topology is a free topology. You can daisy-chain, star, tree, whatever. You just can't make loops. The programming is done with a software tool called ETS, the Engineering Tool Software. That's a professional tool and it requires a license. The lite version is about two hundred euros. There's a learning curve. It's not like pairing a Zigbee device where you just press a button. You need to understand group addresses and device parameters. But it's not rocket science either. If you're the kind of person who's comfortable configuring Home Assistant YAML, you can learn ETS.
The barrier is more about knowledge and willingness to learn than about requiring specialized equipment or certifications.
And there's a very active community around KNX DIY. There are forums, YouTube channels, even online courses. It's niche, but the resources are there.
Daniel also asked about where to actually buy this stuff. He said he hasn't seen it on AliExpress.
You can find some KNX stuff on AliExpress, but I wouldn't recommend it. The reputable sources are electrical wholesalers and specialized online shops. In Europe, places like Voltus, Eibmarkt, and Ivory Egg. These are B2B suppliers that also sell to individuals. You can just create an account and order. In North America, it's a bit harder because KNX is less common there. Loxone sells direct through their website and through a network of installers. You can buy their gear as an end user, but their support model assumes you're an installer.
That's an important practical point. If you're in North America, KNX is a less obvious choice than in Europe, simply because the supply chain and installer ecosystem are smaller.
In North America, you might look at something like Lutron's professional systems instead. Lutron HomeWorks is the rough equivalent of KNX in the US market. It's a wired, dealer-installed system that's been around for decades and is extremely reliable. But Lutron is more locked down than KNX. You typically need to be a certified dealer to program it. There are third-party integrations with Home Assistant, but they're reverse-engineered, not officially supported.
The open, DIY-friendly professional system is really more of a European phenomenon, driven by KNX being an open standard.
KNX is the standout here because it's truly open. Any manufacturer can make KNX devices, and there are over five hundred manufacturers in the KNX Association. You've got everything from premium German brands like Gira and Jung to more affordable options like MDT and Zennio. Competition keeps prices somewhat in check, and you're not locked into one vendor's ecosystem.
Let's pivot to something Daniel mentioned in passing. The ultra-wealthy yacht automation world. Is that a different set of protocols entirely?
Yachts use a lot of the same industrial protocols. Modbus is huge in marine automation. So is CAN bus, which is the protocol used in cars. NMEA 2000 is a marine-specific standard built on CAN bus. But the philosophy is the same. Wired, distributed, no single point of failure, no cloud dependency. The difference is that yacht systems are even more redundant because failure at sea is a lot more consequential than a light not turning on in your living room.
The cost is in a completely different universe.
A yacht automation system from a company like Crestron or Lutron's marine division can run into the hundreds of thousands. But the underlying principles are identical to what we're talking about with KNX in a house.
The average technically minded person building a house can tap into the same reliability principles without the yacht budget.
You're not getting the triple-redundant servers and the twenty-four-seven support contract, but you're getting the same bus topology, the same distributed intelligence, the same twenty-year lifespan. That's the democratization that's happened in the last decade. These professional protocols are now accessible to individuals.
There's a question of future-proofing here too. If I install KNX today, am I locking myself into something that'll feel dated in ten years?
I'd argue the opposite. KNX is more future-proof than any consumer protocol precisely because it's so simple and so standardized. The KNX bus doesn't care what's happening in the world of Wi-Fi or Matter or whatever comes next. It's just a bus. It sends telegrams. A telegram says "group address five slash one slash three is now value one." That's it. That abstraction layer means you can swap out the controller, the user interface, the integration hub, without touching the underlying infrastructure. In ten years, you might be running Home Assistant version twenty on whatever hardware exists then, talking to your KNX bus through whatever IP interface exists then, and the switches on your walls will still just be KNX switches doing their thing.
That's a sharp contrast to consumer systems where the protocol and the hardware are tightly coupled. If you buy a Philips Hue system, the bulbs and the hub and the protocol are all one ecosystem. If Philips decides to change the protocol, you're replacing everything.
Or if they shut down the cloud service. Which has happened multiple times in consumer IoT. Companies go under, servers go offline, and suddenly your hardware is e-waste. With KNX, the bus is the bus. Even if every KNX manufacturer went out of business tomorrow, the devices in your walls would still work. You just wouldn't be able to buy new ones. But they'd keep working.
Let's talk about the integration with Home Assistant more practically. Daniel's got a Home Assistant setup. He's comfortable with it. If he installs KNX, what does that actually look like day to day?
You install the KNX IP interface, which is a little DIN-rail module that connects to the KNX bus on one side and ethernet on the other. You give it an IP address. In Home Assistant, you add the KNX integration, point it at that IP address, and it just works. You don't need to configure individual devices. Home Assistant discovers them automatically through the bus. Every switch, every actuator, every sensor shows up as an entity. You can then build your dashboards, your automations, your scenes, exactly as you would with Zigbee or Z-Wave devices.
KNX telegrams propagate across the bus in milliseconds. The IP interface adds maybe ten to twenty milliseconds of latency. So from the moment you tap a button in the Home Assistant app to the light turning on, you're looking at maybe thirty to fifty milliseconds total. That's faster than most consumer Zigbee setups, and dramatically faster than anything that goes through a cloud server.
Reliability wise, if Home Assistant crashes, the KNX bus doesn't care. The physical switches still work. The basic automations that are programmed directly into the KNX devices still work.
That's the key. You program the critical stuff directly into the KNX devices using ETS. Things like "this switch controls that light" or "if the motion sensor triggers, turn on the hallway lights." Those are KNX group address assignments. They run on the bus, not on Home Assistant. Home Assistant handles the higher-level stuff. "When everyone leaves the house, turn off all the lights and arm the alarm." That kind of cross-system automation is where Home Assistant shines, and if it fails, you lose those conveniences but not basic functionality.
That separation of concerns is so clean. The bus handles reliability-critical local control. The server handles integration and intelligence. Neither depends on the other for its core function.
It's the exact architecture Daniel described from the hotel episode, scaled down to a single-family home. Room-level controllers for local functions, a building-level controller for cross-room coordination, and then whatever supervisory layer you want on top.
What's the catch? Why isn't everyone doing this?
Cost, complexity, and awareness. The cost we've covered. It's five to eight times more expensive up front. For a lot of people, that's a non-starter, even if the lifetime cost might actually be lower because you're not replacing failed devices every few years. The complexity is real. ETS is not an app you download and figure out in an afternoon. You need to invest time in learning it. And awareness is probably the biggest factor. Most people simply don't know KNX exists. They walk into a hardware store and see Philips Hue and think that's what smart lighting is.
There's a fourth reason that's more subtle. Most people don't stay in the same house for twenty years. The long-term reliability argument is less compelling if you're going to sell the house in five years.
That's a fair point. Though I'd argue that a well-documented KNX system could actually be a selling point for a house, especially to technically minded buyers. It's like having proper structured wiring instead of just Wi-Fi everywhere. It signals that the house was built with care.
Let's get into some specifics about manufacturers. If someone is convinced and wants to start planning a KNX system, who should they be looking at?
For switches and visible devices, the big names are Gira, Jung, and Basalte. Gira's E2 and E3 lines are the most common. They're solid, well-designed, and available in dozens of finishes. Jung's F-series and A-series are also excellent. Basalte is the high-end option, very minimalist, very expensive. For actuators and infrastructure devices that sit in the electrical panel, MDT is probably the best value proposition. They're a German company that makes reliable, no-frills DIN-rail devices at prices that are noticeably lower than Gira or Siemens. Zennio is a Spanish company that's also very competitive on price and makes some interesting multi-function devices.
The IP interface?
The KNX IP interface is a standardized device. You can get one from any manufacturer. MDT, Gira, Weinzierl, they all make them. They're functionally identical. Pick whichever is cheapest or in stock. The one thing to be aware of is that there's also something called a KNX IP router, which is slightly different. A router connects two KNX bus segments and also provides IP connectivity. An interface just connects one bus segment to IP. For a single-family home, an interface is all you need.
The software side. ETS is the programming tool. What versions are we talking about?
ETS6 is the current version as of 2026. ETS5 is still widely used and perfectly fine. The lite version of ETS6 is around two hundred euros and it's limited to sixty-four devices per project, which is enough for most houses. The professional version is a thousand euros and supports unlimited devices. For a DIYer, the lite version is almost always sufficient.
Sixty-four devices sounds like a lot, but if you've got twenty actuators, ten switches, a few sensors, an IP interface, a power supply, you're already at thirty-five or forty. Add blinds and heating and you could hit that limit.
You could, but it's rare in a typical house. And the limit is per project, not per bus. You can have multiple projects talking to the same bus if you really need to, though that gets complicated. For most houses, sixty-four is plenty.
Let's talk about Loxone again for a moment, because I think it's a compelling alternative for a certain kind of person. If ETS sounds intimidating, Loxone's programming tool is genuinely approachable.
Loxone Config is the closest thing to an "easy button" in the professional automation world. It's a graphical programming environment where you literally drag and drop function blocks and connect them with lines. A light control block has inputs for switches and outputs for lights. You wire them up visually. It's intuitive in a way that ETS is not. The tradeoff is that you're locked into Loxone's ecosystem. Your switches, your actuators, your sensors, they all have to be Loxone or Loxone-compatible. You can't mix and match manufacturers the way you can with KNX.
The cost difference?
Roughly comparable to mid-range KNX. Loxone hardware is not cheap, but it's not Basalte-expensive either. The Miniserver is six hundred euros, their switches are around two hundred, their actuators are competitive with MDT. Where Loxone gets expensive is if you want to integrate third-party stuff. They sell various extension modules for Modbus, for DALI lighting, for one-wire temperature sensors, and each of those adds cost.
That's another protocol Daniel didn't mention but that's relevant here.
DALI is the professional lighting control protocol. It stands for Digital Addressable Lighting Interface. It's a two-wire bus specifically for controlling luminaires and LED drivers. It's widely used in commercial buildings and it's often paired with KNX. KNX handles the switches and the high-level control, and then a KNX-DALI gateway translates between the two buses. DALI lets you do things like individual dimming control of every light fixture, color temperature adjustment, and emergency lighting testing. It's overkill for most houses, but if you're doing a lot of architectural lighting, it's worth considering.
A truly maximalist approach would be KNX for switching and sensors, DALI for lighting control, Modbus for HVAC and energy, all tied together with Home Assistant.
That's not a hypothetical. That's what high-end residential systems look like. It sounds complicated, but each piece is simple and reliable in its own domain. The complexity is in the integration, and that's exactly where Home Assistant excels.
There's a philosophical point here that I think Daniel's getting at with his "course of technology trends towards integration" comment. The consumer smart home industry keeps trying to build walled gardens. Apple HomeKit, Amazon Alexa, Google Home, Samsung SmartThings. Each one wants to be the platform. And the result is that consumers end up with fragmentation and confusion. Meanwhile, the professional world just uses open standards and integration layers, and it works.
The professional world figured out decades ago that no single protocol can do everything well. KNX is great for distributed switching and control. DALI is great for lighting. Modbus is great for industrial equipment and energy metering. BACnet is great for large-scale building management. M-Bus is great for utility metering. The solution isn't to make one protocol that replaces all of them. The solution is to have good gateways between them.
Matter is the consumer world's attempt to solve this, and it's been...
Matter is trying to do what KNX did thirty years ago, but over IP and with a much more complicated security model and a much broader scope. I think Matter will eventually get there, but it's still in its awkward adolescence. KNX is the grown-up in the room. It's boring, it's stable, and it works.
If Daniel and Hannah are building a house, and they're serious about this, what's the practical roadmap?
Decide on the backbone protocol. KNX if you want maximum openness and manufacturer choice. Loxone if you want simplicity and don't mind the ecosystem lock-in. Design the bus topology. Where do the cables run? Where does the DIN-rail panel go? This is something you'd typically work on with an electrician or a KNX consultant, but a determined DIYer can do it themselves with enough research. Buy the gear. Get it from a European online shop if you're doing KNX. Pull the cable and mount the devices. This is the physical install, and it's the most labor-intensive part. Program the system with ETS or Loxone Config. Integrate with Home Assistant.
Make sure your partner is on board with the budget and the aesthetic choices for the switches.
That might be the hardest step of all. Switch design is surprisingly contentious. Gira and Jung make beautiful stuff, but it's a particular aesthetic. Modern European minimalism. If your house has a more traditional look, you might need to look at some of the other KNX manufacturers that do more classic designs.
Daniel mentioned that Hannah is an architect, so she's probably got opinions about switch aesthetics.
Architects love KNX. The switches are sleek, the plates come in every finish imaginable, and the whole system can be completely invisible if you want it to be. You can put the actuators in a utility closet and just have the switches on the walls be these minimalist panels that don't look like technology at all.
Let's talk about one more practical concern. When something goes wrong with a consumer smart home, you reboot the hub, you re-pair the device, you google the error message. What happens when a KNX system has a problem?
KNX problems are rare, but when they happen, they're usually physical. A cable gets damaged. A device loses power. The bus voltage drops below the threshold. ETS has diagnostic tools built in. You can monitor the bus traffic, see which devices are responding, check the bus voltage. It's more like troubleshooting a network than troubleshooting an app. The good news is that because the system is so simple at the physical layer, the problems are usually straightforward to diagnose. Bad cable, loose connection, failed power supply.
KNX devices are built to industrial standards. They're designed for a twenty-year lifespan in commercial environments. In a residential setting, they'll probably outlast the house. But if a device does fail, you replace it with the same model or a compatible one, download the configuration from ETS to the new device, and you're back up. No re-pairing, no re-configuring automations. The configuration lives in your ETS project file, not in the device.
That's a huge difference from consumer IoT. If a Zigbee switch fails, you have to exclude it, include the new one, re-name it, re-add it to all your automations. It's a pain.
If the manufacturer changed the device firmware or the model is discontinued, you might be starting from scratch. With KNX, a switch from 2005 and a switch from 2026 are functionally identical on the bus. You can mix them freely.
Let's circle back to Daniel's core question. Is this actually feasible for a technically minded DIYer building their own house? I think the answer is a qualified yes.
It's more work up front, it's more money up front, and there's a learning curve. But the result is a system that's more reliable, more private, more future-proof, and more satisfying than anything you can buy at a consumer electronics store. And the fact that you can integrate it with Home Assistant means you don't have to give up the flexibility and the community and the constant innovation that makes Home Assistant great.
You get the best of both worlds. The rock-solid physical layer of a professional bus system, and the rich software ecosystem of the open-source smart home community.
The cost, while significant, is not insane. We're talking about maybe five to ten thousand dollars in hardware for a whole house. That's in the same ballpark as a high-end kitchen appliance or a nice home theater setup. It's a luxury, but it's not a yacht-budget luxury.
If you're already spending hundreds of thousands building a house, an extra five or ten thousand for a lighting control system that will work flawlessly for twenty years starts to look like a pretty good value proposition.
Especially when you compare it to the alternative. Spending a thousand dollars on consumer smart home gear, dealing with flaky connections and cloud outages for five years, and then replacing it all when the protocols change.
The one thing I'd add is that this is not an all-or-nothing decision. You can start with KNX for the hardwired infrastructure, lighting and blinds and heating, and still use Zigbee or Z-Wave for the more ephemeral stuff like battery-powered sensors and smart plugs. The systems coexist fine under Home Assistant.
That's actually the most pragmatic approach. Go wired where you can, go wireless where you must. Wired for anything that's in the walls and should last decades. Wireless for things you might move around or replace every few years.
Daniel, if you and Hannah do build that place, we expect a full write-up.
Photos of the DIN-rail panel. A well-organized electrical panel is a beautiful thing.
Sloths appreciate a good panel. Lots of places to hang from.
I don't think that's what DIN rails are for.
Everything is what you make of it, Herman.
Hilbert's daily fun fact.
Hilbert: The average cumulus cloud weighs approximately one point one million pounds, about the same as one hundred elephants.
When I say I have my head in the clouds, I'm carrying a lot of weight.
That explains so much.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping the clouds in the sky. If you enjoyed this episode, leave us a review wherever you get your podcasts. It helps more than you know. I'm Corn.
I'm Herman Poppleberry. We'll be back next time.
