Will Smartthings ever support ZGP "friends of Hue" devices?

Dear all

Recently i bought a pile of busch jaeger devices believing that they would work with ST. Devices are produced by Lab3D for the LK fuga buttons.

I didn’t know there were different zigbee standards, but this is my experience:

Anyway i learnt quickly that these buttons i bought only use the ZLL zigbee Green Power standard while ST only support the ZHA zigbee.

A bit more info here: They're here! : new Green Energy Battery-free Wall switches for Hue Bridge (Illumra, Busch-Jaeger, etc) - #29 by JDRoberts

The devices work fine as “friends of Hue” devices in the Hue bridge. And here comes the strange thing. I can pair the Hue bridge with ST either through LINK or CONNECT. Devices are transferred fine to ST except the “friends of hue” devices. Sometimes they show up… if they do… then they appear offline and non responsive. But mostly they don’t even show up in ST.

So, my hope was to use the Hue bridge to connect the ZLL devices but this doesn’t even work.

My question, will ST ever support ZLL and “friend of Hue” or will ST ever support “friends of hue” through the connect option to Hue bridge?

@JDRoberts you are most likely my only hope on this… :slight_smile:

Late edit: ZGP added to title, since this is not supported by ST. ZLL is. See discussion below.

1 Like

I think it unlikely that smartthings will add the green power commands to its own Zigbee stack, but I don’t think it matters as long as you are willing to use a hue hub to bridge them.

There is already a community-created edge driver that can bring in a number of these devices. This should be the most feature-rich integration. But this does require that you have a SmartThings/Aeotec hub.

[ST Edge] Philips Hue LAN [BETA]

Alexa can also now use many of them to trigger Alexa routines, which can give you some partial integration that way. (You still need the hue Bridge, but that would be an option for people who don’t have a smartthings/Aeotec hub.) I myself am already using this method with a few green power devices, including a friends of hue switch.

Here is a screen from the Alexa app (not the smartthings app) for creating an Alexa routine (not a SmartThings routine) using a Friends of Hue switch.

Finally, once both parties have full matter support, there may be a possible matter integration as well. If so, that would likely bring in more devices than the current official integration.

So you can use them now, it’s just not a full integration, and I don’t expect that there ever will be, unless you count matter as that. But it’s a lot better than it was when they were first introduced.

Do you know how different it is compared to the standard already in ST?

Similar in that both work by talking to the hue bridge over the local area network.

Very different in that the community-created driver has way more features. It can import scenes and rooms created in the hue app. It handles groups in a much more efficient way so you don’t get the popcorn effect. It can handle many of the accessories that are connected to a hue bridge. It’s really nice work. :sunglasses:

By the way, I’m seeing a lot of confusion about the Zigbee profiles, so let’s clear that up to avoid any additional future confusion.

Originally back in 2014 the SmartThings hub supported one of many different Zigbee profiles: ZHA 1.2, the Zigbee Home Automation profile.

ZLL, or Zigbee Light Link, was just coming into use and was only intended for smart bulbs being used in a set up which didn’t have a hub. under the specification, every ZLL device had to also be able to fall back to the ZHA profile if connected to a ZHA hub. So there was never an issue of smartthings “not supporting ZLL”— it didn’t have to.

Separately from that, the integration between a hue bridge and a smartthings hub has never been a Zigbee connection, and still isn’t. it’s over the local LAN, or it’s cloud to cloud. The hue bridge creates its own little Zigbee Network for the devices connected to it. The smartthings/Aeotec hub creates its own Zigbee network. So they aren’t using Zigbee to talk directly to each other anyway.

One of the other existing zigbee profiles was the “green power“ profile, which was used for batteryfree devices. It was mostly popular in Europe. The Philips hue bridge included the green power Zigbee stack, which they used for their own 1st generation tap button. Smartthings did not include the green power profile.

The next thing that happened was that the Zigbee alliance came out with a new profile, which was intended to unify some of the existing profiles. That included ZHA, ZLL, and the green power profile, but it was left optional for whether certified Zigbee hubs included the green power command support, or not, and most of them didn’t.

Most smartthings hubs were updated to Zigbee 3.0 about two years ago as was the second generation Philips hue bridge. They still don’t use Zigbee to talk to each other, though.

ZLL and ZHA were both dropped as independent profiles.

So…if the light switches that you bought are current models, they are very likely to be Zigbee 3.0, not ZLL. But if they use the optional green power stack, they will work with the hue bridge, but not directly with the smartthings hub.


OK, so that’s all the different Zigbee issues. The smartthings hubs are now Zigbee 3.0 certified and they can handle all the regular ZLL devices, no problem. But they don’t support direct connection with green power devices.

And the ST/Hue integration isn’t using Zigbee anyway, but it doesn’t show the greenpower devices either. that’s because of an entirely separate issue: what was included in the integration that was written by the smartthings staff working with the Philips hue staff.

And for reasons unknown, that project decided not to send messages about the greenpower devices from the hue bridge integration. They Certainly could have, but didn’t.

Just last month, the greenpower devices showed up in the Alexa/Hue integration as available triggers for an Alexa routine. I’m guessing that had to do with work being done for matter, but in any case, it was nice to see.

Meanwhile, the developer for the custom edge driver has been working on getting information for devices linked to a hue hub into smartthings through that custom edge driver. The switches have taken longer than the motion sensor, but he has that in alpha testing now. So I do expect that to happen pretty soon.

I hope that helps clear up some of the confusion and the terminology. If you could give us the model number of the devices that you bought, I can tell you whether they are in fact, green power devices or not.


Thanks for the outline. Nothing new to me and I know ST and Hue talk tcp/ip not zigbee. But for many others this is most likely a perfect basis for knowledge.

I’m very sure the devices are green power only. The supplier says so. A few links below. The homepage says model ZGP2801K4-FOH-E

1 Like

Thanks for the details.

Yes, that model is a rebranded Sunricher device, and is indeed using the Green Power addressing scheme, which at present is only handled by Hue devices.

It’s technically possible under the Zigbee 3.0 specification to route green power messages through other Zigbee 3.0 devices to a device that can understand their messages, but that’s not very useful to us since the Hue bridge which can understand the green power messages doesn’t share a Zigbee network with SmartThings. So in practice that just means a Hue light bulb on the same network can help pass messages from a Friends of Hue green power switch along to a Hue bridge.

But the good news remains the same. Hue does share the green power devices through some of its integrations, such as HomeKit and (as of December 2022) Alexa routines.

It does not at present share the green power devices through the official SmartThings integration, but it looks like there will soon be a community Edge Driver that can do so (as of this writing it is still in alpha testing).

And you could use Alexa routines now for partial integration with SmartThings if desired.

We will just have to wait and see if Hue’s Matter implementation adds a way to expose these switches to SmartThings through an official integration or not.

The Zigbee Green Power specification does allow for supplemental battery power, as this device has. But those still use a different addressing format than other Zigbee 3.0 devices, which is why they can’t talk to a SmartThings hub directly.

I can add a detail: as of now jan 14 2023 the ST Hue EDGE LAN driver alpha version allows you to use the Busch Jaeger devices in ST through a Hue.

  1. Get a Hue and Connect the ZLL device to Hue
  2. Get the EDGE driver
  3. Connect ST to Hue - this will currently give 2 connections to Hue.
  4. Delete the ST connection established by Samsung. Only use the EDGE driver
  5. Your switches are now available under “No room assigned” in ST

Some benchmarking: a Tradfri IKEA directly connected to ST has a delay from you press until light goes on of 0.2-0.4 sec… the ST Hue link has a delay of 1-2 sec and more often 1.3 sec.

A question to @blueyetisoftware, I don’t know where in the feed chain of pressing until we get light that the delay is buried. My devices are on the same LAN GB switch. Can we expect quicker response at a final release of the EDGE driver?

1 Like

Please don’t refer to these only as a ZLL device, it’s confusing. SmartThings doesn’t have any problems with 95% of ZLL devices, with or without a Hue Bridge being involved.

The issue is with Zigbee Green Power (ZGP) devices. Those might be certified as ZLL, Zigbee 3.0, or just plain Green Power, but it’s the Green Power message format that’s the issue. Thanks! :sunglasses:

1 Like

Very good news! Thanks for letting us know. :sunglasses:

For those who haven’t been following the whole conversation, this is a community-created edge driver written by @blueyetisoftware . (Like all Edge Drivers, you must have a SmartThings/Aeotec hub to use it.)

Information in the following thread:

[ST Edge] Philips Hue LAN [BETA]

If the light is a zigbee device, you’d be better off connecting that to the same zigbee network as the switch (e.g. Hue Hub) and letting that hub turn the light on. That would allow the hub to turn the light on immediately. The driver would still sync over the resulting light state if you wanted to know that in ST.

If you run things through the driver, there is a delay caused by the Hue implementation. This is from their docs, but it basically says that events coming from the Hue hub are delivered in 1 second buckets, so it isn’t realtime.

There is a 1 second rate limit on the amount of event containers the Bridge will send. If the same property has changed twice within that timeframe, you only get the last state. If multiple resources have changed within that timeframe, then you will get multiple events grouped in a single container.

Leaving out any delay in the driver code itself…

Switch --> Hue Hub --[1 sec bucket]--> Edge Driver on ST --> Light


Switch --> Hue Hub --> Light

The Edge driver will never reach the performance of a pure zigbee network due to this latency as well as the time to run a network stack over LAN. However, if you have to control a non-zigbee device or want events from sensors (temps, lux, motion, etc.), then the driver makes that possible.

1 Like

I currently cannot get double press to function? Is this the reason?

I agree this is the most optimal… i just like to keep most automation in the ST and if i start pooling more lights in the other network, I will most likely loose some coverage (zigbee signal long distance routing)… which i experienced before.

Noted. ZGP from now on.

1 Like

Yep you are right. But the hold - which seems to be supported - doesn’t fire.
It clearly supports both toggled down and pressed ( toggled up). But hold - no - despite its in Hue.

The alpha version is taken down and the beta doesn’t include switch functionality as of jan 26th. Waiting in patience for next release. :stopwatch:

1 Like