Not necessarily true. I have several Zigbee 3.0 devices on my v2 hub. The ZIgbee spec says that a 3.0 device needs to be backwards compatible.
Why are you concerned about Zigbee channels? Are you having interference with the hub and your wifi router?
If you’re having a problem getting that Niko device to join your ST hub, it’s not a Zigbee channel issue. It means there’s no device handler available, or there’s a device handler available but it’s not being picked up properly because the device’s “fingerprint” isn’t recognized.
The reason your Hue bridge found it is because, well, it says is for Hue system.
The new “friends of Hue” Battery free switches are kind of an odd design as they Are using Zigbee green power, not the full zigbee 3.0 clusters. In order to save energy, these are teeny tiny pulse commands. And so far most of these devices have come out working only on a choice of two or three of the ZLL channels. (See the Illumra Details above in post #14.)
Since smartthings also used the ZHA channels, It’s quite common for a smartthings hub to be on a zigbee channel like 14 while the switch is on 25.
So adding one of these green power devices is not like adding a lightbulb which will find the right channel when it joins the network.
While zigbee 3.0 itself is backwards compatible, there are some exceptions for devices which would have been green power profile devices prior to Zigbee 3.0. (And of course there’s also a touch link issue, although that doesn’t apply to these particular devices) In particular, the manufacturers of green power devices are allowed to limit channel changes to manual touch patterns rather than making the device smart enough to do it on its own, which would require power the device doesn’t have.
All of which is to say that first before you do anything else you have to make sure that the channels match for these green power devices.
That is unfortunate. It does happen, there are several Zigbee channels that the smartthings hub can use which the hue bridge cannot. And in order to change the Zigbee channel for the smartthings hub, you have to factory reset it and you have no control over what you get the next time. You might get one you can use, you might not. You might even get the same one you had before.
So I don’t know if it’s worth it to you to pursue this, or if you would rather just use the switch with the hue bridge.
Yes, support can. Just finished going through the process… support initially pushed back, but I kept on them and it was completed with very few issues. The only gotcha I’ve found is the old ST presence senors don’t support zigbee 25.
I had a request outstanding at firstname.lastname@example.org to change my ZigBee channel from 11 to 25. Yesterday it (suddenly) appeared my channel had been changed :-), but it’s also possible from now (firmware version 000.032.00012) to modify the channel by yourself selecting My Hubs - View Utilities - Zigbee Utilities - Change Zigbee Channel.
Now my next point is to get this Green Power Friends of Hue smart switch enabled. This seems still an issue, although I was under the impression it should work after this channel change.
Working through several others threats and despite several people to write device handlers, it seems that ST does support Zigbee 3.0 including ZLL, but does not (yet) have a required GPS (Green Power Sink) implementation. This doesn’t seem to be a requirement for certification but it’s required to match/map GPD commands to instructions/scenes to other devices. That does make sense. Though now we have to get this on the roadmap, so where is the roadmap/request for input?
Other question. Would it be possible to ‘implement’ the sink functionality with a ST SmartApp?
In that case I would need, initially, to add my Friends of Hue smart button to ST. So far device pairing mode does not see/receive any pairing requests, no Live logging events or Hub events available.
The smart button can be paired with a Philips Hue bridge, but even then it won’t appear in ST as other device attached to the bridge do. Anyone experience in this area?
It sounds like we are mixing apples and oranges here, but maybe I am just confused.
I am not aware of any “friends of Hue smart button.“ There is a Phillips hue smart button, but it is not a green power device, it has a battery. So it would be off-topic for this particular thread. If that’s the one that you were talking about, please start a new thread for it and we can discuss what might be possible.
This is the one that I am referring to:
If there is instead a green power smart button from another brand, please let us know the brand and model. In that case, it should run into the same issues as the “friends of Hue“ batteryfree Switches.
Green Power Devices and SmartThings”
If there is a way to get around the missing platform features, it would be with a DTH (device type handler), not a smartapp. You would have to be capturing the raw message stream from the device and then convert it to somethings smartthings could understand.
However, before you can do that, you have to have connected the device to your smartthings zigbee network even if it’s just as a “thing.“ And my understanding is that that is not possible with green power devices right now. If you can’t even connect it as a thing, then there’s nothing you can do just with code.
There is an additional issue which is that green power devices, unlike most others Zigbee profiles, do not check in on a regular basis because they don’t have any power until someone presses them. So even if you do get them to add as a thing, one of my concerns would be that it would be marked as “off-line“ until there is official support for this stack. That might make them unusable with SmartThings.
My guess would be that you can connect the smart button, which again, is not a green power device, as a thing, but you cannot connect the batteryfree devices at all.
Green Power Devices on a Hue Bridge without HomeKit
There is another possibility, which some people have done with the hue tap (another green power device). That is to connect it to a hue bridge and then poll the bridge “heartbeat“ for activity. But for some technical reasons you probably also have to have a Hue motion sensor connected to that bridge and this method has not been very reliable in the past. And unfortunately that method seem to have broken about a year ago. But here is the link to the thread if anybody wants to take a look:
The most reliable method right now would be to use homebridge to expose your smartthings devices to apple’s Homekit and then use HomeKit to create rules for the green power devices. But that’s a lot of work and requires an additional server. It’s not something I would recommend just to get those devices, it’s only something to consider if you are already using homebridge.
Hi Robert, thanks for the exhaustive feedback and explanations!
I see it was also you who mentioned in another threat that a GPS (Green Power Sink) is required and not yet/currently implemented in SmartThings. Therefore, I was looking for a/the roadmap and/or an official (uservoice) place to put this on the (priority)list, because (lots) more people are looking for this functionality.
At this moment I own a Philips Hue Bridge (PHB), acquired for testing purposes. Other Zigbee devices, once connected to this bridge, are discoverable on ST, but not this Green Power Device (GPD). Any integration with other devices including scenes therefore becomes useless.
I don’t think polling the bridge won’t work either, I’m not looking for device existence/health/status, I need (device/scene) triggers to be forwarded to ST.
I do understand when ST sees no heartbeat and/or will be unable to ‘health check/poll’ the device, it’s put it in an ‘offline’ state. Though I think it’s possible to disabled health checks in a DTH, not sure what that means for the status :-). From the GPD perspective it will not be able to except/execute any commands anyway, so why bother. It’s no more than a (uni-directional) button, once pressed/held, some other device(s) is assumed to respond and that’s where the GPS comes in.
I also understand a DTH is required for a GPD, at the and it is a device. Several people started developing one to no avail. But, to my understanding, as long as these GPD’s are undiscoverable by the platform why write a DTH. As mentioned, I use the same pairing sequence as with the PHB on the same channel (PHB is off), but nowhere any log records for this pairing request for the Thing …
Again, writing a DTH makes no sense and I assume more is needed at a lower level in ST.
A Green Power Sink (GPS) is indeed an GP infrastructure requirement. Before nodes can operate using the ZigBee Green Power feature, they must be commissioned to establish their relationships with each other. Therefore a (one) GPS must be commissioned for pairing GPD’s and maintaining a table. A GPD and GPS can be combined in a so called Combo Basic device/node, in this case implemented on the ST Hub.
Without this lower level ‘component’ in ST, building a DTH makes no sense.
So we have to wait for ST to put this on their roadmap/priority list.
Implementing a GPS would be a differentiator for SmartThings. It’s pretty hard to replace dump switches with smart controllers and dip-switched into the same outlet. In Europe it won’t even fit at all. Because these (GPD) buttons have no body, it’s much easier to replace, putting the GPD on top or anywhere else. Samsung might even consider building them, though now I’m getting to commercially involved.
At the time of this writing, unfortunately there are no kinetic switches that work with SmartThings.
If the Zigbee module that controls your lights works with a Hue bridge (for example, several Gledopto modules do), then you can get a parallel means of control that way.
Connect the light module and the kinetic switches to the hue bridge.
Connect your Hue account to your SmartThings account.
The kinetic switches will never show up in your ST account, but the light will, and the switch can still control the light as well.
But as always, the first rule of home automation applies: “The model number matters.” We’d need to know the brand and model of the light module as well as the intended switch to know if this will work.
Alternatively, if you’re just looking for a “place anywhere” switch that WILL show up,in the ST app, there are several battery operated models that will and can be used to control any light on your ST account. Some look just like a regular switch. But I don’t know if you’re interested in ones with a battery.
We would need to know what country you are in as the device selection does vary.
Sorry, I found this confusing. If it has a receiver, it’s a “smart switch”even if it’s not a smart switch that can communicate with SmartThings.
If you are asking if you could have devices from two different platforms controlling the power to the same ceiling fitting, it’s possible, but they won’t be synchronized, so turning one off would cut power to the other, making it then unavailable to that platform. Or at least it would make it so the other one could no longer turn the light back on until the other one was on again. I don’t think you would get the results you want unless you use an intermediary like the Hue bridge I mentioned.
With an intermediary, there’s only one device turning the light on and off, the Zigbee module you already have or another similar one, but a switch can send a request to the intermediary (in this case, the Hue bridge) or ST can send a request to the intermediary, and it is the intermediary which then sends instructions to the Zigbee module, so everything stays in sync.