ESP Home failed update on a device

ESPHome
1

Hello,
Today’s update of ESP Home went fine, but now I can’t update two devices I used to be able to.
Can anyone tell me from this code what’s wrong?

INFO ESPHome 2025.2.0
INFO Reading configuration /config/esphome/kauf-plug-2.yaml…
ERROR Unexpected exception while reading configuration:
Traceback (most recent call last):
File “/usr/local/bin/esphome”, line 8, in
sys.exit(main())
^^^^^^
File “/esphome/esphome/main.py”, line 1049, in main
return run_esphome(sys.argv)
^^^^^^^^^^^^^^^^^^^^^
File “/esphome/esphome/main.py”, line 1027, in run_esphome
config = read_config(dict(args.substitution) if args.substitution else {})
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/esphome/esphome/config.py”, line 1095, in read_config
res = load_config(command_line_substitutions)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/esphome/esphome/config.py”, line 949, in load_config
return _load_config(command_line_substitutions)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/esphome/esphome/config.py”, line 939, in _load_config
return validate_config(config, command_line_substitutions)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/esphome/esphome/config.py”, line 835, in validate_config
target_platform = core_config.preload_core_config(config, result)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/esphome/esphome/core/config.py”, line 222, in preload_core_config
if _is_target_platform(domain):
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/esphome/esphome/core/config.py”, line 184, in _is_target_platform
if get_component(name, True).is_target_platform:
^^^^^^^^^^^^^^^^^^^^^^^^^
File “/esphome/esphome/loader.py”, line 205, in get_component
return _lookup_module(domain, exception)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/esphome/esphome/loader.py”, line 181, in _lookup_module
module = importlib.import_module(f"esphome.components.{domain}")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.11/importlib/init.py”, line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “”, line 1206, in _gcd_import
File “”, line 1178, in _find_and_load
File “”, line 1149, in _find_and_load_unlocked
File “”, line 690, in _load_unlocked
File “”, line 940, in exec_module
File “”, line 241, in _call_with_frames_removed
File “/data/external_components/e395f423/components/wifi/init.py”, line 106, in
cv.Required(CONF_STATIC_IP): cv.ipv4,
^^^^^^^
AttributeError: module ‘esphome.config_validation’ has no attribute ‘ipv4’

2

I am having this exact issue with two Kauf Plugs. Are your devices plugs as well?
Namely the KAUF Smart Plug (PLF12)

3

Yes that’s exactly what they are. I also can’t update my new Voice Preview device. But it’s a different error.

4

This is error from Voice Preview update:

INFO ESPHome 2025.2.0
INFO Reading configuration /config/esphome/home-assistant-voice-0919d7.yaml…
INFO Updating https://github.com/esphome/home-assistant-voice-pe@dev
WARNING GPIO0 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See Frequently Asked Questions — ESPHome
WARNING GPIO3 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See Frequently Asked Questions — ESPHome
Failed config

light.esp32_rmt_led_strip: [source /data/packages/dc43710d/home-assistant-voice.yaml:559]
platform: esp32_rmt_led_strip
id: leds_internal
pin: GPIO21

This feature is not available for the IDF framework version 5.
rmt_channel: 1
num_leds: 12
rgb_order: GRB
chipset: WS2812
default_transition_length: 0ms
power_supply: led_power

5

I too am having the same issue but mine is with KAUF light switches.

6

Post the YAML code with the preformatted text in the editor.

7

Same issue - here is my config for a KAUF plug:

substitutions:
  name: kbulb-7db6f4
  friendly_name: Living Room Driftwood Light
packages:
  Kauf.RGBWW: github://KaufHA/kauf-rgbww-bulbs/kauf-bulb.yaml
esphome:
  name: ${name}
  name_add_mac_suffix: false
api:
#  encryption:
#    key: 13QMm/fg8ksyi8eDXqs9LC5vbAVsVqEUy82VerF0zgA=

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
8

And the rest of your YAML code?

9

I’m having the same problem with PLF10 and PLF12 KAUF plugs.

For now I’ve switched to the “lite” config and everything seems to be working.

packages:
  kauf.plf10: github://KaufHA/PLF10/config/kauf-plug-lite.yaml
2 Likes
10

Not sure what else you’re looking for. That is everything in the yaml file for that device.

11

The ESPHome update had a lot of breaking changes, which could affect the workings of the code.

12

This is all there is in Yaml locally:

substitutions:
name: kauf-plug-2
friendly_name: Kauf Plug Two
packages:
Kauf.PLF12: github://KaufHA/PLF12/kauf-plf12.yaml
esphome:
name: ${name}
name_add_mac_suffix: false

wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password

13

I get the same error regarding ipv4 for my Nibe Gateway;

esphome:
  name: nibegw
  comment: Nibegw

esp32:
  board: esp32dev

# General ESPHome setup
api:
  reboot_timeout: 0s

ota:
  - platform: esphome
    password: !secret ota_password

logger:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: true # Fast connect to connect to my hidden network
  power_save_mode: none

# Load nibe component
external_components:
  - source: github://elupus/esphome-nibe

# Set pins required for LilyGo T-CAN485 board
output:
  - platform: gpio
    id: ENABLE_PIN # Enable the chip
    pin:
      number: GPIO19
      inverted: true
  - platform: gpio
    id: SE_PIN # Enable autodirection
    pin:
      number: GPIO17
      inverted: true
  - platform: gpio
    id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
    pin:
      number: GPIO16
      inverted: true

# Configure uart that will be used
uart:
  rx_pin: GPIO21
  tx_pin: GPIO22
  baud_rate: 9600

# Configure NibeGW
nibegw:
  udp:
    # The target address(s) to send data to. May be a multicast address.
    target:
      - ip: XXX.XXX.XXX.XXX
        port: 9999

    # List of source address to accept data from, may be empty for no filter
    source:
      - XXX.XXX.XXX.XXX
    
    # Optional port this device will listen to to receive read requests. Defaults to 9999
    read_port: 9999

    # Optional port this device will listen to to receive write request. Defaults to 10000
    write_port: 10000

  acknowledge:
    - MODBUS40

  # Constant replies to certain requests cabe made
  constants:
    - address: MODBUS40
      token: ACCESSORY
      data: [
            0x0A, # MODBUS version low
            0x00, # MODBUS version high
            0x01, # MODBUS address?
      ]

# Some helper functions to restart ESPHome from HA
button:
- platform: restart
  name: Nibegw Restart
- platform: safe_mode
  name: Nibegw Safe Mode Boot

Any help would be greatly appreciated.

14

Are we posting the issue in the right place to get assistance, should this be posted on Github or Discord or something?

15

I guess it wouldn’t hurt to post it on the github of KaufHA as well.

16

My guess is that it is this breaking change that cause it.

17

I just posted this issue on KaufHA Github as well.

18

When ESPHome updates, we have to update our custom components to match if there are breaking changes, which is common. We usually have the changes pushed to our github well in advance based on the beta, but we then have to push the new configs for each device once the ESPHome update actually releases. The timing of this can cause problems like you are seeing. Everything should resolve within 24 hours. This will continue to be a problem for most ESPHome releases until I figure out a way around it, which I’m not sure there is right now.

2 Likes
19

I guess what I need to be able to do is automate pushing an update to github in response to ESPHome releases. Then I can get everything ready to go in advance and have it auto post immediately.

20

Flashing the newest version of ESPHome to the ESP device every time it is released is also generally not advised to do.
If there are no updates to your specific use case, then you just add wear to the flash memory on the ESP device and it is the write session that have the highest chance of destroying the device, by far!