Hue node server requires better support for color and non-color bulbs

[mjwesterhof]

Users have reported that the hue node server crashes when a non-philips-hue bulb has been added to the hue hub (e.g. GE Link bulb).

At the very least, the node server should not crash and merely ignore the odd bulb -- but better would be if the node server could do something to 'fake up' the color coordinates for the odd bulb so that basic on/off/dim capability would work.

Some type of resolution is fairly high-priority since this renders Polyglot/Hue unusable for affected users.

[mjwesterhof]

A quick fix, although somewhat less-than-ideal, is to replace the two constructs that retrieve the XY color coordinates from the Hue bulb data structure with a get() so that we can specify a default should the data not exist. For example, the references currently look like this:
for val in data['state']['xy']]
These can be rewritten as:
for val in data['state'].get('xy',[0.0,0.0])]
This solution has been tested with a GE Link bulb, and works.

(Regarding the "less-than-ideal" comment above -- the ideal solution would be to implement a new node type for non-color-capable bulbs, one that would not expose the XY color information. This shouldn't be hard, but would require much more testing, so I think slipping the aforementioned fix into the code ASAP is a good short-term fix, and then we can simply leave this issue open until the longer-term fix is written and tested.)

[mjwesterhof]

Updated the title to broaden the scope a bit -- in addition to a new node type for non-color-capable bulbs, whilst messing with the profile we should also add support for the Hue "alert" feature (which flashes the identified bulb).

[mkohanim]

Hi MIke,

I think that's an excellent idea. What's needed for this on ISY side? Also, assuming that there will be more than one node servers (such as io_guys solutions), how would we handle those?

With kind regards,
Michel