Hue Integration?

[jkmonroe]

So I have been reading the forum for days now, trying to get a feel for how Hue is (or can be) integrated with the ISY, and I'm a bit confused.

 

As I understand it, you basically interact with the Hue bridge by formatting the URL in order to accomplish what it is you're attempting, right?

 

So for example, if I wanted to call a scene, I can save a network resource somewhere that has all of the formatted URLs for recall.  But how do I call that?  Can I link it to a keypad button as a scene or a program?

 

There is also something about the Polyglot rPi thing that I don't fully understand which supposedly has Hue support baked in.  I do have a couple of rPis laying around doing nothing if that is what I need.

 

I don't have the largest Hue install out there, but I am currently at 39 bulbs.  I am hoping to replace my Taps and Dimmers with the 6 and 8 button Insteon keypads.  Considering that I wired everything to be always on, I won't have any load control, and am hoping to use the buttons as on/off switches for light groups and scenes.

 

Is this a viable scenario?  The ISY is already supported by my HA controller, so I could backdoor it that way, but would prefer to keep 'lighting' as a separate system that doesn't fully rely on my server running.

 

 

[Scottmichaelj]

Larrylinx has done a lot of messing around with HUE, network resources and programming. I just asked him based on another post to clarify a statement he made and will post back here with a link or the answer, unless he beats me to it here.

 

Basically if he is able to turn on/off/dim/brighten at a set level and color of the HUE bulbs then all we/you need to do is add those network commands to the networking module (purchased separately) then use a program that basically says "IF X switch is turned on then, run program that turns on HUE bulbs at the desired color and brightness via the network url".

 

Then that would accomplish what you want correct? Hope this helps. I am eagerly awaiting a response. Ive been stuck on finding an under cabinet lighting solution for months that works well with the ISY/Insteon.

[jkmonroe]

yep, that would seem to do what i want.  except instead of a switch, i'd be using a button on a keypad.  

[Scottmichaelj]

yep, that would seem to do what i want. except instead of a switch, i'd be using a button on a keypad.

Can you test and report back? Specifically pick a color (say red or blue) and then test that it turns on/off via the keypad using a program via the network resources?

 

Thanks.

[jkmonroe]

i don't have an ISY yet, hence me asking all of these questions.  

[mwester]

Works for me  

 

I'm actually using 5.0.2 and the new Polyglot node server with Hue support right now - and can change the color and intensity quite easily.

 

However, the node server implementation does not yet support some of the "cool" features of the Hue that I use (I use the Hue's notification feature to blink one of bulbs when a door sensor indicates that an exterior door has been left open too long).  So for that feature, I continue to use network resources.

 

The two approaches co-exist nicely, which is great because each has some complementary features that the other lacks yet.

 

The one big PITA is that the Hue bulbs do not return to their last-known state after a power failure - they turn on.  I don't find this a big problem, since they're LEDs and neither generate enough heat to be a concern nor do they consume enough power to be worrisome for the few times this actually happens.  I guess i could write an ISY program to turn them off when the ISY boots up, but it's just not a big enough deal for me to have ever gotten around to writing that simple bit of code

[jkmonroe]

this right here is what im trying to decipher.

What is a Polyglot node server?  I tried to read those threads, but they're not really for the beginner.  Would you be so kind as to explain that to me from the bottom up?

 

treat me like a 5 year old.  

[mwester]

The short answer: a Polyglot node server is a Raspberry Pi that is running UDI's Polyglot software.

 

One of the challenges with ISY controller is that UDI, the creators of the controller, need to make an update to the firmware in order to support new devices and types of devices.  It would be great if there were a way to do this without requiring UDI and firmware updates -- this would not only allow third-party companies to issue "drivers" for their products to add support in the ISY, but it would allow the community to contribute (or even possibly sell) drivers for devices.  And even UDI might use this to add support for a new type of device without re-releasing an update for the entire firmware for the ISY.

 

In order to make this happen, the ISY controller, with the 5.0 versions, uses the generic concept of a "node" to describe any device that it knows about, regardless of type of device (Insteon, Z-Wave, etc).  The concept of a "node server" is to support nodes (devices) that the built-in firmware doesn't handle.  A node server is an external network device or computer that communicates with the ISY using a very specific set of network commands - it could be a custom "black box", but it could equally well be a Window computer, a Linux computer, or even a mainframe if you had the right software and networking on it!  The ISY, when faced with an action to be performed on a device that is not one of the built-in types, will look at the device record it has in memory in order to find out which node server manages that type of device, and then using those specific network commands, it will forward that action to the node server device or computer to be processed.

 

Polyglot is a software package provided by UDI that runs on the Raspberry Pi computer and implements a set of node servers - the first one being a node server that knows how to talk to Hue Hubs.  It's also extensible, so that developers can easily create their own custom types of devices.  There are other node server implementations already being used, so the concept seems sound even though UDI's Polyglot package is still in "beta" and not generally available yet.

[jkmonroe]

thanks for that.

 

so to get 'better' hue integration, i would need to run the Polyglot node server on a rPi.  that's no problem.

 

the ISY would then be told where to look for my node server somehow, and devices/integrations configured on the node server become serviceable to the ISY as devices.

 

in the particular case of Hue, rather than going the roundabout way using the network resource to write directly to the API, the Hue lights discovered in the node server simply become available devices to the ISY?

 

so if each of my 39 bulbs would be directly addressable, it seems like my original idea of using the keypads to turn Hue bulbs/groups/scenes on and off would be doable.

 

this probably isn't the place for this question, but my current HA controller actually polls the Hue bridge to get the status of the bulbs - would this be something possible using Polyglot?  i can see how this would be amazingly powerful.  if there was a powered USB port on the ISY you could just sticky the rPi on top.

Edited December 24, 2015 by jkmonroe

[mwester]

Yes, the Polyglot implementation is bi-directional (unlike the network resource technique, which has no way to obtain the current status of the hue bulbs).  It polls the Hue Hub every second for status, so it actually feels very responsive.

[kohai]

The short answer: a Polyglot node server is a Raspberry Pi that is running UDI's Polyglot software.

 

One of the challenges with ISY controller is that UDI, the creators of the controller, need to make an update to the firmware in order to support new devices and types of devices.  It would be great if there were a way to do this without requiring UDI and firmware updates -- this would not only allow third-party companies to issue "drivers" for their products to add support in the ISY, but it would allow the community to contribute (or even possibly sell) drivers for devices.  And even UDI might use this to add support for a new type of device without re-releasing an update for the entire firmware for the ISY.

 

In order to make this happen, the ISY controller, with the 5.0 versions, uses the generic concept of a "node" to describe any device that it knows about, regardless of type of device (Insteon, Z-Wave, etc).  The concept of a "node server" is to support nodes (devices) that the built-in firmware doesn't handle.  A node server is an external network device or computer that communicates with the ISY using a very specific set of network commands - it could be a custom "black box", but it could equally well be a Window computer, a Linux computer, or even a mainframe if you had the right software and networking on it!  The ISY, when faced with an action to be performed on a device that is not one of the built-in types, will look at the device record it has in memory in order to find out which node server manages that type of device, and then using those specific network commands, it will forward that action to the node server device or computer to be processed.

 

Polyglot is a software package provided by UDI that runs on the Raspberry Pi computer and implements a set of node servers - the first one being a node server that knows how to talk to Hue Hubs.  It's also extensible, so that developers can easily create their own custom types of devices.  There are other node server implementations already being used, so the concept seems sound even though UDI's Polyglot package is still in "beta" and not generally available yet.

 

Thanks for this.  I've read through the polyglot stuff and it was pretty technical -- this is easier to understand.

[Brian H]

Phillips recently changed the ability of third party devices working with HUE.

Not sure if this will impact what is being done by the members here.

http://www.extremetech.com/electronics/219450-philips-updates-hue-introduces-lightbulb-drm

[kohai]

Phillips recently changed the ability of third party devices working with HUE.

Not sure if this will impact what is being done by the members here.

http://www.extremetech.com/electronics/219450-philips-updates-hue-introduces-lightbulb-drm

 

I think the next day they reversed their decision due to backlash:

http://techcrunch.com/2015/12/16/philips-hue-reverses-decision-to-block-third-party-light-bulbs/

 

I wouldn't be surprised to see them try a different angle at it down the road.

Edited December 24, 2015 by kohai

[Scottmichaelj]

The question still becomes at the end of the day they still have the open API. So would a firmware update kill that? Hmmm....

[jkmonroe]

The question still becomes at the end of the day they still have the open API. So would a firmware update kill that? Hmmm....

 

i doubt they would kill that, but it is a risk of every integrated device, isn't it?

[jkmonroe]

Yes, the Polyglot implementation is bi-directional (unlike the network resource technique, which has no way to obtain the current status of the hue bulbs).  It polls the Hue Hub every second for status, so it actually feels very responsive.

 

can you react to status coming back from the Hue bulbs with Insteon devices?  for example, a trigger turns on my kitchen - could i have the keypad turn on the corresponding button light?

 

i think this has pushed me over the edge to order the ISY.  before I do, is the Polyglot and 5.X firmware publicly available?

Edited December 24, 2015 by jkmonroe

[Brian H]

I also saw a post that they did reverse their position.

[larryllix]

Here are a few screen shots of network resources tat operate my Hue bulbs.

 

The left Network Resource is bulb specific while the right is generic and operates any bulb.

 

The reason I do not use the generic version right now is rapid firing commands to Hue devices  can get the buffered data  out of sync with the desired operations.

This is an ISY built in caching style currently, that does the variable value conversion at the Ethernet send time, instead of the ISY PLC command time. Command data can get crossed up if the variable is changed in between times. The workaround is  individual bulb operating resources s this result in quite a few of them or injecting time  delays ....yuk.

 

This is to be made an option in order to fix this, in v5 later releases, and could eliminate many resources needed to operate bulbs in rapid fire or apparently simultaneously.

 

This is quite easy to set up for noobies by just copying this and asking for help here.

 

The variables referenced are setup for a generic bulb (right) and a specific bulb (left) and are comprised of Hue, Brightness, Saturation, and Bulb Number (for the generic resource only)

 

 

      

Edited December 25, 2015 by larryllix

[DualBandAid]

So if I was starting from scratch, with just an ISY...and wanted to start adding Hue bulbs to my system...

 

1) What's the first step?

 

2) Do I need the Hue hub or can I control directly from the ISY?

 

Thanks

 

P.S. I have two homes running fairly robust ISY systems...and am relatively computer literate (I made an iPhone app, for example)...but really this is not my field at all.  Like, I know *what* a Pi is.  But that's about it.  Everything I do, I have to bootstrap myself up from scratch.

[larryllix]

So if I was starting from scratch, with just an ISY...and wanted to start adding Hue bulbs to my system...

 

1) What's the first step?

 

2) Do I need the Hue hub or can I control directly from the ISY?

 

Thanks

 

P.S. I have two homes running fairly robust ISY systems...and am relatively computer literate (I made an iPhone app, for example)...but really this is not my field at all.  Like, I know *what* a Pi is.  But that's about it.  Everything I do, I have to bootstrap myself up from scratch.

Read this thread from the beginning but....

 

The Hue bulbs need a hub as a bridge between Etherenet and whatever the Hue protocol is.

The ISY can use the Network resource module to access the Hub/Bridge.

 

Start building resources to send URL codes out. See the previous post two back for sample screen shots.

 

IIRC Polyglot has Hue support built into it for the RPi.

[DualBandAid]

Thank you for the response.  I did actually read the thread from the beginning and especially got a kick out of jkmonroe's post...

 

What is a Polyglot node server?  I tried to read those threads, but they're not really for the beginner.  Would you be so kind as to explain that to me from the bottom up?  treat me like a 5 year old.  

 

And then the response he got, which led him to post:

 

so to get 'better' hue integration, i would need to run the Polyglot node server on a rPi.  that's no problem.

 

I don't know many five year olds who know what a node server is (or an rPi - for that matter).  

 

But from what I can tell, the majority of this thread was about how people can get 'better' hue integration.  I'm trying to figure out how to get ANY Hue integration.  In other words, where do I start?  What is required for even basic integration?

 

1) So I know how that I do need a Hue bridge

 

2) Is a rPi a necessary component as well?  Are there alternatives or is that it?

 

3) Is the "Polyglot node server" (wherever or whatever that is exactly) also a necessary component?  Are there alternatives or is that it?

 

4) I already have the ISY network module...but what that be required for someone who didn't already have it?

 

5) I noticed there is a Zigbee purchasable module.  Hue is Zigbee.  There is no cross-over there?  Do I need to buy that?

[mwester]

1)  You ALWAYS need a hue hub to control the hue bulbs -- this is a requirement of Philips, not of the ISY.

 

2) No, the Raspberry Pi is not necessary.  If you choose to use network resources to control the Hue bulbs, then you need no outboard computing device at all.  And if you choose to use Polyglot, then you can use other Linux devices, or perhaps even a Windows host -- depending on how self-sufficient you are with Python and computer admin things.

 

3) Polyglot is not a necessary item -- with limitations, you may be able to use nothing but network resources to communicate directly from the ISY to the Hue hub.  Here's the details:  with a network resource you can send ONE command to the Hue hub with a pre-defined hard-coded network resource.  You cannot receive information from the Hue hub (i.e. you cannot write a program that queries the state of the bulbs, for example).  If you have a very few bulbs, and limited settings for them, this is practical.  Consider my original setup -- I had three bulbs.  I wished to turn the all on at once and turn individual ones on.  That's four network resources.  Of course, if you turn them on, you need to turn them off.  That's four more.  And in the evenings, dimming to 50% was nice.  Four more resources.  Some colors were cool -- we selected four colors that were nice, and wanted each color to work at 50% dimmed and full on -- that's (4 + 4) * 3 or 24 more resources... at about that time I stopped and said the heck with it.  What polyglot and the node server offer is the ability to make each bulb appear as if they were Insteon devices.  So things like on and off and dimming are built-in, and easy to do.  Color is also built-in (although the XY color coordinates that the Hue uses are a real pain).

 

4) You need the network module regardless -- in order for the ISY to communicate (send data) with any external device, be it the Hue hub with network resources or the Polyglot service on a Raspberry Pi, it needs the network module.  So yes, if someone doesn't have it, they'll need it. (Frankly, I think the network module needs to be rolled into the base ISY, with a price bump to the ISY base price if necessary, because most creative things require that module anyway - but that's my opinion, and I'm lousy at marketing things...)

 

5) The ISY Zigbee module communicates only with utility meters, I understand.  Even so, I don't think reverse-engineering the Philips Hub-to-Bulb protocol is a worthwhile thing to do -- huge amount of labor, having to be re-done each time Philips introduces a new device or new version of a device.  The Node Server concept and the Polyglot implementation was designed to avoid exactly that by simply making another vendor's hub device easy to subsume into the ISY's notion of devices.

[larryllix]

I have five Hue bulbs and these are the total Network resources I use to control them anything I want.

 

Once ISY has the option to not cache parameters and evaluate them at resource call time these can be reduced to about four or maybe five for some convenient operations without setting up parameters.

 

I make use of parameters for each call.

 

 

Here is how I set up parameters for each call when dinning levels or special colours are needed.

 

Colours.orange - [iD 00C6][Parent 00C5]

 

If

$sGathRm.colours is $cMOOD.ORANGE

 

Then

. $Hue.hue = $cHUE.ORANGE

. $Hue.saturation = 254

. $Hue.brightness = 100

. Resource 'Hue.set(all)'

 

Else

- No Actions - (To add one, press 'Action')

 

 

If you are not inclined to do a lot of program setup/learning the network resource method works well with complete control over every bulb, level, hue, and brightness.

Edited July 17, 2016 by larryllix

[nridge]

I have an ISY with network module .  I also have a hue hub.   Is it possible to trigger a hue scene within an isy scene?  is the triggering of a scene 1 network resource?  turn on red scene, etc.

[larryllix]

No.

 

A Network resource send one line of command code out through your Ethernet connection from the ISY.

 

Whatever the Hub can do with that command is what one Network resource can do