4.0.6 - performance improvements for troublesome devices.

ECHONETLite Home Assistant Integration — v4.0.6

What's New

This release focuses on reliability improvements for devices with non-compliant or slow firmware, particularly those with multiple ECHONET instances on a single IP address. Most changes are invisible for well-behaved devices but significantly improve stability across a wide range of embedded hardware.

This release was developed to address the significant performances issues encountered with the Panasonic SmartCosmo HEMS platform (Issue #259)

The intent was to improve the tolerance of the DataUpdateConnector architecture to missed UDP packets and to bring the 4.X version closer to 3.9.0 in terms of behavior. The 3.9.0 and earlier versions that used the Throttle decorator to control polling updates were (unintentionally) very tolerant of missing ECHONET response packets, this release seeks to improve reliability and more closely align with the 3.9.0 behavior to improve user experience with devices that have occasional minor reliability issues.

---

Highlights

Partial poll failures no longer cause sensors to go unavailable

Previously, if a single batch of EPC requests timed out during a poll cycle, the affected sensors would go unavailable until the next successful poll. This was a regression from 3.9.0 where stale data was always served.

4.0.6 now merges new poll data into the existing dataset rather than replacing it. Sensors only go unavailable if the device becomes completely unreachable — if some batches succeed and others are skipped, affected sensors retain their last known value rather than flashing unavailable.

Per-host request semaphore

When multiple ECHONET instances share the same IP address, their poll timers can converge over time and fire simultaneously, causing a burst of requests that overwhelms embedded firmware. A per-host semaphore now ensures only one instance polls a given host at a time. Others wait their turn naturally, partially replicating the spacing that @Throttle provided accidentally in 3.9.0 via HA's entity update cycle.

This significantly improves stability for multi-instance devices such as distribution panel meters, solar power generation systems, and lighting controllers.

Graceful timeout handling

pychonet raises TimeoutError when a device does not respond to a request. This exception was previously not caught at the batch level, causing it to reach a generic exception handler that would mark all entities unavailable even when other batches had already returned data successfully.

Timeouts are now caught individually per batch and per singleton EPC. A skipped batch means affected sensors serve cached data. Only a complete device blackout raises UpdateFailed and marks entities unavailable.

Backoff after timeout

After a batch timeout, the integration now waits 1 second before sending the next batch rather than 100ms. This gives slow or momentarily overwhelmed embedded firmware time to recover before the next request arrives.

Singleton EPC retry

EPCs declared as SINGLETON_POLL in a device quirk file get one automatic retry on timeout after a 200ms pause. This improves data retrieval for large list EPCs (such as 29-channel power consumption lists) that occasionally fail on the first attempt under network load.

---

Device Quirks

Panasonic SmartCosmo MKN7350S1 (Distribution Panel Meter 0x0287)

A quirk file has been added for this device addressing a firmware issue where EPCs 0xB3 (measured cumulative power consumption list, simplex) and 0xB7 (measured instantaneous power consumption list, simplex) cause silent UDP frame drops when batched with other EPCs. Both EPCs return ~118 bytes of channel data and appear to overflow the device's internal response buffer when combined with other requests.

Both EPCs are now declared SINGLETON_POLL and are always requested individually, eliminating the silent drop behavior.

---

pychonet 2.7.14

This release requires pychonet 2.7.14 which introduces an important distinction in the _waiting[host] queue:

• None — queue was busy, request was never sent (serve cached data)
• False — request was sent but device did not respond (genuine timeout)

Previously both cases returned False, making it impossible to distinguish queue contention from a genuine device non-response. The HA integration now handles each case appropriately.

---

Other Fixes

• Fixed a bug where singleton EPC results stored as dicts (e.g. 29-channel power lists) were being merged into the coordinator data dict as top-level keys rather than stored under their EPC code, causing list sensors to always show unavailable even when data was successfully received
• Fixed an f-string formatting bug in the device timeout debug log
• Fixed mixed f-string/percent formatting in polling log messages
• server._logger demoted from WARNING to DEBUG — pychonet internal message logs (Updating instance, ECHONETLite Message Received) no longer appear in the WARNING log
• Added INFO-level logging for device initialization and loaded instance summary, visible without enabling debug logging
• sensor.py — guard against None before calling accessor_lambda on list sensors
• base_entity.py — guard against missing manufacturer in device_info
• Setup retry loop now correctly catches DeviceTimeoutError in addition to TimeoutError and UpdateFailed

---

Upgrading from 3.9.0

Sensors will now correctly show as unavailable when a device goes offline rather than displaying stale data indefinitely. This is the correct behavior but may be noticeable for devices that were previously appearing functional while silently failing to update. If you see sensors going unavailable that were previously stable, check your device's network connectivity and ECHONET Lite configuration.