Can't seem to talk to the device.

[jacobnash]

I have a different vendor and product number. I have updated those. but it seems like the device is connecting but it isn't reading my messages. have any ideas? I think it may be in the buffer. is there a reason for the last concatenation in the buffer?

[ericpulvino]

Sounds like a badly formatted message. All the Kuando devices I've seen have the same vendor and product number but often times with different packaging. It is possible that if you're seeing another vendor/product number that the device may need different code. I had used the https://github.com/porsager/busylight library as a starting point for my library, I reverse engineered the USB messaging using wireshark to sniff the USB communication to the device when used with that library. What I found is that the last portion of the message never changed. It is possible you could try the other library as well and see if it works with your device. If there are enhancements that can be made here based on device type I'd be happy to accept them.

[domneill]

Likewise with my new BusyLight Omega. Maybe they've changed the firmware? For what it's worth, here's the various IDs according to Kuando's USB API:

Model	Vendor ID	Product ID
BusyLight Alpha	0x27bb	0x3bca
BusyLight Omega	0x27bb	0x3bcd
BusyLight UC	0x27bb	0x3bcb
KuandoBOX	0x27bb	0x3bcc
Bootloader for all models	0x27bb	0x3bc0
Busylight v1	0x04d8	0xf848

I can connect to my BusyLight Omega using its listed PID, but it doesn't respond to commands until pulsing with the named color 'goldenrod', at which point it does illuminate, but rapidly flickers before turning off when the connection times out.

[adaminchicago]

Same issue as domneill. Did you figure out a solution?

[ericpulvino]

I could for sure take the vendor id and product ids as arguments for the class so that way it could be modded for different products, I.e. in the line shown here: https://github.com/ericpulvino/pyBusylight/blob/master/example.py#L6

bl=pybusylight.busylight(idVendor=0x04d8, idProduct=0xf848)

However until I can get one of the other busylight types I won't be able to fix whatever is wrong with the communication for those.

[nitram2342]

I have the same issue with a Busylight Omega. I changed the USB vendor and product IDs according to the table from @domneill. The 'goldenrod' actives the light, but other calls seem not to work.

I requested access to the "USB API" (https://www.plenom.com/downloads/download-software/). Lets see how far I get.

[nitram2342]

I tried to get the USB API spec, but failed and only got more questions to answer. Luckily, I found a newer spec (https://github.com/porsager/busylight/blob/master/Busylight.API.rev.2.2.-.22052015.pdf). The USB API seems to have changed a bit. I adjusted the constructor to allow users to specify USB vendor and product IDs. I merged the patch from @idleline (https://github.com/idleline/pyBusylight/commit/d905db26210d4f79f8ac246ecafc08080e5c23c5), because color codes definition changed, rewrote the __build_buff__() function, added a checksum calculation, and now the code seems to work, even with audio. Since I only have an Omega, I can test it with the one I have, but I suppose it works with other devices as well. Later, I will push the updated code to my fork.

[nitram2342]

I pushed the updated code at https://github.com/nitram2342/pyBusylight and I would be glad, if people with other devices can test if it still works. I also added a device probing feature. The code will look for devices with the product ID listed by @domneill.

[domneill]

@nitram2342 it works!™

Just ran the example script with my UC Omega and it ran all the way through with no issues 👍

Thanks for solving this!