finish lifx

[mrose17]

@russnelson - if you "get the latest" you'll see the lifx driver. i renamed it and did some work on the color handling. here are the remaining issues. let me know if you can look at them…

1. get/set color to LIFX is in HSL+K, but clients are responsible only for RGB and CIE1931 and temperature (the low-end and the high-end). so lighting drivers are responsible for mapping any other model to RGB.

if you look in LIFX.prototype.update, you'll see where it takes the HSL model from the update and converts it to RGB; similarly, if you look in LIFX.prototype.perform you'll see how the RGB model from the client gets converted to HSL for the bulb, and then later on, you'll see how HSL gets put back into RGB for the internal state.

i don't think the mapping is reversible, but haven't had time to verify that yet.

1. more importantly: the driver never sees any bulbonoff events, nor does it see any bulbstate events after the first one. i also dealt with the issue of events coming in before a bulb was fully initialized (because the database is involved, device.discover returns early).

could you take a look at these two items? thanks!

[RussNelson]

Oh, well, I can help with number one, if only for development purposes. On a different login, cd steward/node_modules/lifx; sudo node ./cli.js You don't need to type any keys. It starting up is sufficient to cause the bulb to announce itself.

I see the scan() routine is supposed to help discover bulbs. I'll do some network tracing to figure out why it isn't and the cli.js code is.

[RussNelson]

There's another problem: when you turn the bulb off, the steward forgets what color and brightness it was using. So then, when you turn it back on again, its brightness is 'undefined'.

[mrose17]

i'll fix that one. that's easy.

[mrose17]

i think that's now fixed in the master.

[RussNelson]

Yes, it is fixed. Still working on the two remaining problems.

[RussNelson]

Making progress. I notice that the lifx driver is already polling for a gateway. I think that it's NOT a simplicity to ignore the gateway. Better to absorb the complexity, particularly if it causes the code to work. :)

[mrose17]

any luck?

[RussNelson]

No, as usual, my bulb crashed overnight. I think I'm going to wait until they have usable firmware.

Cuz, y'know, I always wanted to have to load new firmware into my light bulbs.

[mrose17]

uh, okay. (-;

i went through and made the color mappings for rgb/hsl close to reversible, but it's really not exact. we're going to have to add an HSL picker to the HTML5/D3 client for greater fidelity...

[mrose17]

i also put in some code to handle the disconnection. i suspect that you'll see better behavior now. just be sure to do this:

    % cd steward
    % git pull
    % cd steward/
    % rm -rf node_modules/lifx
    % npm -l install

and the restart the steward.

[RussNelson]

I'll give it a try. Right now I'm trying to figure out if my bulb is crashing on its own, or if it's crashing because the lifxjs code is talking to it. I have the attention of a LIFX engineer, so there's some hope of addressing this problem.

[mrose17]

good luck. be sure to grab the latest. i see tcp disconnects on my bulb, but the version of lifx.js i'm using (what you'll get after doing the steps above) automatically reconnects.

[RussNelson]

Hey, what did you do? The LIFX code is working! Good job!

[mrose17]

thanks. there were basically three things, after i started with your base.

• the lifx.js library didn't reconnect when the connection dropped, so it got forked and fixed.
• the lifx bulb doesn't send updates after the first one, so now we poll.
• as you observed, the first update can arrive before the device is fully instantiated (due to an asynchronous database dip) that got added in 1.3 - so, it's queued.

the basic logic was fine, it was just a matter of seeing where reasonable assumptions weren't being honored (-;

so, what are you integrating next?