The 10 Reasons I Ripped Out a £6k Lighting System

Back in 2012 my wife and I started a house renovation project in Edinburgh (Scotland) having moved to that great city the previous year. In our previous London abode we’d installed a wireless lighting system from a company called Rako and it worked well enough to convince us that wireless was the way to go. Now, having installed and maintained a system with over 150 wireless lighting control circuits over the past 7 years I’ve finally had to admit that my technology choice was wrong. The Z-Wave wireless lighting system I installed just doesn’t work for a home like mine. I have now ripped out almost all of the Z-Wave units I installed – which had cost me more than £6k to buy and install. Read on to see the 10 reasons I finally kicked it out and what I have now replaced it with.

My career in Wireless

Firstly let me explain that I spent most of my career in the wireless (mobile phone) industry and consider myself to have a reasonable degree of expertise in the field. The company I founded ( has been a leading specialist in planning and optimising new wireless technologies for the past 25 years and has developed solutions for measurement and optimisation of everything from Analog to 5G.

Wireless technology is behind some of the most amazing developments of the last 50 years – things like the iPhone and satellite TV. So you may find it strange that I would be doubting the ability of a leading home-automation wireless technology to do something as straightforward as turning a light on and off. But unfortunately my experience has been exactly that. 

Z-Wave – The system I chose in 2012

Back in 2012 I asked for recommendations from the people I knew who were Home Automation pioneers – not least Pilgrim Beart (the founder of the Hive product now owned by BG) and Quentin Stafford-Fraser (co-inventor of the webcam). The consensus around the time was that one of the wireless technologies already on the market would become the de-facto standard for domestic lighting control. That seemed pretty compelling as companies like AeoTech, Fibaro, Philips and LightwaveRF were already producing wireless lighting systems including (in the first two instances) control modules that could be retro-fitted into the pattress (wall-box) behind a light switch.

At that time there were essentially three main choices of wireless technology: Z-Wave, LightwaveRF and ZigBee. I discounted LightwaveRF as it was (still is?) very range limited and my house is an old one built almost entirely from large stone blocks (even internally) that are very good at blocking RF signals. Between Z-Wave and ZigBee there wasn’t much to choose from a wireless perspective but the decision was made for me when I looked at the manufacturer support for each technology. As mentioned above companies like AeoTech and Fibaro already had modules (devices that turn on/off or dim a circuit) on the market that I thought would be ideal for my lighting control system whereas such support for ZigBee was pretty much completely absent save a few hobbyist-level companies.

So I found a supplier (Vesternet – who have been great by the way) and started ordering Z-Wave modules to try out. Fast-forward 18 months or so and I’d installed (with the help of a great electrician called Lorenzo) over 150 circuits with Z-Wave control. Many of the modules I installed in that period were Fibaro generation 1 dimmer and switch (relay) units. They had a few quirks but I found that if I bought the right LED lamps (mainly Philips ones) and used the balun that you can buy to compliment a Fibaro dimmer then I could get (relatively) flicker-free dimming wirelessly.

Lorenzo is the guy on the roof harnessing the lightning. Picture by Rab (Ian or Yanny) Gamble.

Since Lorenzo was replacing most of the wiring in the house I managed to get him to bring a lot of the control cables together in around five separate locations. This simplified the task of adding devices and also helped me to keep track of the actual units. To this day I have a spreadsheet with around 500 lines (around 3 lines per circuit) which details all of the lighting circuits in the house, the circuit breaker they are connected to, the type of device that controls the circuit and its location. Unfortunately I wasn’t 100% successful in getting the control point of all the lighting circuits in one of these five locations and there are actually at least three units lost in the walls somewhere which respond to Z-Wave commands but don’t seem to control anything I can find!

Z-Wave Hubs

Having chosen a technology and the modules to turn things on and off (or dim them) the next step is to decide on a central hub or controller as all Z-Wave networks need one of those. At the time a popular one was called Vera and I initially opted for that. It had a reasonably good way of overcoming one of the problems of Z-Wave (adding a new module requires the hub and the module to be close together) which came in the form of a battery box that could power the hub while you moved it around to add modules (the AeoTech Z-Stick has a similar feature). Unfortunately Vera also had a number of downsides – a limited API to allow it to be controlled by other systems, a non-working backup system that forgot what modules had been added and a slow processor which meant adding multiple modules took a stupidly long time.

So began a waltz through a significant part of the available hub-landscape, taking in Fibaro’s HC2 hub, a Mac-based home automation app called Indigo, an open-source system called Domoticz and finally Home Assistant (recommended by Quentin who I mentioned previously – did I tell you he co-invented the web-cam – I did – but I guess that’s cool enough to be mentioned twice – right?). Each has their own strengths and weaknesses but ultimately a lot of the problems I found with any of these systems came down to issues with Z-Wave itself and while my sashays from one to another sometimes gave me the impression of progress they generally just shifted the shadows around and left the underlying issues unresolved.

What did prove to be significant though was the hardware on which these systems are based. The Vera and Fibaro HC2 have their own hardware platforms which are not open and this gave me quite a bit of trouble as I tried to work though the failure concentration problem that I will attempt to explicate later. The Mac-based system was good in the sense that it was based on Mac hardware which I have found to be relatively reliable. However, it was, ironically, the failure of a Mac Mini which ultimately precipitated another switch that I had been mulling due to a lack of Z-Wave diagnostics.

The systems I moved to (Domoticz and then Home Assistant) were based on Raspberry Pi hardware and that has resulted in quite a few more problems – SD card corruption due to brown-outs, reboots at unfortunate times due to me attempting to automate system updates and hardware failure initiated by some circuit breaker issues I experienced.

Reason 1: Z-Wave Pairing

The process of adding a module to a Z-Wave network is to put the hub into “include” mode and then press a button on the module while it is close to the hub. That sounds simple enough but now imagine doing this for 150 modules scattered around a house, some behind wall-plates, others in waterproof boxes, concealed in ceilings, etc.

It was quite onerous to do it once but I think I’ve probably done it on average three times for every module in the house plus quite a few more times for modules that I’ve moved around, or have failed and had to be replaced. That’s getting on for 500 include processes. And that’s just to get the module visible to the system. Once it is included you generally have to locate the specific function(s) of the module you want to use (e.g. a motion sensor might have a temperature reading, a light-level and an alarm setting in addition to the motion detection function), then you give each function a name, then you need to indicate what room it is in, then you might want to group it with other module functions (so, for instance, a mood setting in the dining room sets the light levels on five different modules via a scene or group). All of that needs to be typed in and you will generally be doing this while wandering around, so you will do it on a laptop or tablet and sometimes up a ladder or in a cupboard.

I have now gotten to the stage where I dread some modules failing. The one that controls a water-feature in the garden is in a sealed box, the one that controls an out-door heater is in a small loft area that can only be accessed by a rickety ladder, the one for the guest-room extractor fan is in a crawl space, etc. This can’t be the right way to do things can it?

When I compare this to the way IT operations used to be compared to the way dev-ops is now I think it is fair to say that we are just at the start and that things must change. It used to be normal that an IT person would have to physically sit at a computer for hour on end to install OSes, applications and security. Now it is done remotely and automatically on predominantly virtualized hardware. Furthermore, most apps are now in the cloud and the management of the servers that run them are automated to the Nth degree. Home automation and IoT have a long way to go!

Reason 2: Z-Wave Healing After Adding a Module

As mentioned a common challenge with Z-Wave is that introducing a new module to the network requires the module and hub to be close together. This actually creates a lot of work. There are two main ways to handle this:

  1. bring the hub to the module once it is in-situ and operating
  2. power the module up when it is close to the hub and then move it later

Both options are problematic if you are relying on the mesh network capabilities to extend the range of the network because the mesh works by finding routes from one module to another so that it can communicate at distance.

In the first case the hub will think that the module can be communicated directly – rather than through the mesh. In the second the module will have the wrong list of neighbors altogether.

In both cases, when a module is added, the hub always considers that it is in direct communication with the module so it has to be disabused of this before it will operate properly when the hub is returned to it’s proper place. The way to achieve this is to “heal” the network and this involves sending lots of messages around to discover which modules are neighbors of (can “hear”) each-other. This leads to the next problem

Problem 3: Scale

With a small network a “heal” is relatively quick but as the network grows it can take a lot longer and if things have moved around or aren’t powered on then there can be big problems.

With just a few modules a full network heal took only a few minutes but as I added more and more devices the heal took longer and longer and eventually it didn’t complete overnight. In the first version of Z-Wave a nightly-heal was recommended but I quickly went past the point where this was possible – well before I got to 100 modules I think.

I’ve read quite a bit about improvements made to the “heal” operation in Z-Wave Plus and, indeed I did start buying Z-Wave Plus devices to replace failed Z-Wave ones. But I haven’t been able to detect any improvement – possibly because I now have a mixed network of Z-Wave and Z-Wave Plus devices. For completeness though I did try creating yet another network with only Z-Wave Plus devices but I didn’t get far enough testing it before I gave up due to other issues.

Problem 4: Resilience and Backup

Z-Wave is a proprietary protocol and this is blamed by several suppliers of home automation software for the lack of backup capabilities on their Z-Wave network hubs. It is also exacerbated by the many different approaches used for actual Z-Wave connection to the hub. For instance Domoticz, Home Assistant and others are open-source software packages that make use of the third-party library OpenZWave (OZW) to connect to your network.

Also, the actual hardware used to connect is generally a USB dongle (AeoTech Z-Stick or ZWave.Me for instance) or the RaZberry which is a Raspberry Pi compatible add-on. To back-up each of these devices requires a different piece of software and, as far as I’m aware, can’t be done while the device is connected through OZW. So every time you change the configuration of your Z-Wave network you would need to bring down the home automation software and backup the memory on the USB dongle.

I think it is fair to say that no dev-ops person worth their salt would accept a system so likely to be prone to human error.

A further issue is that the configuration of the network (stored in non-volatile memory on the USB dongle) and the home automation software configuration (names of devices, rooms, groups, scenes, rules – for instance turning devices on and off at specific times) are stored (and backed-up) separately from each other and using different backup mechanisms. But if these backups are out-of-step then it isn’t possible to restore the full capabilities of the system. Here’s a brief explanation of why backup isn’t possible.

Problem 5: Failure Concentration and Complexity

Once upon a time I had a friend who was sceptical about wireless lighting systems. I told him that the system was run by a computer and this was when he pounced. “What if the power goes down” he said, “your computer will be off and you won’t be able to control the lights”. Of course I scoffed and pointed out that if there was no power there would be nothing to power then lights. 1-0 to me!

But I am the one who should have thought more carefully. Any network that depends on a single central hub (as Z-Wave does) has a single point of failure – which is an extension of his point I guess. Since a Z-Wave hub has a number of components, the failure of any of these can bring the network down. Over the years the main elements of the hub (Raspberry Pi – due to SD card corruption, Domoticz software – due to buggy updates and the USB stick – due to being physically damaged) have all been a problem for me.

A single software/hardware/connection failure at the hub means I can’t turn on any of the lights in the whole house. This is a huge problem for this technology!

Of course anyone familiar with Z-Wave will tell you that there is a way around this concentration issue by adding a secondary controller. But this leads me to the related problem. Complexity.

Adding a secondary controller is a non-trivial exercise and is not well supported by any of the home automation platforms I’ve tried.  The fact is that the secondary capability is really only handled at the level of basic network configuration. Ideally you would host the secondary on a different hardware and software platform in case it is a systematic issue but this results in having to set up the entire system a second time.

I’ve tried several times to set up a secondary controller and actually have the system fail-over to it but every time it has either been too complex and time-consuming or it has just failed for reasons too difficult to identify when push-came-to-shove.

Problem 6: Failure Rate

Another problem, if you aren’t tired of this yet, is the unacceptable rate of failure of modules in moderately large network. I now have around 150 modules and I think it is safe to say that I haven’t had a single month in the last five years when no modules have failed. I can’t keep up with the rate of failure. Right now there around 7 dead nodes on the network and at least three modules are indicating that they are functional but not operating correctly.

Admittedly some of this was probably caused by a whole-street power failure which occurred last month and that also caused an SD corruption issue on a Raspberry Pi. But whatever the reason, even if each module has a mean-time-between-failure (MTBF) of 100,000 hours (more than 10 years), when you combine 150 of them into a system then the MTBF for one module is actually less than one month.

So the only ways to get anywhere near an MTBF of a year or more would be to reduce the number of modules by a factor of more than 10 or to massively increase the reliability of each one.

Problem 7: Dead-Nodes

Now for another group of problems associated with modules that are either really dead, not dead but not communicating reliably, not dead but unreachable, not dead but have been off some time, etc. With any communications system there have to be some methods to handle communication or node failure which result in a degraded but still functional system. In a mesh network this is harder because a node which has failed or isn’t communicating reliably may be part of a path used to reach other nodes further away in the network.

The main way Z-Wave handles the lack of communication of a node is to gradually reduce the rate at which communication is attempted until it gives up altogether. This might work ok in a small network but in my experience the idea of giving up on a node altogether probably costs me a couple of hours a month in maintenance. Every time this happens – and it happened to about 10 nodes when we had a power failure while I was away – forces me to locate the module and physically press a button on it to wake the node and get it communicating.

I believe that if the network was setup in polling mode then this wouldn’t be a problem. But polling is a time consuming operation and for all but the smallest Z-Wave networks it is discouraged. So anyone thinking about a large-ish network should build-in time for spotting and fixing these issues and, if you don’t keep better records than me, a lot of that time will be spent wandering around trying to find the module which controls that light in the hall that used to work but now doesn’t.

Problem 8: Handling Power-Failures

The power failure I mentioned before was probably the main thing that pushed me into ditching the majority of the Z-Wave system. But a full power outage isn’t the only issue I’ve had of this kind. Several mini-outages have occurred due to circuit-breakers. These perform an important function of course and can trip the power if a person inadvertently touches a live wire or if there is water ingress into a light fitting, etc.

Since a number of our lighting circuits are outdoor we’ve had quite a few of these kinds of outage. Light fixtures such as pillar lights seem to last around five years before there is a good chance of water ingress. Up-lights set into paving probably last around the same amount of time. A set of christmas lights we put in a tree in the garden seem to work for around six months before something trips their circuit-breaker. And the lights we put under a feature-wall in the garden didn’t work for more than a week before they had to be disconnected completely as they tripped the circuit-breaker almost immediately every time they came on.

Each time this happens on a less obvious circuit, the module ends up with a “dead” indicator in Domoticz and the only way I’ve managed to revive them has been to open up the enclosure they are in and press the little button to get them talking. What a waste of time!

Problem 9: Poor Diagnostic Tools

Diagnostic tools are an important part of any technology that is more than moderately complicated. I would say that Z-Wave falls easily into the complicated bracket but the tools available are poor at best. Some of he home-automation apps have rudimentary route-map and logging tools and there are some log files that you can access from Open Z-Wave if you look hard but in general you are pretty much on your own. The tools from are some of the best at the lower level but their user interface and home-automation is pretty poor. There are also some proprietary tools but I paid for a couple and they are not that helpful. 

In the end a technology like Z-Wave which is marketed for the home user needs to “just-work”. If a regular user has to start connecting up test equipment or disconnecting their home automation system such that diagnostics can be run on part of it then there is a problem of maturity and quality in the current solutions.

I have found many occasions where things I thought I knew – like the routing the hub would take for a particular module – have proven incorrect – perhaps because a heal changed things unexpectedly – or because a new module was added that had a different performance characteristic. So either a technology like this “just works” or it becomes a mill-stone around the neck of the person tasked with keeping it working.

It is just such a mill-stone that I have finally ridden myself of and it feels good to no longer have the burden.

Problem 10: The Cost

Z-Wave modules are not cheap. When I started buying them back in 2012 they were about £50 for one circuit. Amazingly, in 2020 they are still around £50. This is pretty surprising to me as there is now a lot of good competition from things like the Shelly 1 which is only €9 and the Sonoff which is about £12 for two. The Shelly 2.5 can control two circuits and costs around €65 in a four pack.

Z-Wave modules are not cheap. A Fibaro or AeoTech Z-Wave module to switch one or two circuits is around £50 in the UK while a Shelly 1 WiFi module is under £10. 

This disturbs me. I don’t see much justification for the high price and all I can believe is that they haven’t yet woken up to the competition.

My New Lighting System

So, finally, we get onto what I’ve done to replace the Z-Wave system that I’ve mainly ripped out. It’s actually taken a lot of lockdown to get rid of almost everything but I’ve ended up with a predominantly WiFi-based system.

I could just have built the system using Shelly 2.5 modules and Shelly Dimmers as they are keenly priced and seem to work really well. Equally Sonoff units would probably have been fine also but they are a bit chunkier and some have to be installed in wall boxes (pattress boxes).

Problem 6 (Rate of Failure) would have still been an issue though and – as described before – even a 100,000 hour MTBF would have meant replacing one or more units every month. I also had a relatively unique situation that might help with this – as I mentioned earlier I had our fantastic electrician Lorenzo concentrate connections in around 5 places around the house. So it was possible for me to install a single piece of hardware to control many circuits.

One possibility would have been a Shelly Pro which can control 4 circuits. I tried this approach but didn’t really like it – for one thing it is based on a DIN Rail mounting system and I didn’t have the hardware installed to make this work well – I was replacing lots of individual modules remember.

So, me being me, I decided to go it alone and design my own switching units based around the ESP32 microcontroller and solid-state relays – I call this LightScader (you can see the designs here) because you can cascade up to four units together to get control of up-to 32 circuits. It isn’t all that complicated to do of course but the result that I now have seems to be a pretty reliable system. I’ve gone for quite high quality components – in an attempt to improve reliability – and it still works out much, much cheaper than Z-Wave modules. I also ended up using my own software to reprogram the Shelly 2.5 modules (but not – yet – the shelly dimmers) as it was easy to build from the same code I used for the LightScader. Hopefully one day I will find time to document the new system 🙂

In addition I have around 20 Shelly 2.5 modules and a similar number of Shelly Dimmers which are installed in wall boxes and other out-of-the-way places as well as in foot-switch boxes to control table and floor lamps.

Relative Merits of Z-Wave vs WiFi

PairingNode has to be close to hubNode can be anywhere in WiFi coverage
Healing after AddingA Z-Wave specific issueNo need to heal
Scale100+ network is unworkable in my experienceNetworks with over 200 WiFi nodes can work well
BackupNo solutionCan be backed-up with any standard backup system
Failure ConcentrationFailure of the hub leads to complete system failureStill an issue if the WiFi network goes down. Possible to have more than one WiFi network though and have nodes switch to another network on failure.
Failure Rate100,000 hours MTBF leads to > 1 module fail per month with 100+ modulesMy design of controller handles 16 or more circuits so failures will, hopefully, be less frequent
Dead NodesA problem unique to Z-WaveNodes never stop trying to connect as long as they are powered
Handling Power FailureMainly a problem with lower cost hardware like 1st or 2nd generation Raspberry PiMachine running Home Assistant or similar can be a linux server with redundant power supplies and an Uninterruptable Power Supply (UPS)
Poor Diagnostic ToolsZ-Wave products are immatureDiagnostics of WiFi is mature and there are a lot of good tools on the market
Cost£50 per circuitaround £15 per circuit on average for my new system

Some Potentially Useful Links

Comments 21

  1. Like you, I used fibaro units (from vesternet). They have all failed in the space of 3.5 years. I’m an EE – theres clearly a fundamental issue with the product.
    Also like you, I have developed my own espressif based solution. Having been involved in HA since dialup times, my design is fully distributed and fault tolerant- there is no longer any single point of failure.
    Zigbee could have been great, but is flawed. I’m glad to see the back of it – although I still have to keep one nose going for the CAD on the smartmeter

    1. Post

      Thanks for the comment, I do think it’s pretty disappointing that Z-Wave seems so flaky. I saw a lot of feedback on hacker news too and there are a lot of people who just don’t get why you’d want a system like this. For me there is no question I want home automation, it’s just that most of the stuff out there just doesn’t seem to work very well.

  2. Hear, hear.

    About five years ago, I put in a Pi/HomeAssistant/AeoTech Z-Stick system. I, too, selected Z-Wave since it was a free-as-in-beer protocol and enjoyed widespread device adoption. I regret this whole decision whenever things go wrong, and it often does.

    First off is Home Assistant. There is absolutely no way a non-linux user would be able to use this. It is absolutely not designed for the average user. They have tried to be more user-friendly in the past year or two by moving a lot of admin functions to the UI, but so much troubleshooting involves command lines, it is now in this obnoxious state where some functions need to partially be done in the UI and then continued in the command line. For example, deleting a node. You have to initially “delete” it in the UI to clean things up, then manually remove them from the HA config files.

    Another issue with HA is how they love to completely rewrite and break things for the sake of rewriting things. In my five years with HA, I have witnessed install methods get created, rebranded, and deprecated (, complete overhaul of the UI architecture, and complete overhaul of the Z-Wave architecture. You *have* to read the release notes before updating. I’ve run into occasions where pip upgrades will break the whole setup.

    It doesn’t help HA with how flakey Z-Wave and devices themselves are. The only Z-Wave light switches are made by Jasco, which rebrand as GE, Honeywell, etc. The first generation was garbage. I’ve had a 40% failure rate with them. They’ll randomly die or fry in a power failure. So far, knock on wood, no failures with the second generation. However, it’s extremely common for the switches to misreport their state to HA. Like you mention, devices reporting state is one thing, but whether that state is actually true is another.

    Seriously, it’s 2020. Home automation is nowhere near “just works.”

    1. Post

      I don’t know whether to be heartened that I’m not alone are massively disappointed that I’m not an outlier. I can’t really understand how people manage to get along with Z-Wave – as you say it seems like it is still immature and unreliable tech. I think I probably missed some of the problems you mention with Home Assistant though because I came late to the party. I’m not making myself too dependent on it though as I’ve now been burned enough times to approach every home automation tool with caution.

      I hope that 2021 (or 2022..) is the year that home automation does start to “just work” – but I’m not holding my breath.

    2. At one time, I had wrote a pretty popular AiO installer for Home Assistant. That was 3-4 years ago… Right about that same time the project shifted to state you perfectly described. After having my automation “offline” far more then “online” due to those pain points you mention, I have removed ALOT of the automation from my house these days.

      I’ve found Zwave2MQTT to be the reliable backbone, and mostly have HASS for “looking” at things nowadays. All the failures have really beaten the enjoyment of automation out of me at this point.

      1. Zwave2MQTT looks interesting. I’ll have to check it out, thank you.

        It seems like HA is trying to integrate with so many platforms and protocols these days, overall quality of each have suffered. If Z-Wave can be delegated to specialists like Zwave2MQTT, it may be a solution to a lot of problems.

        1. Post

          I did have a look at Zwave2MQTT. I think it would have taken some effort to get to a point where it would work for me and I decided that there were enough other issues with Z-Wave that it would still be disappointing. I do use MQTT though and it works really well.

  3. Rob,
    Your comments about Z-Wave are largely relevant to the early 100 and 300 series of Z-Wave devices which I suspect is the version you purchased back in 2012. Many of the issues you discuss were solved with the 500 series and even more so with the new 700 series.

    Pairing: Network-Wide-Inclusion (NWI) was added back to the early 500 series devices which avoids brining to device close to the controller during inclusion. Since then Z-Wave has also added SmartStart which means a device can join without any button presses. NWI also solves the healing after inclusion since the node is in it’s final location during the inclusion process. However, a Heal should solve this problem. Some Hub Vendors still don’t do heal well but this is a lack of software support by the hub vendor and not Z-Wave itself.

    Scale: I agree that networks of more than 100 nodes on any network (Z-Wave, Zigbee, BLE, Wifi, etc) are challenging and care must be taken to properly manage dead nodes and healing on the Z-Wave mesh . However, I disagree that Wifi does it better. My Z-Wave hub (HomeSeer Raspberry Pi based) runs for months and no nodes dropping and reboots after power outages without issue (Homeseer forces the /root partition to be Read only to solve that). Conversely, I and my family regularly reboot our Wifi router because for whatever reason somebody can’t join or can’t get to the printer or is really slow. I have a $400 name brand router and it definitely can not handle more than 64 nodes. I have a lot of Wifi devices in my home so we’re often close to the magic 64 devices number. When I light up yet another Wifi device then something else drops – usually a member of my families phone or computer whereupon I receive the full wrath of their ire.

    Backup: Backup is enabled in Z-Wave and there are commands in the SerialAPI to do it (I posted links to the related post you mentioned). This is another case where Z-Wave provides the feature but the Hub vendor has to support it. Most Hub vendors have the ability to restore a backup from their unit to a new one in the event the hardware fails or you want an upgrade. Backing up from one vendor and then porting to another remains challenging as naturally the Hub vendors don’t want you to switch. But they will soon be offering upgrades to 700 series so you can take advantage of Z-Wave Long Range and have devices with 1 mile RF range.

    Reliability issues: I’ll lump the next several issues into the general category of reliability. There are many aspects of this and as you mention anytime there is a single point of failure, that is the weak point in the network. Z-Wave has the ability to support secondary controllers and some Hub vendors (Homeseer) does a really good job of it. Others rely on rapid replacement of failed hardware. On the MTBF issue, the problem is more likely caused by poor quality of the product itself and not on Z-Wave as a protocol. IoT has a lot of products that are buggy or just don’t work well regardless of the communication protocol. I discuss this issue often on my blog and specifically in the WatchDog Timer post:

    Diagnostic Tools: Z-Wave has the “IMA” and the Z-Wave Alliance has CIT and we have the Zniffer and the PC Controller which you can download from and with $25 for UZBs you can make use of these tools. These tools are complex and not geared for consumers but instead for developers but the tools are there. Homeseer as the ZTool which is more geared for consumers. Conversely, WiFi mostly uses wireshark which is a very complex tool great for developers but consumers would be overwhelmed. We could all use better tools in all protocols – no argument there!

    Cost: I have to admit that I have no idea how these $15 Wifi switches can be made so cheaply. The cost for the Z-Wave chip is roughly the same cost as a Wifi chip so its not the protocol that’s causing the price differential. I’m curious to see how long devices that cheap work and as you mentioned, what happens after a power glitch.

    1. Post

      Eric, thanks for the constructive and thorough comment. I can see that you are probably right about the different series of Z-Wave devices solving some of the problems – it is difficult for me to accept that each device in a system like mine would need to be upgraded for each generation in order to get these benefits though. You mention four generations here I think – I was only aware of the Z-Wave and Z-Wave Plus distinction and even then I didn’t see the benefit of Z-Wave Plus devices I installed and only later found comments to indicate that most Z-Wave Plus benefits only occur if all devices in the network are upgrades. With more than a few dozen devices at the price they are this seems pretty unlikely to be a winning solution. If I had known about and tried to follow the trajectory you describe of 100, 300, 500 and 700 generation devices I would have spent in excess of $20k and months of effort accessing and upgrading devices.

      Regarding WiFi scale, I’ve been using Unifi WiFi access points for a while now and I’ve had, at times, many more than 100 wifi devices on the network without any apparent issues. I think WiFi performance is very much determined by the quality of the access point vendor – at least that’s the finding I hear from Stampede ( CEO Patrick Clover and his company has several thousand access points in hospitality venues around the world so I guess he’s seen a lot of issues.

      I honestly can’t say how long the cheap WiFi devices are likely to last though. I have made sure that the devices I designed myself can be CAT-6 connected so that I don’t have to rely on it. Frankly, despite having spent my career in the wireless industry, I’m sceptical that wireless is that way to go for home automation that doesn’t need to be wireless. Lighting systems probably should be wired in my opinion but there is a lot of money betting against me on that so I guess we’ll have to wait and see.

  4. Pingback: 10 Reasons for ripping out a £6k lighting system #Zwave #WiFi #IoT #InternetOfThings « Adafruit Industries – Makers, hackers, artists, designers and engineers!

  5. When I was designing my house, I was wondering whether to rely on a wired-bus, a “every cable runs to one central place”-approach or a wireless system. I am quite happy I chose the central approach. I just recently considered using an ABUS Z-Wave automatic door lock (DON’T BUY IT).
    What I quickly learned was that in order to get a z-wave S2 secured communication working with my local smart-home computer, I would have to buy a license from, which I personally did not trust at all as it is neither open source, nor seemed to work reliably. So I decided to opt for a Nuki door lock and after your comments, I will continue to put everything onto wifi.

    1. Post

      Thanks for the feedback, one thing I’ve learned from writing this is how deep and wide this kind of problem is. It is quite surprising that some big companies are pushing some solutions which are mutually incompatible and not ready for mass adoption. I do think WiFi is a good option right now if you can’t make it fully wired. But I think the main thing is to adopt a cautious approach.

  6. Now that you have all these devices and a HomeAssistant setup, may I propose:

    Push for HomeAssistant to recognize devices by MAC address.
    Static IPs (or static DHCP assignments) work fairly well, but are somewhat fragile in that if something happens to your DHCP server, HomeAssistant can do wild things like:

    – Adding a second entry for the same device (kitchen_lightswitch_2)
    – Disconnecting the device from any automation (since *_2 is a “new device”)
    – Disconnect the device from any groups
    – Disconnect the device from anything to do with a template
    – Mess up the history graphs

    And, in many cases it’s quite a hassle to fix this. The last time it happened to me I had to shut down HomeAssistant entirely and modify multiple files on-disk to clear out both copies of the duplicate, crossing my fingers that it would get the expected name when HA rediscovered it.

    1. Post

      That’s an interesting point. I mentioned Home Assistant mainly because it is the current best option I’ve found but I’m no expert in it and many people have pointed out its deficiencies too on the Hacker News forum which seems to have picked this up. I have found managing IP addresses a pain. MAC addresses might be a good idea – I haven’t really thought about it though to be honest. I’ll have to do some homework.

  7. Pingback: Cats, Running, Guns, Punk Rock. In That Order.

  8. I would say you have reduced the value of your home because you have fitted a complex system that only you can service and support. No professional smart-home company will go near it.
    If you had been sensible you should have got a professionally installed Rako or similar system and saved yourself a lot of time, money and stress. This would of also added value to your property.

    1. Post

      Karl, it is an interesting point you raise. A friend of mine maintains a Rako system and tells me it difficult to find an electrician who will touch it. Maybe in London or another major city you’d be ok – but in the sticks – no chance – apparently. Googling Amazon Alexa, Google Home, Philips Hue, Home Assistant, Home Automation, etc. indicates that a lot of people are adding home automation to their homes and, while some may be using professional installers, I suspect most aren’t. Of course the majority may be wrong to do this but I think it is clear that this is what is happening like it or not.

  9. I have to agree with the author, I am at 45 nodes and the rate of failure is ridiculous. I am on Domoticz with a mix of mainly Zwave+ nodes. When I add new nodes, old nodes suddenly lose contact and refuse to report status’s, the “inclusion” process usually takes 2 hours per node when you account for ManufacturerSpecific information to reliably be allocated. Once the horrific quirks of each and every module have been resolved, you then have to re-jig all your rules, events, scenes or whatever to deal with the new node ID’s/Device numbers. And then you have the dead devices, flimsy bits of plastic that simply won’t even respond to anything, the dreaded “heal network” which is a total lottery whether it will destroy carefully curated contacts with troublesome nodes. I feel like a mug for believing that “you need more nodes to create a strong mesh” nonsense, nothing could be further form the truth.

  10. I felt the same pain with z-wave for mostly the same period of time as you mention. Hubitat, z-wave plus, and better device suppliers, seems to have improved the situation. Helpful that hubitat also supports zigbee and wifi devices. Not perfect, but has gotten much much better.

  11. i have close to 200 nodes running for over 3 years , superfast never fail or drop out, i can turn on/off lights many times a second, extremely large scene always run as the shulde. If you dont configure z-wave correctly it will not work god, its like buying a car but you don’t know how to drive. wifi is simple as are most zigbee, but its not reliable an misses a lot of functions as most zwave devices have, (if you know how to use them) and for us in europe 2.4ghz vill make thins disturb everything from bluetooth to wlan to zigbee. wifi also has the drawbacks of latency for all things on the network and a big security problem, dont forget a wifi router talks to 1 device at a time, shelly is using old N standard making it need more airtime.

    im have been doing smarthomes for over 20 years, i have runn, KNX,zigbee,bluetooth, shelly/wifi, 433mhz and zwave. only KNX and z-wave gives the stability and speed a real smart home needs.
    im running my setup on vera secure, before this i uset vera plus, this is controlled by Homeassistant, using vera standalone is terrible, using it with HA is awesome. (the is no better mix) And i also like to say the controller for zwave is very important, il like to test new controllers (tested most models on EU market from fibaro hc3 to different usb sticks, but none can match vera controlled by HA,
    hmm maybe i should make a guide on my settings?

  12. Interesting reading, must agree z-wave may be tricky sometimes, especially at inclusion (& just after, to identify all functions and how they report).

    Having to press a button on a device to exclude, after setting controller in exclusion mode, is a real flaw: How possible is this to forget devices may break when specifying this?! This leads to dead nodes and removing them from your networks is a hassle of “kitchen recipes” that depends on your controller setup and too difficult for the average user.

    Too many buggy devices, also and most of them passed certification process:

    Some brands may also be banned, especially some chinese products that may prove dangerous for AC powered ones, don’t manage battery correctly for DC/battery ones (expect erratic behavior under 30% reported capacity)… or may just share the same IDs for several versions of the device (good luck to manage device configuration files). Neo, if you read me.

    But others show bugs that should not get through a certification process: Changing batteries sometimes leading to parameters reset, some parameters setup that does not work as expected (hello Philio and your N-in-one sensors that have otherwise unmatched features)…

    I really don’t know how someone can just think about designing remotes (and any device that may be used from several locations) on a mesh network that does not allow broadcast: They’ll only work reliably from the inclusion location!

    Anyway, I started only 5 years ago and I only have zwave+ devices (gen5). So my system don’t mix different generation hardware and is probably in the early&reliable years: So far, I only fear issues at inclusion and devices integration/setup in my system. After this, I may discover issues over time (like Neo battery powered PIRs) but the system is stable with sometimes 2 months uptime between raspbian reboots.

    No uSD issues since I use some devices branded for applicative use (A1/A2, prefer A2 with more IO/s) that targets 24/7 use and non sequential loads inside tablets/smartphones. Another benefit is the storage FW can be tuned to do static wear-levelling (a feature that needs long uptimes for background processing) instead of static (can’t do better for the use-case of a device only switched-on the time to take a photograph).

    Linux virtual memory management & file-system sysfs also provide interesting “knobs” to modify buffering and commit size/time that also helps preserve storage. This may lead to more data loss in case of power failure, but a DC battery is cheap & will avoid AC drops that may break file-systems (quite unlikely with journaling ones like Ext4) or lead to data losses, some batteries providing 20V to backup your modem + 5V USB for the PI exists. That’s 30 to 50 bucks depending on capacity.

    With ~40 devices, my system proved stable managing heating (a lot of Qubino pilot wire devices, note these ones are swiched off 6 month/year out of heating season & always restart without any hassle) and alarm (several sensors/sirens from Fibaro/Neo/Philio… depending on use-case).

    Network devices I use (wired/wifi), on top of controller hosted by a PI3B, are IP cameras.
    And z-wave may be tricky, but IP cams also shows the drawbacks of network devices, especially when trying to be accessible to everyone:

    -Careful selection to find devices still providing a web configuration page (+some HTTP APIs), not only a smartphone app that’ll be over after a few andoid/ios versions.
    -If HTTP configuration is there, dealing with plugins no more supported or targeting IE that is now EOL (=>will soon need to keep a windows VM with updates blocked).
    -Need to manage network setup or enforce MAC/IP static setups.
    -Manage a dedicated subnet and/or FW all devices that try to communicate with manufacturer almost continuously… on top of possible security issues.

    For the price, must agree with you: This may kill z-wave in a few years for zigbee, even if OEMs does not care a lot about interoperability for this rising competitor. Some universal gateways exists, but this reminds RFXCOM with gateways always needing to be updated to cope with new brands/devices and stability issues that may show up for existing hardware doing so.

    Most probably the chip manufacturer is to blame: Exact same devices now exists with z-wave or zigbee radios with +30% price deserving z-wave.

Leave a Reply

Your email address will not be published. Required fields are marked *