I have a Hue on my ST network. I’m not sure where in my house would be considered out of direct range, but it works from anywhere in my house and garage where I would normally have Zigbee coverage.
It’s not part of my ST network. It’s rooted and I’ve been tinkering with it.
Yes it does and I do.
This is an assumption that it operates on all ZHA channels, but it works on my channel 14 and another hub that I don’t recall the exact channel of, just that it was not one of the ZLL channels. If I recall, ZLL uses 11, 15, 20 and 25.
My technical knowledge of Zigbee isn’t 100% as this is just a hobby, so excuse me if this is a silly question. Can you bind to a device endpoint that only implements the client side of the cluster such as the remote? It seems to me that the remote is looking to bind to an end device implementing the server side of the on/off and level control clusters, which Wink does implement. It seems like the remote, as a controller, is expecting to be doing the binding, not what it sees as an end device.
Hey, I did test this again when I was home for lunch. My Links (save for one) report on/off within about 5 seconds of being turned on by the Lutron remote. I had one that did not. Resetting the bulb using the “blink” method and then re-pairing the device (no need to delete the device beforehand) caused it to start reporting again.
My guess is it didn’t receive all of it’s configuration commands when I redid that fixture. I’m using the community device type located here: https://github.com/constjs/SmartThings-Devices/blob/master/ge_link_bulb.device.groovy which is more or less the same as the ST published version, just with the nice multiAttribute tiles. Perhaps try resetting the bulb and re-joining.
You bet you can that’s the whole idea behind binding. You bind client side clusters to server side. You can bind just about any cluster to the hub as it just receives the packets and forwards it onto that device’s parse method.
Just as an FYI there are two ways you can setup a bind. There is a end user bind where you push a button on the two devices that need to be bound to each other. They send a list of their clusters up to the coordinator and then the coordinator matches client to server clusters and sends back down a bind command to the correct device. The SmartThings Hub supports this and I have used it several times to bind switches to plugs keeping the traffic local. This binding process does not require anything from the SmartThings cloud, no custom device type or anything. Another variant of this is the bind if identifying command. So the way this works is you tell a device to identify its self and then send a bind if identifying command to the coordinator. I have used this to directly bind a 3 button ZigBee switch to a Hue bulb.
The second way to bind a device is how your doing it with the configure method inside the SmartThings custom device type. Your sending a command to the devices radio telling it to bind a cluster to a hub. If the device supports binding for that cluster then bang it will record the hubs address and send reports to that bound address from now on. What the hub does with those reports is up to your custom device type.
The coolest thing is when you have two devices directly bound to each other like a switch to a light the traffic never leaves your ZigBee network. You Hub can be completely turned off and as long as there is a ZigBee router powered up the two devices will still work
Good to know. I figured that the remote was seeing the request from the hub and refusing to bind due to it not having a server to bind to for that cluster (basically saying “nope, you’re not a light”). The same request sent by the Wink hub from the CLI succeeded (I assumed) because it advertises that it supports 0x06 outgoing/server.
Do you have any publicly available code that would be a good example of the other binding scenarios?
An end device bind doesn’t require any code on the SmartThings side its all in the ZigBee stack. I have code but its firmware, specific to my hardware.
If you want more information on an End Device Bind take a look at section “2.4.2.2 End Device Bind Overview” on page 95 of the ZigBee Standards guide. Its a bit dry but it is the spec so your getting it straight from the horses mouth! Here is a copy of the ZigBee spec: Intranet DEIB. This PDF is not from an official ZigBee site you may want to download the official document from ZigBee.Org. You will have to fill out a little form with your information and they will send you a link but its free.
I’ve got copies of the specs and yes, they are a bit dry. I’m content writing code at the ZCL layer for now
Not to derail this thread any further… I do wish we had an option for more verbose logging; it’s tough to understand what’s actually happening (or not, in this case) when you can’t see the entire dialog between devices.
I got the remote talking with the Hue bulbs again without stealing them off the bridge.
Hope this helps someone else, even if it is basic.
When I first opened the Lutron Connected Bulb Remote, I tried to pair it to the Hue Bridge by telling it that it was one of the new 4 button Hue Dimmers (Not available yet, but they are configurable in the App). I forgot that I had done that, so when I started playing with the remote as a 4 button shortcut device, the remote must have been switched over to a different mode (Zigbee HA?) and it stopped sharing the lights. It would just steal a light instead of sharing it.
I remembered I had tried setting it up faking a Hue Dimmer, and when I tried that again, it worked perfectly.
I factory reset the Lutron Connected Bulb Remote (Buttons 1 + 3 for ~20sec), then opened the Hue app and went to My Devices, selected the Hue Dimmer, Option 1. It starts looking for the remote and says to check the remote (Hue Dimmer) for an orange light. At this point, I held Button 1 on the Lutron Connected Bulb Remote. It started flashing Green like it was pairing, and did a flash sequence to show it succeeded. The Hue App never sees the actual Hue Dimmer, so it thinks it was not successful, but the Lutron remote will now pair with a bulb directly and leave the bulb connected to the bridge.
TL;DR, Pair your Lutron Connected Bulb Remote through the Hue App as a Hue Dimmer.
Wanted to update this thread with my experience with the Connected Bulb Remote, my Cree bulbs, and ST. I don’t have a wink, just ST and I was looking for a reliable way to wall-control all the lamps in a room (rather than having to unlock the phone, get into and app, etc). I had tried the z-wave 7 scene controller and found it to be too unreliable to deploy around the house. This remote is a great solution - I used the wall mount in one room and it looks great. I’ve got it programed for another room and plan on deploying it in two more rooms, all of which will be wall mounted for four total rooms. Others in this thread were extremely helpful as I figured out programming for the remote with ST.
As earlier posts suggested, if you take the remote out of the packaging and follow the directions for pairing your Cree bulbs to the remote (holding the top button for 30 seconds near the bulb), the remote will steal the bulbs from the ST hub so they can only be controlled by the remote and not the hub. I wanted to control both. So, I reset the remote (holding top and bottom buttons for 30-45 seconds), then I put ST in discovery mode and joined the remote to ST (holding the top button for about 30 seconds). Note that this tripped me up at first because ST doesn’t recognize it usually as it would other things so I opened live tracking and watched for the remote to be seen and then stopped the joining process. The remote appears under unconfigured things and can’t be modified in any way and doesn’t show state, etc but it can be added to a room for what that’s worth. With that out of the way, I then took the remote over to each bulb that I wanted to control with the remote, and, with the bulb on and the remote within a couple inches of the bulb, I joined the bulb to the remote (holding top button for about 30 seconds until the bulb flashes). Now, ST can still control those bulbs, but I’m able to use the remote as a secondary controller mounted on the wall for a 100% reliable secondary controller. It is a perfect solution for my house.
The only issue is that, as others said earlier on this thread, in this configuration with ST and Cree bulbs, the bulb status is not updated in ST when state is changed on the remote. This is really only an irritation but does become an issue if you’ve got a routine (like “Sleeping” which turns off all house lights at night) because even though the routine is programmed to turn off those bulbs, it doesn’t actually send an off command if it thinks the lamps are already off. Here’s hoping ST officially supports the remotes soon so we get state changes and this issue is eliminated. Otherwise, the benefits of this solution for my home are great - reliable wall control of lamps in a room - we’re really happy with the remotes.
I did a little packet sniffing on this device. It pairs to the bulb using ZLL Commissioning (touchlink) and sends all commands using it’s unique group number. It does not seem to support any endpoint binding, unfortunately. It would respond with success to a bind command, but it wouldn’t send anything other than a group multicast when a button is pushed.
I don’t think there’s any way right now to configure SmartThings to accept a group multicast packet.
I just picked one of these up at my local Home Depot and I was able to get it to pair with the ST Hub v2. It only recognized it as a thing and doesn’t display anything in the logs. I moved over from Wink to this new Hub for the local control and I have 3 Lutron Caseta switches and a pico remote that won’t work.
Lutron Connected Bulb Remote: Secondary controller that does not report back the the SmartThings hub, but can toggle zigbee bulbs that are also controlled by SmartThings
That’s all that’s going to happen for now, smartthings to recognize it as a thing. That’s important, because it will then allow you to have the remote control individual bulbs which are also controlled by smartthings so you’re going to get to parallel means of control. However smartthings will not know what the lutron connected bulb remote did, so the status will be out of sync until the next time that smartthings happens to poll that bulb.
If you do not pair the Lutron connected bulb remote to smartthings, then it will have a different network ID than smart things does and it will probably steal your bulbs from smartthings altogether. That’s a worse result.
Pico Remote: does not work with SmartThings
The pico remote is not going to pair to smart things, and is not going to work with it. There are other remotes that you can use that are similar, in particular the Aeon Minimote, more about those at the end of this post.
Lutron Caseta Switches: cannot integrate directly with SmartThings. You can use the IFTTT integration, but it may have lag
Smartthings does not support the LUtron Caseta protocol. So there’s no way to pair these directly to SmartThings. They do both have an IFTTT channel, and that works pretty well, but you may have some leg.
There is another method if you have a Staples connect controller but that method does not work with wink as far as I know. And it’s still indirect anyway.
Remotes that do work with SmartThings
There is a topic that lists the remotes and buttons that work with SmartThings. Those can be set up to controls zigbee bulbs or Z wave switches change modes or run routines. You’re still stuck with indirect connections for the Caseta lights though.
Thanks that is good information. I have been lurking around for 3 days now and I understand the reasons why my switches and picos won’t work. Just means I’ll be running dual hubs for now. I actually went to Home Depot to get two GE bulbs and saw this remote. The thought process behind getting the remote was that I could get these and and have the look and functionality of the picos but using zigbee. I was hoping that it would be simple for ST to add these to the hub but looks like lutron made them not standard if I’m understanding this thread correctly.
They’re perfectly standard for zigbee as a handheld remote. The Wink integration with status update is something special that those two companies agreed to. Hopefully SmartThings can set up the same arrangement sometime soon.
I migrated from SC to v2. Fortunately I have only 1 Caseta switch and several pico remotes. You are able to unpair or reset the remotes and pair them directly to the switch. This works for me now until ST supports Lutron or I decide to invest in a new switch.
