Category: Essay

The sad state of smart homes

“A camel is a horse designed by committee.” – Sir Alec Issigonis

I am enamored by the idea of the smart home. Devices working to make life a little easier.

Over the last few years, I’ve been adding smart home devices to our home, mainly for simple purposes like turning the porch lights or Christmas lights on and off automatically. Nothing particularly complicated. For the most part, Amazon’s Alexa is up to the task to manage these things, despite the frustrating software interface. I can speak commands and it mostly works, hang ups typically being a need to reboot a smart switch.

We’ve replaced our old ceiling fans with new ones with LED lights and remote control that don’t wobble. Inexpensive and easy to install, the one drawback is that they don’t talk to any general smart home software. Alexa can’t control them, nor can Google Home or Apple Homekit. Not the end of the world, but a bit of a splinter in the mind for me.

Because I’m a nerd, I have been following podcast discussions about smart homes and how interoperability can be addressed. I’ve read about Matter (the new smart home protocol) and Thread (the new smart home networking method), but never dove into the details. My assumption was that the Connectivity Standards Alliance (CSA) who standardized Matter & Thread had done a good job and it simply would take time for actual products to catch up.

This was a poor assumption.

I’m an engineer. I don’t have qualms about dealing with networking issues, configuring software, and reading the instructions.

Optimistically, I started looking into how I might control the ceiling fans with Alexa.

No easy path, but there was a slightly twisty one. There are small Bluetooth proxy devices, like the M5Stack ATOMS3, that can emulate the commands used to control the fans.

An AtomS3 Bluetooth proxy


Unfortunately, Alexa won’t talk directly to the Bluetooth proxy, but open source software called Home Assistant can.

Undaunted, I set up Docker containers to run Home Assistant on our home NAS server and the bridge that allowed it to talk to Alexa. No simple task, I was grateful to Claude to help me through the configuration steps. Home Assistant is unfortunately a bit user hostile and not for the weak of heart. If words like ‘container’, ‘Docker’, or ‘command line’ are unfamiliar to you, do not try using Home Assistant.

Container Station dashboard showing a list of 3 running Docker containers including home-assistant, matter-hub, and matter-server with their respective statuses and images.


The Bluetooth emulation works and saying the specific incantation to Alexa does indeed turn the ceiling fan and light on and off. I take this as a good sign as to the state of smart homes.

Emboldened, I started thinking about trying the new smart home devices from Ikea. They are super cheap and say they work with Matter & Thread. The $6 smart button seemed like a great deal to control a lamp I had built that ran off a smart plug.

A hand holds a small white and yellow product box labeled "BILRESA" with an oval-shaped device visible through a clear window on the front.
An Ikea Bilresa smart button

I followed the instructions, using the Alexa app, with no luck. It just went in circles. Wouldn’t join the device.

Optimistically, I went into Home Assistant to add the button. No luck. The same kind of endless loop.

Frustrated, I finally read up on the technical underpinnings of Matter & Thread, and to my horror, saw the disaster the CSA had created.

As an engineer, I understand the urge to build things with elegance and correctness. But the world is rarely an elegant place. I learned the hard way that the best is the enemy of the good.

The CSA tried to be smart, elegant, and correct to the detriment of anyone actually trying to use Matter & Thread.

To be clear, many of these issues are implementation problems rather than flaws in the underlying specs, but for users, that distinction doesn’t matter.

IMHO, there are three major failures of the design. They are ‘one-time’ QR code use, IPv6 for Thread, and Bluetooth commissioning.

‘one-time’ QR code use – In the quest for ultimate security, the QR codes printed on Matter devices can only be used basically one time. Well, technically they aren’t one-time use, but effectively one-time use in practice due to fragile commissioning flows. If something goes awry during the first use, the QR code might as well be invalid.

The use of a one-time cryptographic key may be great for spy tradecraft, but for the average person it is maddening. In theory you can do a factory reset, and try again, but this is nonsense for the average person. They will just assume the device is defective.

Heaven help you if the QR code gets lost or is unreadable. If the code is lost and the device isn’t already paired, it is permanently bricked.

A hand holds a small white oval device labeled "IKEA BLE-ESA" with a QR code and product information printed on it.
Don’t get me started on the tiny font size


IPv6 for Thread – The Thread networking stack will only run on IPv6. IPv6 is the next generation of how computers and electronic devices identify themselves to each other. It’s exceedingly complex, obtuse to even most technical folks that don’t do network sysadmin on a daily basis. Great in theory, but doesn’t account for the fact that not everything running in people’s homes are configured to run IPv6.

The spec assumes a ‘flat’ network where every device has a seat at the table, ignoring many of us early adopters running containerized environments where ‘Network Address Translation’ (NAT) is a hard wall that Matter simply cannot climb. Even in my case, running Home Assistant in a Docker Container on a NAS server is broken as the firmware doesn’t allow IPv6 traffic to the containers. Swapping my NAS out to make the Ikea button work is not really an option.

A user shouldn’t need to understand Prefix Delegation or SLAAC just to install a $6 button. IPv6 is great in concept, but no one is running out of IPv4 addresses in their home. Without even a fallback method to use IPv4, this is a bit of an overreach. Thread runs on IPv6 internally, but it’s supposed to be abstracted away from the user.

The CSA spec assumed a well-functioning Thread Border Router ecosystem that doesn’t exist yet. In a normal home setup, you shouldn’t need to know, or care, that IPv6 is even involved. Imagine your non-technical friends and family trying to set up IPv6 over the phone with their local ISP.

Bluetooth commissioning – Despite all of the CSA’s forward looking decisions, they amazingly decided that the only way to actually commission and activate a Matter device was to use Bluetooth (BLE standardized in 2010) to do this final step and join the device to the Thread network.

The use of Bluetooth is intended to ensure physical proximity, a ‘digital leash’ to prevent remote attacks. But in reality, Bluetooth is slow and hinky. The cryptographic ‘handshake’ required by Matter can take up to a minute, which in modern UX design is an eternity. If a user navigates away or their phone screen locks, the Bluetooth connection snaps, the link dies, and the device enters a zombie state that only a factory reset can fix.

We are using a protocol standardized in 2010 to secure a future that hasn’t arrived yet.

In theory the phone is the optimal device for this, but in reality, no one wants to stare at a spinning icon. While existing smart home hubs may have Matter & Thread enabled, only the very latest models have Bluetooth as well.

Amazon claims they have millions of Matter-ready devices, but they don’t mention that most of them are deaf to new devices. While most Alexa devices have Bluetooth for music, only the very latest models have the ‘Matter Commissioner’ software enabled to use that radio for setup. Eero routers have Bluetooth, but only to talk to other Eero devices, not Matter devices. Ironically, Eero is a Thread Border Router, but unable to commission Matter devices onto Thread.

A man in a blue shirt expressing exasperation and face palming.


Taken individually, these design failures can be worked around by the tech savvy, but the combination of all three creates an almost impenetrable smart home fortress, one that you can’t add devices easily. Yes, it’s quite secure, but you can’t do much with it.

Some reading this may take issue and respond with anecdotes about how it’s easier with their preferred smart home hub system, or that they have never encountered issues, or that I just need a Zigbee bridge. This fallacy doesn’t hold up when looking at the abysmally high failure rates of Matter device commissioning.

Hope on the horizon?

A screen shot of the Gandalf on the Third Day in the East in bright dawn sunlight from the Lord of the Rings movie, The Two Towers.


The CSA has been forced to recognize these issues and is planning some improvement. The ‘one-time’ QR code and Bluetooth need looks to be replaced by NFC onboarding (think of it like ‘tap to pay’ tech). The standard for NFC is finally set, the phone in your pocket already has NFC, but most smart home devices don’t include the NFC chips to support it yet. An improved Thread router specification will allow Thread to talk to IPv4 devices in your home.

This is hopeful, but for people buying Matter devices now, they are buying devices that will be permanently orphaned in the future, unable to meet the new, upcoming standards.

Standards work is long, boring, and frustrating. I’ve spent days in those meeting rooms arguing about Java usefulness, video format frame rates, ECMAScript use in ATSC standards, and other boring technical topics. I get it that the CSA meant well, but they lost sight of the target, which is simplified installs for the average person at home.

I’ll end my rant here.

Unrelated, does anyone want a couple free Bilresa buttons?

The WWI Biplane Era of Enterprise AI

Most of the conversation about AI in business is coming from people selling it; pundits, software developers, and venture capitalists pushing the hype cycle. Very little is coming from people who have to make it work and actually support businesses with technology.

A split illustration showing AI vendors and investors on the left enthusiastically promoting AI with buzzwords like "TRANSFORMATION!" and "BILLION DOLLAR OPPORTUNITY!" while IT professionals and operations staff on the right express concerns about realistic costs, data quality issues, and security risks.

(An obviously AI generated image)

As someone that has been providing technology systems to my business counterparts in Fortune 50 companies for 20+ years, I know a bit about how technology does and doesn’t work within corporate environments.

In 2018, my team installed our first AI system. We were using machine learning to identify actors’ faces, create transcripts, and identify text and objects in video files from television shows in production. This allowed creative teams to find scenes quickly and easily, speeding up the editing process and avoiding the drudgery of “logging tape”.

Over the last few years, I’ve followed the remarkable advances in LLMs, the “generative” tools under the AI moniker.  I learned a lot about what they can and can’t do. 

One caveat: software development is changing much faster than everything else. My thoughts apply to the rest of a modern enterprise.

Here are my three key takeaway points:

– Agents are in a nascent stage and can’t replace people

– LLMs make mistakes regularly

– AI costs are subsidized now, but won’t be forever

These aren’t abstract concerns. Each one has real consequences for how you deploy AI inside a company.

Agents are in a nascent stage and can’t replace people

The recent advances in agent capabilities are inspiring.  Headlines are dominated by OpenClaw and NemoClaw, the current hot autonomous agent frameworks. Neither of which are AI themselves, making it easy to confuse these agents with LLMs.

The big idea being discussed is replacing roles with AI.  I mean if OpenClaw seems to read, think, and respond to emails, why can’t it replace people?

We are seeing a lot of ‘AI washing’ right now with layoffs, but those layoffs aren’t really about replacing people with AI, they are about making Wall Street analysts happy.

The difficulty is that the idea of an AI CFO or AI travel person is not a true AI or agent.  There isn’t really a piece of AI software that is running 24/7 thinking about CFO issues.  An “AI CFO” isn’t a sentient agent, it’s just a static prompt rerun each time, with no memory or context beyond that single interaction. It’s not a little computer homunculus waiting to leap into action.

An AI corporate person would require a triggering system of sorts, a database or jumble of JSON files that store everything it needs to know, and some kind of boundary on what it’s supposed to look at to have a reasonable context window.  You simply cannot make an LLM look at all the information of a business every time it’s invoked.

There is a hazy future of ideas that help with these kind of things to create some sort of standardized framework, but that does not exist right now. There are no gold standard best practices. We are at the “throw stuff at the wall and see what sticks” phase right now.

LLMs make mistakes regularly

It’s often said that LLMs can have hallucinations.  I prefer to call them what they are, mistakes.  LLMs are incredibly complex systems, but at the highest level they are very good guessing machines, basing their guesses on their training. Even though they are extremely good, they are not perfect.

LLMs are not deterministic systems. They are probabilistic outputs wrapped in confident language. For this reason, I built my llm-discussion app, that has three different AI models debate and come to consensus on a question.  Relying on a single LLM’s answer as the gospel every time is a recipe for problems.

The fallout from a miscalculated quarterly report due to an AI hallucination can have a huge negative impact on a company, causing long lasting harm.

In the corporate world, mistakes are real problems.  Financial spreadsheets need to be 100% correct.  Presentations can’t have misspellings or incorrect logos. 

AI costs are subsidized now, but won’t be forever

At the core of any LLM usage are tokens.  You can think of tokens like counting each word in an email and charging per word.  Buying access to the frontier LLMs is basically buying tokens to use.

Processing these tokens is what all these gigantic data centers are designed to do.  Spending hundreds of billions in infrastructure is hugely expensive. That has to be paid for somehow.

The truth of the matter is that the current cost of tokens does not reflect the actual cost of processing the tokens. In other words, AI companies lose money on every single interaction.

Currently, all costs of using AI are subsidized and do not reflect their true costs. The true costs are being paid with venture capital money and money from adjacent lines of business. For example, profit from Google Search pays for Gemini and profit from Microsoft Azure pays for Copilot.

At some point the AI business has to make enough money to be profitable, that means costs will rise.

We’ve seen this business cycle play out before. This follows a pattern Cory Doctorow describes as ‘enshittification.’ In that framing, we’re still in stage one.

Money is what corporate IT divisions are most concerned with. Yes, they have a nice PowerPoint about ‘value add’ and ROI, but their main role is cost containment. The slog into process heavy ITIL processes and standardization is all about saving money.  IT groups will deploy a crappy $9 mouse instead of a nicer $30 mouse to save money.  They’ll switch from Slack to the inferior Microsoft Teams to save money without hesitation. The user comes last in most of these calculations.

IT managers face a real dilemma when implementing AI tools.  Currently, they can put in AI tools provided via a SaaS implementation that are pay by the seat, all you can drink situations.  But those arrangements simply will not last.  The current subsidized situation is untenable and eventually companies will need token budgets and a way for staff to use those tokens.

Can you imagine the department that stresses over the cost of a mouse, seeing the token bills skyrocketing up when a creative team starts making hundreds of image generation requests in an afternoon.  Or that a single employee could accidentally rack up a $5,000 bill just by asking an LLM to “analyze these 500 PDFs” is a nightmare scenario for ITIL-focused managers. There will be aneurysms.

AI optimists will point out that token prices are plummeting, and they aren’t wrong. Cheap tokens during the land-grab phase are exactly how the “subsidized” playbook works. But in the enterprise, the Jevons Paradox usually wins: as a resource gets cheaper, we don’t save money, we find more ways to consume it. A 90% drop in token price doesn’t matter if your workforce increases usage by orders of magnitude.

Corporate email used to be measured in megabytes; now it’s measured in gigabytes. We didn’t save money on storage as it got cheaper; we just stopped deleting things.

I may sound dramatic, but we have to live in the real world.  And in the real world, we are in the infancy of how AI will be used in business.  Comparing where we are with AI on the timeline from the Wright brothers first flight to the SpaceX Dragon, we are at the World War I biplane era.  Everything is made of cloth, wood, and glue.

There is tremendous opportunity, but also tremendous risk. 

The winners won’t be the companies that replace people with AI. They’ll be the ones that make their people more effective with it, without blowing up costs, creating mistakes, or breaking processes.

A vintage biplane enhanced with glowing digital overlays and technological elements flies through a futuristic sky filled with data streams and circuit patterns above a cityscape.

A non-coder’s take on AI coding 

After hearing opinions of AI, ranging from the end of humanity to the Singularity, I decided to dive in a bit deeper.  I’ve led projects that worked on using AI/machine learning to analyze video at work, I hadn’t used it on any serious personal effort before. 

I’m not a software coder. In the early days of personal computing, I did know some Assembly, Basic, Fortran, and even Pascal. But I’ve never made software development a skill of mine.

I’ve worked in technology my entire life and am comfortable configuring and working the guts of software that I’m dealing with, but I’ve never written any real software. While I have managed petabytes of storage, large technical operations, and dealt with the nitty gritty of networking, writing C, javascript, or python are beyond me.

After hearing from much more savvy friends that AI tools do amazing stuff when helping to code software, I decided to give it a try.

Python Scripts

The first task was cleaning up a very old personal web site.  The site goes back 20+ years.  I wanted to move it to a new server and clean up a bunch of problems.  First and foremost, most of the HTML code used http: instead of https: making all modern browsers unhappy.  You’re probably thinking, “Well, that’s just a simple python script.” And you’re right, but I don’t code python.

I started with ChatGPT to get started.

ChatGPT not only wrote the Python script but also guided me through installing Python and troubleshooting errors. In minutes, thousands of files were fixed—an impressive feat for someone with no coding background.

As I looked at the HTML to confirm code had changed, I saw other there were other issues.  I had included email addresses, web stat trackers, and many other artifacts of the early web.  ChatGPT was able to write more scripts that found and fixed all of these things.  In the end, it wrote a general security scanner that looked for many common issues and surfaced them. 

The process was very much like having a knowledgeable friend sitting over my shoulder, patiently walking me through the process. 

After this experience, I started trying several different AI systems to help with technical questions.  The one that I seemed to like the most was claude.ai.  Clear and to the point, claude almost always did the work I needed rather than telling me what work was needed. 

Instead of telling me to generically “check the logs for errors”, claude said “go to the logs that are located in /var/log and upload it to me for review”.  And sure enough it would parse the logs and give me specifics on what to try.

Most importantly, claude could help me with one of the most difficult issues in computing.

WordPress Plugin

I had recently returned my weblog to operation thanks to my friend Greg doing the needed necromancy. 

Seeing the linkblogs on sites I liked, I wanted one for my site.

We (claude and me) quickly iterated on the functionality and design.  I didn’t want to use JSON for input. I wanted a manual entry process in the WordPress admin page and didn’t want it to run using jQuery.

It took minutes to get it working. Again, my mind was blown.

Making changes was straightforward and simple.

Within an hour, the linkblog was running and looked the way I wanted.  Even if I was a WordPress shorttcode expert, I don’t think I could have done this all in an hour. 

Best of all, I can keep modifying the code as needed without having to call in favors from friends.

Speech Interface

After watching a few Youtube videos of people speaking to an AI and hearing a response like a conversation, I was intrigued.  Could I build something like that?

The HTML code for the needed Javascript popped up and we were off to the races.   Claude walked me through setting up an API key, getting tokens, and working through errors.

The process quickly got complicated as I needed to set up a kind of reverse proxy for the API calls to claude that meant changing the settings of the Apache web server and installing a node.js server.  I was walked through this process and the testing of it easily.

At each point, claude was positive and explained what was needed to be done. It never sighed, rolled it’s eyes, or got exasperated at me.

After about and hour, it was running an I was able to ask important questions.

Improvements were easy, making a better UI design and even creating a button to stop the audio when it got long winded.

For some this may not be impressive, but to me it was mind blowing.  A range of possibilities opened up in my mind.  No longer stuck with googling for someone else’s work on the web that might fit my needs, I am actually able to build what I dream up.

I’ve played with a few different things to scratch my own itches and I continue to see what many others see in the use of AI in software development.

What does it all mean?

Fuck if I know. 

I just looked a small slice of what AI tools might be capable of in coding.  In that area, it seems clear that use of AI tools by software developers will be a game changing addition that allows more to be done in a shorter amount of time.  I don’t see it eliminating the need for humans, just as pneumatic nailguns didn’t eliminate the need for human carpenters.  Just powerful tools to let humans get things done.

I don’t see AI diagnosing networking problems and be able to go room to room examining fiber jackfields or replacing QSFPs.  Or AI being able to read a room of execs and their body language when presenting ideas.  Or AI being able to stop people from having bad video conference etiquette.

But the AI tools are currently a huge boon to software development and troubleshooting.  I know many people that want nothing to do with AI and have strong feelings about it’s use.  I get that.  But to reject it’s use in this area is like sticking with a typewriter instead of trying a word processor back in the 1980s.  A quixotic quest to maintain the status quo when the world is moving forward quickly.