Device associations let you create direct communications between two or more Z-Wave devices without the need for a central hub/controller. One device acts as a controlling node which sends commands to one or more receiving, or ‘slave’, devices.
- Click ‘Settings’ > ‘Z-Wave Associations’ to open the device associations page:
- You must have paired your devices with an Ezlo or Vera controller in order to create an association between them in EZLogic.
- You can only associate Z-Wave devices with each other. You can’t, for example, associate a Z-Wave device with a Zigbee device.
- Not every Z-Wave device supports association. Check the manufacturer’s documentation if you don’t see a particular device in the ‘Source’ or ‘Target’ drop-down menus.
- EZLogic automatically shows a ‘Device-to-Controller’ association for every Z-Wave device you have paired with your controller:
If a device only supports one association then this is used up by its association with the controller.
Please see the following sections for more help with device association:
- Why use device association?
- Association groups
- ‘Basic_Set’ and command classes
- Device classes
- Source Channel
- API links
Note – The following points are a general discussion of the pros and cons of associations, rather than a description of what you can or cannot do in the ‘Device Associations’ area of EZLogic.
For example, ‘Use unsupported devices’ speaks of how you could use associations to overcome a controller’s lack of support for a device. However, you wouldn’t be able to create such an association in the EZLogic interface if the device wasn’t supported by Ezlo or Vera hubs in the first place.
- Faster communication. Associating two devices lets them send signals directly to each other without going through a controller. This speeds up the communication and avoids network traffic jams so your tasks can often be completed faster.
- Automation without a controller. Device association adds flexibility by letting you automate in networks that do not have a static controller. You might need a controller to create the initial association, but the devices can be moved out of the controller’s range right afterwards. The devices will directly communicate with each other going forward.
- Use unsupported devices. Not every smart-home device is supported by every controller. Direct association lets you access the functionality of such unsupported devices to perform automations with them.
- Cost savings. Direct association of devices can allow you to achieve your automation goals without the expense of a controller or third-party management software.
- Less complex. Most controllers require you to manage a set of rules in a mobile app or web-interface. Direct association bypasses this requirement so you don’t need to master an app’s logic engine to get your automations running. This can also make troubleshooting easier as you don’t have to worry whether your rules or a software bug are at fault.
- Fewer points of failure. Your automations will still run if your controller goes down, or if there is an issue that prevents your controller communicating with your network. For example, you might want an alarm or security system to be capable of operating independently of your central controller.
Limited scope. Associations are mainly used for simple tasks that do not involve nuanced situations or scenes. For example, to have a door lock command a light bulb to turn on when it is opened. However, you would probably need a controller if your needs are more sophisticated. For example, if you wanted to dynamically set the dim level of the light, or specify how long the light should remain on, or make it come on only if it is night-time, etc.
- More complex. Associating devices can entail delving into Z-Wave device settings and multiple rounds of trial-and-error before the connection works. This is further complicated when you consider each device has a unique set of proprietary commands that varies from manufacturer to manufacturer.
Yes, association can bypass the need to learn the rules engine of your controller’s app, but bear in mind that those apps are explicitly designed to make life simple for you. They are designed to remove the complexities you might encounter when attempting to create a scene ‘by-hand’ via device association.
- An association group is a list of device IDs stored on a controlling (source) device when you create an association in EZLogic. The controlling device will send a command or notification to all devices in the list when certain conditions are met. For example, a motion detector could send an ‘On’ command to a light switch device when it is tripped.
- The group number determines the type of commands that can be sent from the source device to the target device. The group number must be available on both devices and it must support the same type of commands. For example, if group 3 on a light switch is the group that sends dimmer commands, then group 3 on the target device must be capable of receiving dimmer commands.
- Groups are not ‘global’ – they are specific to each device. The number of groups supported by a device, and the commands within each group, varies by device and manufacturer. Please check the device’s manual to find out which groups it supports (if any).
- For example, group 4 on one device might have a completely different set of commands to group 4 on another device. This means you can associate device ‘A’ with device ‘B’ over group 4, and also associate device ‘C’ with device ‘D’ over group 4. The two operations will not interfere with each other.
- Group 1 is usually called the ‘lifeline’ group and is for communications between a device and a central controller. The group lets the device report basic information to the controller, like its battery level, on/off status and other details.
- Group 1 is generally not used for direct associations between two devices. If you want one device to send a specific type of command to another then you should consider group 2 and upwards.
- Group 2 is a good starting place if you just want one device to send On/Off commands to target devices. Most device manufacturers use group 2 to send or receive Basic_Set On/Off commands.
- You can find the names and number of groups that a device supports by clicking ‘Settings’ on its tile in the ‘Devices’ area:
- You can associate a single controlling device with multiple target (slave) devices. For example, to have a switch turn on your lounge main lights, a lamp, and your music center.
Simply create a separate association for each target device and use the same source group for all three:
All three target devices will receive the On/Off command from the switch at the same time.
Z-Wave devices communicate with each other using signals organized into ‘Command Classes’. These classes are groups of commands and responses which reflect the functionality of the device.
The ‘Basic’ command class is a set of three simple commands supported by every Z-Wave device. It acts as a common-denominator to ensure all Z-Wave devices can communicate with each other
There are two commands and a response in the basic command class:
- Basic Set – sets a value between 0 and 255. This command is sent from the controlling device to the target (slave) device.
- Basic Get – asks a target device to report its current status (value) to the controlling device.
- Basic Report – returned by the target in response to the ‘GET’ command. Again, this is a value between 0 and 255.
The way a device interprets the values mentioned above depends on the functionality of the target device. For example:
- Switch – Turns on when it receives a value of ‘255’, and off when it receives ‘0’.
- Thermostat – May engage different modes for different values. For example ‘0’ = ‘Normal’ mode, ‘255’ = ‘Energy Saving’ mode.
- Temperature Sensor – Will report a value between 0 and 255 in response to a ‘GET’ request.
- Door Lock Sensor – Reports ‘0’ if the door is closed, and ‘255’ if the door is open.
- Motion Detector – Reports ‘0’ if there is no movement and ‘255’ if there is movement.
…so a single device can send a ‘Set’ value of ‘255’ to a variety of devices, and each will take actions which correspond to its interpretation of ‘255’.
- The exact manner in which your device handles the basic commands might be different to those described above. Please consult your vendor’s documentation for precise details.
- The ‘Basic’ command class is just one of many. See this page in our API docs for a full list of supported command classes.
- The command classes that a particular device must support are determined by its ‘Device Class’. See the next section, ‘Device Classes’, for more on this.
Device classes are a Z-Wave standard that ensures each device’s functionality is well-defined, and that devices are interoperable with each other.
A device’s class determines the mandatory command classes it must support. There are three device classes as follows:
- Basic Device Class – Simply defines a device as a controlling device, slave, or routing slave. These are called ‘source’ and ‘target’ devices respectively in the EZlogic UI.
Generic Device Class – Defines the core functionality of the controlling or slave device.
- See Supported Generic Device Classes in our API docs for a full list of generic classes.
Specific Device Class – A sub-division of a generic device class which further defines a device’s functionality.
- See Supported Specific Device Classes in our API docs for a full list of specific classes.
To be Z-Wave compliant, a device must belong to a ‘Basic’ and ‘Generic’ class. It must also support all command classes required by its given device class. Manufacturers can further define functionality by adding an optional ‘specific’ device class.
Some devices can independently control multiple devices using different types of commands, or by sending the signal over a different port. This is known as having multiple ‘endpoints’. For example, a powerstrip may contain both binary switch and multilevel switch functionality which operate over different channels. A relay switch may be capable of controlling two different loads, letting it operate two lights or appliances independently.
The source channel menu lets you specify the channel over which a controlling device communicates with a slave device. Both the source and target devices must support the ‘multi channel associations’ command class.