tested on Raspberry Pi: error message ...

[mcnahum]

Hello, I tried it on my Raspberry Pi but I got that message who is not really clear:

pi@raspberrypi:~ $ pip install -U busylight-for-humans Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple Collecting busylight-for-humans Could not find a version that satisfies the requirement busylight-for-humans (from versions: ) No matching distribution found for busylight-for-humans

any clue? or it's not made for it...

[JnyJny]

I can recreate that error using python 2 instead of python3:

# python --version
Python 2.7.13
# python -m pip install busylight-for-humans
Collecting busylight-for-humans
  Cache entry deserialization failed, entry ignored
  Could not find a version that satisfies the requirement busylight-for-humans (from versions: )
No matching distribution found for busylight-for-humans

After reading this article I have begun using this style command line to install to ensure I'm using the python version I expect:

$ python3 -m pip install ...

I was able to install on my RPi using that invocation.

[mcnahum]

good catch! installation completed

[mcnahum]

ok install is ok ... but ...

pi@raspberrypi:~/.local/bin $ busylight -a on :0x2c0d:0x0003 pi@raspberrypi:~/.local/bin $ busylight on :0x2c0d:0x0003 pi@raspberrypi:~/.local/bin $ busylight on red :0x2c0d:0x0003 pi@raspberrypi:~/.local/bin $ busylight off
:0x2c0d:0x0003

[JnyJny]

Looks like an exception is getting thrown and the product_string is null. Which BlyncLight model is that? I only have two that I test with:

• BLYNCUSB30-161 ( 0x2c0d:0x0001)
• BLYNCUSB40S-181 (0x2c0d:0x0010)

[mcnahum]

it's a Embrava Blynclight Mini working ok with blync

pi@raspberrypi:~/.local/bin $ blync -a Number of available lights: 1 KEY:ID:VALUE path:00:/dev/hidraw0 vendor_id:00:0x2c0d product_id:00:0x3 release_number:00:0x100 manufacturer_string:00:None product_string:00:Blynclight usage_page:00:0xc600 usage:00:0x761f interface_number:00:0x0

[JnyJny]

Huh. That points to a bug somewhere in busylight since it's "newer". My initial thought was to make sure your UDEV rules weren't too restrictive but if the light works with blync then the rules are good.

[JnyJny]

On my RaspPi I couldn't get either blync or busylight to successfully "open" a BlyncLight until I updated my /etc/udev rules and added my userid to the "plugdev" group.

# usermode -a -G plugmod <username>

My updated rules look like:

/etc/udev/rules.d/99-busylight.rules

KERNEL=="hidraw*", ATTRS{idVendor}=="2c0d", GROUP="plugdev", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2c0d", GROUP="plugdev", MODE="0666"

To be honest, I'm not 100% sure about the need for the plugdev group but for now it's working for me.

Also, there seems to be a bug in the typer minimum version for busylight which conflicts with blynclight.

(.venv) solid:tmp -> busylight list
ID: Device Name
 0: Blynclight Plus
(.venv) solid:tmp -> busylight on
Traceback (most recent call last):
  File "/home/ejo/tmp/.venv/bin/busylight", line 8, in <module>
    sys.exit(cli())
  File "/home/ejo/tmp/.venv/lib/python3.7/site-packages/typer/main.py", line 215, in __call__
    return get_command(self)()
  File "/home/ejo/tmp/.venv/lib/python3.7/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/home/ejo/tmp/.venv/lib/python3.7/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/home/ejo/tmp/.venv/lib/python3.7/site-packages/click/core.py", line 1257, in invoke
    sub_ctx = cmd.make_context(cmd_name, args, parent=ctx)
  File "/home/ejo/tmp/.venv/lib/python3.7/site-packages/click/core.py", line 700, in make_context
    self.parse_args(ctx, args)
  File "/home/ejo/tmp/.venv/lib/python3.7/site-packages/click/core.py", line 1048, in parse_args
    value, args = param.handle_parse_result(ctx, opts, args)
  File "/home/ejo/tmp/.venv/lib/python3.7/site-packages/click/core.py", line 1630, in handle_parse_result
    value = invoke_param_callback(self.callback, ctx, self, value)
  File "/home/ejo/tmp/.venv/lib/python3.7/site-packages/click/core.py", line 121, in invoke_param_callback
    return callback(ctx, value)
TypeError: handle_color() takes 1 positional argument but 2 were given
(.venv) solid:tmp -> python3 -m pip install -U typer
Collecting typer
  Downloading typer-0.3.0-py3-none-any.whl (21 kB)
Requirement already satisfied, skipping upgrade: click<7.2.0,>=7.1.1 in ./.venv/lib/python3.7/site-packages (from typer) (7.1.2)
ERROR: blynclight 0.5.0 has requirement typer<0.0.9,>=0.0.8, but you'll have typer 0.3.0 which is incompatible.
Installing collected packages: typer
  Attempting uninstall: typer
    Found existing installation: typer 0.0.8
    Uninstalling typer-0.0.8:
      Successfully uninstalled typer-0.0.8
Successfully installed typer-0.3.0
(.venv) solid:tmp -> busylight on

[JnyJny]

Experimenting more with the UDEV rules, I've been able to retain control of the light as a non-root user without being in the 'plugdev' group. My 99-busylight.rules file now looks like:

KERNEL=="hidraw*", ATTRS{idVendor}=="2c0d", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2c0d", MODE="0666"
KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", MODE="0666"

04d8 is the vendor_id for the Luxafor Flag product.

[mcnahum]

ok it's interesting ... I have a file 99-blynclight.rules but not a 99-busylight.rules. I tried to create it and put the 4 lines you have on it but still the same issue...

On Tue, Jul 14, 2020 at 9:31 PM Erik OShaughnessy notifications@github.com wrote:

Experimenting more with the UDEV rules, I've been able to retain control of the light as a non-root user without being in the 'plugdev' group. My 99-busylight.rules file now looks like:

KERNEL=="hidraw", ATTRS{idVendor}=="2c0d", MODE="0666" SUBSYSTEM=="usb", ATTRS{idVendor}=="2c0d", MODE="0666" KERNEL=="hidraw", ATTRS{idVendor}=="04d8", MODE="0666" SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", MODE="0666"

04d8 is the vendor_id for the Luxafor Flag product.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/JnyJny/busylight/issues/1#issuecomment-658370867, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMHRFUOL22FTAIRSQXDOILR3SXCFANCNFSM4OZP6KEA .

[JnyJny]

Does this script work?

import hid

d = hid.device()
d.open(0x2c0d, 1)

If it works for the root user and not for a "regular" user, it's a permission problem.

[mcnahum]

how do you recommend I should run it?

On Wed, Jul 15, 2020 at 1:06 AM Erik OShaughnessy notifications@github.com wrote:

Does this script work?

import hid d = hid.device()d.open('02c0d', 1)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/JnyJny/busylight/issues/1#issuecomment-658455681, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMHRFXJRUSXYIO3ZGU7X6LR3TQIDANCNFSM4OZP6KEA .

[JnyJny]

My apologies. I added a gist which you can use to download that script as a file to your RaspPi and run it from the command-line as a non-root user and as the root user.

$ whoami
not-root (your userid)
$ python3 debug.py
<errors>
$ sudo su -
#  python3 ~username/debug.py
<maybe no errors?>

You could also start a python3 interpreter and type it in directly:

$ python3
>>> import hid
>>> d = hid.device()
>>> d.open(0x2c0d, 1)
[errors]

[JnyJny]

As far as the rule files in /etc/udev/rules.d, the name of the file doesn't matter (busylight vs blynclight) it's the contents of the file is important. Could you post the contents of your rules files too?

[mcnahum]

Yes, I now have 3 files, find them below:

cd /etc/udev/rules.d/

pi@raspberrypi:/etc/udev/rules.d $ ls -l total 12 -rw-r--r-- 1 root root 57 May 12 22:36 99-blynclight.rules -rw-r--r-- 1 root root 223 Jul 14 23:23 99-busylight.rules -rw-r--r-- 1 root root 1127 Aug 1 2019 99-com.rules

pi@raspberrypi:/etc/udev/rules.d $ cat 99-blynclight.rules KERNEL=="hidraw*", ATTRS{idVendor}=="2c0d", MODE="0666"

pi@raspberrypi:/etc/udev/rules.d $ cat 99-busylight.rules KERNEL=="hidraw", ATTRS{idVendor}=="2c0d", MODE="0666" SUBSYSTEM=="usb", ATTRS{idVendor}=="2c0d", MODE="0666" KERNEL=="hidraw", ATTRS{idVendor}=="04d8", MODE="0666" SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", MODE="0666"

pi@raspberrypi:/etc/udev/rules.d $ cat 99-com.rules SUBSYSTEM=="input", GROUP="input", MODE="0660" SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660" SUBSYSTEM=="spidev", GROUP="spi", MODE="0660" SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660" SUBSYSTEM=="argon-", GROUP="video", MODE="0660" SUBSYSTEM=="rpivid-", GROUP="video", MODE="0660"

SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660" SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\ chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\ chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\ '" KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\ ALIASES=/proc/device-tree/aliases; \ if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \ echo 0;\ elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \ echo 1; \ else \ exit 1; \ fi\ '", SYMLINK+="serial%c" KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\ ALIASES=/proc/device-tree/aliases; \ if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \ echo 0; \ elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \ echo 1; \ else \ exit 1; \ fi \ '", SYMLINK+="serial%c"

On Wed, Jul 15, 2020 at 4:41 PM Erik OShaughnessy notifications@github.com wrote:

As far as the rule files in /etc/udev/rules.d, the name of the file doesn't matter (busylight vs blynclight) it's the contents of the file is important. Could you post the contents of your rules files too?

[JnyJny]

You can delete the 99-blynclight rules, the 99-busylight rules will work equally well for blynclight as for busylight. I don't see anything in the 99-com rules that affect USB devices. After deleting the file:

# udevadm control -R

And then unplug/plug your USB light. That should reload the rules and then apply them when the device is plugged back in.

[mcnahum]

ok ... I don't know if it's a progress or not ... I now have a real error:

pi@raspberrypi:/etc/udev/rules.d $ busylight on /usr/lib/python3/dist-packages/click/core.py:940: Warning: Invoked legacy parameter callback "<function handl e_color at 0x7687b5d0>". The new signature for such callbacks starting with click 2.0 is (ctx, param, value) . value, args = param.handle_parse_result(ctx, opts, args) Traceback (most recent call last): File "/home/pi/.local/bin/busylight", line 8, in sys.exit(cli()) File "/home/pi/.local/lib/python3.7/site-packages/typer/main.py", line 215, in call return get_command(self)() File "/usr/lib/python3/dist-packages/click/core.py", line 764, in call return self.main(*args, **kwargs) File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main rv = self.invoke(ctx) File "/usr/lib/python3/dist-packages/click/core.py", line 1135, in invoke sub_ctx = cmd.make_context(cmd_name, args, parent=ctx) File "/usr/lib/python3/dist-packages/click/core.py", line 641, in make_context self.parse_args(ctx, args) File "/usr/lib/python3/dist-packages/click/core.py", line 940, in parse_args value, args = param.handle_parse_result(ctx, opts, args) File "/usr/lib/python3/dist-packages/click/core.py", line 1477, in handle_parse_result self.callback, ctx, self, value) File "/usr/lib/python3/dist-packages/click/core.py", line 95, in invoke_param_callback return callback(ctx, value) TypeError: handle_color() takes 1 positional argument but 2 were given

On Wed, Jul 15, 2020 at 6:13 PM Erik OShaughnessy notifications@github.com wrote:

You can delete the 99-blynclight rules, the 99-busylight rules will work equally well for blynclight as for busylight. I don't see anything in the 99-com rules that affect USB devices. After deleting the file:

udevadm control -R

And then unplug/plug your USB light. That should reload the rules and then apply them when the device is plugged back in.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/JnyJny/busylight/issues/1#issuecomment-658846686, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMHRFVO2RPYNAV4L52KTH3R3XIS5ANCNFSM4OZP6KEA .

[JnyJny]

Weird. That is a really old version of click ( latest appears to be 7.1.2 ). Have you tried installing into a virtual environment? This will isolate the installed software from the "system python" and could mitigate these sorts of version mismatches.

For instance:

$ python3 -m venv .venv 
$ source .venv/bin/activate
(.venv) $ pip install busylight-for-humans
(.venv) $ busylight on

[mcnahum]

Thanks, it's worked like a charm I didn't know about this virtual environment option ... with that I was able to identify all modules necessary and found that Typer was not up-to-date

I got this error: ERROR: blynclight 0.5.1 has requirement typer<0.0.9,>=0.0.8, but you'll have typer 0.3.0 which is incompatible.

but the install worked and now it's working :->

Thanks a lot

On Thu, Jul 16, 2020 at 5:15 AM Erik OShaughnessy notifications@github.com wrote:

Weird. That is a really old version of click ( latest appears to be 7.1.2 ). Have you tried installing into a virtual environment? This will isolate the installed software from the "system python" and could mitigate these sorts of version mismatches.

For instance:

$ python3 -m venv .venv $ source .venv/bin/activate(.venv) $ pip install busylight-for-humans(.venv) $ busylight on

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/JnyJny/busylight/issues/1#issuecomment-659132074, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMHRFT652FPM4RDWCHYIVLR3ZWD5ANCNFSM4OZP6KEA .

[mcnahum]

1 extra question there (but I can open a separated subject if needed)

is there, or you plan to have, a timer? e.g. have the light on for 1h

[JnyJny]

I can fix blynclight's inconsistent typer requirement, but consider busylight to be a replacement for it. I'm planning a suite of light-specific command-line interfaces since they have such different capabilities. I'll add blync first since I've already done that one and then probably the Luxafor Flag since it's reasonably simple. I've written initial support of the ThingM blink(1) light which a surprisingly sophisticated device, hoping to push that in the next day or so. I also have acquired a Kuando Busylight Omega which has an interesting programming model for such a seemingly simple device. That one may take a few iterations to get right.

[JnyJny]

WRT to having a timer function, I think the answer is a solid maybe but I would prefer to not incorporate that functionality.

The best way to get the functionality you indicate would be to use either cron or at. The cron facility is used to schedule repeated execution of commands, while at is used to execute a command once at a specific time.

The at command was not installed by default on my RaspPi but was reasonably easy to get:

# apt-get install at
...

Once installed you can use at to schedule the single execution of a command at a specific time ( see man at for usage).

You can use at to schedule busylight to visually indicate your "working" status (assuming busylight installed into /usr/local/bin, use `which busylight` to determine where your installed copy of busylight ended up).

$ echo "/usr/local/bin/busylight on red" | at 8:00AM
$ echo "/usr/local/bin/busylight off" | at 11:30AM
$ echo "/usr/local/bin/busylight blink green" | at 12:55PM
$ echo "/usr/local/bin/busylight on red" | at 1:00PM
$ echo "/usr/local/bin/busylight blink green" | at 4:59PM
$ echo "/usr/local/bin/busylight off" | at 5:00PM

If your schedule is like that every day, then a cron job might be more appropriate. There are many many tutorials on using cron so I'm going skip that example. The advantage here is that the light is operated on and then released for each of those jobs. You can "manually" change the light settings without affecting any of the jobs that will execute in the schedule.

[mcnahum]

Thanks for the feedback. My need is a little bit different, I’m starting the light when I’m starting a meeting and when I’m not alone..

But I could find a way to schedule an off when I run it.

On Thu, 16 Jul 2020 at 18:18, Erik OShaughnessy notifications@github.com wrote:

WRT to having a timer function, I think the answer is a solid maybe but I would prefer to not incorporate that functionality.

The best way to get the functionality you indicate would be to use either cron or at. The cron facility is used to schedule repeated execution of commands, while at is used to execute a command once at a specific time.

The at command was not installed buy default on my RaspPi but was reasonably easy to get:

apt-get install at...

Once installed you can use at to schedule the single execution of a command at a specific time ( cron is used to schedule the repeated execution of commands at a specific time).

You can use at to schedule busylight to visually indicate your "working" status (assuming busylight installed into /usr/local/bin, use which busylight to determine where your installed copy of busylight ended up).

$ echo "/usr/local/bin/busylight on red" | at 8:00AM $ echo "/usr/local/bin/busylight off" | at 11:30AM $ echo "/usr/local/bin/busylight blink green" | at 12:55PM $ echo "/usr/local/bin/busylight on red" | at 1:00PM $ echo "/usr/local/bin/busylight blink green" | at 4:59PM $ echo "/usr/local/bin/busylight off" | at 5:00PM

If your schedule is like that every day, then a cron job might be more appropriate. There are many many tutorials on using cron so I'm going skip that example. The advantage here is that the light is operated on and then released for each of those jobs. You can "manually" change the light settings without affecting any of the jobs that will execute in the schedule.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/JnyJny/busylight/issues/1#issuecomment-659518634, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMHRFRRGGVVZWTD4M3EGLDR34R3RANCNFSM4OZP6KEA .

[JnyJny]

Since the initial problem has been addressed, I'm going to close this issue. Re-open if you run into more problems on the RaspPi.