Verify a fixed ambient sensor isn't picking up heat from the charger itself

[zebraengine]

Context

With a fixed LAN ambient sensor deployed (Ecowitt gateway ingest, zebraengine/tesla-wall-connector#36), its readings take the top tier — they outrank the car sensor and the handle proxy, and the thermal model trusts them completely. That promotes sensor placement from an installation detail to a correctness concern.

The model's premise is handle_temp = ambient + rise. If the ambient sensor is close enough to the connector to be warmed by it, then measured "ambient" climbs whenever charging heats the surrounding air — which cancels out part of the very rise the model exists to measure.

Impact

Two failure modes, both quiet:

• Derate under-prediction, in the unsafe direction. An inflated ambient during a charge shrinks the apparent rise, so the forecast under-estimates how hot the handle will actually get and the suggested cap comes in too high.
• Corrupted degradation baseline. The per-segment fits feed the drift watch. A placement-induced rise suppression looks exactly like an install that is not degrading, so a genuine trend could be masked indefinitely.

How to check

No new instrumentation needed — fit_sessions() already records ambient_drift_c (measured ambient at the end of a load window minus the start) on every session fit, exposed via /api/thermal.

A positive ambient_drift_c is not on its own evidence of contamination: an uninsulated garage genuinely does warm over an afternoon charge, and that is real ambient change the model should be tracking. The tell is the time constant:

• Real garage warming — slow (tens of minutes to hours), does not reverse when current stops.
• Sensor contamination — tracks the handle closely on a scale of minutes, and collapses quickly once charging ends.

The per-sample ambient history is retained, so both can be checked directly against the handle trace for the same window rather than inferred from the aggregate.

Possible outcomes

• Clean — document the placement guidance in the README so the next install gets it right by default: beside or below the cable run rather than above it (a hot handle's convective plume rises), a few feet of horizontal offset, close enough to share the connector's air mass but not close enough to be heated by it, and mounted with an air gap on a low-mass surface rather than pressed against thermal mass.
• Contaminated — relocate, and consider surfacing this as an explicit diagnostic (e.g. flag fits whose ambient_drift_c correlates with charge current) so the failure is loud instead of silent.

Notes

Worth resolving before leaning on measured-ambient fits for degradation conclusions, since the corruption mode is specifically one that hides a real problem rather than inventing a false one.

🤖 Generated with Claude Code

[zebraengine]

Correction to the verification method proposed above

ambient_drift_c is the wrong instrument, for two reasons found while trying to use it.

It inherits gates built for a different question. That field only exists on segments clearing the model's fit-acceptance gates (MIN_SEGMENT_S = 480 s, MIN_RISE_SEEN_C, MAX_FIT_RMSE_C, …). Those gates are correct for what they do — they ensure a segment actually teaches the thermal model something, since fitting an exponential needs enough curvature to constrain the asymptote, and 480 s is ~0.76 of the fitted 10.5 min time constant. But whether a segment is good enough to teach the model is unrelated to whether the sensor is sited correctly. Inheriting those gates discards usable evidence: a six-minute top-off that warms the handle 10 °C is useless for fitting tau and perfectly good for asking whether ambient moved.

Raw drift can't answer it regardless. An uninsulated garage genuinely warms over an afternoon charge — real ambient change the model should track. And a naive correlation actively misleads: on a hot day ambient rises and the handle rises, the handle partly because ambient rose, so shared diurnal trend yields correlation with no coupling at all.

PR zebraengine/tesla-wall-connector#51 replaces the method with a dedicated read-only script computing two discriminators that separate the mechanisms — a detrended correlation (removes slow weather trends, preserves minute-scale tracking) and a snap-back test (a coupled sensor cools when the heat source stops; weather doesn't reverse on cue).

First results

Three testable segments since the sensor was deployed:

08-04 18:20   58 min @ 44.5A    handle 34.9 → 63.9 °C  (+29.0)
   ambient 32.0 → 33.6 (+1.6);  slope during +0.023 → after stop +0.048 °C/min
   detrended r = −0.25

08-05 00:10    6 min @ 47.1A    handle 30.9 → 41.4 (+10.5)   drift  0.0   r = n/a
08-05 05:16    6 min @ 47.1A    handle 28.1 → 39.0 (+10.9)   drift −0.1   r = −0.08

The 58-minute segment is the informative one — long, and the handle reached 63.9 °C — and it also demonstrates why the discriminators matter. Its raw drift is +1.6 °C, which the originally-proposed check would have flagged as suspicious. But ambient rose faster after the charge stopped (+0.048 °C/min) than during it (+0.023), identifying that drift as the garage recovering from an open door rather than charger heat. The detrended correlation is negative, so with the trend removed ambient moved slightly against the handle rather than with it.

The two overnight top-offs are consistent but weak evidence on their own: six minutes and a peak handle of ~40 °C is an easy test, and radiative transfer scales with the fourth power of temperature, so they barely exercise the mechanism.

Remaining before closing

No contamination signature in three segments including one severe test. Worth accumulating a few more long, hot segments with the garage closed throughout before treating it as settled — the strongest available evidence still has an open-door confounder handled by analysis rather than avoided by design.

[zebraengine]

Resolved a confounder: garage door state

The strongest available segment (58 min, handle reaching ~64 °C) had an ambiguity that neither discriminator in PR zebraengine/tesla-wall-connector#51 could settle on its own. Its ambient rose ~+1.6 °C, and the rise happened in the same ten-minute window where the handle was hottest — so "the garage door closed and the space re-warmed" and "the sensor is picking up peak charger heat" predicted the same observation.

Worse, the snap-back test was compromised in a way that isn't obvious. Comparing the ambient slope during the segment against the slope after it looks convincing, but if a door closes partway through the segment, that exact pattern falls out with no information content: the "during" slope averages a door-open stretch with a door-closed one, while the "after" slope is entirely door-closed. It would have been measuring the door, not the sensor. Single-line detrending has the same problem — a door event puts a kink in the trend, and removing a straight line leaves that structure behind.

What fixed it

Independent ground truth on door open/close times, from a source outside the thermal data. That matters methodologically: inferring door events from the same ambient trace you are trying to validate is circular, and the inflection is genuinely ambiguous when read alone.

With door times known, the segment splits into two windows of constant door state:

Window	Door	Handle	Ambient
39 min	open	+27.4 °C (34.9 → 62.3)	−0.6 °C
18 min	closed	+1.5 °C (62.3 → 63.8)	+1.9 °C

The ambient rise occurs in the window where the handle is nearly flat, and ambient declines through the window where the handle climbs 27 °C. That is backwards from coupling, which would track handle heat.

The magnitudes close the loop too: opening the door dropped the space ~3.2 °C, and closing it recovered ~2.6 °C before the overnight decline resumed. The +1.9 °C is fully accounted for by door physics, leaving no residual that needs a charger explanation.

Status

No contamination signature. Two overnight segments agree (no drift against a ~10 °C handle rise), and post-session ambient decayed slowly and linearly rather than tracking the handle's exponential cooling.

Remaining caveat before closing: the cleanest window had the door open, meaning high air exchange that could mask coupling. A long, hot segment with the door closed throughout is the one test still missing.

Generalizable lesson for the placement guidance

Environmental confounders need to be identified from an independent source, not inferred from the ambient trace under test. Worth noting in the README that if a validation segment overlaps a door event, it should be split by door state or discarded — and that a raw drift figure alone can be entirely door-driven.