Q: Is this still working?

[Wizek]

I was trying to compile and run the example.hs file, and I got these errors:

Press the link button on the base station
Error 6: parameter, username, not available
Error 6: parameter, username, not available
Error 6: parameter, username, not available
...

Upon a bit of digging, it seems the API might have been changed:

• parameter, username, not available shokai/node-philips-hue#12
• https://developers.meethue.com/documentation/important-whitelist-changes

Is this a fair reading? Could this be easily fixed?

From what I see in these links, this library would need to somehow persist this API token that it gets back. My first idea is to do it in a config file in the working directory. Any other ideas?

cc @sjoerdvisscher

[sjoerdvisscher]

Ooh, I haven't looked at this code for a very long time! Could be fun to look at since I now actually have hue lights at home 😃

I think persisting the token is something the user of the library should do, although it could provide some default options.

[Wizek]

I think persisting the token is something the user of the library should do

Hmm, are you sure about that? I am a fan of the 'batteries included' approach to library design. I.e. provide the simplest API for the most common usecase. Connecting to a bridge in the simplest way sounds to me to be one of the most common things users of this (or any hue) library would do. So how about we by default persist this token for them, and make it so that they can also use lower level functions if they wish to persist it for themselves?

Could be fun to look at since I now actually have hue lights at home

Cool!

[dminuoso]

I don't think there is a reasonable way to store the token/username in the library. If the token is not written to persistent storage, we will have to re-link with the hue bridge on every program restart.

And secretly putting a security token onto the filesystem is not good security hygiene.