I have a Conbee on my Zigbee network. It lets you send all sorts of information to the devices. I was able to figure out what group the remote was in and then manually add that group to a non touchlink device. The device was controllable. Kind of a lot of work but it is possible.
Let me see if I got this straight:
- Pair bulb to Hubitat
- Pair Remote to Hubitat
- Link Remote to Bulb
Is this correct?
What Device do you configure the Remote as in HE after pairing?
Once linked to the Bulb, what can you control with the Remote? I assume only the Bulb, since there is no driver that could accommodate the various button pushes . . . .
I think only Step #1 and Step #3 do anything.
I just confirmed that does work. The remote can control my two test bulbs, and Hubitat can control my two test bulbs.
Some wrinkles:
- According to the Zigbee logs, in my case only one bulb is reporting back to the hub its state change when the remote does something, even though both are changing physically. Is this due to the message coming from bulb 2 through bulb 1? shrug
- According to the logs, no events from the remote to Hubitat
- Using the built-in Groups and Scenes app to group my two bulbs, the fact that only one of my bulbs changes state isn't updating the group's state to match. So my toggle rules don't work well. This could probably be fixed, though.
- The remote doesn't know when Hubitat changes the bulb's state, so if the bulbs get out of sync the on/off button needs two presses to get back in sync. Remote seems to be sending an "on" or "off" command and tracking state internally - rather than a "toggle" command (if one even exists).
This makes the whole thing useless for my purposes, but it is interesting information.
That's about what I saw. I think any touchlinked remote would have limitations. The advantage is you skip the hub and get direct control. This is probably why all the Ikea remotes are touch link. No need for the user to program what the remote does. Easy setup but if someone moves to Hubitat then they can't use the remote. Smartthings and Deconz support adding the coordinator to a group so they can use the remotes that only support group messages (if they have a driver).
Smartthings and Deconz support adding the coordinator to a group so they can use the remotes that only support group messages (if they have a driver).
Is there any reason Hubitat can't/won't support this? Has this been talked about elsewhere?
2 Likes
Thank you for that information. His position makes sense - if you're limited on developer resources, you have to pick and choose your priorities, and sane devices with lots of demand make sense to prioritize.
That said, it's a shame the answer wasn't "we'll add inbound group messaging (a core feature), but will leave it to the community to write the drivers".
Are we sure that the remote is using zigbee group messaging? Group messaging and touchlink are not the same thing. If the remote is Zigbee 3.0, it supports more than TouchLink to be sure.
Why would that matter? Also, the Symfondsk remote must be paired to the hub to control speaker volume. You can't pair it directly to the speaker.
The Tradfri Dimmer and Symfondsk remotes works with Hubitat.
It looks like support has been added to Home Assistant: https://github.com/dmulcahey/zha-device-handlers/blob/dev/zhaquirks/lds/ and Support for LDS ZBT-CCTSwitch-D0001 · Issue #209 · dmulcahey/zha-device-handlers · GitHub
They are adding the coordinator to the group of the remote. Until we can do this with Hubutat we are probably out of luck.
This type of remote is seemly becoming more and more popular...and with IKEA now a board member of the Zigbee Alliance. I think this is only going to expand.
At a bare minimum you get another remote to reset ZLL bulbs with at least, right?
I do have to say, after getting mine, the whole one button dimming thing is REALLY annoying. I'll probably never use the remote at all, unless the buttons can be re-mapped. If I want a bulb dimmer, I don't want to have to make it go to max brightness first. I want it to dim from the current level. I can understand one button for Color Temp but they should have taken the preset button and made it the dim button. Or why not simply made the top button on and brighter, the bottom button off and dimmer and the middle two buttons adjust color temp? super strange way to set up a remote.
This is super annoying too. This wouldn't be a problem if there was a dedicated on and off button like, oh, every other remote I've ever seen! Super strange.
Has anyone else noticed that the bulb has an odd behavior at lower levels too? If you have the bulb at the lowest level and turn it off, when you turn it back on, it will come on to much brighter, then dim down to the lowest level. The LEDs in this thing must be super cheap. I've never seen a bulb do that. Usually the lowest level is just the lowest level the LEDs will come on successfully. What do you expect for $4.99 though. Hue, this bulb ain't, I can tell you that.
I went back and got them to price adjust and picked up a few more. The bulbs are a good deal.
I think the Hubitat is filltering broadcast messages. Broadcast packets in parse?
The Home Assistant Zigbee implementation can use the same USB stick as was used on the C-4 so the hardware should support passing the messages.
1 Like
as far as broadcast packets, is it possible that this remote being Zigbee 3.0 might have hope of being parsed?
I think the guys at Hass.io got remote working
In case anyone is curious like I was above, both the bulb and the remote can pair to a Hue Bridge network. The bulb is easy to pair--just reset (6 times on/off), and Hue found it.
The remote is probably Touch Link only (I reset it, then held the power and dim buttons as specified when putting the Bridge in Touch Link mode). Like non-Hue and non-Friends devices, these won't show up in the Hue app, but you can Touch Link then to a bulb (or few) for direct manipulation. Unfortunately, that information doesn't seem to make it back to the Hue Bridge, but the power, dim, and CT buttons all worked for me. The presets (scene?) button didn't work for me--I tried to save a few but it always kept cycling between whatever its defaults must be.
I haven't tried either on Hubitat but see lots of people have above. Given that they work on Hue, I'd probably keep the bulbs there if you have one and don't have a dedicated hub. But it would definitely be nice if the remote could function as a generic button device on Hubitat and free us from the manufacturer's awkward choices (you may notice that there is only one dim button; it cycles down and back around, so good luck getting to 100 without guessing when to stop).
2 Likes
It stops itself at max bright and min bright. It doesn't wrap around. It only goes in one direction. Same is true for the color temp button.
That is the only part of the remote that is great actually. Makes it easier than using a pico directly paired to Hubitat. Hold down a pico using startDimmerChange and you'll blow right past lowest dim level and turn the light off. Happens to me almost every time.
1 Like
Interesting, I guess I got impatient and pressed the button multiple times so it may have appeared to wrap around. 
The startLevelChange thing depends on the device/driver. With Hue Bridge bulbs, it stops at 1%. With directly paired Sengleds, I noticed the same issue as you. Not sure about most others.
Picked up a bunch of these today. Looks like I’ll have a pile of remotes until someone can come up with a way to repurpose these like Pico remotes.
I don't think it's a Zigbee 3.0 related issue. It's the way the Zigbee network stack is configured on Hubitat. We will have to convince Hubitat to make the change.
Given how many of these remotes I have, I'm super-eager to figure something out. I wonder if there's another option using a zigbee USB dongle and a rPi running a proxy/repeater (over wifi) to Hubitat - kind of like the Pico remote enthusiasts are doing with the Lutron Caseta Pro hub.
Anybody who knows more about that have any thoughts or pointers in that direction?
I feel like the weirdness in the button behaviors could probably be worked around by entirely remapping what the remote is sending to what you want to happen... if I could just get button press messages at all.
EDIT: Looks like this is the Home Assistant device handler: Add LDS ZBT-CCTSwitch-D0001 device. by Adminiuga · Pull Request #211 · dmulcahey/zha-device-handlers · GitHub - and Home Assistant certainly runs on an rPi. Looks like I might be re-trying Home Assistant with a less broken Zigbee module than last time - if only to proxy these remotes.
