Z-Wave Associations with an Arduino

The problem

There are 2 small, rather dark hallways in my house. They just connect the rooms, so you don't stay there long. This makes them ideal places for motion sensor automated lights so you can get away with the tedious: turn on lights, take 2 steps, turn off the lights, continue sequence and instead just walk through while the lights go on and off automatically.

The motion sensors have to be wireless because I didn't feel like doing a lot of rewiring in the walls and ceiling. As I've already installed my z-wave gateway in a previous post, I figured using some z-wave enabled device: it's wireless and low-energy.

Making a z-wave motion sensor control a light is easy: just set up a z-wave association between the 2 and done. Only problem: The lights in that location are part of the original structure and are controlled by an arduino based PLC replacement. Z-wave associations only work between 2 z-wave devices. So another approach is required.

My solution

Luckily, both the z-wave gateway and controllino were already connected to the cloud through AllThingsTalk, so from there I was able to set up a couple of rules that take care of the automation.

Here's the rule for the hallway downstairs:

All it says is: When there is movement downstairs in the hallway, turn on the lights. When, after x nr. of minutes, there is no more movement, turn off the lights.

To create such a rule:

• On maker.allthinstalk.com, open the rules view

• Click 'create rule '

• Follow the wizard steps

You will want to have it trigger on a 'device state change ' of your zwave device's movement sensor and actuate your controllino's light actuator.

More details

To mimic an association, our rule needs to do 2 things:

• It is triggered 'On every state change' which simply means that the rule will be executed whenever a new event has arrived (aka: the device has sent a value to the cloud).

• The value of the sensor is sent to the actuator, which is performed in the 'then ' part of the rule.

Automation types

Over the course of this series, I'll present you with different ways to automate things (or have something happen because of some events). Each method has it's own characteristics making it more suitable for some use-cases but not so for others.

The solution that was presented in this little project relies on the online rules engine provided by AllThingsTalk. It's characteristics are:

• Only supports basic if-then-else operations with 1 or 2 'if' assets and 1 operation in the then and else parts (at the time of writing)

• 1 message goes to the cloud and the processed response comes back in a single response, as you can see from the diagram in the schematics section.

• The application resource is shared across multiple users.

We will be exploring alternatives for all 3 characteristics in coming projects.

Cons:

Because all messages need to go through the cloud for processing, this solution should not be used for mission critical stuff. In my house, this means that all relationships between buttons and lights (the primary lighting system), are performed locally. But an additional layer like some light automation, can be performed in the cloud. If something were to go wrong, I can still operate them manually.

At the very beginning, this turned out to be a very well working 'canary' warning system, giving me feedback at my earliest convenience.

Pros:

This solution can work across big distances and more communication protocols (ex: LoRaWan). If the sensor would have been far away from the actuator, (as in another town), then this would have been the ideal solution.

Basic relationships between sensors and actuators, like rules, can be performed very quickly in a secure manner on the cloud. The description language of a rule is simple and does not allow for much abuse. Executing external, 'non-trusted ' scripted code (like Python or Javascript for instance) always comes with an extra overhead that this solution doesn't suffer from.