easee: warn on rogue CommandResponse not triggered by evcc

[GrimmiMeloni]

Summary

• Replaces the shared unbuffered cmdC channel with a pendingTicks map[int64]chan SignalRCommandResponse — each outgoing API command registers its tick to a per-tick buffered channel
• CommandResponse() is now the single routing point: known tick → delivers to channel; unknown tick → emits WARN log identifying the charger serial, tick value, and a note that another system may be controlling the charger
• Helps users detect third-party apps (Easee app, another evcc instance, partner integrations) sending commands to their charger unnoticed

Test Plan

• All existing TestEasee_* tests pass (go test ./charger/ -run TestEasee)
• TestEasee_CommandResponse_rogue — verifies unknown tick logs WARN without panic
• TestEasee_CommandResponse_legitimate — verifies known tick is delivered to the registered channel
• Verify go vet ./charger/ is clean
• Observe WARN log in a real evcc trace when Easee app sends a command in parallel

🤖 Generated with Claude Code

[GrimmiMeloni]

WIP - will test this on my local build first.

[GrimmiMeloni]

tested locally, tweaked some minor things, looking good on my end.

[sourcery-ai]

Hey - I've found 2 issues

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="charger/easee.go" line_range="443-444" />
<code_context>
+	chID, idOk := c.pendingByID[obsID]
+	c.cmdMu.Unlock()
+
+	if tickOk {
+		chTick <- res
+		return
+	}
</code_context>
<issue_to_address>
**issue:** Using a blocking send to the tick channel may deadlock if multiple responses are received for the same tick.

When `tickOk` is true, this does an unguarded `chTick <- res`. Since `chTick` has a buffer of 1 in `postJSONAndWait`, a second `CommandResponse` for the same `Ticks` value would block indefinitely and stall the SignalR handler. Consider a non-blocking send (e.g. `select { case chTick <- res: default: /* log/drop duplicate */ }`) or otherwise handling unexpected duplicates explicitly instead of risking a blocking send.
</issue_to_address>

### Comment 2
<location path="charger/easee_test.go" line_range="228-237" />
<code_context>

 		if tc.cmdResp != nil {
 			go func() {
-				e.cmdC <- *tc.cmdResp
+				// wait for postJSONAndWait to register the per-tick channel
+				var ch chan easee.SignalRCommandResponse
+				for {
+					e.cmdMu.Lock()
+					ch = e.pendingTicks[tc.cmdResp.Ticks]
+					e.cmdMu.Unlock()
+					if ch != nil {
+						break
+					}
+					time.Sleep(time.Millisecond)
+				}
+				ch <- *tc.cmdResp
</code_context>
<issue_to_address>
**issue (testing):** Add a timeout in the polling loop to avoid a potentially hanging test

The spin loop that waits for `pendingTicks[tc.cmdResp.Ticks]` has no upper bound, so if registration regresses or the tick value changes, this test can busy-wait indefinitely and hang the suite. Please add a timeout (e.g., `time.After` in a `select`) and fail the test if the channel is not found in time, so issues show up as test failures rather than stuck runs.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue: Using a blocking send to the tick channel may deadlock if multiple responses are received for the same tick.

When tickOk is true, this does an unguarded chTick <- res. Since chTick has a buffer of 1 in postJSONAndWait, a second CommandResponse for the same Ticks value would block indefinitely and stall the SignalR handler. Consider a non-blocking send (e.g. select { case chTick <- res: default: /* log/drop duplicate */ }) or otherwise handling unexpected duplicates explicitly instead of risking a blocking send.

[sourcery-ai]

issue (testing): Add a timeout in the polling loop to avoid a potentially hanging test

The spin loop that waits for pendingTicks[tc.cmdResp.Ticks] has no upper bound, so if registration regresses or the tick value changes, this test can busy-wait indefinitely and hang the suite. Please add a timeout (e.g., time.After in a select) and fail the test if the channel is not found in time, so issues show up as test failures rather than stuck runs.