Has something changed in the flashing of the modules?
I can flash the firmware for the two halves but I just cannot seem to get the modules to get updated.
Flashing modules via uhk80 is not supported yet.
There has been no changes to module code for ages, and probably won’t be in any forseeable future, so no worries ;-).
1 Like
FYI to future readers: This answer is apparently not up-to-date as of (at least) 2025-06: I was just able to flash a new key cluster module attached to the LHS of UHK80.
On the other hand! Instructions in the firmware update window were not adequate for me! It refused to flash the LHS of the UHK80 and insisted I either a) disconnect the USB cable from the RHS and plug it into the LHS OR b) use a second USB cable. Neither worked! Finally I disconnected the phone cord connecting LHS to RHS and it immediately flashed the LHS. So, suggestion: Firmware update program should remind users to NOT connect LHS to RHS when flashing firmware.
(So now running 14.0.1 on RHS, LHS, and key cluster just fine.)
Wow, this doesn’t seem right at all…
To be clear; when you were able to finally flash the left-half, was it (LHS) connected to USB while it flashed (even though the bridge cable was disconnected)? I’m pretty sure both halves of the UHK80 MUST flash over USB in order to flash at all…?
1 Like
On first try - only RHS connected via USB, bridge cable attached - it flashed the RHS then refused to flash the LHS. After fiddling around, on nth try - both halves connected via (separate) USB, bridge cable removed - it flashed the LHS and the key module.
Ok, that weirded me out for a second. 
I’m not sure what the latest module FW is supposed to be, but I don’t think it’s had an update since like the end of 2023…
If you restart Agent, and press the UHK80’s reset buttons, does you module FW version show something different?
I only have the touchpad module, and it’s FW is implemented by the right-half, so it doesn’t get updates.
Maybe it didn’t update the module firmware but just checked it and then the UI said it had done the upgrade. The log shows:
- [DeviceService] Left module firmware version: null
- [DeviceService] Left module remote firmware checksum: null
- [DeviceService] Left module built firmware checksum: 628e2b535f3c722456e2985f6a0157d1
- [DeviceService] To continue the firmware upgrade, now connect the left half via USB. (You can disconnect the right half or use a second USB cable.)
Ah! The Agent tooltip shows “The module runs firmware 14.0.1 (binary identical to previously installed firmware 13.0.2); no updated needed.” So it just checked it.
1 Like
I still don’t think the null part looks right in your log snippet. I’d try unplugging the bridge cable again and then force re-flash the latest v14.1.0, (not v14.0.1). Maybe save your logs as well, just in case.
Question for devs-
In the following sections of the UHK FW logs;
Can someone confirm if the word “module” here refers to the detachable modules (Trackball/Trackpoint/Touchpad/Key Cluster), or to the main left/right halves of the board themselves?
I just want to clarify since I still get “Left module” checksums, even though I’ve never had anything but a Touchpad module. Might help clear up confusion for those trying to decipher the logs…
[DeviceOperation] Read "leftHalf" version information
[DeviceOperation] Read "leftHalf" repo information
[DeviceOperation] Read "leftHalf" firmware checksum
[DeviceOperation] Read "rightModule" version information
[DeviceOperation] Read "rightModule" repo information
[DeviceOperation] Read "rightModule" firmware checksum
[DeviceService] User configuration will be saved after right module firmware upgrade
[SmartMacroService] start downloading firmware documentation {"firmwareGitRepo":"UltimateHackingKeyboard/firmware","firmwareGitTag":"216affa"}
[SmartMacroService] firmware documentation downloading
[UhkHidDevice] Device communication closing.
[UhkHidDevice] Device communication closed.
[DeviceService] Left module firmware version: 14.1.0
[DeviceService] Left module remote firmware checksum: 642ecbd9ea59cf3074491b7647ba4088
[DeviceService] Left module built firmware checksum: 790b02591f8e4e7f64af3e829dce83b3
I have bumped Robert to take a look at it (and the request still stands), but for all its worth…
- 642ecbd9ea59cf3074491b7647ba4088 is uhk80 left half 14.1.0 checksum, as can be verified in the package.json packed inside the firmware tar. This is the checksum of the firmware that is actually running on the left half.
- 790b02591f8e4e7f64af3e829dce83b3 is the checksum of the uhk80 left half firmware that the currently-flashed uhk80 right half firmware was built with (i.e., the 790b02 is checksum of the firmware that should be running on the left half). Given the log, it is a non-tagged firmware on commit
216affa. My guess is that it was taken from a CI artifact. - Hypotheses:
- The log messages may have been written before actual modules were introduced. I.e., at the times when the only two devices were the right half and the left half/module.
- Context: uhk60 left half is a module (in uhk terminology). This means that it exposes a bunch of interfaces on I2C and lets drivers implemented in the right half control various aspects of the module (one interface is the “uhk module interface” which reports key states, another driver controls backlight, another module flashing… basically uhk60 left half has no brain of its own) . In other words it behaves just the same as actual modules.
- We (I?) made a terrible mess with the checksum handling, which we have later fixed by a relatively large refactor of the device/module usb commands, during which the semantics of those commands changed. It is easily possible that the logs weren’t altered to reflect these changes.
- The log messages may have been written before actual modules were introduced. I.e., at the times when the only two devices were the right half and the left half/module.
1 Like
FYI, w.r.t. “My guess is that it was taken from a CI artifact” - this is an install of the official 7.0.1, most probably via the “check for update” feature. (Possibly I explicitly downloaded it from the release page, therefore, an official tag, but I certainly didn’t pick an arbitrary commit and build it…)
Actually, that snippet I posted was just to show a comparison from my UHK80 flashing from v14.1.0 (Release version) > v14.1.0-216affa (global_macro_report_state branch) Thats the FW I’m testing for the new global/persistent macro features over in the Gaming Config (Tips & Tricks?) thread.
•Both halves USB to host PC
•Bridge cable connected
•Dongle & Touchpad
BTW, if anyone ever needs to see em, I’ve been keeping all my FLogs & corresponding UART logs with notes & connection details for several months. Here’s the checksums for the other components in case anyone’s interested:
[DeviceService] Current Dongle built firmware checksum: f7480f470319e8eb67aa26693d0e51d3
[DeviceService] New Dongle firmware checksum: 4d015a75f5fe07e14c3ce0aaaa48eff9
[UhkOperations] UHK Dongle firmware successfully flashed
[DeviceService] Current Device right built firmware checksum: 821b304c41d3b96f70ec2ef5ab3f1d79
[DeviceService] New Device right firmware checksum: e7df60c709ae6f9af1042f196f63e498
[UhkOperations] UHK 80 right firmware successfully flashed
[DeviceService] Left module firmware version: 14.1.0
[DeviceService] Left module remote firmware checksum: 642ecbd9ea59cf3074491b7647ba4088
[DeviceService] Left module built firmware checksum: 790b02591f8e4e7f64af3e829dce83b3
[UhkOperations] UHK 80 left firmware successfully flashed
1 Like
[DeviceService] Left module firmware version: null
The null value weird for me too.
@davidbak please run the Agent with -- --log=misc,usb,usbOps command line argument. And please attach the whole log.
You can find it in the following path
- on Linux: ~/.config/uhk-agent/uhk-agent.log
- on macOS: ~/Library/Logs/uhk-agent/uhk-agent.log
- on Windows: %USERPROFILE%\AppData\Roaming\uhk-agent/uhk-agent.log
1 Like
Uploaded to gist at UHK Agent log after upgrading to UHK80 - possibly showing issue related to flashing LHS keyboard half · GitHub. Everything from 2025-06-11 which is when I removed my trusty UHK60 and attached my new (birthday!) UHK80. I went in and out of Agent several times though. The last bit from 2025-06-12 is today with the command line flags you suggested.
Thank you for the logs, but looks like the end of the logs are missing.
Maybe it is a gist limit.
Key cluster upgraded
Anyway I checked the earlier log entries and it does not contains [DeviceService] "Key cluster" firmware version: lines so the modules of the left and right half were not updated.
Left half is not enumerated
To be clear; when you were able to finally flash the left-half, was it (LHS) connected to USB while it flashed (even though the bridge cable was disconnected)? I’m pretty sure both halves of the UHK80 MUST flash over USB in order to flash at all…?
@kareltucek I also experience same issue randomly on mac. But I can’t reproduce it. The earlier opened firmware issue UHK80 left half not available if the right half connects first · Issue #1030 · UltimateHackingKeyboard/firmware · GitHub
Sometimes I have to use the reset button of the keyboard to enumerate the left half when the keyboard has battery.
Left module firmware version: null or undefined
@davidbak I recognised the following log entries
[2025-06-11 08:49:33.023] [info] [DeviceService] Left module firmware version: undefined
[2025-06-11 08:49:33.023] [info] [DeviceService] Left module remote firmware checksum: undefined
[2025-06-11 08:49:33.024] [info] [DeviceService] Left module built firmware checksum: 628e2b535f3c722456e2985f6a0157d1
The weird thing in this log entry is the undefined value. The undefined alone is weird but with extra space more weird.
The extra space is also in the front of 628e2b535f3c722456e2985f6a0157d1 value
I don’t find any log entry that contains null value.
I would like to investigate what is the reason of it, but the command line argument is not correctly passed to Agent.
I left my windows machine on other location so I could not test what is the perfect command line argument syntax on windows in cmd or in powershell.
The log contains only the USB transfer messages USB[T]. Maybe only the last entry after the comma had been parsed. I need the misc and USB read USB[R] and USB write USB[W] lines too properly investigate it. Maybe you have to use " to value like -- --log="misc,usb,usbOps"
Ihe argument setting is correct if the logs will contains same line like
...
20:24:50.107 › [UhkHidDevice] USB[T]: Get device state
20:24:50.107 › [UhkHidDevice] USB[W]: 00 09
20:24:50.110 › [UhkHidDevice] USB[R]: 00 00 01 01 00 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
Perhaps I didn’t understand which logs you wanted …
Here, after starting agent with -- --log=all are logs from the firmware update: I pressed the button to do the update, then pressed NO when it asked me if I wanted to force update since the firmware was up to date.
this link should be pointing at a new comment at the end of the previously posted gist
I assumed the words “left module” in my logs were referring to the left-keyboard half, but the confirmation from you and Karel is good to know. Since I only have a Touchpad module (which doesn’t receive its own updates), I’ve never seen the above line in my flash logs. Am I correct to assume the Trackball and Trackpoint modules would be named similarly to [DeviceService] "Key cluster" firmware version if they are updated?
Perhaps I didn’t understand which logs you wanted …
The logs are perfect in the referenced comment. Sorry, my english is far from perfect.
Based on the new logs Agent could read the correct checksum and other information. Looks like we would not find the reason of the null and undefined values.
I found the extra space “inserted” by the log component when concatenates 2 log arguments. I think it is a new feature of the log component. I will adjust our log message to prevent this “miss reading” in the future.
1 Like
Yes. agent/packages/uhk-common/src/models/uhk-products.ts at 03924209571011d3a81971594eb378ebcfa94162 · UltimateHackingKeyboard/agent · GitHub find the module name.
I think I have to use the Left keyboard half official module name instead of Left module.
4 Likes
Thanks!
I agree that using Left keyboard half would probably be better. 
1 Like