Skip to content
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.

Sign up for GitHub

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

Jump to bottom

tested on Raspberry Pi: error message ... #1

Closed
mcnahum opened this issue Jul 14, 2020 · 23 comments
Closed

tested on Raspberry Pi: error message ... #1

mcnahum opened this issue Jul 14, 2020 · 23 comments

Comments

@mcnahum
Copy link

mcnahum commented Jul 14, 2020

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
Copy link
Owner

JnyJny commented Jul 14, 2020

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
Copy link
Author

mcnahum commented Jul 14, 2020

good catch! installation completed

@mcnahum mcnahum closed this as completed Jul 14, 2020
@mcnahum mcnahum reopened this Jul 14, 2020
@mcnahum
Copy link
Author

mcnahum commented Jul 14, 2020

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
Copy link
Owner

JnyJny commented Jul 14, 2020

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
Copy link
Author

mcnahum commented Jul 14, 2020

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
Copy link
Owner

JnyJny commented Jul 14, 2020

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
Copy link
Owner

JnyJny commented Jul 14, 2020 •
edited

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
Copy link
Owner

JnyJny commented Jul 14, 2020

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
Copy link
Author

mcnahum commented Jul 14, 2020 via email

@JnyJny
Copy link
Owner

JnyJny commented Jul 14, 2020 •
edited

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
Copy link
Author

mcnahum commented Jul 15, 2020 via email

@JnyJny
Copy link
Owner

JnyJny commented Jul 15, 2020 •
edited

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
Copy link
Owner

JnyJny commented Jul 15, 2020

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
Copy link
Author

mcnahum commented Jul 15, 2020 via email •
edited by JnyJny

@JnyJny
Copy link
Owner

JnyJny commented Jul 15, 2020

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
Copy link
Author

mcnahum commented Jul 15, 2020 via email

@JnyJny
Copy link
Owner

JnyJny commented Jul 16, 2020

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
Copy link
Author

mcnahum commented Jul 16, 2020 via email

@mcnahum
Copy link
Author

mcnahum commented Jul 16, 2020

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
Copy link
Owner

JnyJny commented Jul 16, 2020 •
edited

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
Copy link
Owner

JnyJny commented Jul 16, 2020 •
edited

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
Copy link
Author

mcnahum commented Jul 16, 2020 via email

@JnyJny
Copy link
Owner

JnyJny commented Jul 19, 2020

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.

@JnyJny JnyJny closed this as completed Jul 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@JnyJny @mcnahum