Repository navigation
Tapo P110M firmware 1.4.3 periodically times out on get_device_time every ~612 seconds #1732
Description
Summary
Four Tapo P110M plugs consistently fail a bulk module query and then get_device_time approximately every 612 seconds.
A fifth P110M on the same network, with the same hardware revision and Home Assistant polling configuration but older firmware, does not exhibit the recurring failure.
The switches, energy sensors and cloud-connection entities remain available. The repeated failure appears limited to the Time module.
This report is separate from the known noisy ERROR-level logging fixed on master by PR #1587. The installed release is python-kasa 0.10.2, which does not contain that change.
Environment
Home Assistant Core: 2026.7.4
Home Assistant OS: 18.2
Supervisor: 2026.07.5
Device: Home Assistant Green, aarch64
python-kasa: 0.10.2
Network: All devices are on the same IPv4 LAN and subnet.
TP-Link integration polling interval: 5 seconds
DHCP reservations: Configured
DNS: AdGuard Home is used, but Home Assistant communicates with these devices directly by IP address.
Affected devices
Four devices showing the periodic failure:
Model: Tapo P110M
Hardware version: 1.0
Firmware: 1.4.3 Build 260526 Rel.224153
Comparison device that does not show the recurring failure:
Model: Tapo P110M
Hardware version: 1.0
Firmware: 1.4.1 Build 251020 Rel.183216
All five devices expose the same modules:
Time
AutoOff
DeviceModule
Energy
Matter
PowerProtection
Error pattern
The four affected devices fail in synchronised bursts approximately every 612 seconds.
Example errors:
ERROR [kasa.smart.smartdevice] Error querying DEVICE_IP for modules 'Time, AutoOff, DeviceModule, Energy, Matter, PowerProtection' after first update: ('Unable to query the device: DEVICE_IP: ', TimeoutError())
ERROR [kasa.smart.smartdevice] Error querying DEVICE_IP individually for module query 'get_device_time' after first update: ('Unable to query the device: DEVICE_IP: ', TimeoutError())
WARNING [kasa.smart.smartdevice] Error processing Time for device DEVICE_IP, module will be unavailable
The interval was measured as approximately 612 seconds, plus or minus one second, over repeated samples. It remained phase-stable over several days.
The “Error processing Time” warning has occurred more than 1,100 times across the three longest-running affected devices. No other module is repeatedly marked unavailable.
Network control test
A simultaneous 20-minute test sent 1,200 ICMP packets to each of five P110M plugs while Home Assistant logs were collected.
Results:
Affected P110M 1: 0.00% packet loss, 2 Home Assistant timeouts
Affected P110M 2: 0.00% packet loss, 2 Home Assistant timeouts
Affected P110M 3: 0.08% packet loss, 2 Home Assistant timeouts
Affected P110M 4: 0.00% packet loss, 2 Home Assistant timeouts
Healthy P110M comparison device: 0.17% packet loss, 0 Home Assistant timeouts
None of the eight Home Assistant timeouts correlated with packet loss or latency above 100 ms within ten seconds before or after the timeout.
The healthy comparison device had the highest packet loss but no application-level timeouts. The affected device with the cleanest network connection still timed out.
This does not prove the application protocol is healthy, but it makes ordinary LAN packet loss unlikely to be the trigger.
Home Assistant behaviour
Switch entities remained available.
Power sensors remained available.
Cloud-connection entities remained on.
No unavailable or unknown entity transitions occurred during the controlled test.
No event-loop, blocking-call, CPU, memory, recorder, disk or I/O warnings coincided with the failure windows.
Home Assistant coordinator-level failures are rare compared with the raw SmartDevice query errors.
The devices continue to function normally for switching and power monitoring despite the recurring Time-module failure.
Relevant upstream references
python-kasa issue #1575 reports the same P110M error and module list.
Home Assistant Core issue #152283 reports the same noisy timeout behaviour.
python-kasa PR #1587 changes SmartDevice query connection failures from ERROR to DEBUG, but this change has not shipped in python-kasa 0.10.2.
Questions
- Is there a known P110M firmware or session issue causing get_device_time to stop responding periodically?
- Could the device be expiring or resetting its KLAP or application session at approximately 612 seconds?
- Would protocol-level debug output help identify why only the P110M devices on firmware 1.4.3 show this stable periodic pattern?
- Is a python-kasa release containing PR Use log-level debug for smartdevice query error reporting #1587 planned?
- Are there any specific debug commands or redacted diagnostics that would help investigate the Time-module failure?
I can provide redacted Home Assistant diagnostics, exact timestamps and a bounded debug log if required.
Activity
DrEvilSecretLab commented on Sep 22, 2026
Additional reproduction on two different TP-Link models shows the same stable ~612-second pattern described here.
Environment
Affected devices
TP-Link S505
Tapo Hub H100
Observed behavior
Six consecutive failure intervals were measured for each device:
For both devices, the initial multipleRequest/batch times out. The individual fallback then fails on get_device_time, and only the internal Time module is marked unavailable. Other modules named in the batch are not individually marked unavailable.
The Matter request itself is not failing: get_matter_setup_info is present in successfully returned diagnostics for both devices. Subsequent get_device_time requests also succeed, so the Time failure is periodic rather than permanent.
A 100-packet ICMP control test to each device showed 0% packet loss, with average latency of approximately 7.0 ms and 7.5 ms. RSSI reported by the devices was -37 dBm (S505) and -23 dBm (H100).
All enabled entities remained available during a separate 30-minute observation window. The H100 child devices (two T315 sensors and one T110 sensor) continued reporting normally. The S505 switch also remained functional.
This appears to extend the same reproducible pattern beyond the P110M to S505 and H100 firmware stacks. PR #1759 may be relevant because the failure starts with a batched-request timeout, although in this case the current individual fallback still isolates get_device_time as the only unavailable module.
I can provide redacted Home Assistant diagnostics, exact timestamps, or a bounded debug log if requested.