Commander core update

[Meriemi-git]

Add support for the last Corsair Commander Core firmware v2.10.219.
I follow the explanation of ParkerMC to fix the issue, I changed the flow inside the _read_data and _write_data functions to follow the flow described by ParkerMC : set_mode > read / write > reset

I changed the read operation inside _send_command function to read until response starts with 0x00.

After changes to the command flow the tests failed with an "Key Error" at line 117 of file test_commander_core.py.
This is because when i delayed de reset command in read_data and when we start with a set_mode command the _modes array of the Mock device is empty. To prevent this i set in init a None value inside the _modes array.

Fixes: #464

---

Checklist:

• Adhere to the development process
• Conform to the style guide
• Verify that the changes work as expected on real hardware
• Add automated tests cases
• Verify that all (other) automated tests (still) pass
• Update the README and other applicable documentation pages
• Update the liquidctl.8 Linux/Unix/Mac OS man page
• Update or add applicable docs/*guide.md device guides
• Submit relevant data, scripts or dissectors to https://github.com/liquidctl/collected-device-data

New CLI flag?

• [] Adjust the completion scripts in extra/completions/

New device?

• Regenerate extra/linux/71-liquidctl.rules (instructions in the file header)
• Add entry to the README's supported device list with applicable notes (at least en)

New driver?

• Document the protocol in docs/developer/protocol/

[Meriemi-git]

I have test this on my Corsair H150i Elite Capellix with firmware v.2.10.219, it works but i'm not very confident about the few modifications of the unit tests.

[ParkerMc]

Fix looks good. Do you mind adding the flow to the protocol documentation?
I think for the unit test, the main thing is to verify it is closed(reset) before the mode is changed or it is set to sleep mode.

[jonasmalacofilho]

Thanks!

On top of Parker's comment, please see the two notes I left.

[jonasmalacofilho]

To me it seems that the issue is that

# In MockCommanderCoreDevice.write():
if self._modes[channel] is None:

should have always been

if self._modes.get(channel) is None:

What do you think, @ParkerMc?

---

Either way, initializing a dict with a list doesn't feel right.

[Meriemi-git]

@jonasmalacofilho Thanks for your feedback you're right it seems to be a better solution to leave the dict empty. I tested with your suggestion to get the mode and it works.

[jonasmalacofilho]

Please use a personal global gitignore file for editor files, given that they are a personal and therefore vary varied choice. See gitignore for more information, especially the core.excludesFile part.

[Meriemi-git]

It's done.

[Meriemi-git]

@ParkerMc I updated the write function in test to ensure mode is not set whereas previous was not reset. I had to ensure device initially call a reset because of the command flow modification (reset is not the first command anymore) .
I put the initial reset call in the _wake_device_context function but i hesitated between here and in the init function.

I don't see any section in protocol documentation about the command flow but i can create a new one to document this changed for all new firmware versions from v2.10.219

[ParkerMc]

I put the initial reset call in the _wake_device_context function but i hesitated between here and in the init function.

Is that necessary? From my testing, reset is only needed after a write or read.
Hense why I proposed renaming it so it makes more sense (see below)

It should become: open endpoint(currently called set_mode) -> read and/or write -> close endpoint(currently called reset)

I don't see any section in protocol documentation about the command flow but i can create a new one to document this changed for all new firmware versions from v2.10.219

This is the proper use of the protocol so it applies to v1 and v2. I just had the flow wrong but it still worked.

[Meriemi-git]

@ParkerMc You're right, i remove this unnecessary call and update the protocol doc.

[jonasmalacofilho]

@ParkerMc does everything here look good to you?

[ParkerMc]

@ParkerMc does everything here look good to you?

Yeah, looks great. Sorry, I thought I had replied the other day.

[jonasmalacofilho]

Great! Thank you both!