Coerce null identifier to empty string

[SBoudrias]

Problem

Since ~2026-09-10, the Hilo cloud returns a null serial/identifier for the Hilo gateway. HiloDevice.update() stores identifier=None, and the HA integration (dvd-dev/hilo) builds every entity unique id as f"{device.identifier.lower()}-...". On None this raises AttributeError: 'NoneType' object has no attribute 'lower', and because the gateway entities are constructed first, the entire hilo sensor platform fails to set up — every Hilo sensor (challenge, rates, reward, weather, meter power) goes unavailable until the integration is fixed.

Observed on our host every boot from 2026-09-10 to 2026-10-09 (14 boots), on python-hilo 2026.3.5 + hilo 2026.8.3:

2026-10-09 14:18:38.825 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up hilo platform for sensor: 'NoneType' object has no attribute 'lower'
Traceback (most recent call last):
  File "/config/custom_components/hilo/sensor.py", line 193, in async_setup_entry
    new_entities.extend(generate_entities_from_device(d, hilo, scan_interval))
  File "/config/custom_components/hilo/sensor.py", line 116, in generate_entities_from_device
    HiloChallengeSensor(hilo, device, scan_interval),
  File "/config/custom_components/hilo/sensor.py", line 988, in __init__
    self._attr_unique_id = f"{device.identifier.lower()}-{slugify(self._attr_name)}"
AttributeError: 'NoneType' object has no attribute 'lower'

Fix

Coerce None back to the empty string in HiloDevice.update(). The empty string is what the cloud used to return, so existing device-registry entries and entity unique ids (e.g. -defi_hilo) keep matching.

Also checked: _build_gateway_dict in graphql.py can still emit identifier: None when the MAC can't be extracted from hiloId; with this guard in place that path is safe too.

Testing

• New regression test: TestHiloDevice::test_identifier_none_coerces_to_empty_string
• Full suite: 67 passed
• Validated live on our host since 2026-10-09 (the equivalent coercion patch in the HA integration): all 35 Hilo sensors restored, no crash in the boot log since.

[Moustachauve]

I assume this date "2026-09-10" is today? Or is it September 10th?

If it is today, I'd strongly recommend always using ISO date format to avoid confusion.

[SBoudrias]

Hi — the mypy 'unreachable' failure from the first push is fixed (commit 6ffa3ec: explained type: ignore[unreachable] on the guard, since the cloud genuinely sends nulls beyond the declared kwargs type; mypy, ruff and the 67-test suite pass locally). The new CI runs sit in 'action_required' awaiting first-time-contributor workflow approval — could you approve/re-run when you get a chance? Merci!

[SBoudrias]

Merci for the review over on dvd-dev/hilo#1070 — closing this companion PR as moot. We upgraded to hilo 2026.10.1 (+ python-hilo 2026.9.1) today, so the deprecated REST gateway path (the null dsn source) is no longer used and the guard isn't needed. Our legacy empty-keyed entities didn't migrate automatically; we resolved them with a one-time entity-registry migration onto the historic entity_ids, and everything has been clean since — no duplicates, no orphans. Thanks again for the detailed explanation of the graphql path!