search

kusti8 / hue-plus

A Windows and Linux driver in Python for the NZXT Hue+
GNU General Public License v3.0
229 stars 18 forks source link

Hangs on reading data from serial #1

Closed jonathan-deprizio closed 7 years ago

jonathan-deprizio commented 7 years ago

I've spent a few hours trying to get this to work, but no luck. The code as written hangs when attempting to read from the serial device inside of the 'fixed' function if I call "power off". It seems like it never gets a response after writing the first item of "initial".

I've tried getting the device to react using screen, minicom, etc... Sometimes I can get it to throw some raw bytes at me by pounding on the keyboard, but nothing useful.

I installed Windows in a VM, and I installed the NZXT software in it; and the LEDs turned Blue (they are otherwise stuck on white) but then the Cue software froze, possibly because of the VM setup (USB passthrough etc). So I'm pretty sure that the strip works properly.

kusti8 commented 7 years ago

Are you sure that this is the right device. What does ls /dev/ACM* say? It may be a defective Hue if it doesn't work with Windows, but I'm not sure. Try rebooting and powering off and on the Hue+.

kusti8 commented 7 years ago

I've pushed a new update which should fix this, I've recently experienced this myself. It also includes cleaner code and saves your preferences for easy switching and editing channels.

trolando commented 7 years ago

Not working for me either, I even tried various different speeds, parity, hardware/software flow control, nothing.

I did some wireshark USB dump and the Windows driver first tries sending "C0", a couple of times with what appears different control settings... then after the device returns "01", the driver sends "8D 01" and "8D 02" and "8C 00" with different returned data... and then after, when I change settings it first sends the prefix you have in your tool too (46 00 c0 00 00 00 ff) and then the desired change (eg 4B 00 .....)

I wrote a little script that just connects with various speeds and options (with pyserial) and tries sending C0 and 8D 01 and the prefix, but never did it properly return "01"... only sometimes "FF FF" or "F8" or other ...

kusti8 commented 7 years ago

It seems that NZXT changed the protocol again so I'll have to totally rework it. 3.2.04 is the culprit. I'm taking some time off from the project before I can resume so I can pursue other things, but I am looking into it. On Sun, Nov 20, 2016 at 3:19 PM Tom van Dijk notifications@github.com wrote:

Not working for me either, I even tried various different speeds, parity, hardware/software flow control, nothing.

I did some wireshark USB dump and the Windows driver first tries sending "C0", a couple of times with what appears different control settings... then after the device returns "01", the driver sends "8D 01" and "8D 02" and "8C 00" with different returned data... and then after, when I change settings it first sends the prefix you have in your tool too (46 00 c0 00 00 00 ff) and then the desired change (eg 4B 00 .....)

I wrote a little script that just connects with various speeds and options (with pyserial) and tries sending C0 and 8D 01 and the prefix, but never did it properly return "01"... only sometimes "FF FF" or "F8" or other ...

— You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub https://github.com/kusti8/hue-plus/issues/1#issuecomment-261802614, or mute the thread https://github.com/notifications/unsubscribe-auth/AJW73OjySZ5ftX29w8mXO5_1NvzU5hNjks5rAKtRgaJpZM4KbsDB .

trolando commented 7 years ago

I seem to think maybe the speed is different too, I don't seem to be able to get any good reply going :(

kusti8 commented 7 years ago

What I do is I use ILSpy to look around the source code a bit also. It's big and tedious, but it helps to get those small things.

trolando commented 7 years ago

Oh, never heard of that. Dunno if that's legal though.

BTW if you like I can help clean up the Python code a bit if you like, I've written controllers before (https://github.com/trolando/python-rx320)

kusti8 commented 7 years ago

I'm not a legal expert so I wouldn't know. If you want to help, you're very welcome to make a pull request. I'm going to come back to this project soon.

epsol commented 7 years ago

for the port speed, ive noticed it first tries to sync at 4800 then 9600 and again at 256000, then commands are passed back and forth between the hue and cam sodtware, but in my testing I just get an occasional FF back as a response or lock up the hue controller..

epsol commented 7 years ago

Okay, wanted to add more information. I am noticing I have to send 125 hex codes to it to respond. otherwise I get a response back from the hue everytime it has received 125 of them.. I have gotten it to to return 1 and manually using the hex of "4B00C0FFFFFFFF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" seems to turn it off ..

Still toying around, but making some headway