For the receiver, you can remove the stale-match risk instead of guarding against it, because it takes absolute commands. Denon's published telnet protocol has SIBD to select Blu-ray and PWON to power on, and each one names the target state rather than flipping the current one. So I'd send SIBD even when the read says already, then confirm on port 23. It's still one command per step, not a resend, and a stale HTTP value can now only delay the confirmation. It can't skip the step and log a success.
Read before send stays the right rule for the recorder, where the only key is a toggle and a wrong read turns it back off. Sorting each device by whether its command is absolute or a toggle tells you where a read has to gate the send and where it only confirms the result.
Thanks, good point. Sending SIBD once without reading first isn't a resend. The result no longer depends on the read being right, and the read is only there to confirm. It also fixes a weak spot in my current code. If port 23 doesn't answer, the sequence trusts the HTTP value, so a stale value can still end up as already in the log.
One thing I've seen on my receiver (AVC-X6700H). In standby, SI[code] turns the main zone on but doesn't change the input. So I still need to check the power first. Once the zone is on, I can send SIBD every time. For power, I send ZMON (main zone only), which also sets the state directly.
I like your idea of sorting devices by whether their command sets the state or toggles it. It's clearer than the "read first" rule I wrote. Changing the plugin that way is one option, and I'd like to think it over a bit.
For the receiver, you can remove the stale-match risk instead of guarding against it, because it takes absolute commands. Denon's published telnet protocol has SIBD to select Blu-ray and PWON to power on, and each one names the target state rather than flipping the current one. So I'd send SIBD even when the read says already, then confirm on port 23. It's still one command per step, not a resend, and a stale HTTP value can now only delay the confirmation. It can't skip the step and log a success.
Read before send stays the right rule for the recorder, where the only key is a toggle and a wrong read turns it back off. Sorting each device by whether its command is absolute or a toggle tells you where a read has to gate the send and where it only confirms the result.