I share the neo-luddist perspective of many of the other commenters, but it's also clear that there are basic product quality issues at hand. Switching something on and off on a schedule is not a hard problem to solve, in theory, so why doesn't it work? Is there something about the ecosystem and interfaces between devices and hubs that is lacking? Did the company just not test their product sufficiently?
> Did the company just not test their product sufficiently?
Almost nobody in the software industry does. Quality is hard. Testing to high quality makes testing take 70% of the time budget - most places want to ship yesterday. Google and Amazon have popularized push to production, which is a stupid idea. (Note that Google and Amazon have invested a ton into fast automatic rollback which most people miss, even so Google regularly breaks features people depend on)
There are things we can do. Automated tests are a good thing, you should have an extensive suite. My company has a suite that takes 3 hours when running on 40 machines in parallel. That just assures things aren't completely broken before the humans testers start their 1000 hour test starts [not the real number but the right magnitude]. While we are looking to move more of that 1000 hour test to automated systems, much of it is about proving that our simulation matches the real world and so cannot be automated.
We have had good luck with static and dynamic analysis tools. They pick up a lot of errors that are hard to find manually, and make the code more maintainable.
The above still doesn't meet my quality standards. I'm looking for anything that will make things better. (So far I've only heard of formal proofs, which I've also heard is hard)
