Uptime Sensor blocks build at linking phase

[skykingjwc]

The problem

Using an uptime sensor will not allow firmware to build.

Which version of ESPHome has the issue?

2024.3.0

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2024.3.3

What platform are you using?

ESP32

Board

nodemcu-32s

Component causing the issue

sensor/uptime

Example YAML snippet

esphome:
  name: tm1638test
  friendly_name: TM1638Test

esp32:
  board: nodemcu-32s
  framework:
    type: esp-idf
    #type: aruduino also produces same error
    version: recommended

sensor:
  - platform: uptime
    id: utime
    update_interval: 1s

Anything in the logs that might be useful for us?

INFO ESPHome 2024.3.1
INFO Reading configuration /config/esphome/tm1638test.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing tm1638test (board: nodemcu-32s; framework: espidf; platform: platformio/espressif32@5.4.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.40406.240122 (4.4.6) 
 - tool-cmake @ 3.16.4 
 - tool-ninja @ 1.7.1 
 - toolchain-esp32ulp @ 2.35.0-20220830 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
Reading CMake configuration...
Generating assembly for certificate bundle...
No dependencies
Compiling .pioenvs/tm1638test/src/esphome/components/esp32/core.o
Compiling .pioenvs/tm1638test/src/esphome/components/esp32/gpio.o
......
Compiling .pioenvs/tm1638test/bootloader/xtensa/xt_trax.o
Archiving .pioenvs/tm1638test/bootloader/esp-idf/soc/libsoc.a
Generating partitions .pioenvs/tm1638test/partitions.bin
Generating an empty partition .pioenvs/tm1638test/ota_data_initial.bin
Archiving .pioenvs/tm1638test/bootloader/esp-idf/xtensa/libxtensa.a
Archiving .pioenvs/tm1638test/bootloader/esp-idf/spi_flash/libspi_flash.a
Archiving .pioenvs/tm1638test/bootloader/esp-idf/micro-ecc/libmicro-ecc.a
Linking .pioenvs/tm1638test/bootloader.elf
Building .pioenvs/tm1638test/bootloader.bin
Creating esp32 image...
Successfully created esp32 image.
Linking .pioenvs/tm1638test/firmware.elf
/data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pioenvs/tm1638test/esp-idf/vfs/libvfs.a(vfs.o): in function `esp_vfs_utime':
/data/cache/platformio/packages/framework-espidf/components/vfs/vfs.c:585: multiple definition of `utime'; .pioenvs/tm1638test/src/main.o:/data/build/tm1638test/src/main.cpp:10: first defined here
collect2: error: ld returned 1 exit status
*** [.pioenvs/tm1638test/firmware.elf] Error 1
========================= [FAILED] Took 72.67 seconds =========================

Additional information

Tried with both esp-idf and Arduino frameworks. Same error. Also updated to ESPHome V 2024.3.1 and the issue was not resolved.

[Unfocused]

That looks suspiciously like a mismatched build environment (ie, you've updated ESPHome, but something from the previous version got left behind in the build system for whatever reason).

Try running esphome clean or deleting your .esphome sub-folder (assuming you've not manually put any files in there, which you should never do - that entire sub-folder is meant to be generated by ESPHome).

[skykingjwc]

That looks suspiciously like a mismatched build environment (ie, you've updated ESPHome, but something from the previous version got left behind in the build system for whatever reason).

Try running esphome clean or deleting your .esphome sub-folder (assuming you've not manually put any files in there, which you should never do - that entire sub-folder is meant to be generated by ESPHome).

This output is from the ESP home integration in Home Assistant. I created an entirely new ESPHome entity, and also clicked "clean build files" just to be sure. I'll try it again when I get home to see if anything changes.

[skykingjwc]

Same error after deleting .esphome folder.

[skykingjwc]

Same error when running from esphome command line and pulling a new docker image.

[skykingjwc]

Apparently using the id "utime" as the uptime sensor id, causes the issue. Changing the name to something else fixes it. Recommend adjusting code so that reserved names cannot be used in yaml.