[APP][Pro] Esphome Controller App

Apps
, ,
302

Test v 1.3.31

After installing the updated app:

  1. Add the device using ESPHome Energy Meter, not the generic ESPHome Device driver.

  2. Enter the ESPHome IP address, port and encryption key.

  3. Press Scan Entities.

  4. Under Homey Energy Mapping, select:

    • Production Power (W): Solar Power

    • Total Produced Energy (kWh): Solar Energy

  5. Add the device.

If the device is already installed as an ESPHome Energy Meter:

  1. Open the device settings.

  2. Select Repair.

  3. Open Homey Energy Mapping.

  4. Select Solar Power and Solar Energy.

  5. Press Save Energy Mapping.

If it is currently installed using the generic ESPHome Device driver, add it again as an ESPHome Energy Meter. You can keep the existing device until the Energy tab has been confirmed to work correctly.

303

Hi,
the update works great. I already had added the esphome as energy meter. How I had to remove and re-add it to have the ‘Homey Energy Mapping’ appear. This was exactly the missing piece in the puzzle. My solar panels now nicely appear in the energy tab. I only have to wait till tomorrow to see the behavior of the generated power.

I also have a esphome-based water meter, but to my knowledge a water meter has no special features in the homey app yet, right? I am able to show an insight graph, which is fine.

Thanks for the quick response and the awesome integration app!

304

My esphome energy measurements is now nicely integrated in the Homey energy tab. In a similar style I like to integrate my esphome-based water measuring device. I supports a cumulative measurement in liters. However, I am not able to map the counter to the ‘measure_water’ like capabilities Homey expects to show the water usage in the energy tab. Is this fixable and how should I add my esphome device to Homey? Is there something like the ‘energy mapping’ configuration feature, but then for water?

305

Dedicated ESPHome Water Meter support has now been added.
Please add your device using the new “ESPHome Water Meter” option. During setup, scan the entities and select the cumulative sensor containing the total water consumption.
Sensors using liters or milliliters are automatically converted to cubic meters for Homey Energy. The Water Meter also has a separate icon to distinguish it from a water leak sensor.

Test Version 1.3.33
Improved automatic reconnection for ESPHome Energy Meter and Cumulative Meter devices after network interruptions. Fixed an issue where restarting the app was sometimes required to restore the connection. Added dedicated ESPHome Water Meter support for cumulative water consumption sensors. Liter and milliliter readings are automatically converted to cubic meters for Homey Energy. Added manual source selection and a new Water Meter icon.

306

Awesome, my water meter is now nicely integrated into the energy tab.

307

Hi!
I have a ESPHome device (M5Stack ATOM Lite) running the esp-iq2020 external component to integrate a Hot Spring Prodigy to IQ2020 control board. M5Stack is added using ESPHome Device, which created one Homey device with all entities.

Issue #1: homey temp dial allows a range between 4C up to 35C while spa real setpoint range is 26-40C. If I connect to spa via webserver I can adjust temp beyond 35C, so the firmware is not the problem.

Issue #2: device exposes meter_power.heater_energy and meter_power.pumps_energy. Both update live and show correct climbing values in the device’s own Insights graphs and in the developer tools capability list. However, the device never appears with real data in the Energy tab’s “Top Consumers” widget — it’s listed but permanently shows “— kWh” while other tracked devices populate normally. Suspect this is because the capabilities are only exposed as sub-capabilities (meter_power.heater_energy, meter_power.pumps_energy) rather than a single meter_power.

308

Test version 1.3.34

Could you please test it and provide feedback? If the issue persists, please send the diagnostic log.

Fixed the temperature control range for ESPHome climate devices by using the limits reported by the device. Added combined energy reporting for IQ2020 spa heater and pump energy meters, enabling total consumption to appear in Homey Energy while preserving the individual Insights graphs.

309

Both issues are resolved with test version. Thank you!

310

Hi, I am having connections issues again since the release of 1.3.34 (everything had been working fine since the last test version you provided)

W][api.connection:2461]: @2colors/esphome-native-api 1.3 (192.168.2.35): is unresponsive; disconnecting

However, ESP32 was up and running at that moment

311

Hello, if you send me the diagnostic log when the connection issue occurs, I’ll be able to understand the problem more clearly.

312

Version 1.3.37

Fixed EISCONN and EALREADY connection errors caused by overlapping reconnection attempts. ESPHome connections are now managed through a single reconnect process, preventing duplicate connection attempts while preserving the improved keepalive behavior.

313

This version doesn’t work for me. Both airco’s are not responding.

314

My bed-sensors does not working anymore with this version. Is it possible to install an old version?

315

I have problems too, the IP addresses for my three devices are shifting around, currently I have two with the same IP address. I adjusted them to correct addresses yesterday, but one has changed again over the night.All three are marked ”Unavailable”.

316

Hello Everyone,
diagnostics report: f299995c-83d0-40ba-b1d3-0698ae506947

All 3 of my ESPHome climate devices go Unavailable at the same time,
repeatedly, on v1.3.37. Every other Homey app keeps running, which is
why I think this is app-level rather than network or device.

Setup: 3x Midea AC with SLWF-01 Pro v2.1 (ESP8266), ESPHome 2026.7.2,
Noise encryption, no API password. Wired UniFi/MikroTik network, static
DHCP reservations, all three reachable on port 6053 from Homey during
the outages.

Measured with Homey Insights (uptime_sensor, 5-min resolution, 24h):

mideabianka 39 reboots / 24h (~every 41 min)
mideapanna uptime in minutes
mideaemelet-8c7896 0 reboots, 63h uptime ← control

The control device is on the same network, same firmware, and its
signal is only 2-5 dB better. WiFi is ruled out: only 4 of 39 reboots
were preceded by a >=5 dB signal drop, and over 7 days it was 0/20 -
reboots happened at signal levels 7-11 dB BETTER than the median. So
the device reboots look like a CONSEQUENCE of the app losing its API
connection (api reboot_timeout, 15 min default), not a cause.

Timing: the reboot rate jumped ~7x (1.5/day → 11/day) on Aug 11, the
day v1.3.34 was released. v1.3.37 (“overlapping reconnection attempts”)
looked like the right fix, but the devices dropped again after it.

Possibly related, possibly separate: the “host” setting of one climate
device keeps getting rewritten to the IP of an Everything Presence One
sensor that is NOT paired in this app. It does not hold a stale value -
it FOLLOWS that device: after I moved the EP1 from .95 to .89, the
climate device’s host became .89 within hours. Deleting the device and
re-pairing it did not help; the fresh record drifted the same day.
Meanwhile the other two devices keep their correct host.

Happy to run any test or provide more reports.

317

@clindh @Hullie @JeroenD @Zoltan_Scheffer

I’ve released a fix—I’m sorry, a mistake I made in the code caused the devices to go offline. Could you please install the new version and let me know if the issues have been resolved?

318

Yes it works again! Thank you!

319

Yes, it is working with the new version. Thanks!

320

Installed 1.3.40. Heads-up: after the update, ALL THREE of my devices had
wrong IPs stored — two of them pointing at the same address (an EP1 that
isn’t even paired in this app), and the third pointing at another paired
device’s IP:

Livingroom → .91 (should be .94, .91 belongs to another device)
Bianka → .89 (should be .90, .89 is the unpaired EP1)
Panna → .89 (should be .91, .89 is the unpaired EP1)

So it was never specific to one device. The fix prevents future
overwrites, but it also preserves the already-corrupted values, so
existing users will stay offline until they manually Repair each device.
A migration step, or a warning when two devices share the same IP, might
save other people the confusion.

Fixing all three via Repair now and will report the 24h reboot numbers.

Update: I repaired all three devices and they came back online
immediately and are working normally. So the 1.3.40 fix itself looks
correct — it just doesn’t clean up the values that were already
corrupted before the update. I’ll report the 24h reboot numbers
tomorrow.

321

24h numbers after 1.3.40 + Repair on all three devices:

At 16:25 on Aug 17 all three rebooted together (the Repair). Since then:

Livingroom 0 reboots, 12.4h uptime
Bianka 0 reboots, 12.5h uptime (was 39 reboots/24h before)
Panna ~15 reboots overnight, currently 1.3h uptime

So the fix clearly works — Bianka went from rebooting every ~41 minutes
to 12.5 hours of uninterrupted uptime, and the IPs have stayed correct
through a full night for the first time. Thank you.

One device is still affected: Panna keeps rebooting roughly every 30-90
minutes, always in pairs about 5 minutes apart. WiFi signal is flat
(median -60 dBm, 0 of 20 reboots preceded by any drop), so the device is
losing its API client and rebooting via api reboot_timeout.

The only difference I know of: Panna’s Homey device record was created on
Aug 13 through the “Add ESPHome Device Manually” screen (the one that came
pre-filled with another device’s name and a non-empty API password). The
other two are older, untouched records. Could a record created that way
end up with something inconsistent stored? I’m happy to re-pair it and
report back, but thought the difference might be a useful clue first.