Parse connections from config.

[kareltucek]

I have bumped the version to 8.0.1 for the sake of our internal config version compatibility.

Closes UltimateHackingKeyboard/agent#2408

(This just parses the targets. It doesn't do anything with them.)

[mondalaci]

Given that this is an extension of the user configuration, not a fix, the minor version should be bumped.

I'll merge this when UltimateHackingKeyboard/agent#2385 gets implemented.

[kareltucek]

Well, it is one that is not backwards compatible (or is it?), so it should major version correctly?

Anyways, the only reason I bumped it is so that it can be merged independently of agent implementation. Given that merging waits for Agent, I think we don't need to bump anything?

[mondalaci]

You're right. The major version should be bumped. But let's leave it this way for now. Maybe we'll only bump the major version before merging the UHK 80 repos into the official repos.

[ert78gb]

I am starting to working on Agent side of this PR. I think worth to rebase or update this branch with the firmware80/master because many thing has been modified in the firmware, that affect the firmware upgrade process

[ert78gb]

I implemented the Agent side requirements in the UltimateHackingKeyboard/agent80#84 PR.

I restarted the CI to generate the firmware artifact. I flashed the firmware with it
I also changed the user config version to 8.1.0
I can successfully save the modified user config.
But after I restart the Agent it reads the old user config from the keyboard. I think it is old because the user config version is 8.1.0

@kareltucek If you will have time could you check it. Thy

[kareltucek]

@ert78gb

I have found and resolved some problems on my side and written some better logging to help troubleshoot cases like these. At the moment, I am encountering this:

usb target 1 
name 5 77 121 32 80 67 

ble target 3 
addres 18 52 86 120 144 171 
name 0 

20 remaining targets:

0 0 0 0 0
110: 0 0 0 0 0 0 0 0 0 0
120: 0 0 0 0 0 
0 0 0 0 0

125: Finished parsing targets here.

What exactly are those zeroes between addresses 125 and 145?

[ert78gb]

What exactly are those zeroes between addresses 125 and 145?

I don't know what are the zeros.

If you start Agent with npm run electron -- -- -- --log=all you could see what are the responses of the status buffer query.
Maybe I parse incorrectly the status buffer but it worked earlier. I parse every response as a zero end string with UTF8 encoding. It is the same method that we use in other places.

I just copy the first iteration of the status buffer from my computer

[UhkHidDevice] USB[W]: 04 12 05
USB[R]: 04 00 39 30 3a 20 53 74 61 72 74 65 64 20 70 61 72 73 69 6e 67 20 74 61 72 67 65 74 73 20 68 65 72 65 2e 0a 38 30 3a 20 32 35 35 20 32 35 35 20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 0a

04 is the report id
00 is the status code
The remaining is the "message"

the message parsed as UTF8 string is

90: Started parsing targets here.
80: 255 255 0 0 0 0 0 0 0 0

The status buffer contains so many 20 30 pair that is <SPACE>0 in utf8

Based on it Agent reads and parses properly the status buffer. I added more log entry to Agent for easer follow the status buffer reading.

Somewhere I read somewhere in other comment Agent hides the error message of the save configuration event.
Every time when Agent sent the user configuration or when sent the "apply configuration` command the firmware returned with non zero status code.
When I save the user config I got 0 status code for every command. This is the reason of Agent not recognise any error

[ert78gb]

or do you ask why are the extra zeros maybe because I send the name for Empty targets to. Maybe I miss read your code earlier, but now I recognised you don't expect any data for Empty target

[kareltucek]

Oh, sorry. The numbers are the relevant parts of the serialized configuration, each number describing one byte. They make sense until address ~125.

Around address 128, the parser errors out when trying to read number of keymaps and it encounters 0.

The above comment describes meaning of the byte sequences as interpretted by me. I believe that targets section should (in the above screenshot) end at address 124.

It seems like you are saving 20 (or so) extra zero bytes that the firmware doesn't expect.

[kareltucek]

As to not returning error codes, I see the problem. Will fix it soon.

[ert78gb]

I also fix the Agent. Now I don't serialise name of the Empty target. And firmware successfully save and returns with the save user configuration

[ert78gb]

thanks for your help

[mondalaci]

It finally works!

Please rename targets to connections according to the new naming across the codebase.

[kareltucek]

"Connection" is a darn generic term. It is going to get mixed up with a number of other connections across the codebase. Wouldn't it be better to use something less ambiguous internally, and use "connections" only in UI and macro language?

What about something like "hid target"?

[mondalaci]

How about the previously proposed "host connection" term? If not, HID target can work.

[kareltucek]

Sounds great! Will "rebrand" that in an hour. (Already got scripts for this kind of thing 😃.)

[mondalaci]

Looks like there are some debug statements left in the code. Wanna remove them before I merge this PR?

[kareltucek]

Oh, yes, forgotten about them!

[kareltucek]

Done.