I’m trying to wrap my head around the difference between the two flavors of zigbee that I see routinely discussed in the community(Home Automation and Light Link). From what I’ve read:
The two have different sets of clusters
Light link devices can talk HA but only on certain channels common to both.
The questions I have are:
Would ST need a new radio to natively work with LL?
Are LL and HA two separate protocols or just two separate application types? Could both coexist on the same network?
Are the limitations that cripple native support for Hue bulbs because of this incompatibility or because of functions that haven’t yet been implemented by ST.
The web seems to not have very much information on this and I would like to understand the issues involved with making ST LL capable.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
2
Good questions … I am interested in following this Topic… so I’ve written up a few notes, but these are not official or verified:
Have you downloaded the full specifications from ZigBee.org for careful detailed comparison? You need to input your contact information in order to get the PDF, though I can send them to you privately upon request (I would just post a link to my copy of the files, but I guess that technically violates their copyright, geesh!).
Maybe these links to the PDF downloads on their site will work without form submission?
At first glance, I think that ZigBee HA contains (nearly?) everything in ZigBee Light Link. The Clusters for various types of lights (dimmable, color, etc.) seem identical… but, the documents are not in the same format so it is difficult to compare without a lot more reading.
Can you find some specific differences to focus on?
As far as what I’ve seen in SmartThings so far, except for SmartHubs with very old firmware, Light Link compatible bulbs (Philips Hue, GE Link, and Cree) have been able to be connected directly to the hub / cloud and handled with Device Type Handlers documented throughout the Forums; but certainly with various quirks still being worked out.
Current answer: I don’t think I would call the current situation “crippled”. Based on my observations so far, SmartThings is handling these natively “pretty well”. It would be interesting to determine specific native features of Hue or other native Light Link bulbs that are not replicable by SmartThings in some form. The mobile Philips Hue apps, for example, can define Groups of Bulbs and Scenes … but these are implemented in the app and/or in the Hue Bridge or Hue Cloud … i.e., not in the “network of bulbs themselves”. Thus, it should be easy to replicate this functionality in a SmartThings SmartApp or extensions to the SmartDevice Type.
The bulbs can alternatively be connected interchangeably to each other’s branded hubs (well – I have both Philips Hue and GE Link bulbs on a Philips Hue Bridge/Hub), and, in turn, these hubs have a local IP / http / REST-API that SmartThings can relay through. In this scenario, an independent ZigBee mesh network is created. This scenario is working well for me and many of us, as we can use both SmartThings as well as the Philips Hue mobile apps.
Again: Search the Forum for Philips Hue configurations: I recall reading that if you join a bulb to SmartThings hub directly, then you can no longer join to the Philips Hue Bridge. Is this just because a bulb cannot be on two networks, or does the initial join force a channel change? Is there a reset procedure?
Here is a note that discusses the different ZigBee HA or Light Link channels utilized on SmartThings hub vs. the Hue Bridge…
You may find this entire Topic Thread to be helpful in helping to understand ZLL vs HA in SmartThings:
If the HA network master (SmartHub) can handle all the functions of the bulb, what is lost by not being able to move it back to the LL network master (bulb firmware upgrades from the manufacturer, perhaps?)
NB: The points I’ve made above are based on my limited knowledge at this time; other Community members may join in. More research will be interesting.
Also: The Light Link examples integrated to SmartThings (in various ways) are applicable so far to light-bulbs, but not“Scene Controllers”. Indeed, many of us would like a wider selection of controller devices so we don’t need to rely on the mobile SmartThings App and/or automation. A few Z-Wave controllers have been found to be compatible, but I don’t know of any ZigBee controllers (yet). This paragraph is subject to edits !
Good-luck to us all!
…CP / Terry.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
3
I just found this very short summary of differences between ZLL and HA:
Zigbee Light Link device vs Zigbee Home Automation device
*** Profile ID:
ZLL - 0xC05E, used for touchlink commissioning commands. All other ZCL commands are sent using HA profile.
HA - 0x0104
*** Commissioning method:
ZLL - Touchlink commissioning: an inter-Pan method. The role is to form a network or to add new nodes to an existing network, by finding devices in the neighbourhood according to the received signal strength;
HA - EZ mode commissioning: a network steering and commissioned method focused on the network and device installer. Requires two steps which can also be combined: network steering (forming/joining to the proper network) + finding and binding (discovering and creating source bindings between a specific lists of clusters);
*** Security
ZLL - the architecture is based on encryption/decryption of the network key with a fixed secret key (ZLL master key) or ZLL pre-installed link key(classical commissioning). The network key is generated randomly by the initiator when it starts the network.
ZLL master key and ZLL pre-installed link key are a secret distributed only to certified manufacturers that signed a safekeeping contract.
*** Interoperability:
A ZLL device could be added to a trust centre protected network (HA network) using the touchling commands: Device Discovery followed by Reset to Factory New Request. On receipt of the Reset to Factory new Request, the ZLL device shall leave the network and depending on the device implementation could start a classical commissioning procedure or wait for user interaction.
HA devices could be added to a ZLL network using classical commissioning, only if these devices know the ZLL pre-installed link key.
First of all, great post @tgauchat! A couple of comments/questions…
Do you know this for sure? It’s possible the hue API is making use of the zigbee group and scene clusters natively, which would be in the “bulbs themselves”. If Hue bulbs simultaneously respond, then they are most likely using these native group/scene functions or maybe using an multiple target message broadcast of some sort.
I think this is answered by your next post about the difference between ZLL and HA. To reset a ZLL device, it looks like you need the controller to initiate it; which is why you currently can’t remove a Hue bulb from ST. ST doesn’t have the ZLL functionality to reset the Hue bulbs.
ZLL is a zigbee standard designed specifically for residential lighting. It’s intended that all ZLL certified lights and switches will be able to automagically work with each other without requiring a complex install or pairing process. It’s intended to be super easy for consumer use, no hub (Zigbee “coordinator”) required. That’s why the Connected Lighting Alliance (founding members include GE, Greenwave, LG, Lutron, Osram, Panasonic, and Philips) has adopted ZLL as their standard.
The older Zigbee Home Automation standard can do pretty much the same stuff and more BUT assumes there will be a central hub with each device paired to it through a process zigbee calls “commissioning.”
ZLL does allow for the use of hubs/coordinators as well, but the main point of it was that a hub would not be needed, you’d just screw in a lightbulb, touch one button, download a smartphone app and go.
A device can be ZHA certified, ZLL certified, both, or neither.
Everyhue has a good short post about the difference between a zigbee home automation coordinator and a zigbee light link controller that might be helpful:
NXP labs also has a very good detailed 50 page explanation of how the Zigbee Light Link protocol works for those who are interested in the design side:
Samsung was originally an associate member or trial member or something like that of the Connected Lighting Alliance but since seems to have dropped out as they don’t appear on the 2015 member list. Samsung’s connected lighting products as originally introduced used ZHA, not ZLL, I don’t know what they use today.
TCP lights aren’t certified for either ZHA or ZLL. Since zigbee is an open standard, anyone can build something that communicates using zigbee protocols.
The difference between certified and not certified is that certified means the Zigbee Alliance has tested it to make sure it is truly interoperable with the standard in place at the time of certification. AND if it’s a ZLL certified device, the manufacturer has paid the Zigbee Alliance and gotten the “secret handshake” key to use in their devices so that other Zigbee certified ZLL devices will recognize them.
For example, the ZLL protocol has strict rules about which device IDs get assigned to which types of devices. The manufacturer doesn’t have to do that to just turn something on and off, but if they don’t, other ZLL certified devices may not correctly include the device in clusters or other group commands, and may even have trouble with installs. Again, the NXP doc goes into this in detail.
One more note: GE Link bulbs are not ZLL. They use the Home Automation profile, not Zigbee Light Link. Hue and Cree are both ZLL. This is based on the profile info the various bulbs report to ST when pairing.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
7
Interesting tidbit!.. But they pair with my Philips Hue Bridge exactly as Philips Hue bulbs, as far as I can tell.
Is this because the Hue Bridge explicitly handles HA, or because there is enough overlap with ZLL that the Bridge can’t tell the difference in this instance?
The GE Link and Hue Lux (no color version) use the same inClusters and thus accept the same commands. They would have a different profile Id, device Id, and ZLL bulbs appear to have an additional outCluster; but none of those attributes would affect on/off/dim control as long as the controller can communicate to the correct endpoint.
Thanks–I should have been clear that just belonging to the Connected Lighting Alliance doesn’t mean that all the lighting products from those companies will use ZLL. Consumers still have to check the certification for each individual product. A company may have reasons for choosing different protocols for different devices.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
10
Appreciate the detailed information…
But from a TL;DR perspective, can we make a generalization WRT integration with SmartThings?
Currently SmartThings has not defined any Capabilities for handling Groups of Lights (or Scenes or whatever terminology is appropriate – regardless of ZigBee, Z-Wave, or other type of connectivity in use.
Are Groups of Lights only available in ZLL or also in HA?
SmartThings can manage Groups using it’s own proprietary data structures and interfaces (Shortcut Solution SmartApps, etc.).
In order to be a ZigBee ZLL Certified Controller, shouldn’t SmartThings support ZLL Groups explicitly per the ZLL (or HA?) standards?
ZigBee groups and scenes are general ZigBee features and supported by both ZLL and HA. The big advantage of ZigBee groups is that the hub can send, for example, only one ‘on’ command to a group rather than sending each light in a group the command. For groups with more then 5 lights this is makes a noticeable difference.
The GE Link bulbs are also ZLL certified, otherwise the Philips hub would not let them join to the network (due the ZLL master key).
ST doesn’t utilize the zigbee Groups/Scenes commands because they don’t want groups to be protocol specific and instead relies on its capabilities so that any light can be “grouped” with any other light. This is where the Hue bridge/app might have an advantage in managing groups of Hue bulbs.
I have tested the GE Link bulbs with the Groups and Scene clusters of zigbee via ST, and it works fine. The only problem is that I can’t find a way for ST to send a Group command to multiple bulbs at once. ST commands define the device to be addressed. I think I found the solution using pre-buffered commands and “send_multicast”; but I can’t figure out how to properly format the commands that I send.
I didn’t think the SmartThings Hub is a zigbee certified device for any standard. Just that it uses the open protocol. Is it certified? Usually that’s listed on the box.
Interesting, Based on the posts above it appears that ZLL is designed to be more of a peer to peer network. Also according to the thread noted above on everyhue, you need to be ZLL certified in order to get a linking key and join a ZLL network. This is probably one reason why there isn’t native LL support. It also appears for a LL device to join a HA network, it needs to be discovered and sent a factory reset to began a traditional commissioning process. I really like the hue, but I’ve heard if it drops off the network, it’s game over unless you have a ZLL controller to send a reset. I also haven’t heard great things about the integration of the hue bridge into ST either so it looks as if I’ll have to wait until ST becomes LL certified or Phillips makes a hue that can be reset by cycling power. At the same rate I’m not sure if a hubless environment will ever really catch on.
Technically it’s a hubless mesh network, not peer to peer, because there’s still a distinction between controller nodes (like the Hue bridge) and device nodes (like Hue bulbs).
It’s not that each node can both cue and perform requests as in true peer to peer. Rather in a mesh network each node can pass along information, which is not quite the same thing.
Hue bulb A can’t command Hue bulb B to dim. It can only pass along the dim request that originated with a controller node like the Hue bridge.
The difference in the ZLL standard is simply that each certified device is preauthorized to join the nearest network. The join network password comes installed on the device, and any node can verify it. So you don’t need a hub to authorize a new device.
LIMITED CHANGES
The only reason anyone thought this was a good idea is because from the beginning it was intended to be limited to residential lighting. On, off, dim, and color changes. That’s pretty much it. There’s very little damage a mockingbird device could do even if it was capable of joining the network and issuing commands.
CHANGE A BULB WITHOUT REQUIRING TECH SUPPORT
The use case was simple: to allow anyone to change a bulb without requiring router access or complicated steps. Put in the new bulb, push one button, done. You can keep the bridge in a locked room and still let your teenager put in a fresh bulb when one burns out.
In a true peer to peer network, each node has the ability to command other nodes. That’s not the intent here. You still have controller nodes that you can restrict access to if you want to. Your teenage son can’t use the bulb in his room to turn off the lights in his little brother’s room. But either boy could replace a burned out bulb in his own room with a one button process.
NETWORK CHOICES
So I do think hubless mesh networks make a lot of sense for the residential lighting use case, and I think Hue’s success demonstrates it.
A true peer to peer would likely open up too many hacker options, or just malicious mischief options, for most HA use cases. So I doubt if we’ll see that anytime soon. Maybe once we get biometric authentication and super smart devices.
Of course you only need this solution to begin with if the bulb itself is a node, since it’s the replaceable part. If the node ID is limited to the receptacle, then you don’t have the burned out bulb problem. Swapping one dumb bulb with another doesn’t require rejoining the network. So it’s not clear ZLL will end up as the dominant lighting protocol, it’s not the only way to address the use case.
The ST doesn’t need to become ZLL certified!
The ZLL reset command does not use ZLL master key.
It’s possible for the ST developers to implement the reset feature without bothering with certification. Still it’s hard to do, behind the scenes it’s not just a single reset command which is simply sent to a bulb, but a whole sequence of actions like scanning all channels for nearby devices, collect responses, execute the reset command and return to former operational mode. Tricky to implement.
The main reason I run my 10 Hue Bulbs directly connected to the SmartThings Hub is to extend my SmartThings ZigBee Home Automation (HA) network. Each Hue Bulb is a ZigBee Router and when they are joined to a HA network other HA devices can use them to relay traffic. I have bulbs outside, in the basement and on the second floor and they all work together to extend my ZigBee network. As long as they are powered on!! But if one is powered off usually another one is close by to pickup the traffic.
I have a ZigBee routing tool that maps out my ZigBee network on my PC and it is so cool to see ZigBee devices connected to my light bulbs!!
If the bulbs were joined to the LightLink network they will only act as routers to other LightLink devices. This is a known problem with ZigBee and is going to be addressed in the next version.
Unfortunately, this is true for both Zigbee and Z-Wave. By ignoring features provided at the protocol level and replacing them with pure “software” solution, ST degraded user experience, as can be noticed if you try to create a scene that turns on 10 different light bulbs.
Have you had any problems with your hue bulbs dropping off the network? This is one of the major issues that I see. If the bulb loses it’s connection, there is no way to reset it. The smartthings hub can’t send a reset and neither can any other hub as the bulb is not connected to their network. The only way to restore order is to use lampstealer to reset the bulb.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
20
I certainly feel that SmartThings should support “native groups” of Devices (scenes, fixtures, whatever the manufacturer or protocol calls them).
This could be implemented with a new Capability (capability.lightGroup?), but SmartThings have difficulty representing the same light bulb in both a group as well as an individual Thing. The platform doesn’t know how to represent a Group-Thing (and/or have the ability to handle this in the most effective combination of native HW and SW mixed environment).
!