Add CLI for controlling the amplifier from the command line - #8
Add CLI for controlling the amplifier from the command line#8brew-your-own wants to merge 5 commits into
Conversation
Adds `devialet` as an entry point (installed via the `cli` optional extra) with commands: status, volume, mute, power, source. Supports `.env` for optional IP pinning via DEVIALET_IP. Documents CLI usage in README. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Merci, looks good! I'll try to give it a try one of these evenings, when I'm at home (and it's not too hot) |
|
Hi dimitris, any progress with this PR ? |
|
There is something wrong with source selection. With the CLI if I try to select my I tried with the GUI, it seems to work ok there, which is weird. Maybe something with the parsing of the CLI arguments. |
|
I was able to reproduce, indeed the CLI can only do 1 source change. |
Each CLI invocation created a fresh DeviMoteBackEnd, resetting its command sequence counter to 0. The amplifier tracks that counter across commands, so back-to-back CLI runs sent the same counter values again and got treated as stale duplicates - reproduced by comparing a persistent backend (works) vs a fresh one per command (fails switching sources). Persist the counter across invocations in a small per-IP state file, and wrap it modulo 256 in backend.py so it doesn't grow past the single byte it's packed into. Also surface the state file path and current counter in `status`, and document the session state file (and its per-OS location) in the README. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
uv.lock is tool-managed and regenerated by `uv lock`, so a sidecar .license file is used instead of an inline header that uv could strip on the next regeneration (same pattern already used for doc/images/devimote_demo.gif). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
here is an update that should fix the problem, I tested it here. Let me know what you think. |
|
Looks good. From what I've seen the packet counter is never reset? Do you know perhaps what happens if it overflows or if there is a corner case where we might actually need to reset it (e.g. after a full power cycle of the amplifier perhaps) |
I actually changed this, now the counter is calculated like this: So the counter does not overflow. The corner case with the amp itself restarting / rebooting is unclear, indeed. I have not tried this. |
|
Oh, I'm not sure that the modulo 256 is correct here. I don't remember anymore why I did it like this, I have to look again at the wireshark traces, but the packet counter is written to data[3] and data[5], with data[5] having a shifted right by one copy of the packet counter. This means that the amplifier may consider 9 bits (8 from data[3] and 1 extra bit from [data[5]) for the packet counter. I'll do a test script that runs in a loop and checks if settings are still correctly applied once the counter wraps at 256 back to zero. |
Adds
devialetas an entry point (installed via theclioptional extra) with commands: status, volume, mute, power, source. Supports.envfor optional IP pinning via DEVIALET_IP. Documents CLI usage in README.