`_map_power` silently coerces `power.value: None` to `0`, masking missing telemetry as a real zero reading

[njloof]

Describe the bug

When Hilo's SignalR onAnyDeviceUpdated subscription reports a device's power attribute
as {"value": null, "kind": "WATT"} (i.e. Hilo itself has no current power reading for the
device), GraphqlValueMapper._map_power converts that None into 0 before it ever becomes
a DeviceReading:

def _map_power(self, device: Dict[str, Any]) -> Dict[str, Any]:
    value = device["power"]["value"] if device["power"]["value"] is not None else 0
    return self.build_attribute(
        device["hiloId"],
        "Power",
        self._power_kw_to_w(value, device["power"]["kind"]),
    )

By the time this reaches the hilo HA integration's PowerSensor.state
(str(int(self._device.get_value("power", 0)))), the distinction between "Hilo has no power
data for this device right now" and "Hilo confirms this device is drawing 0W" is already gone.
The sensor reports a normal-looking 0 — not unknown/unavailable — so there's no visual or
programmatic signal that the reading is missing rather than genuinely zero.

_map_heating has the same pattern (power.value is not None and value > 0 else not heating),
so a missing power reading is also silently interpreted as "not heating."

Impact

On our install (Home Assistant Green, HA Core 2026.9.0, Hilo integration v2026.8.2/pyhilo
installed via HACS), the following device types have been reporting power.value: None from
Hilo's backend continuously since at least Aug 26, 2026 (confirmed via custom_components.hilo

• pyhilo debug logging over ~2 weeks of history):

• lowvoltagetstat (Sinope24V HVAC thermostat, model TH6250WF)
• cee (SinopeWaterHeater, model RM3500WF)
• unknown_source_tracker (Hilo's own "Unknown Source Tracker" device)

All of the corresponding sensor.*_power entities, and any utility_meter/energy-integration
sensors derived from them, have been flatlined at exactly 0 for the entire period — which is
indistinguishable from "device draws no power" without cross-referencing an independent power
source. We only caught it by comparing whole-home Hydro Quebec hourly grid consumption against
these devices' reported states and noticing the power sensors never moved despite the grid
showing multi-hundred-watt swings correlated with HVAC hvac_action.

We don't know whether the None values originate from a real gap in Hilo's own telemetry for
these device types, or from something specific to our account/hardware — but either way, the
client shouldn't present "no data" as a confident zero.

Suggested fix

In _map_power (and _map_heating), preserve None rather than coercing to 0:

def _map_power(self, device: Dict[str, Any]) -> Dict[str, Any]:
    raw = device["power"]["value"]
    value = self._power_kw_to_w(raw, device["power"]["kind"]) if raw is not None else None
    return self.build_attribute(device["hiloId"], "Power", value)

This would let DeviceReading.value be None, and the hilo HA integration's PowerSensor
could then report unavailable/unknown instead of 0 when the underlying reading is
genuinely absent (that part would need a corresponding change in dvd-dev/hilo's
PowerSensor.state, since get_value("power", 0) currently defaults missing/None values to
0 as well — happy to file that as a follow-up over there once the semantics here are agreed).

Steps to reproduce

1. Install pyhilo-based Hilo integration for a location with a Sinope24V HVAC thermostat,
   SinopeWaterHeater, or a location using "track unknown sources."
2. Enable debug logging for custom_components.hilo and pyhilo.
3. Observe Received subscription result {'onAnyDeviceUpdated': ... 'power': {'value': None, ...}}
   in the logs for the affected device.
4. Observe the immediately following [<Device>] Received <Reading power 0W> log line — the
   None has already become 0.
5. The corresponding sensor.<device>_power entity in Home Assistant shows 0, not
   unavailable.

Environment

• Home Assistant OS 18.2, Core 2026.9.0, Home Assistant Green
• Hilo integration v2026.8.2 (HACS)
• pyhilo (bundled dependency of the above)

[ic-dev21]

Sinopé's stuff is cloud to cloud and I believe does not report power values to hilo's backend, I would have to double check that.

If you can't see the power values in the app, the component can't either.

Low voltage stuff didn't exist for Hilo back when this was written and I own no such devices so cannot really develop anything for them either. I have to rely on third parties or contacts at Hilo for that part.

[njloof]

Confirmed — checked the Hilo app directly and it doesn't show a power value for these devices either. Makes sense given how the hardware works: this thermostat (TH6250WF) only knows it's opening/closing a 24V relay signal to the HVAC equipment, it has no actual current/wattage sensing on that circuit. So there's no power figure for Hilo's backend to relay in the first place — this isn't a dropped reading, it's a device class with no power-sensing capability at all.

Given that, I think the fix is still worth making, maybe more so: _map_power currently has no way to distinguish "this device has a power sensor and it read 0W" from "this device has no power-sensing capability, full stop." Right now both cases produce the same power.value: None from the API and the same 0 after _map_power, so sensor.<device>_power permanently shows a confident-looking 0 for a device that was never capable of measuring power to begin with.

Preserving None instead of coercing to 0 would let that distinction surface as unavailable in HA, which seems like a more honest representation than a numeric zero for a channel that was never instrumented. Alternatively, if that's more churn than it's worth, it might also be reasonable not to create a sensor.*_power entity at all for device types/models that are known to never report power (e.g. low-voltage relay thermostats) — happy to help identify which models/device types those are if that's a direction you'd rather go.

Either way, thanks for digging into the hardware side — that answers the open question from my last comment.

[ic-dev21]

Confirmed — checked the Hilo app directly and it doesn't show a power value for these devices either. Makes sense given how the hardware works: this thermostat (TH6250WF) only knows it's opening/closing a 24V relay signal to the HVAC equipment, it has no actual current/wattage sensing on that circuit. So there's no power figure for Hilo's backend to relay in the first place — this isn't a dropped reading, it's a device class with no power-sensing capability at all.

Given that, I think the fix is still worth making, maybe more so: _map_power currently has no way to distinguish "this device has a power sensor and it read 0W" from "this device has no power-sensing capability, full stop." Right now both cases produce the same power.value: None from the API and the same 0 after _map_power, so sensor.<device>_power permanently shows a confident-looking 0 for a device that was never capable of measuring power to begin with.

Preserving None instead of coercing to 0 would let that distinction surface as unavailable in HA, which seems like a more honest representation than a numeric zero for a channel that was never instrumented. Alternatively, if that's more churn than it's worth, it might also be reasonable not to create a sensor.*_power entity at all for device types/models that are known to never report power (e.g. low-voltage relay thermostats) — happy to help identify which models/device types those are if that's a direction you'd rather go.

Either way, thanks for digging into the hardware side — that answers the open question from my last comment.

I think the actual best way to do this would be to build the devices according to telemetry rather than creating a blanket power sensor for each device whether it actually has one, or not.

This should be already working in this piece of logic, we probably just need to add the TH6250WF to the list of unmonitored devices:

https://github.com/dvd-dev/hilo/blob/039bed1a24ee818eb9a51f03d217d35491f00465/custom_components/hilo/sensor.py#L137-L138

[njloof]

Correction on RM3500WF: it does report real wattage (~4400W) when actually heating — confirmed by testing directly. The None we saw was just it being idle at the time. So that one's not affected by this issue; should have checked before including it. This issue is specific to TH6250WF.

TH6250WF added to UNMONITORED_DEVICES works for that one.

Let me know if you'd like a PR.

[ic-dev21]

Correction on RM3500WF: it does report real wattage (~4400W) when actually heating — confirmed by testing directly. The None we saw was just it being idle at the time. So that one's not affected by this issue; should have checked before including it. This issue is specific to TH6250WF.

TH6250WF added to UNMONITORED_DEVICES works for that one.

Let me know if you'd like a PR.

By all means, you deserve the credit for it. I'll use that in the next release @njloof