Native Hue Support

Will Indigo ever natively support the Hue? I know there's a awesome plugin that works just fine for this purpose, but the reason I am curious is because I consider it another technology rather than an accessory, it's more of a protocol like Zwave or Insteon and that seems to make sense that it would be natively supported as it has grown in popularity.

One of the reasons I bring his up is that I have noticed that my Hue lights (using the Hue plugin) react faster than most of my other devices. My Insteon is pretty fast and my Zwave is slower but acceptable, while the Hue is nearly instant. There's nothing wrong with the plugin but since RGBW has been incorporated into Indigo, wouldn't native support of Hue make sense?

Especially as more people incorporate Hue as their only home automation technology, it would seem logical to open a software to that audience. I'm even thinking, based on performance, of replacing Insteon switches/modules with Hue bulbs where possible because of ease, performance and function. If nothing else, when I decide to move it's only a matter of unscrewing some bulbs rather than unwiring a bazillion Insteon/Zwave devices and putting in standard switches.

Just curious.

[jay (support)]

Will Indigo ever natively support the Hue?

The Hue hub? Unlikely. Read on to see why.

I know there's a awesome plugin that works just fine for this purpose, but the reason I am curious is because I consider it another technology rather than an accessory, it's more of a protocol like Zwave or Insteon and that seems to make sense that it would be natively supported as it has grown in popularity.

The technology used by the Hue products is ZigBee Light Link. If we were to ever add built-in support for something else, it would most likely be ZigBee Home Automation and Light Link protocols via a ZigBee dongle. Demand has been relatively low, however, for several reasons I suspect: first, the Hue hub and plugin has sorta made direct light link support somewhat less necessary. Second, ZigBee HA devices (not lightlink) are still on the more expensive side, and with the wide variety of Z-Wave devices available the demand is just lower.

My Insteon is pretty fast and my Zwave is slower but acceptable

I'm very puzzled about this: Z-Wave is almost always faster than Insteon (the underlying protocol runs at a faster rate) and in some cases is very significantly faster.

The Hue hub? Unlikely. Read on to see why.

Not the hub, the bulb itself. The Alexa-Hue Bridge takes care of the hub portion, I am talking about the Hue plugin that talks directly to your bridge and bulbs and allows you to control them.

I'm very puzzled about this: Z-Wave is almost always faster than Insteon

I'm not sure why that appears to be the case. I can tell you that my Fibraro Zwave motion sensors are almost twice as slow as my Insteon wireless (I get they are both wireless and will be slower naturally than wired), but when I hit a Zwave switch to turn on my light it's slower than my Insteon switches.

Especially as more people incorporate Hue as their only home automation technology, it would seem logical to open a software to that audience. I'm even thinking, based on performance, of replacing Insteon switches/modules with Hue bulbs where possible because of ease, performance and function. If nothing else, when I decide to move it's only a matter of unscrewing some bulbs rather than unwiring a bazillion Insteon/Zwave devices and putting in standard switches.

Colorado4wheeler, I think one of the biggest gambles we have going on right now in home automation is the forward march of technology. While insteon may be stale and stagnant in relative comparison technologies like hue and alexa are introducing new capabilities almost monthly. It’s more likely that i’ll be switching out my devices over time for the rest of my life, and when I do move....i won’t want my current constellation of aging obsolescence along for the ride. I’ll need new toys.

[jay (support)]

Not the hub, the bulb itself. The Alexa-Hue Bridge takes care of the hub portion, I am talking about the Hue plugin that talks directly to your bridge and bulbs and allows you to control them.

So your question is answered by my technology explanation as there is no other way to directly talk to the Hue bulbs. The Alexa Hue Bridge has nothing to do with this as it doesn't talk to the Hue hub. The Hue plugin controls the bulbs via the Hue Hub, not directly.

I'm not sure why that appears to be the case. I can tell you that my Fibraro Zwave motion sensors are almost twice as slow as my Insteon wireless (I get they are both wireless and will be slower naturally than wired), but when I hit a Zwave switch to turn on my light it's slower than my Insteon switches.

Wow - my Z-Wave motion sensors (all Aeotec) are almost an order of magnitude faster than my Insteon sensors in scenarios where they aren't directly linked to other Insteon devices. The round-trip to Indigo then to the actual device does add some latency, but implementing ZigBee directly wouldn't help that.

I use SwitchLinc's almost exclusively because I like direct Insteon links, but I do have a few HomeSeer switches and they seem to respond just as fast when manually operated. What brand of Z-Wave switches do you use?

As I said: odd.

The Hue plugin controls the bulbs via the Hue Hub, not directly.

I realize that, just thought that it would be simpler to go straight through Indigo.

What brand of Z-Wave switches do you use?

I think they may all be GE, but I don't really use that many switches as I was often told to stick with Insteon for switches by you and Matt, I just got a few to play with. It's not like I'm waiting 5 seconds for them to come on, but a slight difference if it's not controlling the circuit they are connected to - which is a lot of my home configuration. When it's on the same circuit then it's fine. That's where I compare the Hue bulbs, they aren't connected to a switch either and they are instant, almost zero delay.

Within the whole Alexa-Hue-Amazon-Indigo ecosystem, I’m seeing slower and slower performance lately....along with broken links where indigo works but Alexa won’t. A few days ago, for the 2nd time, I lost all alexa links....the fix being to go to the alexa app, delete the hue skill, then re-enable the hue skill. When that’s happened, I also lose some of my groups now within Alexa and have to reconnect those.

On the plus side, Amazon now has feedback within the Alexa devices so that all you need to do is open up each one and see if alexa reports an error....so you know which devices alexa is choking on.

I have no idea what causes this...if I did I’d fix it.

On another ‘promising’ side, Amazon has added room awareness to the dots, echo’s, shows. I say “promising” because yes, it works.....if you’re willing to wait until the cows come home.

I assume...I’m not totally sure... the sequence of events goes something like this:

“Alexa, turn on the lights”. —> dot sends command to amazon MarkIV super-computer....where far-away spy/software determines you use lightbulbs, determines which dot heard you, asks your amazon data which devices are associated with that particular dot, notifies amazon partner ad agencies to sell you more light bulbs, amazon MarkIV then sends commands to my indigo-embedded bridges, managed by the Indigo Alexa-Hue plugin (I’m currently using 6 bridges) through the appropriate ports...AND possibly to the Hue hub port itself if one or more devices are actually real Hue lights.

The real hue lights light right up and then, within (up to) 20 seconds, some or all of the indigo driven devices come on... usually. Given enough time and my cows didn’t have far to walk.

I’ve noticed that if I address the actual light (turn on the “sitting room ceiling”) it takes much less time.

Is my preception more or less accurate?

What I don’t yet understand is why a simple “alexa turn on the lights” takes so long. Profanity sometimes seems to help but thats also inconsistent. Any thoughts? I’m thinking the delay is in the time slicing given Amazon’s MarkIV kernal and their algorithm needs some bit lube...or some of us just have more than 4 lights.

[jay (support)]

A few days ago, for the 2nd time, I lost all alexa links....the fix being to go to the alexa app, delete the hue skill, then re-enable the hue skill.

That's odd given that the Hue skill has nothing to do with the Alexa-Hue bridge. I personally don't have the Hue skill enabled and just control everything through the bridge plugin. I also don't use rooms so I haven't seen any delays.

I've also not lost any device connectivity in recent months.

Hmmm instructive. I thought i needed the hue skill enabled. Ill disable it maybe there's a conflict.

As i eluded to in my post, i didnt think the broken links had to do with insteon. I think some of my lights have naming conflicts between hue control and indigo alexa hue bridges.

So, if i disable the hue plugin from alexa....there goes my hue color control.

Mine also works fine except for the delays, which have been noticeably worse since Christmas, presumably because there are a lot more people taxing the servers.

Perhaps voice control of homes shouldn’t be cloud-based after all.

[jay (support)]

So, if i disable the hue plugin from alexa....there goes my hue color control.

That's true for setting arbitrary colors. I tend to set the color once (seasonal or whatever) and just leave it alone so dynamic color control isn't that important for me but I get it.

As an example, i lost connectivity this morning first thing. I use a z-wave plug controller to control power to the electric blanket. When i go to bed, I say “alexa, turn on the blanket” and usually it works. This morning, I said “alexa turn off the blanket” and alexa immediately responds with “blanket is not responding”. I gave it 5 tries, same result. Now the z-wave devices isn’t known to the hue hub in any way, just one of the the alexa-hue bridges. But the ‘fix’ was to go to alexa smart home menu, go to the ‘blanket device’...delete it...and then (maybe needlessly) i manually tell alexa to discover devices. Alexa reports “No new devices were discovered.” But then, when I repeat “alexa turn off the blanket” it works. So another lost link. Wish i knew what caused this. I use nothing else in any realm but the alexa-hue bridge, any device named “blanket”. It’s a head scratcher. Same failed link can happen at any time with any device.

How many Amazon Echo / Echo Dots do you have?

I ask because, I have six devices. I have discovered that when you ask an Echo to do something for you (e.g. in the bedroom, "Alexa turn off the electric blanket"), it isn't necessarily that particular Echo that issues the command to the Indigo Alexa-Hue Bridge. There appears to be a preferred Echo that issues the commands. When I get this situation (i.e. "device not responding"), which was happening a lot but doesn't appear to be happening as much (if at all) more recently, if I go to the preferred Echo and ask Alexa the same command, this will then "wake-up" all the Echos that were replying "device not responding" and all goes back to normal.

Obviously, given the above scenario, one needs to know which is the preferred Echo. I have done an update to the Alexa-Hue Bridge that I will shortly upload to Github as a pre-release. This change will enable you to define additional devices of type "Amazon Echo" for each of your real Echo devices. The device is very simple you just name it as normal and in device settings specify the Echo's IP address. Once the devices are set-up it facilitates extra visibility of what is going on in the Plugin. When you issue a command to an Echo e.g "Alexa turn on dining lamp", the plugin will report this request with the additional detail of the name of the Echo (or IP Address) and port the request came from. In addition the Echo device's status in Indigo will change from No Activity to Active and the associated coloured dot from grey to green (for 15 seconds).

With this change, I can now see that for the most part, whatever Alexa device I ask to do something, it is always the Echo Dot in my study that is issuing the command to Indigo.

What I haven't been able to determine (yet) is why once the preferred Echo has worked OK, suddenly all the other Echos work.