todbot / blink1-tool Goto Github PK

View Code? Open in Web Editor NEW

84.0 6.0 15.0 80.1 MB

Command-line tools and C library for blink(1) USB RGB LED

Home Page: https://blink1.thingm.com/

License: Other

Makefile 3.49% C 83.13% Shell 0.78% HTML 0.78% JavaScript 0.71% C++ 11.11%

blink1 usb rgb led hid

blink1-tool's Introduction

Hi there 👋

blink1-tool's People

Contributors

Stargazers

Watchers

Forkers

pearsonk cromagn octavianx dnedrow rjbs bipinmehta normanr chris0607 dannyzen chrma baxeno felfert tatsuyai713 sanketss84 profburke

blink1-tool's Issues

Could you supply FreeBSD devd rules for making the Blink(1) device available to non-root users?

A set of udev rules are supplied for making the Blink(1) device available to non-root users on Linux systems.

FreeBSD does not use udev, but instead uses devd rules, which have a completely different format.

Here is an example of the rules for FreeBSD:

blink1.conf

notify 51 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "ATTACH";
match "vendor" "0x27b8";
match "product" "0x01ed";
action "chmod 666 /dev/$cdev";

The file goes in the /usr/local/etc/devd directory, and you should do a "service devd restart" and unplug/replug your Blink(1) device.

CLI pattern read and write inconsistencies with old blink1 devices

I'm noting a number of inconsistencies when writing patterns to an (admittedly ancient) blink1:

Patterns, e.g. a color, time, index triplet - #ffffff,9.00, 0, are taken in order presented, without regard to specified index.
No matter how many triplets are presented, only 12 are inserted, although 32 are reported.
If more than 12 triplets are pushed, the first triplet is skipped and the last is used as line 0.
Time values reported inconsistently: If I write 1.00 (s) it will be written as 1000 (ms?), but in readpattern will show 500, which is what will be played
Color values reported inconsistently: if I write, e.g. #ff5f00,1.98, 4, I will see writing line 4: ff,5f,00 : 1980 : 4, readpattern will yield #ff1c00,0.99,4,. I don't have a good sense as to how accurate this color is.

I recognize that my hardware may be too ancient to deal with, and I'm comfortable with the workarounds I've found, but thought I'd mention these.

~> blink1-tool --list
blink(1) list: 
id:0 - serialnum:1A00259F  fw version:100
~> blink1-tool -v --writepattern '{0,#999999,9.99,0,#ff0000,0.02,1,#ff0000,1.98,2,#999900,0.02,3,#999900,1.98,4,#00ff00,0.02,5,#00ff00,1.98,6,#009999,0.02,7,,#009999,1.98,8,#0000ff,0.02,9,#0000ff,1.98,10,#990099,0.02,11,#990099,1.98,12}'
deviceId[0] = 0
cached list:
0: serial: '1A00259F' '0002:0004:00'
openById: 0
write pattern: {0,#999999,9.99,0,#ff0000,0.02,1,#ff0000,1.98,2,#999900,0.02,3,#999900,1.98,4,#00ff00,0.02,5,#00ff00,1.98,6,#009999,0.02,7,,#009999,1.98,8,#0000ff,0.02,9,#0000ff,1.98,10,#990099,0.02,11,#990099,1.98,12}
s:'#999999'
s:'#ff0000'
s:'#ff0000'
s:'#999900'
s:'#999900'
s:'#00ff00'
s:'#00ff00'
s:'#009999'
s:'#009999'
s:'#0000ff'
s:'#0000ff'
s:'#990099'
s:'#990099'
writing line 0: 99,99,99 : 9990 : 0
writing line 1: ff,00,00 : 20 : 1
writing line 2: ff,00,00 : 1980 : 2
writing line 3: 99,99,00 : 20 : 3
writing line 4: 99,99,00 : 1980 : 4
writing line 5: 00,ff,00 : 20 : 5
writing line 6: 00,ff,00 : 1980 : 6
writing line 7: 00,99,99 : 20 : 7
writing line 8: 00,99,99 : 1980 : 8
writing line 9: 00,00,ff : 20 : 9
writing line 10: 00,00,ff : 1980 : 10
writing line 11: 99,00,99 : 20 : 11
writing line 12: 99,00,99 : 1980 : 12
~> blink1-tool -v -v --readpattern | sed 'sP,#P,\n#Pg'
deviceId[0] = 0
cached list:
0: serial: '1A00259F' '0002:0004:00'
openById: 0
read pattern:
{0,
#510051,0.99,0,
#ff0000,0.01,1,
#ff0000,0.99,2,
#515100,0.01,3,
#515100,0.99,4,
#00ff00,0.01,5,
#00ff00,0.99,6,
#005151,0.01,7,
#005151,0.99,8,
#0000ff,0.01,9,
#0000ff,0.99,10,
#510051,0.01,11,
#510051,0.99,12,
#510051,0.99,13,
#510051,0.99,14,
#510051,0.99,15,
#510051,0.99,16,
#510051,0.99,17,
#510051,0.99,18,
#510051,0.99,19,
#510051,0.99,20,
#510051,0.99,21,
#510051,0.99,22,
#510051,0.99,23,
#510051,0.99,24,
#510051,0.99,25,
#510051,0.99,26,
#510051,0.99,27,
#510051,0.99,28,
#510051,0.99,29,
#510051,0.99,30,
#510051,0.99,31}
~>

Dual-licensing for APIs like blink1-tool

Perhaps also add MIT license too, or CC-BY-4.0, in addition to CC-BY-SA-4.0.

I think this shouldn't be a problem for the non-hardware, non-firmware aspects of the blink(1) ecosystem.

See todbot/blink1#337

Either hsbtorgb has a problem or I'm completely confused

Hi Tod,

I'm finally getting round to making some updates to my Lua bindings for blink1-lib and I was working on wrapping the hsb to rgb conversion. Now as I understand the color model, hue can be any number between 0 and 360. But in the code it's represented as a uint8_t. So unless I'm missing a trick in the algorithm, I think the algorithm is incorrect.

I'm working on adapting some code from https://blog.adafruit.com/2012/03/14/constant-brightness-hsb-to-rgb-algorithm/ that represents hue with a uint16_t. As soon as I get that implemented and tested, I can open up a PR if you'd like.

Regards,

Matt

blink1-tiny-server doesn't support non-default device

The -d/--id option to blink1control-tool doesn't work with blink1-tiny-server, because blink1-tiny-server uses blink1_open and not blink1_openById

Request for degamma support in pattern related commands

Hey there,

I've noticed the blink1-tool has degamma enabled by default for fade and set light commands, but it's not available for pattern related commands. After poking around the code, it seems like there's no explicit degamma handling there.

If it's possible, could we get degamma added to the pattern commands (setpattern, getpattern etc.) too?

Thanks!

Blink1 not working on raspberry pi 4.

pi@raspberrypi:~ $ git clone https://github.com/todbot/blink1-tool.git
Cloning into 'blink1-tool'...
remote: Enumerating objects: 10681, done.
remote: Counting objects: 100% (225/225), done.
remote: Compressing objects: 100% (145/145), done.
remote: Total 10681 (delta 110), reused 151 (delta 56), pack-reused 10456
Receiving objects: 100% (10681/10681), 79.74 MiB | 10.24 MiB/s, done.
Resolving deltas: 100% (5610/5610), done.
pi@raspberrypi:~ $ cd blink1-tool
pi@raspberrypi:~/blink1-tool $ make
Building blink1-tool for OS=linux BLINK1_VERSION=v2.2.0-linux-armv7l USBLIB_TYPE=HIDAPI
Type 'make help' for other build products
Submodule 'hidapi' (https://github.com/libusb/hidapi.git) registered for path 'hidapi'
Cloning into '/home/pi/blink1-tool/hidapi'...
Submodule path 'hidapi': checked out 'f6d0073fcddbdda24549199445e844971d3c9cef'
gcc -Wall -Wno-format -Wno-pointer-to-int-cast -DUSE_HIDAPI -I./hidapi/hidapi -fPIC -Wall -std=gnu99 -DBLINK1_VERSION="""v2.2.0"-linux-"armv7l""" -c hidapi/linux/hid.c -o hidapi/linux/hid.o
hidapi/linux/hid.c:44:10: fatal error: libudev.h: No such file or directory
#include <libudev.h>
^~~~~~~~~~~
compilation terminated.
make: *** [Makefile:573: hidapi/linux/hid.o] Error 1

I literally just want to use python to visit the web url to activate spcific colors. Easiest thing. Works on my PC, but the device does not respond on the pi

"--version" command reports "v0" when compiling from .zip download

This is because the Makefile has:

GIT_TAG?="$(strip $(shell git tag 2>&1 | tail -1 | cut -f1 -d' '))"
# deal with case of no git or no git tags, check for presence of "v" (i.e. "v1.93")
ifneq ($(findstring v,$(GIT_TAG)), v)
  GIT_TAG:="v0"
endif

which fails in interesting and non-useful ways if you either don't have git or are building from the zip and not a checkout.

`make clean` fails

On FreeBSD 11.2 amd64 (with #14 merged), make clean fails:

gmake[1]: Entering directory '/usr/home/duncan/code/blink1-tool'
rm -f ./hidapi/libusb/hid.o blink1-lib.o
rm -f libblink1.so
rm -f blink1-tiny-server.o blink1-tool.o hiddata.o
rm -f server/mongoose/mongoose.o
rm -f blink1-tool blink1-tiny-server
make -C blink1control-tool clean
make[2]: don't know how to make w. Stop

make[2]: stopped in /usr/home/duncan/code/blink1-tool/blink1control-tool
gmake[1]: *** [GNUmakefile:567: clean] Error 2
gmake[1]: Leaving directory '/usr/home/duncan/code/blink1-tool'
*** Error code 2

Stop.
make: stopped in /usr/home/duncan/code/blink1-tool

how to clean cached device list of blink1-tool?

with -v opt, device info were retrieved from cache, so how to clean that cache, and where is it stored on macos or linux?

Feature request: enable -m flag with --playpattern

I've had several instances where I wanted to eliminate the fade transition from the blink(1) when playing a pattern from the CLI tool. However, it appears that the -m option is ignored when specifying a pattern.

I can work around this problem by repeating a pattern segment with a very short duration first, but this makes the pattern strings rather unwieldy. Here's an example where I alternate red and off for half a second each on opposing sides (similar to a railroad crossing):

blink1-tool.exe --playpattern "0,#000000,0,1,#ff0000,0.1,2,#ff0000,0.5,2,#ff0000,0,1,#000000,0.1,2,#000000,0.5,2"

And here's what it would look like if -m were honored:

blink1-tool.exe --playpattern "0,#000000,0,1,#ff0000,0.5,2,#ff0000,0,1,#000000,0.5,2" -m 0

I'm using version 2.0.2 on Windows 10 Enterprise version 1709.

Blink1 doesn't show up anymore as of 2.1.0

My blink1 mk2 isn't showing up anymore as of blink1-tool 2.1.0. I reverted to blink1-tools 2.0.5 and it is working as expected.

udev rules in place
Debian armv7l

# dpkg -l | egrep "udev|libusb|libhid"
ii  libgudev-1.0-0:armhf                     230-3                                armhf        GObject-based wrapper library for libudev
ii  libhidapi-dev:armhf                      0.8.0~rc1+git20140818.d17db57+dfsg-1 armhf        Multi-Platform library for communication with HID devices (development files)
ii  libhidapi-hidraw0:armhf                  0.8.0~rc1+git20140818.d17db57+dfsg-1 armhf        Multi-Platform library for communication with HID devices (hidraw backend)
ii  libhidapi-libusb0:armhf                  0.8.0~rc1+git20140818.d17db57+dfsg-1 armhf        Multi-Platform library for communication with HID devices (libusb backend)
ii  libinput-bin                             1.6.3-1                              armhf        input device management and event handling library - udev quirks
ii  libudev-dev:armhf                        232-25+deb9u12                       armhf        libudev development files
ii  libudev1:armhf                           232-25+deb9u12                       armhf        libudev shared library
ii  libusb-0.1-4:armhf                       2:0.1.12-30                          armhf        userspace USB programming library
ii  libusb-1.0-0:armhf                       2:1.0.21-1                           armhf        userspace USB programming library
ii  libusb-dev                               2:0.1.12-30                          armhf        userspace USB programming library development files
ii  libusbmuxd4:armhf                        1.0.10-3+b1                          armhf        USB multiplexor daemon for iPhone and iPod Touch devices - library
ii  udev                                     232-25+deb9u12                       armhf        /dev/ and hotplug management daemon

Store servertickle state to blink(1) flash

How feasible would it be to store the last servertickle command to flash? That way if the computer crashes/power cycles and the blink1-tool script doesn't run automatically (maybe stuck at the BIOS screen or something stupid like that), the blink(1) will run the last servertickle sequence that was issued to the device until it receives it's next command signalling everything is OK.

make blink1-tiny-server easier to use

As a customer has pointed out, it's not entirely simple to figure out what this program does.

Move blink1-tiny-server default port to 8934 from 8000

As mentioned in #14 by @mechengineermike, the default port for blink1-tiny-server is (somewhat confusingly) on port 8000 when the Blink1Control2 HTTP REST API port is 8934.

While they are different apps they have a similar enough API that being on the same port would be good.

It would also help with the occasional confusion when users try to have both the Blink1Control2 API server and blink1-tiny-server running at the same time

blink1-tool not working on raspberry pi 3B / 3B+, works on Zero W

Standard instructions for installing blink1-tool do not work on raspberry pi 3B / 3B+, but it does on a zero w. Both with standard updated Raspberry Pi OS with current 5.10.17 kernel.

Looking around the web, apparently there is some problem with udev or modern HIDAPI.
On the 3Bs, blink1-tool --fwversion -v returns cannot open blink(1), bad id or serial number, while it's present via lsusb: Bus 001 Device 004: ID 27b8:01ed ThingM blink(1)

I've tested on a couple of devices in both armv6l and armv7l architecture, same results with official installation.

Anyway mixing info from the python setup I've got it working, so I'm providing a working installation procedure that covers all mentioned cases (and even resetting the usb connection without physical disconnection).

sudo apt-get install -y git coreutils usbutils build-essential pkg-config libudev-dev udev libusb-1.0-0-dev <&-

mkdir -p "$HOME/Blink1_USBLED/usbreset"
cd "$HOME/Blink1_USBLED/usbreset"

# https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line
echo -e "/* usbreset -- send a USB port reset to a USB device */
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>

int main(int argc, char **argv)
{
    const char *filename;
    int fd;
    int rc;

    if (argc != 2) {
        fprintf(stderr, \"Usage: usbreset device-filename\\\n\");
        return 1;
    }
    filename = argv[1];

    fd = open(filename, O_WRONLY);
    if (fd < 0) {
        perror(\"Error opening output file\");
        return 1;
    }

    printf(\"Resetting USB device %s\\\n\", filename);
    rc = ioctl(fd, USBDEVFS_RESET, 0);
    if (rc < 0) {
        perror(\"Error in ioctl\");
        return 1;
    }
    printf(\"Reset successful\\\n\");

    close(fd);
    return 0;
}" > usbreset.c
cc usbreset.c -o usbreset
chmod +x usbreset


cd "$HOME/Blink1_USBLED"
git clone https://github.com/todbot/blink1.git
git clone https://github.com/todbot/blink1-tool.git
cd blink1-tool
make clean
if [[ "$(uname -m)" == "armv6l" ]]; then 
  # raspberry pi zero w
  make
  # https://github.com/todbot/blink1/blob/master/linux/51-blink1.rules
  sudo cp ../blink1/linux/51-blink1.rules /etc/udev/rules.d/
else
  HIDAPI_TYPE=LIBUSB make
  echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="27b8", ATTRS{idProduct}=="01ed", MODE:="666", GROUP="plugdev"' | sudo tee /etc/udev/rules.d/51-blink1.rules
fi
sudo udevadm control --reload
sudo udevadm trigger

if [[ "$(lsusb | grep blink)" != "" ]]; then
  sudo "$HOME/Blink1_USBLED/usbreset/usbreset" "/dev/bus/usb/$(lsusb | grep blink | awk '{print $2}' | sed "s/://g")/$(lsusb | grep blink | awk '{print $4}' | sed "s/://g")"
fi 
sudo cp -f "$HOME/Blink1_USBLED/blink1-tool/blink1-tool" /usr/bin/
sudo chmod a+rx /usr/bin/blink*

# test
cd
which blink1-tool
blink1-tool --version
blink1-tool --list
blink1-tool --fwversion -v

Windows build environment fails to setup

The Cirrus CI / windows task is failing to setup:

C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build>call pacman -S --noconfirm zip unzip 
'pacman' is not recognized as an internal or external command,
operable program or batch file.

You could probably add choco install msys2 to .cirrus.yml to ensure that msys2 (and pacman) are installed before pacman is called.

Move "blink1 tips and tricks" doc from "blink1" to "blink1-tool" repo

Move and update these docs:

Document the `hiddata.c` differences of `blink1-mini-tool`

Both blink1-tool and blink1-mini-tool have a hiddata.c. This is an alternate, simpler and, for Linux, a libusb-0.1-based way of talking to USB HID devices. The normal preferred way is to use hidapi.

The hiddata.c in blink1-mini-tool attempts to detach the (Linux) kernel driver if it has claimed it for the device and then reattach it when done. Some Linux kernel configurations can be zealous about what USB devices it decides to own. At you may expect, detach/reattach can be a dangerous thing to do. So it's relegated to blink1-mini-tool, which is sort of a last-ditch attempt to talk to blink(1) on minimal embedded Linux systems like WRT routers.

This should be documented somewhere. I need to figure out where.

--servertickle doesn't allow setting of start_pos and end_pos

The "--servertickle" functionality in firmware v205 and above allows the specification of a sub-pattern of the larger color pattern with a "start_pos" and an "end_pos" parameter.

blink1-tool currently doesn't expose that functionality.

Enable servertickle in tiny server

It would be great if the web server would also support servertickle; that way it can be easily checked if an external service is running.

Look into "--servertickle 1,1" issue

A user reported that --servertickle 1,1 is causing issue on older blink(1) mk2 devices. I'm not sure how this can be, but it's worth investigating

Got `--add_udev_rules` on Linux? Why?

Got this warning on Linux host, what's that for?

Have you added udev rules? Try blink1-tool --add_udev_rules

blink1-tiny-server: add access log

It would be good to know what clients are accessing blink1-tiny-server.

Build fails using BSD Make

I am running FreeBSD 11.2 amd64. When I run make to build blink1-tool, I receive the following errors:

make: "/usr/home/duncan/code/blink1-tool/Makefile" line 86: Missing dependency operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 88: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 116: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 118: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 120: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 121: warning: duplicate script for target "ifeq" ignored
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 117: warning: using previous script for "ifeq" defined here
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 121: warning: duplicate script for target """" ignored
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 117: warning: using previous script for """" defined here
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 122: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 124: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 125: warning: duplicate script for target "ifeq" ignored
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 117: warning: using previous script for "ifeq" defined here
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 125: warning: duplicate script for target """" ignored
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 117: warning: using previous script for """" defined here
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 126: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 128: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 129: warning: duplicate script for target "ifeq" ignored
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 117: warning: using previous script for "ifeq" defined here
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 129: warning: duplicate script for target """" ignored
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 117: warning: using previous script for """" defined here
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 130: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 132: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 133: warning: duplicate script for target "ifeq" ignored
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 117: warning: using previous script for "ifeq" defined here
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 133: warning: duplicate script for target """" ignored
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 117: warning: using previous script for """" defined here
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 134: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 136: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 138: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 145: Missing dependency operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 147: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 154: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 160: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 168: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 170: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 176: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 191: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 194: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 202: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 206: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 208: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 211: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 227: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 230: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 234: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 240: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 242: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 248: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 250: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 255: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 268: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 271: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 275: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 281: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 283: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 284: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 286: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 291: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 294: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 296: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 306: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 309: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 313: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 319: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 321: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 326: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 337: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 340: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 344: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 350: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 352: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 357: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 368: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 371: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 375: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 381: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 383: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 390: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 396: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 399: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 425: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 428: Need an operator
make: "/usr/home/duncan/code/blink1-tool/Makefile" line 454: Need an operator
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/home/duncan/code/blink1-tool

Heads up regarding blink1control-tool on macOS 11

To be able to run blink1control-tool on macOS 11 (Big Sur), libidn has to be installed first.
At least that was the case on both my Macs running Big Sur.

Homebrew to the rescue:

brew install libidn

Working 👍🏼

`make package-all` downloads an insecure version of curl

See:

https://www.cvedetails.com/vulnerability-list/vendor_id-12682/product_id-25084/version_id-175642/Haxx-Curl-7.37.1.html

For what it's worth, it seems odd that the build process for blink1-tool is downloading and installing curl, especially given that I already have curl and libcurl installed.

blink1-tiny-server doesn't return any response when html is disabled and an invalid url is requested

If blink1-tiny-server is started with --no-html and an unrecognized uri is requested (eg: /404), then the requests is never completed.

Note that echoing the requested uri back to the client (like was done before version 2.3.0) could open up an XSS, so either don't echo the uri back in the response, or ensure that it is appropriately encoded and that correct http response header (Content-type: application/json? X-Content-Type-Options: nosniff?) is set to ensure that browsers interpret the response as json.

Inconsistent Handling of `dmillis` Value Conversion in CLI Tool

Issue:

While reviewing the CLI and firmware code, I noticed a potential error in the dmillis definition of CLI.

Currently, using % 0xff in the CLI tool stored in this repo causes input values like 2550ms to be interpreted as 0ms. However, the firmware code handles the value correctly by treating it as a 16-bit unsigned integer using & 0xff. I suggest using & 0xff instead of % 0xff in the CLI tool for consistent behavior.

Related Code Samples:

From CLI Tool: blink1-lib.c

buf[5] = (dms >> 8);
buf[6] = dms % 0xff;

From Firmware: main.c

uint16_t dmillis = (msgbuf[5] << 8) | msgbuf[6];

Fix:

Please consider updating all the related code in this repo to use & 0xff for consistent handling of the CLI value conversion.

error 404 on release 2.3.0 - blink1control-tool-v2.3.0-windows-x86_64.zip

error 404 on
https://github.com/todbot/blink1-tool/releases/download/v2.3.0/blink1control-tool-v2.3.0-windows-x86_64.zip

Build fails on FreeBSD 11.2

I'm running FreeBSD 11.2 amd64. When I try building blink1-tool with GNU Make via gmake (not BSD Make because of #12), I get the following errors:

Building blink1-tool for OS=freebsd BLINK1_VERSION=v2.0.1-freebsd-amd64 USBLIB_TYPE=HIDAPI
Type 'make help' for other build products
gcc -DUSE_HIDAPI -I./hidapi/hidapi -I/usr/local/include -fPIC -std=gnu99 -g -DBLINK1_VERSION=\"""v2.0.1"-freebsd-"amd64""\" -c hidapi/libusb/hid.c -o hidapi/libusb/hid.o
hidapi/libusb/hid.c:261:19: error: static declaration of 'libusb_get_string_descriptor' follows non-static declaration
 static inline int libusb_get_string_descriptor(libusb_device_handle *dev,
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from hidapi/libusb/hid.c:47:0:
/usr/include/libusb.h:495:5: note: previous declaration of 'libusb_get_string_descriptor' was here
 int libusb_get_string_descriptor(libusb_device_handle * devh, uint8_t desc_index, uint16_t langid, unsigned char *data, int length);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
hidapi/libusb/hid.c: In function 'get_usb_string':
hidapi/libusb/hid.c:374:18: warning: passing argument 2 of 'libiconv' from incompatible pointer type [-Wincompatible-pointer-types]
  res = iconv(ic, &inptr, &inbytes, &outptr, &outbytes);
                  ^
In file included from hidapi/libusb/hid.c:48:0:
/usr/local/include/iconv.h:85:15: note: expected 'char **' but argument is of type 'const char **'
 extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
               ^
gmake: *** [Makefile:506: hidapi/libusb/hid.o] Error 1

Rework "--servertickle" option to be easier to use

Currently you do things like:

blink1-tool --servertickle 1,1,5,7

To say "enable servertickle, stay lit on enable, play sub-pattern 5-7". This is pretty hard to parse. We can do better.

libusb dependency not handled

The corrosponding libusb version required for libusb.h is not found on most machines, and is not handled by the make script for blink1-tool. The following error occured:

setlucas@SetLucas-Lenovo-Z70-KDE:~/blink1-tool$ sudo make
Building blink1-tool for OS=linux BLINK1_VERSION=v2.0.3-linux-x86_64 USBLIB_TYPE=HIDAPI
Type 'make help' for other build products
gcc -DUSE_HIDAPI -I./hidapi/hidapi `pkg-config libusb-1.0 --cflags` -fPIC -std=gnu99 -DBLINK1_VERSION=\"""v2.0.3"-linux-"x86_64""\" -c hidapi/libusb/hid.c -o hidapi/libusb/hid.o
Package libusb-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libusb-1.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libusb-1.0' found
hidapi/libusb/hid.c:47:10: fatal error: libusb.h: No such file or directory
 #include "libusb.h"
          ^~~~~~~~~~
compilation terminated.
Makefile:518: recipe for target 'hidapi/libusb/hid.o' failed
make: *** [hidapi/libusb/hid.o] Error 1
setlucas@SetLucas-Lenovo-Z70-KDE:~/blink1-tool$

Solution for users: sudo apt-get install libusb-1.0-0-dev

Solution for dev install libusb-1.0-0-dev in the make script.

Cannot execute on Raspberry Pi 5 64bit

Hi @todbot I am unable to execute blink1-tool on Raspberry Pi 5 64bit
I have tried
blink1-tool-v2.3.0-linux-armv7l.zip -- Raspberry Pi Raspbian
blink1-tool-v2.3.0-linux-x86_64.zip -- Ubuntu / Debian 64-bit

Debian 64bit gives error: -bash: ./usr/local/bin/blink1-tool: cannot execute binary file: Exec format error
armv7l gives error: -bash: /usr/local/bin/blink1-tool: cannot execute: required file not found

The raspberry pi 5 uses ARMv8

What's the --ledn for?

In HID command https://github.com/todbot/blink1/blob/main/docs/blink1-hid-commands.md

We got Set ledn:

- Set ledn                format: { 1, 'l', n,0,0,       0,0, 0 } (2+)

In blink1-tool https://github.com/todbot/blink1-tool , we got ledn as well:

{"ledn",       required_argument, 0,      'l'},

So what's the command for? I tried to use it, but it seems not working.

Related to: todbot/blink1#673

Add pkg-config support to package

Adding pkg-config support to the project would make it simpler for other applications to take advantage of the blink1 library.

blink1-tiny-server is the status supposed to return current rgb/brightness?

I'm running the blink1-tiny-server as described in the docs. Everything works (setting colors/fadeToRGB etc.). However the status page at the root / or at /blink1 always returns:


{
"version": "v2.2.0-linux-armv7l",
"uri": "/blink1/",
"millis": 0,
"rgb": "#000000",
"ledn": 0,
"bright": 0,
"count": 0,
"status":  "blink1 status"
}

When running blink1-tool --rgbread, I receive the correct values such as: reading led 0 rgb: 0xff,0x00,0x00.

Am I missing something? Can I change something to get the server to return the current RGB values in the status page?

arm 64 bit support - armv8l

Hi, can we please get an arm 64 bit armv8l support package?

Rest API default URL contains double slashes

The default URL is http://localhost:8934/. This causes the generated URL to have double slashes, which causes issues (at least on windows):

c:\blink>blink1control-tool --off -v
set dev: to rgb:0x00,0x00,0x00 over 300 msec
url: http://127.0.0.1:8934//blink1/fadeToRGB?rgb=%23000000&time=0.30&ledn=0&id=`

If I load that in my browser, it displays "Cannot GET //blink1/fadeToRGB"

You can work around it by specifying the URL, without a trailing slash

c:\blink>blink1control-tool -U "http://localhost:8934" --off -v
set dev: to rgb:0x00,0x00,0x00 over 300 msec
url: http://localhost:8934/blink1/fadeToRGB?rgb=%23000000&time=0.30&ledn=0&id=

The incorrect default URL also causes program to crash if you specify the --list command.

Does not build from source archive

Subject says it all:
The build uses git in the prep target to update the hidapi submodule. This fails, because the tgz does
(rightfully) neither contain a .git subdir and only an empty hidapi directory.

In order to do proper packaging (in my case on Fedora), the tgz needs to be self-contained or it
probably should be possible to specify an external hidapi (e.g. Fedora34 has hidapi-devel-0.10.1-3.fc34.x86_64 available)

servertickle stops and restarts with 205 fw

If I issue the following command:

sudo ./blink1-tool --blue
set dev:0:0 to rgb:0x00,0x00,0xff over 300 msec

And then this:
sudo ./blink1-tool -t 2000 --servertickle 1,1,12,15

after two seconds it will start playing pattern 12-15 (as it should). At about 0:35 it will go dark and then at 0:39 it will start back up. At 1:35 it will stop and at 1:39 start back up and it seems to keep doing that forever.

If I issue the servertickle command with a time of 10000 it will stop/start at different times (16s and 20s respectively) and repeat every minute, so there's something odd going on with the pattern play...

blink1_readRGB returns wrong values

Ok, this is probably PEBKAC, but ...

I'm working on updating my Lua wrapper of the Blink library and am having an issue with blink1_readRGB. Below is a minimal C program that demonstrates the problem:

#include <stdio.h>
#include "blink1-lib.h"

int main(int argc, char **argv) {
  blink1_device *d = blink1_open();
  
  uint8_t r, g, b;
  uint16_t millis;
  
  for (int i = 255; i >= 0; i-=10) {
    blink1_setRGB(d, r, g, b);
    r = i; g = i; b = i;
    printf("Setting: %d %d %d -- ", r, g, b);
    blink1_setRGB(d, r, g, b);
    blink1_sleep(250);
    blink1_readRGB(d, &millis, &r, &g, &b, 1);
    printf("Reading: %d %d %d\n", r, g, b);
    blink1_sleep(250);
  }

  return 0;
}

My expectation is that the values returned by the read call should match the preceding set. But that's not the case:

Setting: 255 255 255 -- Reading: 255 255 255
Setting: 245 245 245 -- Reading: 233 233 233
Setting: 235 235 235 -- Reading: 212 212 212
Setting: 225 225 225 -- Reading: 193 193 193
Setting: 215 215 215 -- Reading: 174 174 174
Setting: 205 205 205 -- Reading: 157 157 157
Setting: 195 195 195 -- Reading: 140 140 140
Setting: 185 185 185 -- Reading: 124 124 124
Setting: 175 175 175 -- Reading: 110 110 110
Setting: 165 165 165 -- Reading: 96 96 96
Setting: 155 155 155 -- Reading: 84 84 84
Setting: 145 145 145 -- Reading: 72 72 72
Setting: 135 135 135 -- Reading: 62 62 62
Setting: 125 125 125 -- Reading: 52 52 52
Setting: 115 115 115 -- Reading: 43 43 43
Setting: 105 105 105 -- Reading: 35 35 35
Setting: 95 95 95 -- Reading: 28 28 28
Setting: 85 85 85 -- Reading: 22 22 22
Setting: 75 75 75 -- Reading: 16 16 16
Setting: 65 65 65 -- Reading: 12 12 12
Setting: 55 55 55 -- Reading: 8 8 8
Setting: 45 45 45 -- Reading: 5 5 5
Setting: 35 35 35 -- Reading: 3 3 3
Setting: 25 25 25 -- Reading: 1 1 1
Setting: 15 15 15 -- Reading: 0 0 0
Setting: 5 5 5 -- Reading: 0 0 0

Bug? Or am I making a mistake?

Thanks!

Build produces compiler warning on FreeBSD 11.2

When I build blink1-tool on FreeBSD (with #14 merged), I get the following compiler warning:

hidapi/libusb/hid.c: In function 'get_usb_string':
hidapi/libusb/hid.c:353:18: warning: passing argument 2 of 'libiconv' from incompatible pointer type [-Wincompatible-pointer-types]
  res = iconv(ic, &inptr, &inbytes, &outptr, &outbytes);
                  ^
In file included from hidapi/libusb/hid.c:48:0:
/usr/local/include/iconv.h:85:15: note: expected 'char **' but argument is of type 'const char **'
 extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
               ^

Blink1 turns off after a few seconds

Hi,
Having an issue on Win 11 x64.
Ive got a few Blink1 plugged in.
They are turning off by themselves after 2-3 seconds.
I turn one with something like blink1-tool -d 1 (or -d 0 or -d 2)

Ive gone through Device Manager and turned all USB devices power management off but no luck

MacOS Version Security Error

When I attempt to run blink1-tool on MacOS Sonoma public beta, I get the following error:

servertickle not available in http api

I want to use the mini server to monitor the main service running on my server. Due to how it is set up (containers) the best way is to communicate over the http api.

Unfortunatly the servertickle command does not seem to be available from this api - or it is undocumented.

blink(1) mk2 Error When Executing Commands Only Supported by blink(1) mk1

I'm encountering an issue with the blink(1) mk2 device, where when it attempts to perform a command that is only supported by the blink(1) mk3, it causes the mk2 device to malfunction, returning abnormal results. This issue persists until the device has been power cycled.

Below is the log of commands I executed:

# alias b1t=blink1-tool
# b1t --readnotes
0:
1:
2:
3:
4:
5:
6:
7:
8:
9:
# b1t --eeread 1
eeread:  addr 0x01 = error
# b1t --on
set dev:0:0 to rgb:0xff,0xff,0xff over 300 msec
error on fadeToRGBForDevices
# b1t --list
blink(1) list:
id:0 - serialnum:20005601 (mk2) fw version:-4848

After reboot:

# b1t --list
blink(1) list:
id:0 - serialnum:20005601 (mk2) fw version:204

The '--eeread 1' command is not supported by the mk2 version. As a result, an error was reported or returned 0 (when it works normally). Furthermore, I experienced an error on the fadeToRGBForDevices command, which I suspect is related to the previous faulty operation. After these operations, the firmware version reported for my device appears to fluctuate erratically, which can only be corrected by power cycling the device.

I believe there should be more explicit error handling in this situation, perhaps preventing unsupported commands from running on devices that do not support them, to prevent this erroneous behavior.

eeread and eewrite Returns 0 Constantly for all 0-255 addresses

I'm using the blink1-tool and experiencing an issue with eeread and eewrite commands. They seem to function abnormally, consistently returning zero regardless of their operation.

The version information is as follows:

$ blink1-tool --version
blink1-tool version: v2.3.0-macosx, fw version: 204

Here are the document references I have been referring to:

It seems that it should not be all 0.

Could you please help understand why these commands are not operating as expected? Is there something else required to make them function correctly?

Add global --brightness option

Note: need to add to both "blink1-tool" and "blink1control-tool".
Has implications for gamma-correction. (do it before or after?)

Can't access blink device via hidraw if it's been opened with libusb

I thought that the 2.1.0 release can't find mk1 devices:

$ blink1-tool-v2.1.0 --list
no blink(1) devices found

The 2.0.5 release shows it fine:

$ blink1-tool-v2.0.5 --list
blink(1) list: 
id:0 - serialnum:<omitted> (mk1) fw version:100

but if I re-plug the device then the 2.1.0 release works fine:

$ ./blink1-tool-v2.1.0 --list
blink(1) list: 
id:0 - serialnum:<omitted> (mk1) fw version:100

The device appears as:

$ dmesg
usb 1-3.3.1: New USB device found, idVendor=27b8, idProduct=01ed, bcdDevice= 1.00
usb 1-3.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3.3.1: Product: blink(1)
usb 1-3.3.1: Manufacturer: ThingM
usb 1-3.3.1: SerialNumber: <omitted>
hid-led 0003:27B8:01ED.01A8: hidraw4: USB HID v1.01 Device [ThingM blink(1)] on usb-0000:00:14.0-3.3.1/input0
hid-led 0003:27B8:01ED.01A8: ThingM blink(1) v1 initialized
$ ls /dev/hidraw4
crw-rw---- 1 root plugdev 248, 4 Jun  5 16:50 /dev/hidraw4
$ ls /sys/class/leds/thingm*
'/sys/class/leds/thingm4:blue':
brightness  device  max_brightness  power  subsystem  trigger  uevent

'/sys/class/leds/thingm4:green':
brightness  device  max_brightness  power  subsystem  trigger  uevent

'/sys/class/leds/thingm4:red':
brightness  device  max_brightness  power  subsystem  trigger  uevent

but after running the v2.0.5 binary (nothing extra appears in dmesg):

$ ls /dev/hidraw4
ls: cannot access '/dev/hidraw4': No such file or directory
$ ls /sys/class/leds/thingm*
ls: cannot access '/sys/class/leds/thingm*': No such file or directory

Re-plugging the device is fine if you have one or two of them, not if you have many. Luckily it looks like the device can be re-bound to re-create the hidraw devices:

$ echo -n "1-3.3.1:1.0" | sudo tee /sys/bus/usb/drivers/usbhid/bind > /dev/null

I assume there's not much the blink1-tool could do about this (particularly if running as a non-root user), but the documentation could call this out, and maybe the no blink(1) devices found error message could be updated to suggest running the above command (the hard part is figuring out the device id to rebind)?