I wondered how my home network looked in comparison. A few years ago I was complaining that routers which limit users to 128 WiFi devices weren't suitable for the average family. I'm not quite at that many IP addresses - but I'm closing in.

So, here's my attempt to map my network - with a splash of colour to explain the different protocols at play.

Created with Graphviz Visual Editor. Using a free trial of RunZero to discover devices.

Conceptually, the network is quite simple. Cable Internet → WiFi / Ethernet Router → Devices. But some of those devices have their own wireless networks, some connect to a mesh, and others over mains electrical wiring. And then it gets a bit complicated

I do have more IoT stuff than is sensible. And, annoyingly, there's no good way to design a home network for (potentially) hostile IoT devices. At least, not without getting professional gear.

This is just our personal kit. There's a guest network for visitors and WFH equipment. I also haven't mapped every ZigBee devices (a lot of lightbulbs) nor all the LoRaWAN sensors (lots of doors and windows being monitored) - and I'm completely ignoring the things controllable by BlueTooth (mini-printers and treadmills).

One thing I notice is that the 2.4GHz is ridiculously crowded. All the cheap IoT devices use it - plus it provides the private network for some equipment. I get it. 5GHz is expensive, power-hungry, and has a shorter-range. But it is a bit annoying that more devices can't make use of its plentiful spectrum - it's currently restricted to phones and laptops.

We have a tall, narrow house. So WiFi extenders have proven a bit useless. But, perhaps it is time to create a couple of IoT networks on different SSIDs?

All told, when including work devices and random old Android phones / tablets, ancient Xbox consoles, and assorted Raspberries Pi - we're pushing 60 devices with an individual IP address.

I've got to admit, this doesn't feel like "underkill"…!

So I dug through my scrapheap of old tech and resurrected an ancient Pi2. It's old, outdated, slow, with limited RAM, and has a bunch of much-abused GPIO pins. But it works and - crucially - is still supported by Home Assistant OS.

Well... ish!

The official Home Assistant installation guide for the Pi says that you can use a:

Raspberry Pi 4 (Raspberry Pi 3 is ok too, if you have one laying around).

But, if you go to the latest releases page and then click "show all assets", you'll be rewarded with a file called haos_rpi2-9.5.img.xz - that's Home Assistant OS for the Raspberry Pi 2. Sweet!

From there it was just a case of following the installation steps. But... my goodness the Pi 2 is slllloooowwwww.

I could see that the Pi was responding to pings, but the web interface wasn't coming up. I left it for a few hours and did something more interesting. And, when I came back, it worked!

But, that slowness becomes a recurrent theme. Not in the interface itself, which is delightfully snappy, but it is slow on any form of add-on installation, upgrade, or reboot. A lot of waiting is involved. Even something like viewing sensor history slows to a crawl.

It quickly detected all my smarthome gadgets (I have far too many). Integration was pretty easy - assuming you trust the system with your username and passwords... Most of these devices don't have OAuth. Some don't even have official APIs. But HA was able to interact with nearly everything.

Of course, that does mean the user interface is a lot!

As long as you're happy to fiddle around making everything just right, then the UI isn't too bad.

The phone UI is great! It interfaces directly with Android 13's quick actions. I was able to add a couple of buttons to my phone to do common tasks like switch off lights, and turn on electric blankets. The app is a bit of a power hog - because it is continually polling for updated data about your home. I put it in battery jail - I care more about control than reports.

Installing update is slow. Installing new integrations is slow. Rebooting is slow. But, thankfully, these are things you only do rarely. For switching lights on and off, getting the bed warm, and checking the air quality, it's fast enough.

At the moment, I'm using sloppy security. The Pi has the usernames and passwords for my various gadgets and talks to them via their official APIs. I guess I could reflash them all with FLOSS firmware - but that seems like a bit too much effort at this point.

Similarly, the Pi is running Let's Encrypt and uses Dynamic DNS to give me a permanent connection back to my home. I'm reasonably sure the security is good enough - but I probably need to Design a Home Network for Hostile Devices.

But, for now, I'm impressed with Home Assistant. It isn't quite "it just works" - but it's good enough for the enthusiast who is willing to put up with a few rough edges.

And I'm pleased my old Pi has a new purpose in life.

I have an IP Camera on my LAN, I want to connect to it via HTTPS. I can't. Why is that?

Why do this?

I have a username and password to access my IP camera. And my TV. And my lightbulbs. And all my networked gadgets. If I try to enter the passwords on a modern browser, I get this error message:

It is now an accepted fact that data should be encrypted during transport - even on a trusted network.

I have a modest home network of several dozen gadgets - all chattering away over Ethernet and WiFi.

Ideally, they are all isolated and under my control - but hackers could break in, or an automatic firmware update could compromise them, or someone could plug something in to my homeplugs.

In short - I want to access 192.168.0.123 via a secure and encrypted connection.

Why it is impossible

The Certificate Authority / Browser Forum are the people who set the policy for how SSL Certificates are issued. They prohibit generating SSL certificates for Reserved IP Addresses - like the ones on your LAN.

Their explanation is:

Only one logical host on the Internet has the IP address “97.74.42.11”, while there are tens of thousands of home Internet gateways that have the address “192.168.0.1”.

The purpose of certificates issued by publicly trusted Certification Authorities is to provide trust in names across the scope of the entire Internet. Non‐unique names, by their very nature, cannot be attested to outside their local context, and such certificates can be dangerously misused [...] issuance of certificates for non ‐ unique names and addresses, such as “www”, “www.local”, or “192.168.0.1” is deprecated

CA/Browser Forum - Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses

Is there a work-around?

Sort of! Some IoT devices have self-signed certificates. if you try to connect to them via https:// they will present the certificate - but the browser will put big scary warnings in place.

Why is that message generated? Because no reputable Certificate Authority will issue a cert, the manufacturer has self-signed it.

So I can ignore all those scary warnings and proceed. Right?

WRONG!

Why is this a problem?

I tried to connect to my IP camera via https:// only to get this error.

The manufacturer doesn't do firmware updates so I'm left with a weak, self-signed certificate, which expired earlier this year.

If I tell my browser to ignore the warnings - what are the consequences? If something takes over that IP address (a malicious Internet Connected Fridge) - will I know?

Outsourcing Responsibility

There is an alternative - but it is almost too dreadful to consider.

I could rely on the manufacturer to provide a secure gateway to my devices.

• My IP toaster can make a secure connection to https://toasty-mc-toastface.biz
• I connect to their API https://toasty-mc-toastface.biz/api/toaster/
• I then use the external API to control my devices

Yuck! Do you trust the Kickstarted company which provided your IP Toothbrush to stay in business for the lifetime of the product? Ha!

Do you trust them not to get hacked?

Do you want to deal with the latency between your home and the Windows Vista box in China which acts as their server?

Sadly, this is how devices like Alexa work. They don't connect directly to your kit, they go via an intermediary.

How to fix it?

I have no idea! If you do - please stick a comment in the box.