[APP][Pro] Esphome Controller App

Apps
, ,
322

I checked the app code and confirmed that values entered on the manual pairing screen, including the API password, are stored in the Homey device record. Since that screen was unexpectedly pre-filled, Panna may have retained an incorrect API password or another stale connection value.

Before re-pairing, please open Repair for Panna and:

  1. Confirm that the IP address is Panna’s correct fixed address.
  2. Leave the API Password completely empty unless your ESPHome YAML explicitly contains an API password.
  3. Enter Panna’s correct encryption key again.
  4. Save and reconnect.

If the reboots continue, please remove and re-add only Panna using the same fixed IP, an empty API Password field, and the correct encryption key. This will be a useful test to determine whether its manually created Homey record is responsible.

The paired reboots approximately five minutes apart also suggest that ESPHome’s api.reboot_timeout is being reached after the API client disconnects. Temporarily setting reboot_timeout: 0s can stop those automatic reboots while we investigate the underlying disconnection, but it does not itself fix the connection problem.

Please send a new ESPHome Controller diagnostic report after the next disconnection. Do not include the encryption key.

323

Result of the debug flash on Panna:

Reset Reason: Hardware Watchdog
Uptime at reading: 3000 s (rebooted ~50 min earlier)
Free heap: 39,504 B
Heap fragmentation: 5%
Signal: -61 dBm

So this one is NOT your bug. A hardware watchdog reset means the firmware
stalls and the chip resets itself — api.reboot_timeout would have shown
“Software/System restart” instead. Memory is healthy too, better than
right after boot.

Your 1.3.38 + 1.3.40 fixes solved the actual app problem. Latest 24h
measurement from Homey Insights, 5-minute resolution:

Bianka 0 reboots, 41.1h uptime, median signal -70.2 dBm
Livingroom 0 reboots, 41.0h uptime, median signal -58.0 dBm
Panna 36 reboots, 0.7h uptime, median signal -61.2 dBm

Bianka is completely stable on the WEAKEST signal of the three, 9 dB worse
than Panna — so this is definitively not RF. The stored IPs have also
survived a full night unchanged for the first time. Thank you for the fast
turnaround on both fixes.

Panna is a device-side fault. The Midea UART on this board runs on
software serial, which is the timing-critical part, and the same config
runs fine on two other units. I’m swapping in a known-good spare dongle
from our office, keeping the same node name, encryption key and fixed IP
so the Homey device record stays untouched, and I’ll watch it for a few
days. No further action needed from you, and I won’t send another
diagnostics report unless something app-related shows up.

324

Test v1.3.44

  • Added a new capability mapping system for newly paired devices while preserving existing devices.
  • Improved Media Player detection with playback, volume, mute, stop, and volume-step controls.
  • Added fan preset mode, oscillation, and direction support.
  • Added ESPHome light effect support.
  • Added new Flow cards for fan oscillation, fan direction, and light effects.
  • Added lock jam detection using the Homey alarm_stuck capability.
  • Added alarm panel triggered-state support.
  • Added correct valve position control and water-valve classification.
  • Expanded sensor and binary sensor mappings for air quality, weather, water, gas, and alarm entities.
  • Improved sensor unit conversions, decimal precision, and cumulative water/gas measurements.
  • Disabled, configuration, and diagnostic ESPHome entities are now filtered automatically for newly paired devices.
  • Existing paired devices retain their previous capability mappings to prevent compatibility issues.