v1.1.3

Release v1.1.3

Release Date: 2026-06-27

Type: Patch release - Makes MQTT topic validation reliable regardless of the device's Tasmota
TelePeriod, and clarifies AUX control requirements.

What's Changed

🐛 Fixed

• Topic validation no longer times out on devices with the default Tasmota TelePeriod. During manual
  setup, manual discovery, and reconfigure, the integration validates the entered MQTT topic by subscribing
  to tele/{topic}/SENSOR and waiting for a NeoPool message. Tasmota's default TelePeriod is 300s and
  SENSOR is published non-retained, so the 10-second validation window almost always expired — and a
  perfectly correct topic failed with "Could not receive messages from this MQTT topic", with no indication
  that the only problem was timing. _validate_yaml_topic now publishes an immediate telemetry trigger
  (reusing the existing _trigger_telemetry helper) right after subscribing, so validation succeeds within a
  couple of seconds regardless of TelePeriod — no Tasmota console workaround needed. As a fallback for
  genuine failures (wrong topic / device offline), the cannot_connect error message now also hints to set
  TelePeriod 10 in the Tasmota console, translated across all 10 supported languages. Reported in
  #18 by @megaherb — thank you for the precise diagnosis!

📝 Documentation

• Clarified that AUX1–4 control requires the Tasmota Berry NeoPool command extension (ESP32). NPAux<n>
  is not a built-in Tasmota command — this is by design, not a bug, per the NeoPool driver author. Without
  the Berry extension, AUX state reads work but toggles are ignored by the firmware. The
  NPAux<n> entry in docs/TASMOTA_NEOPOOL_DRIVER_REFERENCE.md (previously framed as a "firmware quirk"
  with a Power<gpio>/NPWrite workaround) was reworded, and a note was added to the README AUX switches
  feature.

Full Changelog: compare/v1.1.2...v1.1.3

v1.1.2

Release v1.1.2

Release Date: 2026-05-31

Type: Patch release - Fixes a bug that prevented clearing the optional recovery script in the Options flow.

What's Changed

🐛 Fixed

• Recovery script can now be cleared via the Options flow. The recovery-script EntitySelector in the
  Options form used vol.Optional(CONF_RECOVERY_SCRIPT, default=...). When a user cleared the field and
  submitted, Home Assistant sends the key absent from the form data, and voluptuous then refilled it
  from default= — so the cleared submission silently carried the old saved value, which got written
  straight back to the config entry. The result: the script could never be removed through the UI (re-opening
  the form still showed it), and it kept executing on the next connection failure. The fix switches to
  description={"suggested_value": recovery_script}, which pre-fills the form for display without
  re-injecting the value on an empty submission. A blank field now flows through to the saved options and the
  downstream reader resolves it to the default empty string. This was the only Options-flow field affected —
  every other field is vol.Required (boolean/number, always submitted), so none of them could be
  resurrected the same way.

Full Changelog: compare/v1.1.1...v1.1.2

v1.1.1

Release v1.1.1

[][release]

Release Date: 2026-05-28

Type: Patch release - Two fixes for v1.1.0's new throttle and restore-state mechanics. This release
notes file consolidates everything since v0.2.19, the same way v1.1.0's did, so users updating from any
v1.0.x or v1.1.0 can see the complete picture in one place.

What's new in v1.1.1 (since v1.1.0)

🐛 Fixed

• HA default polling no longer bypasses the throttle on cumulative counters and
  controller_time (should_poll fix).
  NeoPool entities inherited Home Assistant's default should_poll = True, so HA's
  ~30-second polling cycle called async_write_ha_state() on its own schedule and
  silently bypassed the min_update_interval throttle introduced in v1.1.0. The
  connection cumulative counters were ending up at ~30 s recorder cadence (matching
  the polling interval) instead of the intended hourly. Fix: set
  _attr_should_poll = False on NeoPoolEntity. All NeoPool entities are
  MQTT-push driven, so polling was redundant anyway. After this update the
  connection counters write to the recorder at most once per hour as designed, and
  sensor.controller_time at most once per 5 minutes.

• Cumulative entities now recover their last value across v1.0.x → v1.1.0 upgrades.
  When v1.1.0 swapped the NeoPoolSensor (no RestoreEntity mixin) for the new
  NeoPoolCumulativeSensor (which is a RestoreEntity), the restore-state cache
  had nothing for these entities — so the cumulative restarted from 0 on the first
  v1.1.0 startup, leaving a visible drop in the entity history graph.
  NeoPoolCumulativeSensor.async_added_to_hass now has a two-tier restore: first
  try RestoreEntity (the fast path, works for v1.1.0+ restarts), then fall back
  to a recorder query for the most recent recorded state of the entity_id. The
  fallback is gracefully skipped if the recorder integration isn't loaded or if
  no prior history exists. Anyone going through a similar class-swap upgrade in
  the future won't see their cumulative reset.

  Note: this fix is forward-looking — it doesn't recover the cumulative for
  anyone who already upgraded to v1.1.0 and lost the value (the entity history is
  what it is now). But HA's TOTAL_INCREASING reset handling in the statistics
  engine kept the long-term aggregate coherent regardless, so the hourly /
  daily / monthly stats graphs (Developer Tools → Statistics) are unaffected by
  the v1.1.0 discontinuity.

Previously in v1.1.0 (carried forward — full context for any pre-v1.1.1 build)

✨ Added — Module coverage (originally v1.0.0)

• Chlorine sensor and setpoint: sensor.chlorine_data (ppm) and number.chlorine_setpoint (0–10 ppm,
  via NPChlorine) for NeoPool controllers with the chlorine module.
• Conductivity sensor: sensor.conductivity_data (%) for controllers with the conductivity module.
  Firmware emits this as a flat scalar (NeoPool.Conductivity), not a nested object.
• Hydrolysis detail sensors: three read-only sensors for hydrolysis diagnostics —
  sensor.hydrolysis_setpoint_gh (g/h setpoint), sensor.hydrolysis_max (max capacity in g/h), and
  sensor.hydrolysis_unit (unit string reported by device).
• Hydrolysis Redox Controlled: binary sensor (NeoPool.Hydrolysis.Redox) indicating whether
  hydrolysis production is being controlled by the redox system.
• Controller Time sensor: diagnostic sensor showing the NeoPool controller's internal clock.
  Displayed as a raw string (no TIMESTAMP device class — the firmware string has no timezone info).
• Sync Controller Time button: sends NPTime 0 to sync the controller clock to Tasmota's current
  time.
• Driver reference documentation: new docs/TASMOTA_NEOPOOL_DRIVER_REFERENCE.md with firmware
  internals — Modbus registers, ResponseAppend_P lines, kNPCommands table, and driver quirks.

✨ Added — Lovelace dashboards (originally v1.0.1)

• Four ready-to-use example dashboards under
  lovelace/ — two for
  fresh installs and two for users who migrated from the YAML package. Each pair has a full-width
  desktop layout (mushroom cards + masonry 400 px) and a mobile-friendly responsive layout (tile cards +
  masonry 320 px).

  • Fresh install:
    ha_neopool_lovelace.yaml
    and
    ha_neopool_lovelace_responsive.yaml.
  • Migrated from the YAML package (entity IDs still neopool_mqtt_*):
    ha_neopool_lovelace_migrated.yaml
    and
    ha_neopool_lovelace_responsive_migrated.yaml.

  All four mirror the structure of the original YAML-package dashboards and extend it with conditional
  sections for the chlorine, ionization, and conductivity modules plus tiles for the new entities
  shipped by the integration (Controller Time, Sync Controller Time button, Hydrolysis Redox Controlled,
  extra relay states). The _migrated.yaml variants additionally drop tiles for the three relay-state
  entities (pH / Filtration / Light) that the integration deletes during migration. See
  lovelace/README.md
  for the fresh-vs-migrated selection guide, installation instructions, full custom-card dependency
  list, and the device-name caveat.

✨ Added — Connection health monitoring (originally v1.1.0)

• sensor.neopool_connection_error_rate — rolling 10-minute Modbus failure-rate percentage. Sliding
  window so a recent issue is reflected within minutes regardless of how big the lifetime denominator has
  grown. Auto-clears on Tasmota reboot detection.
• binary_sensor.neopool_connection_problem — device_class=problem indicator that turns on when the
  rolling rate exceeds a configurable threshold (default 5%). Configure via
  Settings → Devices & services → NeoPool → Configure → Connection error-rate threshold.
• Generic throttle mechanism: min_update_interval attribute on NeoPoolSensorEntityDescription.
  Entity values still track every SENSOR message in memory, but recorder-visible state writes are
  throttled to one per interval. Available for future entities that would otherwise be too chatty.

🐛 Fixed (originally v1.0.1)

• Hydrolysis (%) sensor stuck at 0% for users whose controller is configured in % display mode.
  The sensor read NeoPool.Hydrolysis.Percent.Data, which (a) isn't emitted on Tasmota firmware before
  November 2023 (arendst/Tasmota#19924) and (b) is
  computed by the firmware with C integer math (data * 100 / max) that truncates to 0 whenever
  production is less than 1% of max. The sensor now computes the percent directly from Hydrolysis.Data,
  Hydrolysis.Unit, and Hydrolysis.Max, falling back to Percent.Data only when Max is unusable — so
  it works correctly regardless of the controller's display unit or the Tasmota firmware version.

🔄 Changed — Dynamic entity management (originally v1.1.0)

• Auto-disable entities for absent modules: sensor.chlorine_data, sensor.ionization_data,
  sensor.conductivity_data, number.chlorine_setpoint, and number.ionization_setpoint now default to
  disabled. The integration enables them automatically when the corresponding module is reported in
  NeoPool.Modules (value 1) and disables them again when the module is absent. User-disabled entities
  are left alone. Mirrors the existing relay-binary-sensor behaviour.
• Auto-disable g/h hydrolysis entities in % display mode: when NeoPool.Hydrolysis.Unit is "%", the
  three g/h-labeled sensors (sensor.hydrolysis_data g/h, sensor.hydrolysis_setpoint_gh,
  sensor.hydrolysis_max) are auto-disabled — in % mode the underlying telemetry has no way to recover
  the absolute g/h value (Max is reported as 100%), so showing a number with the wrong unit was
  misleading. Re-enabled automatically when the controller is flipped back to g/h.
• Dynamic refresh of disable state: the integration now subscribes persistently to SENSOR telemetry
  and re-evaluates the disable rules whenever NeoPool.Modules, NeoPool.Relay, or
  NeoPool.Hydrolysis.Unit changes vs the last-seen value. Re-enable transitions trigger an automatic
  config-entry reload so newly-enabled entities actually materialize. Disable-direction transitions skip
  the reload.
• Connection diagnostics are now lifetime cumulative: sensor.connection_requests,
  sensor.connection_responses, sensor.connection_no_response, and sensor.connection_out_of_range
  used to expose Tasmota's RAM counters directly, which meant they reset to 0 on every Tasmota restart —
  long-term graphs looked like a sawtooth. They now track the cumulative across resets in memory: each new
  raw value contributes its delta to the entity's lifetime cumulative, and a counter drop is treated as a
  Tasmota-reboot signal so the new value becomes the delta from 0. State persists across HA restarts via
  RestoreEntity, and state writes are throttled to once per hour (~96 recorder rows/day for all four
  entities regardless of TelePeriod).
• sensor.controller_time throttled to once per 5 minutes: caps the en...

v1.1.0

Release v1.1.0

Release Date: 2026-05-27

Type: Major feature release - This release consolidates everything since v0.2.19. It covers what
shipped as v1.0.0 (initial full module coverage), v1.0.1 (hydrolysis-percent fix + Lovelace dashboards),
and v1.1.0 (dynamic entity management, lifetime connection counters, connection-health monitoring).
v1.0.0 and v1.0.1 are still tagged but if you're updating from v0.2.x you can jump straight to v1.1.0
— this changelog has the full picture.

What's Changed

✨ Added — Module coverage (was v1.0.0)

• Chlorine sensor and setpoint: sensor.chlorine_data (ppm) and number.chlorine_setpoint (0–10 ppm,
  via NPChlorine) for NeoPool controllers with the chlorine module.
• Conductivity sensor: sensor.conductivity_data (%) for controllers with the conductivity module.
  Firmware emits this as a flat scalar (NeoPool.Conductivity), not a nested object.
• Hydrolysis detail sensors: three read-only sensors for hydrolysis diagnostics —
  sensor.hydrolysis_setpoint_gh (g/h setpoint), sensor.hydrolysis_max (max capacity in g/h), and
  sensor.hydrolysis_unit (unit string reported by device).
• Hydrolysis Redox Controlled: binary sensor (NeoPool.Hydrolysis.Redox) indicating whether
  hydrolysis production is being controlled by the redox system.
• Controller Time sensor: diagnostic sensor showing the NeoPool controller's internal clock.
  Displayed as a raw string (no TIMESTAMP device class — the firmware string has no timezone info).
• Sync Controller Time button: sends NPTime 0 to sync the controller clock to Tasmota's current
  time.
• Driver reference documentation: new docs/TASMOTA_NEOPOOL_DRIVER_REFERENCE.md with firmware
  internals — Modbus registers, ResponseAppend_P lines, kNPCommands table, and driver quirks.

✨ Added — Lovelace dashboards (was v1.0.1)

• Four ready-to-use example dashboards under
  lovelace/ — two for
  fresh installs and two for users who migrated from the YAML package. Each pair has a full-width
  desktop layout (mushroom cards + masonry 400 px) and a mobile-friendly responsive layout (tile cards +
  masonry 320 px).

  • Fresh install:
    ha_neopool_lovelace.yaml
    and
    ha_neopool_lovelace_responsive.yaml.
  • Migrated from the YAML package (entity IDs still neopool_mqtt_*):
    ha_neopool_lovelace_migrated.yaml
    and
    ha_neopool_lovelace_responsive_migrated.yaml.

  All four mirror the structure of the original YAML-package dashboards and extend it with conditional
  sections for the chlorine, ionization, and conductivity modules plus tiles for the new entities
  shipped by the integration (Controller Time, Sync Controller Time button, Hydrolysis Redox Controlled,
  extra relay states). The _migrated.yaml variants additionally drop tiles for the three relay-state
  entities (pH / Filtration / Light) that the integration deletes during migration. See
  lovelace/README.md
  for the fresh-vs-migrated selection guide, installation instructions, full custom-card dependency
  list, and the device-name caveat.

✨ Added — Connection health monitoring (new in v1.1.0)

• sensor.neopool_connection_error_rate — rolling 10-minute Modbus failure-rate percentage. Sliding
  window so a recent issue is reflected within minutes regardless of how big the lifetime denominator has
  grown. Auto-clears on Tasmota reboot detection.
• binary_sensor.neopool_connection_problem — device_class=problem indicator that turns on when the
  rolling rate exceeds a configurable threshold (default 5%). Configure via
  Settings → Devices & services → NeoPool → Configure → Connection error-rate threshold.
• Generic throttle mechanism: min_update_interval attribute on NeoPoolSensorEntityDescription.
  Entity values still track every SENSOR message in memory, but recorder-visible state writes are
  throttled to one per interval. Available for future entities that would otherwise be too chatty.

🐛 Fixed (was v1.0.1)

• Hydrolysis (%) sensor stuck at 0% for users whose controller is configured in % display mode.
  The sensor read NeoPool.Hydrolysis.Percent.Data, which (a) isn't emitted on Tasmota firmware before
  November 2023 (arendst/Tasmota#19924) and (b) is
  computed by the firmware with C integer math (data * 100 / max) that truncates to 0 whenever
  production is less than 1% of max. The sensor now computes the percent directly from Hydrolysis.Data,
  Hydrolysis.Unit, and Hydrolysis.Max, falling back to Percent.Data only when Max is unusable — so
  it works correctly regardless of the controller's display unit or the Tasmota firmware version.

🔄 Changed — Dynamic entity management (new in v1.1.0)

• Auto-disable entities for absent modules: sensor.chlorine_data, sensor.ionization_data,
  sensor.conductivity_data, number.chlorine_setpoint, and number.ionization_setpoint now default to
  disabled. The integration enables them automatically when the corresponding module is reported in
  NeoPool.Modules (value 1) and disables them again when the module is absent. User-disabled entities
  are left alone. Mirrors the existing relay-binary-sensor behaviour.
• Auto-disable g/h hydrolysis entities in % display mode: when NeoPool.Hydrolysis.Unit is "%", the
  three g/h-labeled sensors (sensor.hydrolysis_data g/h, sensor.hydrolysis_setpoint_gh,
  sensor.hydrolysis_max) are auto-disabled — in % mode the underlying telemetry has no way to recover
  the absolute g/h value (Max is reported as 100%), so showing a number with the wrong unit was
  misleading. Re-enabled automatically when the controller is flipped back to g/h.
• Dynamic refresh of disable state: the integration now subscribes persistently to SENSOR telemetry
  and re-evaluates the disable rules whenever NeoPool.Modules, NeoPool.Relay, or
  NeoPool.Hydrolysis.Unit changes vs the last-seen value. Re-enable transitions trigger an automatic
  config-entry reload so newly-enabled entities actually materialize. Disable-direction transitions skip
  the reload.
• Connection diagnostics are now lifetime cumulative: sensor.connection_requests,
  sensor.connection_responses, sensor.connection_no_response, and sensor.connection_out_of_range
  used to expose Tasmota's RAM counters directly, which meant they reset to 0 on every Tasmota restart —
  long-term graphs looked like a sawtooth. They now track the cumulative across resets in memory: each new
  raw value contributes its delta to the entity's lifetime cumulative, and a counter drop is treated as a
  Tasmota-reboot signal so the new value becomes the delta from 0. State persists across HA restarts via
  RestoreEntity, and state writes are throttled to once per hour (~96 recorder rows/day for all four
  entities regardless of TelePeriod).
• sensor.controller_time throttled to once per 5 minutes: caps the entity at ~288 recorder rows/day
  regardless of TelePeriod, while keeping it useful as a sanity-check display for the controller's
  clock and the Sync Controller Time button.
• State-change logs upgraded to WARNING: entity enable/disable events are now logged at WARNING
  level (previously INFO) so they're visible without enabling debug logging.

📚 Documentation (new in v1.1.0)

• New README sections:
  • Dynamic Entity Management — explains the three signals
    (NeoPool.Modules / NeoPool.Relay / NeoPool.Hydrolysis.Unit) and the end-to-end scenarios
    (install module mid-session, remove relay, flip display unit, etc.).
  • Connection Health Monitoring — explains the rate sensor and problem binary_sensor,
    threshold-tuning guidance per RS485 cable length, and a copy-paste automation YAML for users who want
    notifications.
  • Recorder Considerations — concrete row-count tables across TelePeriod settings, an honest
    explanation of which counters are Tasmota-RAM (reset on reboot) vs NeoPool-persistent, and an
    optional recorder.exclude block for users on aggressive TelePeriod settings.

Full Changelog: compare/v0.2.19...v1.1.0

v1.0.1

Release v1.0.1

Release Date: 2026-05-27

Type: Patch release - Hydrolysis sensor accuracy fix for controllers in % display mode, plus example
Lovelace dashboards.

What's Changed

✨ Added

• Lovelace dashboards: Four ready-to-use example dashboards under
  lovelace/ — two for
  fresh installs and two for users who migrated from the YAML package. Each pair has a full-width
  desktop layout (mushroom cards + masonry 400 px) and a mobile-friendly responsive layout (tile cards +
  masonry 320 px).

  • Fresh install:
    ha_neopool_lovelace.yaml
    and
    ha_neopool_lovelace_responsive.yaml.
  • Migrated from the YAML package (entity IDs still neopool_mqtt_*):
    ha_neopool_lovelace_migrated.yaml
    and
    ha_neopool_lovelace_responsive_migrated.yaml.

  All four mirror the structure of the original YAML-package dashboards and extend it with conditional
  sections for the chlorine, ionization, and conductivity modules plus tiles for the new entities
  shipped by the integration (Controller Time, Sync Controller Time button, Hydrolysis Redox Controlled,
  extra relay states). The _migrated.yaml variants additionally drop tiles for the three relay-state
  entities (pH / Filtration / Light) that the integration deletes during migration. See
  lovelace/README.md
  for the fresh-vs-migrated selection guide, installation instructions, full custom-card dependency
  list, and the device-name caveat.

🐛 Fixed

• Hydrolysis (%) sensor stuck at 0% for users whose controller is configured in % display mode. The sensor
  read NeoPool.Hydrolysis.Percent.Data, which (a) isn't emitted on Tasmota firmware before November 2023
  (arendst/Tasmota#19924) and (b) is computed by the firmware
  with C integer math (data * 100 / max) that truncates to 0 whenever production is less than 1% of max.
  The sensor now computes the percent directly from Hydrolysis.Data, Hydrolysis.Unit, and Hydrolysis.Max,
  falling back to Percent.Data only when Max is unusable — so it works correctly regardless of the
  controller's display unit or the Tasmota firmware version.

🔄 Changed

• Hydrolysis (g/h), Hydrolysis Setpoint (g/h), and Hydrolysis Max sensors now go unavailable when
  the controller is in % display mode, instead of showing the percentage value mislabeled with a g/h unit.
  In % mode the underlying telemetry has no way to recover the absolute g/h value (Max is reported as 100%,
  not as the cell's g/h capacity), so showing a number with the wrong unit was misleading. Behavior when the
  controller is in g/h mode is unchanged.

Full Changelog: compare/v1.0.0...v1.0.1

v1.0.0

Release v1.0.0

Release Date: 2026-05-26

Type: Major stable release - First v1.0 with full NeoPool module coverage.

What's Changed

✨ Added

• Chlorine sensor and setpoint: New chlorine_data sensor (ppm) and
  chlorine_setpoint number entity (0-10 ppm, via NPChlorine) for
  NeoPool controllers with the chlorine module.
• Conductivity sensor: New conductivity_data sensor (%) for controllers
  with the conductivity module. Note: firmware emits this as a flat scalar
  (NeoPool.Conductivity), not a nested object.
• Hydrolysis detail sensors: Three new read-only sensors for hydrolysis
  diagnostics — hydrolysis_setpoint_gh (g/h setpoint),
  hydrolysis_max (max capacity in g/h), and hydrolysis_unit (unit string
  reported by device).
• Hydrolysis Redox Controlled: New binary sensor (NeoPool.Hydrolysis.Redox)
  indicating whether hydrolysis production is being controlled by the redox
  system.
• Controller Time sensor: New diagnostic sensor showing the NeoPool
  controller's internal clock. Displayed as a raw string (no TIMESTAMP
  device class) because the firmware string has no timezone info.
• Sync Controller Time button: Sends NPTime 0 to sync the controller
  clock to Tasmota's current time.
• Driver reference documentation: New
  docs/TASMOTA_NEOPOOL_DRIVER_REFERENCE.md with firmware internals — Modbus
  registers, ResponseAppend_P lines, kNPCommands table, and driver quirks.

Full Changelog: compare/v0.2.19...v1.0.0

v0.2.19

Release v0.2.19

Release Date: 2026-05-21

Type: Minor release - Ionization module support, codebase cleanup, firmware update.

What's Changed

✨ Added

• Ionization sensor and setpoint: New ionization_data sensor and ionization_setpoint number entity for NeoPool controllers with the copper-silver ionization module. The setpoint max is dynamic — read from NeoPool.Ionization.Max in the MQTT payload, since it varies per device. The entity stays unavailable until the device reports its max, preventing out-of-range commands. A new max_json_path field on NeoPoolNumberEntityDescription supports this and is reusable for future entities with device-reported limits. Contributed by @netbasebe in #13.

🔄 Changed

• JSON path constants: All entity descriptions across sensor, binary_sensor, number, select, and switch platforms now use JSON_PATH_* constants from const.py instead of hardcoded strings. Added 8 missing constants for relay and redox entities.

🐛 Fixed

• Device info sw_version: Tasmota firmware version now correctly included in get_device_info sw_version field.

📦 Updated

• Tasmota NeoPool Firmware: Bundled firmware updated to v15.4.0 Sybil (contributed by @curzon01 in #12).

Acknowledgments

Thanks to @netbasebe for contributing ionization support and for helping surface the hardcoded strings issue during PR review. Thanks to @curzon01 for the Tasmota firmware update.

Full Changelog: compare/v0.2.18...v0.2.19

v0.2.18

Release v0.2.18

Release Date: 2026-04-04

Type: Minor release - Dual NodeID recognition removes SO157 prerequisite, enhanced device info with Tasmota firmware version and dynamic configuration URL, smart relay entity management.

What's Changed

✨ Added

• Dual NodeID recognition: The integration now acquires both hashed (AA55 prefix) and real NodeIDs during setup by briefly toggling SO157. Both values are stored, so the device is recognized regardless of how SO157 is set afterward. Existing installations upgrading from older versions automatically acquire dual NodeIDs on first startup — no manual reconfigure needed. See design document for full technical details.
• Tasmota firmware version: Device info now shows "Tasmota X.Y.Z / Powerunit VX.Y", fetched via Status 2 command at startup.
• Dynamic configuration URL: The device "Visit" link now points to the actual Tasmota device web UI (http://{ip}) instead of the Tasmota documentation page. IP is fetched via Status 5 command. Falls back to Tasmota docs URL when device IP is unavailable.
• Serial number: Device info shows the hashed System ID as serial number.
• Smart relay entity disable: Detects which named relays are actually present in the SENSOR payload and only disables absent ones. Relays that were previously disabled but become present in the payload are re-enabled automatically.

🔄 Changed

• SO157 no longer required: SetOption157 is no longer a prerequisite. The integration works with any SO157 setting and any Tasmota version. No manual SO157 configuration needed.
• Canonical ID is hashed: Entity unique_ids now use the hashed NodeID (AA55 prefix) for privacy by default. The real hardware NodeID is stored internally as an anchor for device recognition across SO157 changes and Tasmota upgrades.
• Renamed sensor: powerunit_nodeid → system_id (per @curzon01 suggestion).
• Named relay entities disabled by default: All 8 named relay binary sensors are now disabled by default for new installs. Users can enable the ones relevant to their installation.
• Device removal allowed: Users can now delete devices from the UI.

🐛 Fixed

• Reliable device metadata fetch: Status 2 (Tasmota version) and Status 5 (device IP) are now fetched using sequential send-and-wait commands instead of Backlog. Tasmota's NeoPool module drops queued commands when busy with Modbus polling and SENSOR telemetry processing — sequential send-and-wait avoids all queue competition.
• Device migration preserves original: When both old and new devices exist during NodeID migration, the original device (with history and area assignments) is kept and the duplicate removed.
• Canonical NodeID migration: Standalone migration step runs on every startup, handling all edge cases: entities with real NodeID unique_ids, duplicate entities from failed migrations, and device registry updates.

🗑️ Removed

• SO157 runtime enforcement — no longer monitors SENSOR data to re-enable SO157.
• SO157 status display in Options flow.
• async_query_setoption157() and async_ensure_setoption157_enabled() helper functions.

Migration Notes

• Automatic: Existing entities are automatically migrated to hashed NodeID format on startup. No manual steps required.
• The powerunit_nodeid sensor is automatically renamed to system_id.
• If you flip SO157 after setup, the device is still recognized — no re-setup needed.

Acknowledgments

Thanks to @curzon01 (Tasmota NeoPool driver author) for the system_id naming suggestion and ongoing technical feedback.

Full Changelog: compare/v0.2.17...v0.2.18

v0.2.18-beta.9

Release v0.2.18-beta.9

Release Date: 2026-04-04

Type: Beta release - Separate Status callbacks, remove blind relay disable.

What's Changed (since beta.8)

🐛 Fixed

• Separate Status 2 and Status 5 callbacks: Split the single status_received callback into status2_received and status5_received with independent events. Each response topic now has its own callback, preventing one from blocking the other.
• Removed blind relay disable: Removed the auto-disable that was disabling ALL 8 relay entities including available ones (like relay_acid_state). Replaced by smart detection in beta.10.

Full Changelog: v0.2.18-beta.8...v0.2.18-beta.9

v0.2.18-beta.8

Release v0.2.18-beta.8

Release Date: 2026-04-04

Type: Beta release - Status topic fix and relay entity disable.

What's Changed (since beta.7)

🐛 Fixed

• Status 2/5 MQTT subscription: Fixed MQTT wildcard STATUS+ not matching Tasmota's response topics. Now subscribes to specific stat/{topic}/STATUS2 and stat/{topic}/STATUS5 topics separately.

🔄 Changed

• Disable relay entities on upgrade: All 8 named relay entities are disabled on startup for existing installations. Note: This was too aggressive — it also disabled relay_acid_state which may be available. Fixed in beta.10.

Full Changelog: v0.2.18-beta.7...v0.2.18-beta.8