Hi,
I have an ESPHome set up that acts as a smart meter for my solar generator.
Because it is in the cellar and I don’t have a good WiFi connnection there, I used an Olimex Esp32-poe device and connected it via Ethernet cable.
The problem is, that the device loses connection on a regular basis - sometimes it works for some days and then the ESP is not reachable anymore.
In the Home Assistant logs I can see the following log entries:
2025-06-18 08:52:56.812 WARNING (MainThread) [aioesphomeapi.connection] esphome-smart-meter @ 192.168.20.20: Connection error occurred: Ping response not received after 90.0 seconds
2025-06-18 08:52:56.813 INFO (MainThread) [aioesphomeapi.reconnect_logic] Processing unexpected disconnect from ESPHome API for esphome-smart-meter @ 192.168.20.20
The only thing that helps is to power off/on the device.
What could be the problem here?
My ESP32Home script is like this:
esphome:
name: esphome-smart-meter
friendly_name: Smart Meter
esp32:
board: esp32dev
framework:
type: arduino
# web_server:
# port: 80
mqtt:
broker: 192.168.0.2
username: sensoren
password: !secret mqtt_password_sensoren
# Enable logging
logger:
level: DEBUG
baud_rate: 0 # Important because we use the UART ports. Prevents warning "You're using the same serial port for logging and the UART component. Please disable logging over the serial port by setting logger->baud_rate to 0.""
# Enable Home Assistant API
api:
ota:
- platform: esphome
password: !secret ota_password
# wifi:
# ssid: !secret wifi_ssid
# password: !secret wifi_password
#
# # Enable fallback hotspot (captive portal) in case wifi connection fails
# ap:
# ssid: "Esphome-Web-321864"
# password: "TnrSQ8T6975Z"
# captive_portal:
# Ethernet configuration for Olimex ESP32-POE, see https://esphome.io/components/ethernet.html
ethernet:
type: LAN8720
mdc_pin: GPIO23
mdio_pin: GPIO18
clk_mode: GPIO17_OUT
phy_addr: 0
power_pin: GPIO12
manual_ip:
static_ip: 192.168.20.20
gateway: 192.168.20.1
subnet: 255.255.255.0
# SML configuration
# See https://community.home-assistant.io/t/esp32-problem-with-two-uart-for-two-times-sml/529767
# See https://www.mittelstedt.net/?tag=esphome
# See https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/iskraemeco_mt681 for the COM port settings.
# UART_0 uses GPIO3 (rx) and GPIO1 (tx). Should not be used because it is for the serial logger to the computer.
# UART_1 uses GPIO36 (rx) and GPIO4 (tx)
# NOT SURE!!!! UART_2 uses GPIO35 (rx) and GPIO33 (tx)
# see https://github.com/espressif/arduino-esp32/blob/4638628873a061c36faffebe4d146d13f960076d/variants/esp32-poe-iso/pins_arduino.h
uart:
- id: uart_01
rx_pin: 3
tx_pin: 1
baud_rate: 9600
# 8N1:
data_bits: 8
parity: NONE
stop_bits: 1
# debug:
- id: uart_02
rx_pin: 36
tx_pin: 4
baud_rate: 9600
# 8N1:
data_bits: 8
parity: NONE
stop_bits: 1
# debug:
sml:
- id: sml_01
uart_id: uart_01
- id: sml_02
uart_id: uart_02
sensor:
# ----------- SML Netz -----------
- platform: sml
id: "netz_bezug_gesamt"
name: "Netz Bezug gesamt"
sml_id: sml_01
obis_code: "1-0:1.8.0"
unit_of_measurement: kWh
accuracy_decimals: 1
state_class: total_increasing
device_class: energy
filters:
- multiply: 0.0001
- platform: sml
id: "netz_einspeisung_gesamt"
name: "Netz Einspeisung gesamt"
sml_id: sml_01
obis_code: "1-0:2.8.0"
unit_of_measurement: kWh
accuracy_decimals: 1
state_class: total_increasing
device_class: energy
filters:
- multiply: 0.0001
- platform: sml
id: "netz_bezug_aktuell"
name: "Netz Bezug aktuell"
sml_id: sml_01
obis_code: "1-0:16.7.0"
unit_of_measurement: W
accuracy_decimals: 0
state_class: measurement
device_class: power
# ----------- SML Z2 -----------
- platform: sml
id: "pv_wechselrichter"
name: "PV Wechselrichter"
sml_id: sml_02
obis_code: "1-0:1.8.0"
unit_of_measurement: kWh
accuracy_decimals: 1
state_class: total_increasing
device_class: energy
filters:
- multiply: 0.0001
- platform: sml
id: "pv_produktion_gesamt"
name: "PV Produktion gesamt"
sml_id: sml_02
obis_code: "1-0:2.8.0"
unit_of_measurement: kWh
accuracy_decimals: 1
state_class: total_increasing
device_class: energy
filters:
- multiply: 0.0001
- platform: sml
id: "pv_produktion_aktuell"
name: "PV Produktion aktuell"
sml_id: sml_02
obis_code: "1-0:16.7.0"
unit_of_measurement: W
accuracy_decimals: 0
state_class: measurement
device_class: power
Having some Olimex PoE installed since years and without problem, I would suspect more a problem with the switch.
Are you sure the network cable is in good conditions ? what model of switch it’s connected to ?
I am seeing exactly the same issue, the device is powered on, but it seems to lose all connectivity, with the Ethernet port not communicating with the switch.
I can’t see logs because serial logging is disabled (logger → baud_rate = 0).
If I remember correctly, I had to do that because I am using both UARTs for my SML sensors and my ESP32 didn’t start and was in a boot loop.
If you can’t get logs, it will be nearly impossible to figure out what is wrong. You have some choices:
Find another way to have the device communicate to you what is going on.
Put in a pre-emptive reboot. Once a day at 04:00 have it reboot itself.
Use other techniques to figure out if the device is completely not responding or the network connection is just down.
Add additional sensors to see the health of the node before it stops responding. I track the free memory on mine.
I have a node running something else that is somewhat problematic and it would regularly go out to lunch. I added a reboot timer to it and it can now go months without failing. I am in the process of moving it to esphome to have more control over the firmware to get a more permanent solution.
0x40084fcf: xt_utils_wait_for_intr at /data/cache/platformio/packages/framework-espidf/components/xtensa/include/xt_utils.h:81
0x40084fcf: esp_cpu_wait_for_intr at /data/cache/platformio/packages/framework-espidf/components/esp_hw_support/cpu.c:111
0x400f8c59: esp_vApplicationIdleHook at /data/cache/platformio/packages/framework-espidf/components/esp_system/freertos_hooks.c:59
0x40087a43: prvIdleTask at /data/cache/platformio/packages/framework-espidf/components/freertos/FreeRTOS-Kernel/tasks.c:4439
I searched for it and it is because the task watchdog detected a task that took too long (that’s also what the previous lines in the log file suggested: “Task watchdog got triggered.”).
What I could see in other places in my log file are lines like this:
ÔÉø[0;33m[W][component:237]: Component sml took a long time for an operation (65 ms).ÔÉø[0m
ÔÉø[0;33m[W][component:238]: Components should block for at most 30 ms.ÔÉø[0m
I believe that SML decoding sometimes takes too long so that the watchdog is triggered and restarts the device.
I will try to increase the watchdog timeout later today.
But: why can’t the ESP reconnect to the network after a reset? Is this a known issue?
I can feel you and your frustration with UART-reading.
I’ve done a lot of UART OBIS-stuff in the last months, so I suggest you debug first if the crashing/ unreponsiveness is related to memory being exhausted.
I’ve got fully working code for reading obis codes from uart with debug only for diffrent board, maybe you can learn from it also for your use case?
And maybe as you’re reading obis codes from UART, you might even use my modified esphome-component? Check it out too as it is much faster and more efficient than debugging UART, maybe it will work for you.
As I checked the nice and easy “how to” check ESPhome memory leaks and found not good one, I made one myself. Hope this help you track your project difficulties:
@nikop with the increased watchdog timeout it took a bit longer now than before for the crash to appear.
The “Reason for last reset”-sensor shows “Unknown”, but for the free heap sensor I have the following diagram which shows me a spike down right before the device is not reachable anymore:
Having both mqtt and api may be part of your reboot problem if you did not integrate both mqtt and esphome api at the same time. There is a mechanism that if the api is not connected, it will reboot every 15 mins to see if that fixes it. There is a setting to prevent the rebooting, but if you do not intend to use the api because you use mqtt, just remove the api line.
