The default ids used in the qmk_rc_commands_quantum enum range from 1 to 15 - which conflicts with VIA (https://github.com/the-via/qmk_firmware) (and VIAL: https://github.com/vial-kb/vial-qmk).

To even compile firmware using both VIA/VIAL and qmk_rc, the addition of the raw_hid_receive function added needs to be renamed to raw_hid_receive_kb. Even then, VIA doesn't explicitly allow commands other than those that it specifies to be routed from quantum to the keyboard-level handler - which, among other things (such as security concerns), makes VIAL a more attractive option for many.

Reading through the raw_hid_receive function in VIA's source, you'll notice the raw_hid_receive_kb keyboard-level handler is only invoked for a small number of pre-defined commands known to VIA (essentially any command with "CUSTOM" in the command enum's name), and the default at the end of the switch statement simply says it was unhandled and tosses it: https://github.com/the-via/qmk_firmware/blob/master/quantum/via.c#L374

VIAL, on the other hand, passes down anything it doesn't recognize to the keyboard-level handler: https://github.com/vial-kb/vial-qmk/blob/2fc27b48b6aa0638914ae3762576cb694ea4d580/quantum/via.c#L455

Once past these initial hurdles (either modifying the line in VIA's quantum/via.c (the default: case at the end of the giant switch in raw_hid_receive) to add the line VIAL has to call the _kb version, or just use VIAL), you should be able to use custom qmk_rc commands.

Worth mentioning, VIAL makes some changes to VIA's implementation in the name of security, so that without first "unlocking" your keyboard - only a very small subset of commands are allowed (none of which are the unrecognized ones). This can be overridden with the rule "VIAL_INSECURE" if you don't want to go through the unlock process every time you have a hard boot of your board.

However, the OOTB default commands you've graciously already implemented cannot be used, as the IDs conflict with the command enums in VIA (VIAL explicitly does this with an additional Byte, using only a single command_id 0xFE at the very last usable command_id they call the id_vial_prefix - minimizing the likelihood of VIA adding more commands that would eventually conflict - then allowing the following byte in the raw payload to serve as the command id and have their own space to play in with whatever command_ids they want).

Basically, I want all the things. The "easy" way to do this (and I will likely fork your repo and try it that way myself first), would be to change the command_id values in the qmc_rc_commands_quantum to not conflict with VIA's. While this would likely work for a while, as VIA adds more commands - they will take precedent over those of qmk_rc. The "right" (or I should say "A better") way to do this would be to do what VIAL does - making a single command_id (0xFD being the obvious choice) the command_id handled at the "quantum" level (although, in practice, at the kb_level). This pretty much keeps the qmk_rc enums intact, only the code in both qmkrd and the top-level handler in qmk_rc will have to shift one index higher (ie. data[0] = id_qmc_rc_prefix (new, and hardcoded to 0xFD), data[1] = "command_id", etc.).

I want to validate that this will work the easy way first (as the better way requires changes to qmkrd as well), but wanted to get it on your radar in case this is something you may have already thought of. If this is all news to you, I will likely open PRs to both qmk_rc and qmkrd upon your approval (and after I implement the "better" solution, making sure to account for people that don't use VIA/VIAL as well as lazy hackers who like GUIs more than having to flash their board every time they want a new keymap).

(great work, btw - super easy to follow - rest assured you've inspired at least one other person to help expand the audience of this promising qmk extension)

Hi! first of all, thanks for this awesome tool, it's exactly what I was looking for :)

I updated my keyboard's firmware without issues. And I managed to run some commands correctly, for example, these commands are working fine:

$ curl 127.0.0.1:9916/command -XPOST \
  -H 'content-type: application/json' \
  -d '{"id":14,"data":[1]}'

$ curl 127.0.0.1:9916/command -XPOST \
  -H 'content-type: application/json' \
  -d '{"id":8}'

However, when I try to modify the led's color, nothing happens, here is an example:

 $ curl 127.0.0.1:9916/command -XPOST \
  -H 'content-type: application/json' \
  -d '{"id":10,"data":[50,75,90,1,4]}'
{"message":"Command sent","bytes":[0,10,5,0,0,0,50,75,90,10,14,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}%

I copied this command from your documentation, I just changed the command id.

Let me know if I can help with this, I'm not familiar with programming in C, but if you need some debug info or something, let me know!

Thanks!

Currently it's all ints. We should figure out a way to share commands with qmkrcd so that its interface can accept command names. Bonus points for a way to generate commands.md out of that.