They're here! : new Green Energy Battery-free Wall switches for Hue Bridge (Illumra, Busch-Jaeger, etc)

Hi JD, the result are not so good! :sunglasses:

The Zigbee channel of the SmartThings hub is on 24, the Hue bridge offers 11, 15, 20 & the current 25.

There is no way to get 24.

Funny problem.

Hue bridge :

SmartThings:

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.

Can anyone verify this?

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.

3 Likes

What contact did you use?

Support@smarthings.com

I had a request outstanding at support@smartthings.com 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?

Thanks in advance!

1 Like

oh wow, never noticed that. nice!

3 Likes

It sounds like we are mixing apples and oranges here, but maybe I am just confused. :thinking:

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:

https://www.amazon.com/Philips-Hue-Button-Control-required/dp/B07XV1HRVZ/

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:

[OBSOLETE] Hue Accessories and rooms using Hue Bridge (TAP, Motion Sensor, Dimmer Switch) [DEPRECATED]

Green Power Devices on a Hue Bridge with HomeKit

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.

The device I was referring to is an ABB Busch -Jaeger 6716 U-500 Friend of Hue smart switch. All devices mentioned in this threat use this same (EnOcean) Green Power Device (GPD) technology as the base, the physical button is vendor specific.

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.

Unfortunattely I found the answer to my question at NXP’s ZigBee Green Power (for ZigBee 3.0) User Guide v1.1 (nxp.com.cn) paragraph 1.6.

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.

2 Likes

Will this be compatible with the Echo Plus given that it has an integrated Zigbee Hub or it only works with the Hue Bridge Hub?

It only works with hubs which support the green power clusters. There aren’t many of those.

Definitely yes, they work with the hue bridge. But they don’t work directly with smartthings or with the echo plus.

Hi all

Has anyone found a kinetic switch that will work with smartthings yet? Just want to control my lights which have a zigbee module attached to them.

I bought the aurora kinetic smart switch, it didnt work, then i read about green power etc above so undertand why.

All help appreciated!

Ps is it possible to get a non smart kinetic switch and somehow connect the reciever at the switch box and place the switch elsewhere?

Thanks

At the time of this writing, unfortunately there are no kinetic switches that work with SmartThings. :disappointed_relieved:

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. :thinking:

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.

For anyone looking to get these switches working with ST: there is a hacky solution involving “phantom bulb” technique in Hue Bridge. I found it in this Reddit thread and described over there how I made it work with these specific switches.

I do hope that imminent Matter/Thread rollout will improve compatibility across ecosystems and this ends up being a temporary solution.

2 Likes

Yep. Just remember that Webcore, being a smartapp hosted in the free groovy cloud, will stop working very soon once that cloud service goes away, so people won’t be able to use that part of the Reddit post instructions any more. :disappointed_relieved:

As for the green power devices, there’s a brand new option as of a few weeks ago and it’s an even easier method than the hue phantom bulb, although more for on/off than dimming. :sunglasses:

Amazon has now added these as potential triggers for an Alexa routine (not a SmartThings routine). So that’s an easy integration to SmartThings for those using Alexa.

(If someone knows one way or another if the same option is available in Google Home routines, please let us know.)

More discussion on the new triggers:

Alexa adds more routine triggers, including buttons and lights

And if you didn’t know Webcore would stop working with SmartThings soon, see:

The End of Groovy Has Arrived

And

FAQ: I have no idea what Edge is. Is that a new developer tool? (2022)

1 Like

Great points!

Fortunately, the Webcore part of the linked instruction is no longer required, as Smartthings routines can do the same things. That’s what I used to get my set up working.

Does Alexa recognize these switches directly, or also through Hue hub? An issue with these switches and ST integration through Hue is that Hue forwards them as lights instead of switches, and doesn’t forward any events (the light shows as disconnected). Sounds like Alexa works better with them?

I actually have Alexa and have all the devices I need to control available there via Smartthings, so of Alexa in fact can handle signals from the switches, that will likely be a better solution for me.

1 Like

It’s for devices connected to a hue hub. I have a runlesswire “click” switch which is exposed to Alexa routines as 4 possible single press triggers:

Interesting. In a nutshell, it works exactly like other Hue switches get forwarded to ST now. It looks like a bug in RunLessWire <-> Hue <-> ST integration, will try to reach out to the parties and see if somebody can look into this.

1 Like