Imagine: you get up in the morning, want to raise the blind – and nothing happens. Try the app? Nothing. Try the physical switch directly? Dead. And here’s the kicker: the fault is buried deep inside a wall-mounted junction box.
That was the moment I realised: my smart home had just turned into a nightmare. And I’m not alone with experiences like this.
Today I’m showing you three devices that made it very clear to me where smart home can really go wrong. Not theoretical problems – but real fails that cost me time, money and nerves. We’re talking about 14 actuators all failing. A robot vacuum that became useless overnight. And false alarms waking me up in the middle of the night.
Watch the video – I demonstrate the problems live and show you what you can learn from them.
Fail #1: Shelly 2.5 – When 14 actuators died at the same time
The slow death inside the wall
This is a Shelly 2.5 – an actuator for roller shutters and blinds. I have 14 of them installed. Fourteen! Nearly all in junction boxes, permanently wired behind wallpaper and plaster. My expectation was pretty clear: install once, close up, forget it. Set and forget.
On the software side I was happy for a long time: locally controllable, great Home Assistant integration, no cloud dependency. Exactly what you want.
And then the drama began.
The same defect – 14 times
In all – yes, literally all – of these Shelly 2.5 actuators, one component failed after some time, one by one. All fourteen, always the same defect. Morning routine, raise the blind? Nothing. App? Nothing. Physical switch? Dead.
Now here’s the real nightmare: these things are of course sitting in junction boxes. That means: open the wall, pull out the actuator, desolder the capacitor, solder in a new one, reinstall, close the wall. Per actuator. Fourteen times.
That was a genuine maintenance disaster for me. And I’m not alone. There are masses of reports about this Shelly generation online.
In the video I show you exactly what went wrong and how I carried out the repair. The detailed repair guide is in this separate article.
Small consolation: repair is possible
With a soldering iron you can swap the faulty component for a few cents in parts. But honestly: do you really want to open 14 wall boxes and replace capacitors?
Important note: this problem affects specifically the Shelly 2.5. The successors Shelly Plus 2PM and the Gen 3 and Gen 4 are ones I use heavily myself and have had zero failures with so far. So this isn’t about bashing the manufacturer across the board.
The key lesson
Wait for long-term community experience before buying new products. First generation? Let others be the testers. Second generation with solid reviews over a year? Then go ahead.
Fail #2: Shark robot vacuum – When the cloud kills your integration
From smart home star to useless appliance
The second device frustrated me in a completely different way. It’s about my Shark robot vacuum. And upfront: the hardware is perfectly fine. It vacuums well, navigates decently, does its job.
For months I had it deeply integrated into my smart home. Built automations along the lines of: “When nobody’s home, start cleaning.” The Home Assistant integration ran perfectly. This wasn’t a toy – it was a solid, reliable part of my daily routine.
Watch in the video how well the system worked – before everything fell apart.
One app update. One dead integration.
And then, one morning: automation triggers – nothing happens. Home Assistant shows: connection lost. Maybe a bug? Open the app – it works. Robot starts via app. But the Home Assistant integration? Dead. Still dead weeks later. Permanently.
What happened? The Shark app had updated itself automatically – as apps do. Completely normal, in the background. Without me actively deciding anything or consciously triggering it.
But with this update, something had changed in the cloud interface. The result: the Home Assistant integration was broken. No workaround, no fallback, no local API.
The moment of realisation
That was the moment I understood: I didn’t buy a device I’m in control of. I bought a device whose capabilities can change at any time via a server update. Without my consent. Without warning. And I can do nothing about it.
In the video I explain in depth why this is a fundamental problem with many cloud-dependent devices.
Imagine buying a car – and a year later the manufacturer says: “Sorry, the radio only works with our app now.” That’s exactly what happened here. Except that the “radio” in my case was the entire smart home integration.
The lesson: an exit strategy is mandatory
Cloud is convenient – but you always need an exit strategy.
- Is there a local API?
- Can I flash alternative firmware?
- Does the device work without internet?
Bose recently handed us a similar case. If that interests you, here’s the article about Bose SoundTouch.
Fail #3: Sonoff Zigbee motion sensor – The night-time false alarms
Bought cheap, paid dearly
The third device looks harmless at first glance: a Sonoff Zigbee motion sensor. Cheap, bought 10 of them, quickly integrated, classic use case for lighting automations.
And at first I thought: okay, maybe a bit sensitive. Adjust the calibration, reduce the range, tried everything.
But then reality hit:
The night-time horror
Middle of the night – light comes on. I wake up, fall back asleep. Half an hour later: again. Three, four times per night. After two weeks I was nearly going mad.
I first thought: a bug in my automation. Checked all the logs. But no: the sensor is genuinely reporting motion. Where there isn’t any.
Same during the day. Light comes on when nobody’s in the room. Shadow from outside? Reflection? An insect on the sensor? No idea. But it doesn’t matter – because the result is the same: the system isn’t reliable.
In the video I demonstrate what these false triggers feel like and what impact they have on your trust in the system.
Unreliability is the death of any automation
In my view, this is the death of any automation. Because sooner or later you start disabling automations. Deactivating sensors. You lose trust in the system.
I replaced these sensors consistently with Aqara motion sensors. More discreet, significantly more reliable – and suddenly the system works. No more false triggers. No more waking up at night. Just: it works.
Not a brand problem, but a product problem
Important: this isn’t a general Sonoff problem. I use plenty of other Sonoff devices myself – Sonoff Basic or S20 plug switches for example – flashed with Tasmota. Local, no cloud, rock-solid for years. Except once, a capacitor issue there too – but that stayed a one-off.
The motion sensor is therefore a specific product problem, not a brand problem.
The lesson: test first, then scale up
Test sensors in everyday use before buying ten of them. One sensor for €10 is cheap – but ten faulty sensors are €100 of e-waste.
Unreliable sensors cannot be “optimised”. No tuning, no configuration makes a bad sensor good. Replacing them decisively is the only solution.
Three golden rules for your smart home purchases
From these three fails I’ve developed three rules I explain in detail in the video:
Rule 1: Have an exit strategy
Ask yourself:
- Is there a local API?
- Can I flash alternative firmware?
- Does the device work without internet?
If all the answers are “no” – think very carefully before buying.
Rule 2: Wait for community experience
Wait for long-term reviews. Read user reports. Only install critical actuators where you can reach them again if needed. So junction boxes only with absolutely proven hardware.
Rule 3: Test sensors thoroughly
Testing one sensor in real life for two weeks might cost you €10. Test first, then buy. Not the other way around.
The opposite: the best devices
If you want, in the next video I’ll do exactly the opposite: Three devices that have run absolutely reliably for years. That I would buy again immediately. That cost me zero maintenance.
Watch the video and write “YES” in the comments if that interests you!
Or do you have a smart home device you could throw against the wall? What was your biggest fail? I’m looking forward to your stories in the comments!