Errors when executing commands over USB on UHK60v2

spoodle · May 1, 2025, 10:47am

Just started noticing this a couple days ago. Not sure if this should be posted to GitHub, since maybe I’m holding it wrong. My original context is rather different from what’s shown here, but here’s the minimal reproducible example I’ve arrived at:

Call a command over USB, such as setLedTxt or set backlight.keyRgb.base.*
Call printStatus over USB
“ERR” is now displayed on UHK
Call printStatus, get shown error message saying Unrecognized command: <some fragment of the original command from step 1>

Here are two examples, one with setLedTxt, one with set backlight. (Note: I’m using the “tee” version of the UHK command script that Max posted here to show what’s being sent to the UHK.)

$ uhkcmd setLedTxt 500 "ABC"
setLedTxt 500 ABC
$ uhkcmd printStatus
printStatus
$ uhkcmd printStatus
printStatus
$ Error at  1/2/1: Unrecognized command: 0> 2 | 0 ABCError at  1/2/1: Unrecognized command: 0> 2 | 0 ABC

$ uhkcmd set backlight.keyRgb.base.1 51 192 0
set backlight.keyRgb.base.1 51 192 0
$ uhkcmd printStatus
printStatus
$ uhkcmd printStatus
printStatus
$ Error at  1/2/1: Unrecognized command: t.keyRgb.base.1> 2 | t.keyRgb.base.1 51 192 0Error at  1/2/1: Unrecognized command: t.keyRgb.base.1> 2 | t.keyRgb.base.1 51 192 0

From my testing, executing these macro commands from a macro did not cause the same problem, even with an intervening delayUntil to replicate the pause between my manual executions of uhkcmd.

The closest GitHub issue I found is 993, but that’s now closed and looks like it was for the UHK80 anyway.

For my testing purposes, I’ve reset my UHK’s configuration to default. I first noticed this problem on firmware 13.0.0, and have done most of my troubleshooting on 13.0.2.

spoodle · May 1, 2025, 11:30am

I forgot to note: the issued commands (e.g. setLedTxt) all seem to actually work without issue. Even after the error status is triggered, further issued commands continue to work.

spoodle · May 1, 2025, 1:25pm

Added some file locking to uhkcmd to queue concurrent calls/prevent simultaneous writes to the /dev/hidraw device. Just in case I there’s something on my system calling uhkcmd that I hadn’t already disabled for troubleshooting.

#!/bin/bash
# if flock is installed, use it to queue calls to this script
if command -v flock > /dev/null; then
	exec 42<"$0" || exit 1
	flock -x 42
fi
hidraw=`grep 'UHK 60' /sys/class/hidraw/hidraw*/device/uevent | LC_ALL=C sort -rh | head -n 1 | grep -o 'hidraw[0-9][0-9]*'`
echo -e "\x14$*" | tee "/dev/$hidraw"

kareltucek · May 2, 2025, 3:00pm

Is your Agent running? If so, please close it and powercycle the UHK, then retry.

(If no, then powercycle the UHK and retry anyways please.)

spoodle · May 2, 2025, 7:20pm

Thanks, Karel. I hadn’t actually thought to close Agent before, I don’t think.

But unfortunately, those steps didn’t change anything.

I’ve booted into an older kernel (Fedora’s 6.14.2-300.fc42.x86_64) whose release predates my problem (and I’m moderately sure I was running it before the problem as well).

I’m going to try to get my hands on a USB drive and boot another OS to try and isolate that aspect. But I don’t know when I’ll be able to do that.

Do you make anything of the fact that commands that are “unrecognized” (e.g. 0 or t.keyRgb.base.1) are both 13 characters into the command string?

Also, I just randomly got newlines (and enter-key presses?) when replicating again. I can only intermittently replicate the newlines.

$ uhkcmd setLedTxt 512 "ABC"
setLedTxt 512 ABC
$ uhkcmd printStatus
printStatus
$ uhkcmd printStatus
printStatus
$ Error at  1/2/1: Unrecognized command: 2
> 2 |bash: Error: command not found...
 2 ABC
Error at  1/2/1: Unrecognized command: 2
> 2 | 2 ABC
$ > 2 | 2 ABC
bash: 2: command not found...
$ Error at  1/2/1: Unrecognized command: 2
bash: Error: command not found...
$ > 2 | 2 ABC
bash: 2: command not found...

kareltucek · May 2, 2025, 7:27pm

The 13 character part is strange, but it doesnt ring any bell. I have tried your commands and they worked fine for me with 13.0.2 development firmware.

If you post your UserConfig, I am happy to retest with it.

(Please generally use printStatus in a text editor ;-).)

spoodle · May 2, 2025, 8:08pm

Super. Here is the config in pastebin kinda thing (not sure if there is a better way to share configs since json/txt/et al. aren’t allowed as attachments). I’ve commented out the clearStatuses that I added as workarounds to shut the UHK up.

Grepping throught my ~/.config, these are the only two places where I call uhkcmd:
uhkcmd "setLedTxt 0 '$statusstring'" > /dev/null &
uhkcmd "exec bellPause" > /dev/null &

kareltucek · May 6, 2025, 8:41am

Sorry, I have forgotten about this!

I have tested with your UserConfig, and everything still works fine with both mine and max’s script.

Let’s dive deeper. Please flash this firmware:

uhk-firmware-13.0.2-cut_macro_hunt-v1.1.tar.gz

Then:

Remove any macro events from your UserConfig (either backup your config, or just prefix them with ‘_’…)
Save the config.
Kill Agent.
Run your uhkcmd command. (Exactly one command. Not a sequence of uhkcmd calls.)
Open Agent again.
Copy and paste the log.

I am seeing this:

spoodle · June 22, 2025, 11:22am

Hey Karel, sorry! I must have not seen the email notification that you had replied to me–that’s normally how I know to come back to the forum and check. My bad!

It seems like that link for the firmware you provided has expired or something. If you are able to post it again, I’ll make sure to attend more closely to the forum so as not to waste your time.

kareltucek · June 26, 2025, 12:35pm

I can still download it fine, but maybe github treats me specially as a logged user?

Try to download it from here: Exec macro command over usb issues · Issue #1285 · UltimateHackingKeyboard/firmware · GitHub

spoodle · June 27, 2025, 6:04pm

Thanks, Karel. The original link is working for me too now. Idk what was up there.

(Everything below is using the stock configuration that Agent provides when clicking “Reset device configuration.”)

Following your instructions and running exactly one uhkcmd, I get the same as you:

Received string: 'setLedTxt 5000 ABC
'
Copied string: 'setLedTxt 5000 ABC
'
Processing command 'setLedTxt 5000 ABC'
Processing command 'setLedTxt 5000 ABC'
Processing command ''

And I know you said only one uhkcmd…but just in case, here’s what happens when I do uhkcmd setLedTxt 500 ABC; sleep 1; uhkcmd noOp:

500 + noOp => error

Received string: 'setLedTxt 500 ABC
'
Copied string: 'setLedTxt 500 ABC
'
Processing command 'setLedTxt 500 ABC'
Processing command 'setLedTxt 500 ABC'
Processing command ''
Received string: 'noOp
dTxt 500 ABC
'
Copied string: 'noOp
dTxt 500 ABC
'
Processing command 'noOp'
Processing command 'noOp'
Processing command ''
Processing command 'dTxt 500 ABC'
Error at  1/2/1: Unrecognized command: dTxt
> 2 | dTxt 500 ABC

Curiously enough, if I change 500 to 5000, no such error happens. It’s like the no-op was never received.

5000 + noOp => no error

Received string: 'setLedTxt 5000 ABC
'
Copied string: 'setLedTxt 5000 ABC
'
Processing command 'setLedTxt 5000 ABC'
Processing command 'setLedTxt 5000 ABC'
Processing command ''

Doing 0500 is basically the same as plain 500 (i.e. error):

0500 + noOp => error

Received string: 'setLedTxt 0500 ABC
'
Copied string: 'setLedTxt 0500 ABC
'
Processing command 'setLedTxt 0500 ABC'
Processing command 'setLedTxt 0500 ABC'
Processing command ''
Received string: 'noOp
dTxt 0500 ABC
'
Copied string: 'noOp
dTxt 0500 ABC
'
Processing command 'noOp'
Processing command 'noOp'
Processing command ''
Processing command 'dTxt 0500 ABC'
Error at  1/2/1: Unrecognized command: dTxt
> 2 | dTxt 0500 ABC

kareltucek · June 30, 2025, 1:33pm

Hmm, this actually sheds some light on it. Great job!

kareltucek · June 30, 2025, 3:01pm

Alright, this is embarassing. The firmware expects the string to be null terminated. If it isn’t, the two commands get mingled in one buffer.

Now the question is who should be blamed for this.

Certainly the hid raw command should explicitly include the null delimiter:

#!/bin/bash
# if flock is installed, use it to queue calls to this script
if command -v flock > /dev/null; then
	exec 42<"$0" || exit 1
	flock -x 42
fi
hidraw=`grep 'UHK 60' /sys/class/hidraw/hidraw*/device/uevent | LC_ALL=C sort -rh | head -n 1 | grep -o 'hidraw[0-9][0-9]*'`
echo -e "\x14$*\x00" | tee "/dev/$hidraw"

And almost as certainly, the firmware should zero the buffer before receiving new data, which it unfortunately doesn’t…

Anyways, I am pushing a bunch of fixes to Fix things around usb macro commands. by kareltucek · Pull Request #1291 · UltimateHackingKeyboard/firmware · GitHub, opening an agent issue (as it seems that the agent also doesn’t include the delimiter), and suggest you to include that explicit null delimiter in your uhkcmd script.

spoodle · June 30, 2025, 3:52pm

This is great, Karel! I can confirm that all looks good now, even having removed the handful of clearStatus calls from my config

Thanks for digging into this! You (and of course the rest of the fine people on here) make this a great forum to come to. I definitely don’t take it for granted that the actual firmware dev shows up and is helpful.

kareltucek · June 30, 2025, 10:49pm

Thanks for reporting odd behaviors like these!

Keeping the macro engine running wouldn’t be possible without the community feedback!