Newbie- Hubitat Question- Hue Bulb shows no 'Data' for binding

Switches General Discussion
,
#1

Newbie here so I apologize if this is a stupid question.

I have a replacement 2-1 switch that I have imported into Hubitat and set as a smart switch. The Hue Bulb was imported to Hubitat also. These are hardwired together as a single pole.

When following the binding instructions, it advises to go to the bottom of the Hue Bulb and copy or remember the “data” line. However mine remains blank.

The other issue is if I go through the binding process, I can find the switch yet when I go to bind it to another ‘device’ all the shows up are other 2-1 switches, none of the lights. How do I get the bulbs into this secondary section so it can be selected?

Hopefully this is a straightforward fix, I’m just new to all of this and after a lot of scrolling and reading I didn’t see anything similar.

Thanks to this community for all the information that is already out there, I’m just blown away.

#2

Is the Hue bulb integrated directly to Hubitat, or is it on your Hue bridge and integrated via the native or community Hue bridge integration app?

#3

It is in via the hue bridge. I’m guessing that may be the issue? Does it need to be brought in directly or is there a way to swap it over?

#4

It cannot be bound to a Blue if it’s on the Hue bridge. To bind it, you’d have to remove it from the Hue bridge and add it to Hubitat directly.

ETA – I’m binding a couple Hue bulbs to one of my Blues, but it’s a long story why… But truth be told, I don’t notice any speed/response improvement with binding versus non-bound. Presumably, binding is faster but whatever that difference is isn’t noticable to me or my wife.

Point being - depending on your needs, binding isn’t always a slam-dunk win for Hue bulbs in particular - when you take them off the bridge, you lose some nice Hue-specific advantages. Just food for thought.

#5

I enjoy the functionality of the hue bridge. What I’m really just looking to do is have the switch act as an on and off dimmer for the bulb.

I’ve got it into smart switch mode however the 2-1 basically feels like it’s dead in the water now. It won’t turn the bulb on or off. I thought that was due to it not being bound. I can still do it via the hue app.

Thoughts there?

What functionality is lost when you bring it in on its own?

Thanks so much for your help and insight

#6

I use the Hubitat Button Controller app to manage each of my Blues - that’s the easiest Hubitat app for programming paddle taps, holds etc etc.

Inovelli has button mapping reference in their Blues guide for Hubitat on the support site here if you search. I’m on mobile at the moment, so I’m not able to link. I keep a screenshot of that button map on my desktop for easy reference.

2 Likes
#7

So I pulled the light out of the hue bridge. And then brought it in on its own. I was able to bind it to the 2-1 switch and it worked perfectly. In doing that it seems as though you lose the ability to use any of the Hue Ap settings like scenes, easy color changes etc…

Is there anyway to have your cake and eat it too? I’m looking to have the 2-1 function as a normal switch/dimmer, while I’m able to use the Hue app to orchestrate the colors and scenes etc? Is that the Button Controller App?

I did play with that and got sufficiently confused so I went to the above step first. Welcome your input. Thanks!

#8

Not that I know of – you have to pick your poison. When you take it off the Hue bridge, it’s completely cut off from all things Hue.

You can recreate the respective scene/colors/etc within Hubitat and then use the Button Controller app to program the Blue correspondingly.

Before you removed the Hue bulbs from your Hue bridge, did you try just programming the Blue to do what you want with those bulbs?

Or said another way, what is your main goal with binding – what advantage are you really after / what advantage do you think you’re gaining?

If it’s just a speedier response, my experience has been that the difference isn’t perceptible but as with most things, YMMV.

There are most definitely legit use-cases for binding, but IMHO the obsession with binding is kinda overblown… It really comes down to deciding for yourself if losing those bulbs’ Hue bridge relationship is worth it.

#9

The main advantage of binding would be that if the hub goes offline, the switch still controls the bulbs. Like @hydro311 mentioned, the speediness of the response itself may not be noticeably faster depending on your environment, but if your goal is to ensure that the light switch still controls the bulbs (without cutting power to them) even if the hub is down, binding is the way to go.

#10

At the end of the day, all I want is the switch to function as a normal switch/dimmer for the Hue bulb.

And then I can use the Hue ap to do the rest.

This is only so family that visits can use the switch to operate the lights as normal then all the advanced stuff I’ll take care of.

Not going to lie, I’ve never felt so slow about anything until I started diving into smart switches.

#11

So I think you may have hit the nail on the head there. It’s the desire to have the switch control the bulb in whatever situation in terms of on and off functionality.

#12

Gotcha, if that is the goal, bindings are the only way to accomplish it while still using smart bulbs ‘properly’ (not cutting power to them to turn them off).

So in terms of getting best of both worlds, I believe you can still use the button controller app to program scenes off of 2-5x taps/holds on the different buttons to replicate desired functionality. It’s not going to be the same and unfortunately you do lose the ability to control it with the Hue app, but that might be what you’re looking for?

#13

Although I’m fortunate to have extremely reliable power and internet service at my house, I do have my bathroom Blue bound to my two bathroom Hue bulbs as a must-work backup in case of hub outage.

That Blue’s day-to-day functionality is driven by Button Controller rules (including behaviors recreated from the bulbs’ old configuration in Hue app), but if hub goes down, the binding at least enables us to turn the bulbs on/off from the switch.

My intent wasn’t to spook you away from binding, but if this is all new to you (Blues and Hubitat), binding can be an additional setup challenge since you have then to account for taking those bulbs out of Hue on top of everything else. It’s obviously do-able, but just more to deal with setup-wise.

2 Likes
#14

I’m putting my Hue bulbs (latest generation) on the Hubitat hub and for critical lighting areas I’m doing direct binding.

What I’ve found however, is that changes to the bulb state through the binding (i.e. from the switch) is not being sent back properly to Hubitat. I’ve got some workarounds but that’s not ideal.

I tried both the Advanced Zigbee RGBW and the Generic Zigbee RGBW drivers, the Generic seems to receive an update from the Hue but whatever the message is it doesn’t do anything with it. The Advanced doesn’t seem to receive anything.

From what I have read, the later Hue bulbs (with bluetooth) do support reporting so I would have thought this should work but my Zigbee knowledge is very limited so far!

I have to agree that even without direct binding, I find the responsiveness really fast but ideally I want the switch to work if the hub is down for safety.

#15

If you find this answer, patent it lol – I will happily pay royalties… We’ve searched hard and long for this and what it boils down to is that Hue wants to play nice with us and allow us to pair directly to their hub.

Long story short, we were presented with two options when this first came out:

  1. Hack our way past their encryption process
  2. Tell people it’s not possible to pair directly to Hue

While #1 seemed like an interesting path and one that I think others take, ultimately it’s not a long term solution because I’m sure Hue could change their encryption and we’d be back to square one. Meanwhile we’d be stuck with a lot of upset customers (rightfully so).

#2, while it stinks, hopefully leaves the ball in the customer’s court to write into Hue and/or cause enough commotion that they want to work with us.

I have had multiple meetings with them, email correspondences, etc, but they ultimately said, “we don’t need that solution, we already have one and it works just fine. Plus, we don’t have the resources right now”. They are referencing a switch that uses EnOcean technology and no wires and no batteries to function. It’s a cool switch, don’t get me wrong, but there are definitely limitations to it that I believe our switch covers.

–

I, like you, love the Hue app and it’s always a struggle for me to pair Hue bulbs outside of the app. Just seems like a huge waste of money – why not just get a cheap Zigbee bulb and call it a day? I like the Hue bulbs because they’re well built and I like their app… but man, do I like the ability to directly bind them to our switch. It makes it so much easier than using button control.

Button control works, but when the hub goes down, you’re out of luck (on some hubs – in my case SmartThings). There’s been times when the internet went out and I could not control any of my bedroom lights because I used smart bulb mode + scene control.

Anyway, done ranting… this has been a sore subject for me too and it’s annoying. I really hope we can get through to Hue that it benefits both of us to allow us to integrate and I’m hoping Matter will solve this, but I’m also not holding my breath.

1 Like
#16

Shoot, I should’ve read all the comments before responding – this is exactly what I do :slight_smile:

Outdoor walkway and entry lights = scene control bc they’re mostly on a timer and I never need to dim them nor do I care too much about speed.

Interior lights (w/a few exceptions) are mostly directly bound because I may need to dim them and, at least with SmartThings (I know Hubitat does not have this limitation) you can’t do a hold/release to mimic dimming, so binding allows for dimming, plus the LED bar stays in sync better.

1 Like