Shota Yamazaki

Update: I've made the change (v0.3.0). The receiver steps now send ZMON and SIBD once on every run, even when a read says it's already there, and the read only confirms the result. On my AVC-X6700H, selecting the input it's already on turns out to be a no-op: no telnet event, and no picture or sound dropout. One gate stays. In standby the input isn't sent, since there SI turns the main zone on without changing the input. I also tightened the confirmation. If port 23 doesn't answer and only the HTTP status page matches, the step is now logged as accepted, not reached, because that page can lag by minutes. The README now sorts the rule the way you suggested. A command that sets the state is sent every time, and a toggle like the recorder's POWER still waits for a read. The projector keeps skipping when it's already on, since its status comes straight from the projector over the same connection. Thanks again for the push.

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.

Agreed, the first question is the harder one, because it needs the change behind the incident. The second is easier to start with. A team can ask whether the volume of change put pressure on review, testing, rollout, or observability without pinning the incident on one change.

Thank you. It is cheap, and it works best when two people write it separately and compare.

Thank you for reading it so closely. One clarification on your question. The owner and refresh trigger fields are a general recommendation for teams, not something from LY's talk, so I can't speak for how LY assigns owners. The next article I plan for this series goes further into verification. Your point about writing down the problem and its finish line before anything is generated is close to where it starts, because verification needs something written to check against.

Thank you, really encourages me.