HomeNetwork/docs/shelly-server-power-negative-analysis.md

# Analysis: `sensor.shelly_server_power_0` Negative Idle Reading

## Scope

Target instance: `home`

Investigated entity: `sensor.shelly_server_power_0`

Question: why the Shelly EM channel reports a negative power value when there is effectively no load, and why that started after previously behaving normally.

## What I Verified

The entity is a direct MQTT-backed device sensor, not a template/helper:

- Entity: `sensor.shelly_server_power_0`
- Platform: `mqtt`
- Unique ID: `shellyem-34945473e228-emeter-power-0`
- Device: `Shelly Server`
- Model: `Shelly EM`
- Firmware: `20230913-114150/v1.14.0-gcb84623`

Current live readings observed during the investigation:

- `sensor.shelly_server_power_0`: about `-12.6 W` to `-13.0 W`
- `sensor.shelly_server_power_1`: `0.00 W`
- `sensor.shelly_server_total_returned_0`: increasing
- `sensor.shelly_server_total_0`: not increasing during the same observation window

This is the critical point: Home Assistant is not merely displaying a signed power value. The device/integration path is also classifying channel 0 energy as returned/exported energy.

Observed behavior during sampling:

- `sensor.shelly_server_power_0` refreshed roughly every 30 seconds and stayed near `-12.8 W`
- `sensor.shelly_server_total_returned_0` increased from `55055.2 Wh` to `55055.4 Wh`
- `sensor.shelly_server_total_0` remained at `1155447.8 Wh`

That combination strongly suggests the Shelly path believes current direction on channel 0 is reversed at idle, not that Home Assistant is simply subtracting or transforming something incorrectly.

## Most Likely Cause

Highest-confidence explanation: channel 0 on the Shelly EM is seeing reversed current direction or a signed measurement offset large enough that the firmware interprets idle noise as export.

In practice that usually means one of these:

1. The CT clamp orientation for channel 0 is reversed relative to the expected power flow direction.
2. The monitored conductor arrangement changed months ago, so the clamp is still physically installed but no longer aligned with the original direction/phase assumptions.
3. The Shelly EM calibration/zero point drifted enough that a small idle offset now crosses zero on the negative side.
4. A Shelly/MQTT discovery behavior change caused Home Assistant to expose the device's signed value and returned-energy counters more faithfully than before.

Given that `total_returned_0` is actively increasing while idle, the first two causes are more likely than a pure UI regression.

## Why This Does Not Look Like a Home Assistant Math Bug

- The entity is not a template sensor.
- The entity comes directly from MQTT discovery for the Shelly EM.
- Home Assistant exposes both forward and returned energy counters separately.
- Channel 1 remains at `0.00 W`, which argues against a system-wide unit/sign issue.
- The behavior is internally consistent: negative instantaneous power is paired with growth in `returned_energy` rather than `total`.

If Home Assistant were incorrectly rendering only the sign, I would expect the energy counters to remain inconsistent or unchanged. They do not.

## Additional Clues

- The device registry still lists some Shelly entities that do not currently resolve through the state API. That suggests the MQTT discovery/device registry state is a bit stale, but it does not explain the negative power reading itself.
- Several sibling entities on this device have `last_updated` timestamps from April 14 while `power_0` and `total_returned_0` are still changing. That suggests channel 0 export-related data is the only part currently showing active movement.
- Firmware is already at the installed/latest version shown by Home Assistant, so there is no obvious pending firmware update to test immediately.

## What I Could Not Prove From This Session

I was able to inspect current entity state, registry metadata, device metadata, integration metadata, and system health through MCP.

I was not able to extract a useful time-series history or relevant HA log lines from the currently exposed MCP tool surface in this session, so I cannot timestamp the exact moment the sign behavior changed. Because of that, I cannot tie the anomaly to a specific restart, firmware flash, MQTT rediscovery event, or wiring intervention from logs alone.

## Likely Root-Cause Ranking

1. CT clamp/channel 0 direction is physically reversed relative to expected load direction.
2. Wiring or what that clamp encloses changed a few months ago, effectively flipping interpreted flow direction.
3. Zero-offset/calibration drift on a very low-load channel is pushing idle around `-13 W`.
4. Firmware or MQTT discovery semantics changed and exposed returned energy where earlier handling masked it.
5. Home Assistant bug in sign handling.

Item 5 is the least likely based on the evidence collected.

## Best Next Checks

These checks should confirm or eliminate the leading hypotheses quickly:

1. Physically inspect CT clamp 0 on the Shelly EM and verify the arrow/direction matches intended consumption flow.
2. Confirm the clamp is still around the same single conductor it was originally monitoring, and not a different leg/path after electrical changes.
3. Temporarily apply a known positive load on the monitored circuit and see whether `sensor.shelly_server_power_0` becomes more negative instead of positive.
4. If safe and practical, reverse the CT clamp orientation or use the Shelly's inversion setting if available in the device UI; the reading should flip sign immediately.
5. Compare the Shelly web UI/raw topic payload for channel 0 against Home Assistant. If the raw device value is already negative, the issue is upstream of HA.

## Practical Conclusion

The anomaly is most likely not caused by Home Assistant itself. The evidence points to the Shelly EM channel 0 measurement path treating idle current as reverse flow, with Home Assistant faithfully exposing that as negative power and increasing returned energy.

If you want the next step automated, the most useful follow-up would be capturing raw MQTT payloads for this Shelly EM or pulling HA history/logs with a tool that exposes recorder/logbook details more directly.