multiple smibhids reporting data

[samcorky]

How should we handle this?

Currently, smib accepts data from any "smibhid" device, and when the /howfresh command is run, it finds the latest log from any of the devices and outputs it, split by sensor.

Sensor data and sensor unit data are stored alongside the device that reported it.

Should we merge the data if they use the same measurement/units?
Should we merge the same sensors?
Should we display one SMIBHID after another?
Should smibhid report a "zone" or should smib have config to "zone" devices, and then group by zone?

Open to any ideas!

[samcorky]

/howfresh has changed in #525 to, by default, show only a handful of sensor readings, averaged out. The full readout will still be accessible by /howfresh detailed

[samcorky]

Per-device config overrides via nested pydantic-settings, using a device map

RelayStatePluginConfig (src/plugins/space/relaystate/config.py) is currently a single set of settings — relay_name, alert channels, thresholds, resend intervals, and the message template all apply the same way to every SMIBHID device reporting relay state, even though each device already gets its own RelayState document keyed on hostname. Fine with one relay in the space, but breaks down as soon as two devices are tracking physically different things (e.g. an extractor fan filter vs. a server rack fan) with different lifespans/owners/channels. This isn't relaystate-specific either — it's the general shape of "one global plugin config, N devices" that any smibhid-facing plugin could eventually hit.

pydantic-settings already supports parsing nested structures from env vars via env_nested_delimiter, so this doesn't need a second config system or a schema migration — just a device map sitting alongside the existing global fields, where anything left unset per-device falls back to the global default:

class RelayDeviceConfig(BaseModel):
    # every field optional — set only what you want to override for that device;
    # anything unset falls back to the global default above
    relay_name: str | None = None
    relay_lifetime_warning_threshold: IntervalField | None = None
    relay_lifetime_alert_channel_id: str | None = None
    drift_warning_alert_channel_id: str | None = None
    # ...extend as needed; mirrors whichever global fields make sense per-device

class RelayStatePluginConfig(EnvBaseSettings):
    # existing global fields stay as-is, acting as the defaults
    ...
    device: dict[str, RelayDeviceConfig] = Field(default_factory=dict)

    model_config = {
        "env_prefix": "SMIB_PLUGIN_SPACE_RELAY_STATE_",
        "env_nested_delimiter": "__",
    }

With env_nested_delimiter = "__", an operator sets one flat KEY=VALUE per device/field — consistent with how every other setting in .env/template.env already looks, no JSON blob required:

SMIB_PLUGIN_SPACE_RELAY_STATE_DEVICE__SMIBHID_DEV__RELAY_NAME=Extractor Fan Filter
SMIB_PLUGIN_SPACE_RELAY_STATE_DEVICE__SMIBHID_DEV__RELAY_LIFETIME_WARNING_THRESHOLD=P90D
SMIB_PLUGIN_SPACE_RELAY_STATE_DEVICE__SMIBHID_SAM__RELAY_NAME=Server Rack Fan

Then a small resolver, called wherever code currently reads config.xxx for a specific device (the drift/relay-lifetime checks and the Slack message builders in common.py):

def get_config_for_device(device: str) -> RelayStatePluginConfig:
    override = config.device.get(device)
    if override is None:
        return config
    return config.model_copy(update=override.model_dump(exclude_none=True))

Devices with no entry in device keep behaving exactly as today — empty map = fully backward compatible, nothing required to change for existing single-relay setups. The RelayDeviceConfig/resolver pattern itself isn't tied to relaystate; any plugin with global-but-arguably-per-device settings could reuse the same shape.

Happy to split this into its own issue if that's cleaner than folding it into this one — same underlying itch as the sensor-zoning question here, just a narrower/simpler slice of it.