-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update to new hue-js interface, storing username token in config file #14
Conversation
@mattbucci actually, when cloning your master of When using
When using
NodeJS version: 6.4.0 (armv7). |
I will test this this weekend when I have access to a newer bridge, thanks! Also, I created a (terribly named) PR a long time ago with good intentions, but it has unfortunately stagnated. Either way, it may be worth incorporating hue-sdk (my own creation) into this module instead of the seemingly abandoned hue.js. |
@TwizzyDizzy assuming you dropped in my version of hue.js as well? Seems odd though that it's saying something about a socket error. I'll test with my version when I get home. I'm on node v6.5.0 x86 osx |
@bahamas10 I'd be glad to help out in anyway I can, even if that means refactoring to a new hue sdk or updating your hue sdk package to be compatible with the new auth flow |
@TwizzyDizzy try changing your package.json to point to mattbucci/master for hue-js, run npm update and see if you have the same problem. My fixes aren't merged to his master yet. |
Yeah, done that. But still... same error (though now just upraded to nodejs 6.6.0 that was released roughly an hour ago). If you have anything I should test, don't hesitate to hit me up :) Cheers |
@TwizzyDizzy I'll break out the raspi today and see if I can reproduce it, I've got the newer hub btw |
@TwizzyDizzy unfortunately my raspi seems dead so you're gonna have to test some untested stuff 👍 So your first error seems to be a common issue with calling sever.address before the port has finished binding....now I can't see why this would ever get executed synchronously but perhaps @bahamas10 would know as it looks like he was the last to touch that. I would edit the file /opt/node-v6.4.0-linux-armv7l/lib/node_modules/hue-cli/node_modules/hue.js/lib/Discoverer.js changing lines 19-24 from. Your log clearly shows that line 21 is executed if (client.bind.length) {
client.bind();
next(); // this fails because bind hasn't completed yet, not sure bind.length is being checked but it's clearly not working
} else {
client.bind(next);
} to client.bind(next); Then report back. (For the sake of the reader I'm referencing the docs located here https://nodejs.org/api/dgram.html#dgram_socket_bind_port_address_callback) As for your second error check out http://192.168.1.205/debug/clip.html and run through http://www.developers.meethue.com/documentation/getting-started to see if you can figure anything else out. are you running a new hub or an old hub? I'm on the new hub but your error seems not to be related to any code but rather a failed response of the hub. Maybe it's an older version and we have to account for both? dunno. You could also try adding a console.log(err) above line 251 of /opt/node-v6.4.0-linux-armv7l/lib/node_modules/hue-cli/hue-cli.js and let us know what the error is that hue is returning |
Mhhh.. that kind of debugging seems to me to be rather cumbersome. If you like, I'd provide you with an unprivileged (read normal user) SSH account on my raspberry so you could test/debug as you like? Send me your pubkey to As for you change above: this lead to an EADDRINUSE error. I'm running the v2 hub. Cheers |
I see where we got confused, @bahamas10 already fixed that issue in his dave branch. I merged that fix of his into my master so that it's a complete working implementation of hue.js and now discovery is working as expected:
|
Hi @mattbucci, alright, since you can't physically press the register button on my bridge, I'm going to test the register functionality when I get home later (around 7PM, CEST). Should I test with the version in your home directory or your github master? Cheers |
they should both be the same now, but I'll add a console log to the one in On Fri, Sep 16, 2016 at 2:33 AM, Thomas Dalichow notifications@github.com
|
Just tested the register function. It worked! As did the light functions and everything else hue-cli shall achieve :) (for readers, this is debugging sample code and not to be used by you. Please refer to README.md instead)
Cheers |
Can we get this merged, plz? 🎊 |
@jgladch @yadomi if you'd like to test this now please do the following and report back and let us know if it works. Will be much more helpful!
I'm sure he'll be much more comfortable merging if we have more people verifying it's fixed 👍 |
hey everyone, thanks for all the debugging on this and interest in the project overall... i'm looking at the code now and will update this thread when everything is merged and working :D |
config.username = resp[0].success.username; | ||
|
||
// writing config file | ||
var s = JSON.stringify(config, null, 2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't realize hue-cli
had as large of a community as it did (thanks everyone!) so I'm interested in gathering insight from everyone. My only concern with this is, when a user runs hue register
it will clobber their existing config file without passing the --save
option. Admittedly, the --save
function currently operates in a less-than-ideal way.
My current proposal would be to drop the --save
functionality completely, and make it so hue register
will automatically write out the config IF ONE DOES NOT ALREADY EXIST. If one exists, hue register
should print a warning, dump the current config, and exit non-zero, and leave it up to the user to remove it before registering a new bridge. What do you all think of that?
Either way though, I'm currently 👍 on this change and appreciate the small diff!
addendum: if you all like this idea, i wouldn't mind merging this as-is and making the code do what i described in a second commit
Hi @bahamas10
👍 seems to be the wisest course of action! |
@mattbucci damn, i'm too late. I've made #15 but it seem you're faster than me :) |
@yadomi I reviewed your work, funny we both chose to work on it at the same time 👍, Seems like I can do a bit of code cleanup if process.exit is preferred over throw |
@mattbucci yes that's funny, we've made almost the same change 👍 btw, should I close my PR (#15) since this one do almost the same things ? |
@yadomi yeh that's fine. please close your PR and review mine. I'll make any changes needed (changing throw to process.exit(1)) and anything else you find and hopefully we can get this merged later today. |
@mattbucci this PR looks OK to me 🚀 |
thank you everyone! I've merged this pr and have published it to npm
|
Before merging bahamas10/hue.js#1 and bahamas10/hue.js#2 must be merged