Compilation fails on ESPHome 2026.2.4 — set_unit_of_measurement and set_device_class not found Body:

[gromlab]

Compilation fails on ESPHome 2026.2.4 — set_unit_of_measurement and set_device_class not found

Disclosure: I'm not a programmer — I arrived at this diagnosis with help from Claude (Anthropic's AI assistant), which walked me through the setup and helped troubleshoot. I wanted to be transparent about that.

Environment

• ESPHome version: 2026.2.4
• ESPHome installed via: Home Assistant Add-on
• Board: ESP32-S3-DevKitC-1 (N16R8)
• Framework: ESP-IDF
• UPS: CyberPower CP1500PFCLCD

Description

The component fails to compile on ESPHome 2026.2.4. The generated C++ code calls set_unit_of_measurement() and set_device_class() on UpsHidSensor and UpsHidBinarySensor, but these methods don't exist on those classes.

It appears that ESPHome 2026.x changed how sensor properties are set — the set_unit_of_measurement and set_device_class methods were removed or renamed on the base Sensor class. The component's Python codegen (sensor.py, binary_sensor.py) still generates calls to the old API.

Steps to Reproduce

Minimal config:

esphome:
  name: ups-monitor
  friendly_name: UPS Monitor

esp32:
  board: esp32-s3-devkitc-1
  framework:
    type: esp-idf

logger:
  level: DEBUG
  hardware_uart: UART0

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

api:

ota:
  - platform: esphome

external_components:
  - source: github://bullshit/esphome-components
    components: [ups_hid, nut_server]

ups_hid:
  id: ups_monitor
  update_interval: 10s
  protocol: cyberpower
  simulation_mode: true

sensor:
  - platform: ups_hid
    ups_hid_id: ups_monitor
    name: "Battery Level"
    type: battery_level

binary_sensor:
  - platform: ups_hid
    ups_hid_id: ups_monitor
    name: "Online"
    type: online

text_sensor:
  - platform: ups_hid
    ups_hid_id: ups_monitor
    name: "UPS Status"
    type: status

button:
  - platform: ups_hid
    name: "Beeper Enable"
    beeper_action: enable

number:
  - platform: ups_hid
    name: "Shutdown Delay"
    delay_type: shutdown

nut_server:
  ups_hid_id: ups_monitor
  port: 3493

Compile Errors (truncated)

src/main.cpp:378:18: error: 'class esphome::ups_hid::UpsHidSensor' has no member named 'set_unit_of_measurement'; did you mean 'get_unit_of_measurement'?
  378 |   battery_level->set_unit_of_measurement("%");

src/main.cpp:379:18: error: 'class esphome::ups_hid::UpsHidSensor' has no member named 'set_device_class'; did you mean 'get_device_class'?
  379 |   battery_level->set_device_class("battery");

src/main.cpp:597:34: error: 'class esphome::ups_hid::UpsHidBinarySensor' has no member named 'set_device_class'; did you mean 'get_device_class'?
  597 |   ups_hid_upshidbinarysensor_id->set_device_class("battery");

The same pattern repeats for every sensor and binary_sensor entry.

Notes

• Simulation mode works on older firmware — when the component successfully compiled (possibly cached from an earlier ESPHome version), simulation mode booted and ran correctly, registering all sensors and polling data.
• The button and number platforms compile fine — only sensor and binary_sensor are affected.
• The issue is in the Python codegen, not the C++ runtime — UpsHidSensor inherits from a base class that no longer exposes set_unit_of_measurement() as a public method in ESPHome 2026.x.
• We also confirmed that hardware_uart: UART0 is needed in the logger config to free up the native USB port for USB host mode — without it, the USB JTAG serial interface claims the port and the UPS HID transport cannot connect.

[kramttocs]

Mine compiles and installs fine but ends up in a bootloop once I restart the esp device with no indication of what's wrong

I am not using Simulation mode so could be entirely different or just a different way of manifesting.

[golfleep]

Same issue, I had been running esphome 2025.11.1 and was able to run the components without issues. I've been playing around with the code for my use case, and happened to upgrade to esphome 2026.3.0. Able to compile and install, but ends up in a bootloop. Rolled back to 2025.11.1, recompiled and installed without issue. Planning to try intermediate esphome versions to try and identify the issue

[EnUfor]

Ran into the 2026.3.0 update issue after I just started using these components last week. 2026.3.0 firmware will build using the same YAML and show a successful OTA, I eventually found the issues in the logs:

[I][app:215]: ESPHome version 2026.2.4 compiled on 2026-03-14 18:11:03 -0400` and report
...
[W][safe_mode:054]: OTA rollback detected! Rolled back from partition 'app1'

It was booting the previous build as a result of catching the boot loop in the new OTA firmware.

I originally missed the rollback warning, so I ended up manually loading the firmware.factory.bin file via USB where I then discovered the boot loop was a result of the new build. Seems 2026.3.0 broke these components and causes a boot loop.

My solution was to compile and load the firmware locally with 2026.2.4 with the same configuration I had prior:

Code

esphome:
  name: ${name}
  friendly_name: ${friendly_name}

substitutions:
  name: "cyberpower-ups"
  friendly_name: "Cyberpower UPS"
  simulation_mode: "false"

packages:
  remote_package:
    url: https://github.com/bullshit/esphome-components
    ref: main
    files:
      - configs/delay_config.yaml
      - configs/entity_groups.yaml
      - configs/essential_sensors_grouped.yaml
      - configs/extended_sensors_grouped.yaml
      - configs/timer_sensors_grouped.yaml
      - configs/ups_controls_grouped.yaml
      - configs/device_types/cyberpower_cp1500.yaml
    refresh: 600s

external_components:
  - source: github://bullshit/esphome-components
    components:
      - ups_hid
      - nut_server

ups_hid:
  id: ups_monitor
  protocol: auto
  update_interval: 10s

nut_server:
  ups_hid_id: ups_monitor
  ups_name: ${name}
  username: ""
  password: ""
 
 button:
 sensor:
 number:

[golfleep]

Using the changes to protocol_factory.cpp as outlined in this commit, I am able to successfully compile and run these components under esphome 2026.3.0+

The changes are described in more detail in the first part of issue 17, as well as in the commit above.

[matias53]

Ran into this too on ESPHome 2026.6.4. The cause: sensor.py / binary_sensor.py emit cg.add(var.set_device_class(...)) / set_unit_of_measurement(...) as fallback defaults when those options are not set in YAML, but those C++ setters were removed in ESPHome 2026.x (device class / unit are now resolved at codegen time via a string table).

Workaround: explicitly declare device_class, unit_of_measurement and accuracy_decimals on every ups_hid sensor and device_class on every binary sensor in your YAML — then the python skips the broken codegen calls.

Proper fix: the python should pass these defaults through the config/schema instead of calling the removed setters.