A house-mode-change evt.pd7.notify is broadcast on the hub component
(component "hub", id "mode"), not component "mode". The previous guard
`notify.component !== 'mode'` discarded every real mode-change notification, so
the Mode select only updated via the 30s poll fallback instead of in real time.
Gate on component "hub" (and, defensively, "mode") and extract the new mode
from either param.mode.current (primefimp Hub/HubMode) or param.current
(edge-iqcontrols/tpflow references), publishing only when a mode string is
found.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FuQAyPde4K57P2XMCKbFek
The Futurehome Modeswitch (Modusbryter) is a house-mode switch: its buttons
change the hub's mode (Home/Away/Sleep/Vacation), which is a hub-level Vinculum
concept broadcast via `evt.pd7.notify` (component "mode") — not a device
`scene_ctrl` event. That is why tapping it produced nothing in the device
message stream and the mapped scene sensor was stuck on `unknown`.
The add-on had no house-mode support at all. This adds it:
- Expose the current house mode as a `Mode` select on the Smarthub device.
It reflects the current mode, updates in real time via `evt.pd7.notify`
(with a 30s house-poll fallback), and can change the mode from Home Assistant
via `cmd.pd7.request {cmd:"set", component:"mode", id:<mode>}` (matching the
reference primefimp `ChangeMode`).
- Always publish the Smarthub hub device so the Mode select is available even
without Thingsplex credentials; inclusion/exclusion tooling stays gated.
- Discover available modes from the Vinculum `mode` component, falling back to
home/away/sleep/vacation.
Also improve genuine scene controllers: `scene_ctrl` now additionally exposes a
Home Assistant `event` entity so momentary button presses can drive automations
(the previous `Scene` sensor latched and could not react to repeated presses).
The sensor is kept for backwards compatibility (renamed "Scene (last value)").
Includes demo-mode support, README/CHANGELOG updates, and a version bump to
1.7.0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FuQAyPde4K57P2XMCKbFek
HA 2026.5 enforces strict validation of device_class/unit_of_measurement
pairs in MQTT discovery payloads. Four categories were broken:
- power_factor: unit was sent as "power_factor" (the FIMP field name); HA
requires the field to be omitted or empty for this device class. Fixed by
normalising the display unit separately from the FIMP data-path key.
- illuminance: unit "Lux" is rejected; normalise to "lx". When a sensor
reports luminance as "%" (some Z-Wave devices), the illuminance device
class is dropped so the entity becomes a generic sensor rather than
triggering a validation error.
- reactive_power (regular/export meter): unit "VAr" is rejected; HA requires
lowercase "var".
- reactive_power (extended meter values, e.g. p_import_react): the unit
determination logic fell through to the generic power branch and sent "W";
reactive power extended values now emit "var", apparent power values emit
"VA", and reactive energy values emit "kvarh".
Fixes#31
Co-authored-by: Claude <noreply@anthropic.com>
