If you’ve been keeping pace with the blog, you’ll know I recently had a new NanoLeaf controller delivered after my previous one failed.

Setting it up was a pain in the proverbial, mainly because their app is a horror show, and also because there is an incompatibility with UniFi access points which I had to Google the workaround for.

To be fair, though, the “standard” method of setting up devices like this is rubbish and well overdue for a rethink.

You know the method I’m talking about - if a device has no screen and/or keyboard of its own, how do you give it credentials to jump on your WiFi for connectivity?

Amazon, of course, have nailed the user experience here. I can’t remember what setting up my first Echo device was like, but I do know that any newly acquired one will just start working by picking up (Bluetooth?) from surrounding ones. I assume they’ve secured it all by registering the device to your account when you order it.

In most other cases, though, the device starts by broadcasting a WiFi network which you then have to join with your phone. If we’re going to do it this way, my preferred route would then be for the device to serve a simple web page which I can punch the wifi details into, press a button, and it’s job done. Mobile phones would pick up that page as the “sign in to network” page and it would all work reasonably well.

However, people seem hellbent on “adding value” by having you go through a wizard in their app, and switch to the wifi network broadcast by the device mid-wizard. Maybe it’s just not feasible to add a web server to some of the simpler devices, but if you’re going to do this, here’s a tip - make an app that doesn’t crash in the middle of the process.

Having wasted an hour of my life wading through all this with the Nanoleaf, I woke up the next morning to find approximately half of my home network shot to bits.

I then did something I hate users doing in my professional capacity - I blamed the thing which had most recently changed. Has to be the cause of my current issues, right?

Well, no - turning the Nanoleaf off at the wall brought no relief.

What had happened is a rogue DHCP server had popped up on my LAN and so any device newly joining it would be handed an IP address and default gateway which did not deliver the internet connection expected.

It was only when I started typing the “wrong” gateway address into my phone and it came up with “Gurgle Apps Word Clock” that I realized the culprit (and unceremoniously disconnected it from the power).

You might say it’s all the Gurgle clock’s fault for suddenly deciding to run a DHCP server after six months of … not doing that … but this whole method of device setup is broken and needs a revisit.

My preferred solution would be to do it all via Bluetooth, and I’d gladly pay a few pounds extra for devices which had such an option and consigned all this DHCP hijacking to the dustbin of history.

Needless to say, I’m looking at whether my router can suppress DHCP traffic coming from sources other than the expected one.