ESPHome crashing and occasional unresponsive batteries

[fignew]

What's the issue?

Hi Tom,

I'm so happy to have the ported version of AstraMeter for ESPHome, Now I can reboot my Homeassistant box without my power going wonky for minutes at a time. The control with ct002 is nice and responsive.

Every morning though I need to go into each battery in the astrameter hass provider and disable "Auto Target" and then re-enable to get them to output power. This happens occasionally during the day also.

I've come across the attached error when reinstalling the image. I suspect the two are connected. I've seen it as far back as v2.1.2

Version

v2.2.4

Installation method

ESPHome

If "Other", which?

No response

Configuration

substitutions:
  name: "powermeter-eg"
  mqtt_prefix: "evcc/powermeter_eg"
  friendly_name: "Power Meter"
  device_description: "Erdgeschoss"

esphome:
  name: "${name}"
  friendly_name: "${friendly_name}"
  comment: "${device_description}"

packages:
  common: !include templates/common.yaml
  wifi: !include templates/wifi.yaml
  esp32: !include templates/esp32.yaml

external_components:
  - source: github://tomquist/astrameter@2.2.4
    components: [ct002]

esp32:
  board: esp32-c3-devkitm-1
  framework:
    type: esp-idf

mqtt:
  id: powermeter_eg
  broker: 10.4.0.120
  username: powermeter
  password: !secret mqtt_powermeter_password
  topic_prefix: "${mqtt_prefix}"
  discovery: false
  log_topic: null

uart:
  id: my_uart
  rx_pin: GPIO5
  baud_rate: 9600
  data_bits: 8
  parity: NONE
  stop_bits: 1

sml:
  id: my_sml
  uart_id: my_uart

number:
  - platform: template
    name: "Power Offset"
    id: power_offset
    restore_value: true
    optimistic: true
    step: 1
    min_value: -400
    max_value: 0
    unit_of_measurement: "W"

  - platform: template
    name: "Multi"
    id: power_times
    restore_value: true
    optimistic: true
    step: .1
    min_value: 0.1
    max_value: 6

sensor:
  - platform: sml
    name: "Consumed Energy"
    sml_id: my_sml
    obis_code: "1-0:1.8.0"
    unit_of_measurement: kWh
    accuracy_decimals: 4
    state_class: total_increasing
    device_class: energy
    icon: "mdi:home-import-outline"
    filters:
      - multiply: 0.0001
      - throttle: 30s

  - platform: sml
    name: "Provided Energy"
    sml_id: my_sml
    obis_code: "1-0:2.8.0"
    unit_of_measurement: kWh
    accuracy_decimals: 4
    state_class: total_increasing
    device_class: energy
    icon: "mdi:home-export-outline"
    filters:
      - multiply: 0.0001
      - throttle: 30s

  - platform: sml
    name: "Power"
    id: power
    sml_id: my_sml
    obis_code: "1-0:16.7.0"
    unit_of_measurement: W
    accuracy_decimals: 0
    state_class: measurement
    device_class: power

  - platform: copy
    name: "Negative Power"
    id: power_negative
    source_id: power_adjusted
    unit_of_measurement: W
    accuracy_decimals: 0
    state_class: measurement
    device_class: power
    filters:
      - clamp:
          max_value: 0
      - exponential_moving_average:
          alpha: 0.005
          send_every: 1
      - multiply: !lambda return id(power_times).state;
      - offset: !lambda return id(power_offset).state;
      - clamp:
          min_value: -400
      - lambda: |-
          if (isnan(x)) {
            return 0;
          }
          return x;

  - platform: copy
    name: "Adjusted Power"
    id: power_adjusted
    source_id: power
    unit_of_measurement: W
    accuracy_decimals: 0
    state_class: measurement
    device_class: power
    icon: "mdi:transmission-tower-off"
    filters:
      - offset: !lambda return id(power_negative).state;

ct002:
  id: my_ct002
  power_sensor_l1: power_adjusted

  mqtt_insights:
    base_topic: astrameter
    device_id: powermeter-eg
    ha_discovery: true
    ha_discovery_prefix: homeassistant
    marstek_mqtt_enabled: true
    marstek_mqtt_interval: 300s

Logs

[14:53:11.233][E][esp32.crash:332]: *** CRASH DETECTED ON PREVIOUS BOOT ***
[14:53:11.238][E][esp32.crash:335]:   Reason: Fault - Unknown
[14:53:11.238][E][esp32.crash:339]:   Crashed core: 0
[14:53:11.238][E][esp32.crash:340]:   PC:  0x40383128  (fault location)
WARNING Decoded 0x40383128: esp_cpu_wait_for_intr at /COMPONENT_ESP_HW_SUPPORT_DIR/cpu.c:64
[14:53:11.572][E][esp32.crash:305]:   BT0: 0x40383128  (backtrace)
WARNING Decoded 0x40383128: esp_cpu_wait_for_intr at /COMPONENT_ESP_HW_SUPPORT_DIR/cpu.c:64
[14:53:11.913][E][esp32.crash:305]:   BT1: 0x40383118  (backtrace)
WARNING Decoded 0x40383118: esp_cpu_wait_for_intr at /COMPONENT_ESP_HW_SUPPORT_DIR/cpu.c:57 (discriminator 1)
[14:53:12.241][E][esp32.crash:305]:   BT2: 0x420DDC50  (stack scan)
WARNING Decoded 0x420ddc50: prvCheckTasksWaitingTermination at /COMPONENT_FREERTOS_DIR/FreeRTOS-Kernel/tasks.c:4576
 (inlined by) prvIdleTask at /COMPONENT_FREERTOS_DIR/FreeRTOS-Kernel/tasks.c:4301
[14:53:12.497][E][esp32.crash:363]: Use: addr2line -pfiaC -e firmware.elf 0x40383128 0x40383128 0x40383118 0x420DDC50

[sincze]

Just want to add a data point that might help separate this into two issues.

I'm running a similar setup (ESPHome ct002 + Marstek HME-4, via MQTT). My battery publishes its own telemetry on marstek_energy/HME-4/device/<mac>/ctrl roughly every 5 minutes normally. Today it skipped several consecutive cycles — last update 21:17, nothing until it resumed at 21:46/21:51 — a gap of ~4-5 missed intervals. In that same window, AstraMeter's own poll of the same battery (ct002/.../consumer/..., poll_interval: 0.4) never stopped updating. So the ESP32/AstraMeter/network path was fine the whole time — only the battery's own periodic MQTT push had stalled.

It resumed the moment I manually switched the Marstek app's mode to "self consumption" — no reboot, no crash. That's functionally the same kind of manual nudge as toggling the "Auto Target" switch in HA that you described needing to do daily.

This makes me think your crash log and the daily-unresponsive symptom may be two separate bugs bundled into one report: a real firmware crash on one hand, and a battery-side polling/report hang that just needs any manual re-trigger to clear — independent of whether a crash actually happened.

A couple things that would help confirm/rule this out:

1. Next time the battery goes unresponsive, before you touch Auto Target — can you check whether the ESP32 actually crashed/rebooted around that time (uptime sensor or ESPHome device log), or if it stayed up the whole time? If it stayed up, that points at the battery-side hang, not the firmware crash.
2. Does the daily unresponsive event happen even on days where you don't see a crash log? If yes, that's good evidence they're independent bugs.
3. If you have HA history on the "Auto Target" switch or on power_adjusted, a screenshot of the gap (last good value → stale → recovery after toggle) would make the pattern very clear, same as what I saw above.

[tomquist]

A change has been made to 2.3.0. please open a new issue if you're still running into any issue with the new version.