"No such device" error with blync CLI

[dend]

I have an Embrava Blynclight that I am trying to control on macOS Catalina (10.15.5). If I run system_profiler SPUSBDataType, I can see the device:

Blynclight:

       Product ID: 0x2517
       Vendor ID: 0x0e53
       Version: 1.00
       Speed: Up to 1.5 Mb/s
       Location ID: 0x14312000 / 14
       Current Available (mA): 500
       Current Required (mA): 100
       Extra Operating Current (mA): 0

However, when I run blync, I get an error:

Traceback (most recent call last):
  File "/Users/pat/source/blynclight-base/.env/bin/blync", line 10, in <module>
    sys.exit(cli())
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/typer/main.py", line 213, in __call__
    return get_command(self)()
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/click/core.py", line 1236, in invoke
    return Command.invoke(self, ctx)
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/typer/main.py", line 496, in wrapper
    return callback(**use_params)  # type: ignore
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/blynclight/__main__.py", line 102, in blync_callback
    light = BlyncLight.get_light(light_id)
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/blynclight/blynclight.py", line 178, in get_light
    return cls.from_dict(cls.available_lights()[light_id])
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/blynclight/blynclight.py", line 196, in from_dict
    return cls(info["vendor_id"], info["product_id"])
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/blynclight/blynclight.py", line 252, in __init__
    self.immediate = immediate
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/blynclight/blynclight.py", line 316, in __setattr__
    n = self.device.write(self.bytes)
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/blynclight/hid/__init__.py", line 269, in write
    return hidapi.hid_write(self.handle, data, len(data))
  File "/Users/pat/source/blynclight-base/.env/lib/python3.7/site-packages/blynclight/hid/__init__.py", line 244, in handle
    raise LookupError(f"no such device: {self.identifier}")
LookupError: no such device: 0x0e53:0x2517

This seems odd, since it does seem like the device vendor ID and the product code are correctly detected, it's just that the writing fails with the specified handle.

Running blync -l actually detects the light as well:

Number of available lights: 1
                 KEY:ID:VALUE
                path:00:
           vendor_id:00:0xe53
          product_id:00:0x2517
      release_number:00:0x100
      product_string:00:Blynclight
          usage_page:00:0xff00
               usage:00:0x1
    interface_number:00:0x0

[JnyJny]

I'm investigating this, it's possibly a bug in how I'm calling ~hidapi.write~ nope looks like hid_open (fingers crossed).

[JnyJny]

How did you install hidapi on your Mac? MacPorts, brew or something else?

[JnyJny]

I couldn't recreate the bug on my machine with my lights, but I'm hoping I found the problem and pushed a revision to PyPI (~0.6.4~ 0.7.1). If you could install that and give me some feedback that would be awesome.

[dend]

I installed hidapi via brew install hidapi. Checking the new version!

[dend]

Just installed the latest version from the GitHub repo (via pip install .) - not sure if the PyPI release would be different, but seems like the error is the same. I wouldn't exclude the fact that something is wrong with hidapi.

[JnyJny]

Well crap. I was hoping that would fix the problem obviously.

What's happening in the stack trace you provided is pretty straightforward:

1. The BlyncLight object is instantiated but the handle property isn't initialized until it's first use (as designed)
2. The first write to the device accesses the handle property
3. The handle property method calls hidapi.hid_open(vender_id, product_id, None)
4. When the library returns None/NULL we raise the LookupError.

I was accidentally passing the 'path' attribute as the third argument to hid_open when it was expecting None or the device's serial number. That was a bug for sure on my part, but not the problem you are encountering. So hid_open is failing for some other reason. The duh is implied I guess.

One thing that stuck out to me and I can't explain is the empty 'path' attribute in your blync -a output. I had just removed that attribute from the output of the report since it can be annoyingly long under MacOS and it didn't seem very helpful. I just added it back into the output for version 0.7.2 (which I just pushed to PyPI).

On my Mac 10.10.5 installation with hidapi 0.9.0 I get the following output:

BlyncLights        :2
ID:KEY             :VALUE
00:path            :IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/TRP0@7/IOPP/PXSX@0/IOPP/pci-bridge@0/IOPP/pci1b73,1100@0/AppleUSBXHCIFL1100@01000000/AppleUSB20XHCIPort@01100000/Blynclight Plus@01100000/IOUSBHostInterface@0/AppleUserUSBHostHIDDevice
00:vendor_id       :0x2c0d
00:product_id      :0x10
00:release_number  :0x100
00:product_string  :Blynclight Plus
00:usage_page      :0xff00
00:usage           :0x1
00:interface_number:0x0
ID:KEY             :VALUE
01:path            :IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/TRP0@7/IOPP/PXSX@0/IOPP/pci-bridge@2/IOPP/pci1b21,1242@0/AppleUSBXHCIPCI@00000000/AppleUSB20XHCIPort@00300000/Blynclight@00300000/IOUSBHostInterface@0/AppleUserUSBHostHIDDevice
01:vendor_id       :0x2c0d
01:product_id      :0x1
01:release_number  :0x100
01:product_string  :Blynclight
01:usage_page      :0xff00
01:usage           :0x1
01:interface_number:0x0

If I wrote some C tools for debugging this problem, would you be able to compile and run them? If not I'll figure something else out. It would be great if you could install the new version and respond back with the blync -a output too!

[JnyJny]

Ok, I think I've been able to recreate this problem. I suspect that you have another application running that has an open file descriptor for the light; Teams or Skype or something else maybe? The lights can only be opened by one application at a time.

[dend]

Hmm... interesting. Definitely do not see another application that would be using the light. I will need to dig into this a bit to see if I can identify how to get a list of applications using a USB device. Updated to the latest version and ran blync -a, and getting this output:

BlyncLights        :1
ID:KEY             :VALUE
00:path            :
00:vendor_id       :0xe53
00:product_id      :0x2517
00:release_number  :0x100
00:product_string  :Blynclight
00:usage_page      :0xff00
00:usage           :0x1
00:interface_number:0x0

Empty path here. The weird thing about the light is that it works fine with blync on another machine, that is on the same macOS version, using the same hidapi release.

If I wrote some C tools for debugging this problem, would you be able to compile and run them? If not I'll figure something else out. It would be great if you could install the new version and respond back with the blync -a output too!

Sure, I can test with C tools - new to HID APIs, but can figure things out.

[dend]

I wonder if this has something to do with macOS restrictions. Will have to dig into this a bit later, but I would not exclude that there is something here natively in the OS blocking HID path access.

[JnyJny]

Thanks for the pointer, following the rabbit hole led to this commit which indicates a known limitation: https://github.com/claui/python-fido2/commit/79173f8d2ce55d26543b8b1af03bc2eda6f8a413

I'm curious how your blynclight is connected ( hub connected to a hub connected to a hub to the Mac )? If it's a long chain can you shorten the chain to consequently shorten the generated path length ?

[Jaharmi]

I get this sort of error if I have the Embrava software open or if I have been controlling the device in an active Python interpreter. Once I closed ptpython (in one Terminal tab), I'm able to use the CLI tool in another tab.

[dend]

@JnyJny @Jaharmi I did connect it through a hub, but on another Mac it's connected through the same hub and it works with no issues. The interesting part is that I do not see any other application that obviously is using the light. I need to see if there is an alternative way to get the path to the device outside the blync CLI. If you folks have any suggestions, I am happy to try them!

[JnyJny]

I read about some sort of "IOExplorer" tool in the Apple Developer Tools bundle, but haven't pursed it yet.

Just for grins, I just published 0.8.0 to PyPI. I removed my ctypes interface to hidapi (blynclight.hid) and replaced it with hidapi which has two virtues: somebody else is (actively) maintaining it and they are tracking hidapi. Give it a shot, if the error was somewhere in my hid implementation this change may fix the problem. Fingers crossed.

[dend]

Bingo - pulling the latest version from PyPI did it, and it now works properly 🙏 Thank you @JnyJny! Excited to see the source code that you publish for 0.8.0.

[JnyJny]

That is great news!