I’ve encountered a couple of bugs with internet-connected devices recently so I thought I’d document them in case some other poor soul had the same troubles.

Yes, I’m kinda aware I’ve brought a lot of this on myself but it does somewhat show that these things aren’t ready for primetime just yet. I’ve done the “sensible” thing and segregated IoT devices onto their own separate, firewalled VLAN although most vendors aren’t necessarily expecting this arrangement. Many devices do NAT hole punching which seems to work ok, except when there’s UDP traffic or IPv6 thrown into the mix. Explicit port forwarding seems to be on the (thankful) wane.

Nest Protect

I had a really strange experience when my Nest smoke alarms suddenly stopped checking in. They couldn’t jump on the network and even a reset failed with the cryptic error code P007(3.9). Their technical support has actually been surprisingly good but they couldn’t figure it out.

I eventually deduced that Nests will only try the first DNS server handed out to them over DHCP. If that one is broken (but a second/third/fourth is still up so name resolution is working for everyone else!) then they fail with this generic error.

Fix: make sure your primary DNS is working; Nest need to fix the bug in their firmware so they’ll failover gracefully (which you’d assume they’d do for a safety device).

Update 05/03/17: the bug doesn’t seem to have been accepted by Nest still so I guess this isn’t going to get fixed. If a single point of failure in networking for a device that’s supposed to tell you your house is on fire worries you, I guess don’t buy one?

Netatmo Welcome

I had a camera working for ages until one day it suddenly stopped and just showed “disconnected”. A reset similarly failed to get it back online and the setup process choked with generic errors about checking the internet connection etc.

Some hints from a forum led me to find that the camera runs an IPSEC tunnel back to Netatmo over UDP. This tunnel is initiated from Netatmo themselves and my stateful firewall didn’t appreciate unsolicited inbound UDP.

Fix: Permit UDP source ports 500 & 4500 from any public IP to the IP of your camera. Note that this is not port forwarding, just a firewall rule.

(I haven’t been able to pin down exact IP ranges this will come from as Netatmo use a variety of servers and they weren’t forthcoming with help.)

Philips Hue

Again, all was working super until one day geofencing and alarms broke. Trying to connect the bridge to the online account (My Hue) would literally cause the bridge to crash – it would remain on the network but be unresponsive over its mini web browser or even zigbee light switch presses.

Philips technical support haven’t been great and blame it all on home networking despite being given packet captures.

Fix: None so far

Workaround: Connect your Hue bridge into Homekit and use the automation features of Apple TV instead.

Update 05/03/17: this randomly started working again recently. Still no word from Hue support though.