PAUL OCKENDEN
Paul dives into wireless home automation protocols and gets a syncing feeling when a reader asks for help with Dropbox
This month, Paul dives into wireless home automation protocols and gets a syncing feeling when a reader asks for help with Dropbox.
If you’ve invested in some smart home kit, or have a house full of Internet of Things things, you’ll know that by and large such products communicate wirelessly. And they do so using a variety of different standards. Most obviously, there’s Wi-Fi, which is great for things that need a lot of bandwidth such as wireless speakers and other forms of media streaming. You wouldn’t want to use Wi-Fi for something like standalone temperature or humidity sensors, though, because it’s a battery hog, best suited for devices that you plug into the mains or use with a power brick, rather than those that run on batteries.
Older temperature sensors often use simple 433MHz signalling – it’s what you’ll find in weather stations and those cheap indoor/outdoor thermometers you often find in the middle bargain bin aisles of the low-priced German supermarkets. You might remember I wrote about receiving and decoding the signals from these using a USB TV receiver last year ( see issue 299, p113). They’re usually very simple devices, powering up their internal radios to transmit every five minutes or so; some only power up when the temperature changes by more than half a degree, and then go back to sleep. It’s all low-power, low-tech, with no acknowledgement signal, so there’s no need for the devices to stay switched on all the time sitting there listening. It’s battery friendly but also quite crude.
Due to these limitations, Wi-Fi and 433MHz signalling aren’t the only games in town. You’ll find kit that uses proprietary protocols: Lightwave RF, the Evohome heating controls and Loxone Air to name but three. Each will have its pros and cons. Take the Ramses II protocol used by Evohome, for example – it was designed to minimise radio on-time to conserve battery power, but again there’s no acknowledgement to confirm that one node has received a signal from another; you sometimes get mid-air data collisions, especially if you have lots of devices, so the system relies on regular repeats of data. It works well, but it’s now a very old protocol (based on the even older Residential Network Protocol), and I’m not convinced that if the designers were creating the same thing today they’d have done it like this.
Doing some Zs
Alongside these proprietary protocols sit some well-respected standards, and you’ll find many people building systems around the two Zs: Z-Wave and Zigbee.
Z-Wave is the older and more popular wireless protocol. It’s one of those “you need to be careful” standards because the operating frequency is different in countries around the world. In the UK and the rest of Europe, the system operates at 868.4MHz, but in the US it’s 908.4MHz, Hong Kong uses 919.8MHz and Australia 921.4MHz. All in the same ballpark, but all slightly different and thus completely incompatible. I’ve lost count of the number of times people have complained in forums or via online product reviews that the cheap
“My advice is to forget repeaters and buy Z-Wave switched sockets”
sensor they bought from an overseas retailer doesn’t work in their setup.
Zigbee doesn’t have this frequency issue because the devices nearly always operate in the 2.4GHz space also occupied by Wi-Fi and Bluetooth. But there are regional differences with things such as maximum transmit power allowed so, again, you’re probably better off purchasing from closer to home if you can.
One problem that you’re likely to come across with both Z-Wave and Zigbee, though, is range. If you read the specifications of the various sensors they’ll all talk about ranges of between 30m and 100m, certainly plenty for a domestic property. But in the real world you’ll sometimes find that one device will struggle to talk to another in the next room.
Thankfully, both systems utilise a mesh network, so if one device needs to talk to another but the signal won’t reach, it can bounce its traffic through something in the middle. Although true for both Z-Wave and Zigbee, the systems are incompatible: you can’t use a Zigbee device to repeat a Z-Wave signal. You’d think that much would be obvious, but again, looking at some of the comments across home automation forums, it appears not.
With both standards, bear in mind that battery-powered sensors won’t act as repeaters, while a mainspowered device usually will – there are exceptions, though, so check the spec sheets before buying.
I’m going to concentrate on
Z-Wave rather than Zigbee for the rest of this section, as that’s far more popular. My first piece of advice: don’t rush out and buy plug-in Z-Wave repeaters. They look a bit like a 13A mains plug, and you just plug them into an empty socket, pair them to your Z-Wave mesh network (the technical term is “inclusion”), and that’s it. They’ll intelligently start to route traffic between nodes. You might think it makes sense to litter your house with these things, but take note of two key caveats. First, a Z-Wave node can talk to another node a maximum of four hops away. If you put too many nodes in, you can make devices unreachable because the easiest path breaks this rule.
The second caveat is that no matter how many mains sockets you have, it will never be enough and you’ll always end up filling them. Unless you happen to live in the house that went viral last year ( pcpro.link/307plu gs).
So, filling your house with repeaters will just waste valuable socket space.
My advice is to forget repeaters and buy Z-Wave switched sockets instead; they’re only slightly more expensive. You don’t need to use the switch functionality, but it means that as long as you leave the switch on you can still use the socket on the front. Just be careful not to plug anything essential such as a freezer into it as, being a remote switch, there’s always a chance that you might accidentally switch it off! Incidentally, Z-Wave sockets still act as repeaters even when they’ve switched the load off (although not, obviously, if you turn the whole thing off from the switch on the wall socket).
You can also buy light socket switches that act as repeaters, but I’d advise against those because they aren’t very user friendly. I had one in a spare room for a while but it confused other family members when the light switch on the wall no longer worked (it needs to be left on all the time, with the light controlled using a Z-Wave signal), and to make matters worse, when they discovered that the light in the room wasn’t working they’d leave it switched off, so both the Z-Wave switch and the repeater were powered down. It’s a more extreme version of the reason that I don’t like smart bulbs, although at least those can often be woken up without a Z-Wave command by flicking the switch a couple of times.
If you’re buying Z-Wave sockets, I recommend those made by Aeotec and Fibaro. They’re both very reliable. You could also look for products from Foxx Project. I’m not sure if they’re still being marketed, but old stock sometimes appears, often at reasonable prices. The Foxx products are just rebadged Aeotec devices. The firmware hasn’t even been changed, meaning most controllers will report them as Aeotec (or
Aeon Labs).
On a more negative note, I haven’t had a great deal of success with three Everspring Z-Wave products. Of my four AN157-3 sockets, two failed within two months; I bought three AN145-4 BC lamp holder switches and their range has been disappointing (one has an intermittent fault, too); and my AN145-2 E27 lamp holder switch sometimes won’t even respond to a signal from the same room.
Ground control
Speaking of controllers, you can buy all kinds of fancy home automation controllers but I reckon a great place for a beginner to start is by using a Raspberry Pi and loading Domoticz onto it. It’s incredibly simple to get it all going. From a terminal window on the Pi, simply type:
The curl command grabs a file from the internet and the pipe character followed by bash means the script you download gets executed by the Pi. The case is important so make sure you type a capital L, which instructs curl to follow any HTTP redirects. Actually, although the -L is part of the “official” instructions I’m not convinced it’s needed – I’ve never known “install.domoticz.com” to redirect to a different address. Probably safest to include it, though.
Once it’s installed, you interact
with Domoticz via a web browser at http://
Head to Setup and then Hardware, where you can start to add devices. Click on the Type dropdown and you’ll see a list of things that come pre-baked into Domoticz. If you have a Nest thermostat or Philips Hue lighting, this is where to add them.
A Raspberry Pi doesn’t speak Z-Wave natively so you’ll need to add some hardware to communicate with Z-Wave devices. Many people use something called a Z-Stick, which is another Aeotec device. It looks like a USB memory stick, and just plugs into one of the ports on the Pi. The Z-Stick is okay but I’ve had more success with a different solution, a Raspberry Pi daughter card called RaZberry from Z-Wave.Me ( z-wave.me/products/
razberry). The version I use is called a RaZberry2 and it cost £50 on Amazon ( pcpro.link/307raz). Z-Wave.Me has its own software for driving the board – called Z-Way – but I find it much easier to ignore that and simply use the OpenZWave drivers that are built into Domoticz.
Well, actually, it’s easiest not to completely ignore Z-Way. You see, for the RaZberry2 to work successfully with the Raspberry Pi, you need to make several config changes such as disabling Bluetooth and fiddling with the serial ports – which means digging around in config files. Far easier is to initially install Z-Way, as that does all of these configuration changes via its install script. Once that’s done, you disable Z-Way with the command:
sudo systemctl disable z-way-server
You’ll need a quick reboot, and then should be able to add the RaZberry2 card to Domoticz by selecting OpenZWave USB from the device list and selecting dev/ttyAMA0 in the serial port list.
I mentioned that Domoticz uses OpenZWave; this is a third-party library for managing and controlling Z-Wave devices. It doesn’t have its own user interface or command line, it’s simply the glue that applications need to speak Z-Wave. Loads of products use it, though, as you’ll discover if you search on GitHub.
One of the most popular is the OpenZWave Control Panel, or ozwcp. You’ll find it at pcpro.
link/307ozwcp, but a version is built into Domoticz, and is exposed the first time you add a Z-Wave controller to the system.
Although ozwcp is great, and offers lots of functionality, it can be a bit confusing for new users. Luckily, Domoticz has its own simpler Z-Wave management facilities. I really like the Neighbours diagram, which is great for trying to debug mesh network issues.
In you’re thinking of littering your house with temperature sensors, or keeping track of things like open doors and windows, I can thoroughly recommend a combination of Domoticz and Z-Wave.
Dropping the box
I don’t often receive technical support type enquires from readers (for which I’m grateful!), but I did get one this month that’s worth sharing because a quick Google suggests that many people are having exactly the same problem. It concerns Dropbox – and, yes, I’ve read everything that Jon Honeyball has written about why you shouldn’t use Dropbox, but I’ve yet to find anything that’s as well supported by a number of third-party apps and devices.
For example, my scanner will save directly to Dropbox, without any midconnection intervention from a PC – I like that. And I also love the smartsync facility, which means files I don’t touch very often are stored in the cloud only, freeing up space on my hard drive, but are still available if needed by an application. It means I don’t have to pay the stupid storage tax charged by many of the high-end vendors selling non-upgradable laptops. With smart-sync, a 1TB SSD is plenty for most users.
The problem the reader who contacted me has is that Dropbox seems to be continually syncing a number of files, and the sync process never seems to finish. A reboot doesn’t fix it, nor does removing and then reinstalling Dropbox. People who are affected are mostly running
Windows, although a few are also running the Mac version and seeing the same error.
The issue is due to a change in the Dropbox clients, which started rolling out during the latter half of 2019. Previously you could add symbolic links into your Dropbox folder so, for example, your Windows Desktop files appeared there even though they were actually sitting in a completely different place in the PC’s folder structure. Similar on a Mac, too. Many people used this facility, but the new release killed it. It’s one of several changes that have annoyed Dropbox users recently. It turns out that this continual syncing is mostly caused by old symbolic links, which are no longer respected. Dropbox doesn’t warn you, it just sits there sulking.
There’s a hidden feature in the Dropbox client that allows you to fix it, though. Go to Preferences, look in the Account tab and then hit the space bar if you’re using Windows or hold down Alt/Option on a Mac (if you don’t see the option, you’ll need to update the macOS app). Two new secret buttons will appear: one says Fix Permissions and the other Fix Hardlinks. It’s that second button that you need to press. It will take a few minutes to run, but hopefully once it completes it should solve the issue. If it doesn’t, try the Fix Permissions button, but this will probably cause a complete resync to happen so it might take a few hours to run. If you’re asked for a username and password, it wants the machine credentials rather than your Dropbox login.
It’s odd that Dropbox has hidden these buttons when they’re able to fix such a widely reported problem. Maybe Jon was right after all…
“It’s one of several changes that have annoyed Dropbox users recently”