Conversation
|
Warning Rate limit exceeded@edwardtfn has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 20 minutes and 2 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughAdds a new tx_ultimate_easy C++ API and cached device-name for emitting enriched Home Assistant events; replaces YAML Changes
Sequence Diagram(s)sequenceDiagram
participant YAML as Device YAML (touch/button)
participant API as tx_ultimate_easy::fire_ha_event
participant ESPAPI as esphome::api::CustomAPIDevice
participant HA as Home Assistant
YAML->>API: call fire_ha_event(domain,type,data)
Note right of API: normalize/augment payload with cached_device_name, firmware, domain, type
API->>ESPAPI: create CustomAPIDevice + fire_homeassistant_event(enriched_payload)
ESPAPI->>HA: deliver Home Assistant event
HA-->>ESPAPI: ack
ESPAPI-->>API: return status
API-->>YAML: return
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml (1)
273-279: Keeptx_device_nameconsistent withcached_device_name
tx_device_namenow exposesesphome::tx_ultimate_easy::cached_device_namein its lambda:lambda: |- return { esphome::tx_ultimate_easy::cached_device_name };but
publish_device_infostill publishes the rawApp.get_name():tx_device_name->publish_state(App.get_name().c_str());So the HA text sensor can diverge from the cached/sanitized name used in your new event helper.
To keep everything aligned (events, logs, and the diagnostic sensor), consider publishing the cached value instead:
- - lambda: |- - tx_fw_version->publish_state("${version}"); - tx_device_name->publish_state(App.get_name().c_str()); + - lambda: |- + tx_fw_version->publish_state("${version}"); + tx_device_name->publish_state(esphome::tx_ultimate_easy::cached_device_name.c_str());(Assuming
cached_device_nameis guaranteed to be initialized by the timepublish_device_inforuns; otherwise you might also want a small helper to initialize/fill it once.)Also applies to: 349-358
🧹 Nitpick comments (6)
ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_touch.yaml (2)
380-388: Multi‑touch HA event wiring looks goodUsing
fire_ha_event("touch", "multi_touch", …)withaction="release"andpositioncentralizes the HA wiring nicely and lines up with the new API. If you ever want stricter validation, you could mirror the range check you use for long‑touch, but it’s not strictly necessary here.
407-418: Swipe event payloads: confirm “action” semantics vs directionThe new swipe handlers look consistent and model‑aware:
const char *direction = (sl_tx_model_format->state == "...EU...") ? "left"/"right" : "down"/"up";and you send:
{"action", direction}, {"swipe-direction", direction},This duplicates the direction in two keys and makes
actionhold the direction, while for multi‑touchactionrepresents"release".If your intent is:
type→ high‑level kind ("swipe")action→ verb ("swipe")swipe-direction→"left" | "right" | "up" | "down"you might want to instead keep direction only in
swipe-directionand reserveactionfor something like"swipe". If you are maintaining compatibility with existing automations that look atactionfor the direction, then the current shape is fine—just worth double‑checking.Also applies to: 419-429
components/tx_ultimate_easy/tx_ultimate_easy_api.h (3)
4-9: Add missing standard includes forstd::stringandstd::mapThis header publicly exposes
std::stringandstd::mapbut only includes<cstdint>. Relying on transitive includes from other headers is brittle.Consider:
-#include <cstdint> +#include <cstdint> +#include <map> +#include <string>This makes the header self‑contained and safer against upstream include changes.
Also applies to: 17-19, 55-76
17-19: Remove duplicateextern cached_device_namedeclaration
cached_device_nameis declared twice:// Cached device name to avoid repeated lookups and string copies extern std::string cached_device_name; ... // Cached device name to avoid repeated lookups and string copies extern std::string cached_device_name;You can drop one of them (the second block at Lines 52–54 is redundant) to avoid noise.
- // Cached device name to avoid repeated lookups and string copies - extern std::string cached_device_name; -Also applies to: 52-54
55-76: Syncfire_ha_eventdocumentation with the actual APIThe doc block is slightly out of date:
- It says “Automatically adds device_name and type” but the implementation also adds
firmwareanddomain.- It references
init_device_name_cache()which doesn’t exist now (name is initialized via WiFion_connectinstead).- The example omits the
domainparameter and doesn’t match the current signature.Suggest updating the comment and example to something like:
/** * @brief Fire a Home Assistant event for TX Ultimate Easy. * * Automatically adds device_name, firmware, domain and type to the event data. * * @param domain Event domain (e.g., "touch", "audio", "relay"). * @param type Event type (e.g., "multi_touch", "swipe", "boot"). * @param data Additional event data; core fields are injected automatically. * * @note The event name is fixed to "esphome.tx_ultimate_easy". * * @code * fire_ha_event("touch", "swipe", { * {"swipe-direction", "left"}, * {"position", "3"} * }); * @endcode */to avoid confusion for future callers.
ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml (1)
366-382: Name sanitization on Wi‑Fi connect is good; small ctype nitThe
wifi.on_connectlambda that buildscached_device_namefromApp.get_name()is a nice central place to normalize the HA‑safe name and publish it.One minor C++/ctype detail:
isalnum(c)andtolower(c)expect anunsigned char(orEOF). Passing a plaincharcan be UB for non‑ASCII values on some platforms.If you want to be fully defensive, you could tweak the loop body to:
for (const char &c : App.get_name()) { unsigned char uc = static_cast<unsigned char>(c); if (isalnum(uc)) { esphome::tx_ultimate_easy::cached_device_name += static_cast<char>(tolower(uc)); last_was_underscore = false; } else if (!last_was_underscore) { esphome::tx_ultimate_easy::cached_device_name += '_'; last_was_underscore = true; } }Functionally you’re fine for typical ASCII hostnames; this is just a robustness polish.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml(3 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_touch.yaml(2 hunks)components/tx_ultimate_easy/tx_ultimate_easy_api.cpp(1 hunks)components/tx_ultimate_easy/tx_ultimate_easy_api.h(1 hunks)
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
📚 Learning: 2025-08-11T22:06:11.073Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_touch.yamlcomponents/tx_ultimate_easy/tx_ultimate_easy_api.hESPHome/TX-Ultimate-Easy-ESPHome_core_common.yamlcomponents/tx_ultimate_easy/tx_ultimate_easy_api.cpp
📚 Learning: 2025-08-05T19:18:45.684Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:547-561
Timestamp: 2025-08-05T19:18:45.684Z
Learning: In the TX Ultimate Easy project's light_attributes_restore script in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml, the user intentionally chose to restore only brightness and RGB attributes without turning the light on. The design uses C++ lambdas instead of ESPHome YAML functions specifically to avoid automatically turning lights on during restoration, allowing users to manually control the on/off state while preserving visual settings.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_touch.yamlESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml
📚 Learning: 2025-07-09T22:37:04.600Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 111
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:121-129
Timestamp: 2025-07-09T22:37:04.600Z
Learning: In ESPHome, to fire Home Assistant events from C++ lambda functions, the correct approach is to create a stack variable of type `esphome::api::CustomAPIDevice` and call `fire_homeassistant_event()` on it, not to use the API server component directly.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_touch.yamlcomponents/tx_ultimate_easy/tx_ultimate_easy_api.hcomponents/tx_ultimate_easy/tx_ultimate_easy_api.cpp
📚 Learning: 2025-08-10T21:47:55.413Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yamlcomponents/tx_ultimate_easy/tx_ultimate_easy_api.cpp
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ IDF Core (dev)
🔇 Additional comments (2)
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp (1)
8-12: Event helper structure and logging look solidThe centralized
fire_ha_eventhelper, including the per‑event logging and the use ofesphome::api::CustomAPIDevice, aligns well with the recommended ESPHome pattern and should make HA event wiring from YAML much cleaner.Also applies to: 21-29, 31-36
ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml (1)
32-37: Core wiring (tag, HA services, firmware macro) looks consistentUpdating
TAG_CORE_COMMON, enablinghomeassistant_services, and adding theTX_ULTIMATE_EASY_FIRMWARE_VERSIONbuild flag all line up with the new centralized HA event helper and firmware reporting. No issues here from a config standpoint.Also applies to: 87-90
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml (1)
127-137: Based on my verification, I've discovered a critical inconsistency in how Home Assistant events are fired across the codebase. The review comment raised valid concerns but missed the core issue. Here's the rewritten review:
Use the
esphome::tx_ultimate_easy::fire_ha_event()wrapper instead ofCustomAPIDevicedirectly for consistency.The
tx_ultimate_easycomponent provides a dedicatedfire_ha_event()wrapper function (defined incomponents/tx_ultimate_easy/tx_ultimate_easy_api.h:74) that automatically handles device_name, firmware, domain, and type fields. The hw_touch.yaml component correctly uses this wrapper, but hw_buttons.yaml (lines 127-137) and common.yaml (lines 151-155) bypass it by directly instantiatingCustomAPIDeviceand callingfire_homeassistant_event().Replace the manual
CustomAPIDevicepattern with:esphome::tx_ultimate_easy::fire_ha_event("touch", "button", { {"action", action.c_str()}, {"button_id", std::to_string(button)}, {"count", std::to_string(count)}, {"position", std::to_string(id(button_press_position))} });This ensures API consistency, simplifies code, and uses the documented public interface.
tx_device_nameis properly defined in common.yaml and available; the issue is architectural inconsistency, not availability.
🧹 Nitpick comments (2)
ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml (1)
5-5: Update file header comment to match new naming convention.The file header at line 5 still references "Standard - Hardware - Speaker", but the new log message at line 89 shortened it to "Hardware - Speaker". For consistency, update the header comment.
-##### Purpose: ESPHome - Standard - Hardware - Speaker ##### +##### Purpose: ESPHome - Hardware - Speaker #####ESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml (1)
5-5: Update file header comment to match new naming convention.The file header at line 5 still references "Standard - I2S Audio", but the new log message at line 40 shortened it to "Hardware - Audio". For consistency, update the header comment.
-##### Purpose: ESPHome - Standard - I2S Audio ##### +##### Purpose: ESPHome - I2S Audio #####
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
ESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml(2 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml(5 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yaml(11 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml(19 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml(3 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yaml(4 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml(3 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_media_player.yaml(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- ESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml
🧰 Additional context used
🧠 Learnings (15)
📓 Common learnings
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
📚 Learning: 2025-08-11T22:06:11.073Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yamlESPHome/TX-Ultimate-Easy-ESPHome_media_player.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml
📚 Learning: 2025-08-10T21:47:55.413Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yamlESPHome/TX-Ultimate-Easy-ESPHome_media_player.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml
📚 Learning: 2025-08-05T19:20:33.157Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:72-76
Timestamp: 2025-08-05T19:20:33.157Z
Learning: In the TX Ultimate Easy project, the `attr_light_output_1` global variable in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml is intentionally saved but not restored on boot because the restoration logic will be implemented in the hw_leds area in the near future. The `light_attributes_restore` script consumer is planned to be in the hw_relays area while the script itself remains in hw_leds as part of the ongoing storage optimization work.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml
📚 Learning: 2025-08-05T19:18:45.684Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:547-561
Timestamp: 2025-08-05T19:18:45.684Z
Learning: In the TX Ultimate Easy project's light_attributes_restore script in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml, the user intentionally chose to restore only brightness and RGB attributes without turning the light on. The design uses C++ lambdas instead of ESPHome YAML functions specifically to avoid automatically turning lights on during restoration, allowing users to manually control the on/off state while preserving visual settings.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml
📚 Learning: 2025-07-29T08:10:32.072Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 112
File: .github/workflows/validate_esphome_dev.yml:52-210
Timestamp: 2025-07-29T08:10:32.072Z
Learning: Media player functionality is now supported by both Arduino and IDF frameworks in TX Ultimate Easy ESPHome configurations, removing the previous Arduino-only limitation.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yamlESPHome/TX-Ultimate-Easy-ESPHome_media_player.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml
📚 Learning: 2024-12-26T21:18:44.593Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 73
File: ESPHome/TX-Ultimate-Easy-ESPHome_addon_media_player.yaml:14-20
Timestamp: 2024-12-26T21:18:44.593Z
Learning: In the TX Ultimate Easy ESPHome setup, the i2s_dout_pin for audio output is defined in respective speaker or media_player components rather than in the core_hw_audio package.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlESPHome/TX-Ultimate-Easy-ESPHome_media_player.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml
📚 Learning: 2025-08-06T21:11:16.509Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:1356-1358
Timestamp: 2025-08-06T21:11:16.509Z
Learning: In the TX Ultimate Easy project's relay light mode selectors in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml, the fallback value for active_index().value_or(1) is intentionally set to 1, which corresponds to the first active light mode (Bottom for EU, Left for US) rather than 0 (Disabled). This ensures the default behavior maintains LED functionality rather than disabling lights on cold boot.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2024-12-21T22:36:10.732Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 50
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_buttons.yaml:201-222
Timestamp: 2024-12-21T22:36:10.732Z
Learning: The user clarified that handling millisecond overflow for button press duration is unnecessary because the relevant logic only runs if current_time is strictly greater than the recorded start time.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml
📚 Learning: 2024-12-24T22:40:00.309Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 71
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_speaker.yaml:20-21
Timestamp: 2024-12-24T22:40:00.309Z
Learning: The BLE addon uses a unique speaker component named mp_speaker and removes the media_player component entirely, so no rename from mp_speaker to mp_media_player is required there.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yamlESPHome/TX-Ultimate-Easy-ESPHome_media_player.yaml
📚 Learning: 2025-08-10T19:32:07.897Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:1326-1333
Timestamp: 2025-08-10T19:32:07.897Z
Learning: In the TX Ultimate Easy project's relay light modes in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml, "Disabled" mode intentionally decouples LED control from relay state changes, allowing users to control the LEDs independently via other means (e.g., Home Assistant). When transitioning TO "Disabled" mode at runtime, lights should turn off. When transitioning FROM "Disabled" to another mode, lights should update based on the current relay state. These transitions should only occur during runtime mode changes, not during boot/restore, to preserve user-defined light states.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2025-08-06T20:53:35.572Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:558-576
Timestamp: 2025-08-06T20:53:35.572Z
Learning: In the TX Ultimate Easy project, brightness values are already clamped using std::min(attr.brightness, uint8_t(100)) in the pack_light_attributes() and unpack_light_attributes() functions in components/tx_ultimate_easy/tx_ultimate_easy_light.cpp. RGB values are naturally constrained by uint8_t casting and bit masking operations. No additional clamping is needed at the calling sites in the ESPHome YAML files.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2025-08-08T12:08:27.935Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:0-0
Timestamp: 2025-08-08T12:08:27.935Z
Learning: In TX Ultimate Easy, the default packed dual light attributes constant must be 0x64FFFFFF64FFFFFF (16 hex digits) across YAML substitutions (LIGHT_DUAL_ATTRS_DEFAULT) and C++ (DEFAULT_DUAL_LIGHT_ATTRS_PACKED). Avoid leading zeros that would push beyond 64 bits.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2025-08-01T08:21:34.925Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 112
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:53-57
Timestamp: 2025-08-01T08:21:34.925Z
Learning: The `esp32_rmt_led_strip` platform in ESPHome does not support a `rmt_channel` parameter. Valid parameters include pin, num_leds, chipset, rgb_order (required) and is_rgbw, is_wrgb, max_refresh_rate, use_psram, rmt_symbols, use_dma (optional). The platform handles RMT channel allocation internally.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yaml
📚 Learning: 2024-12-22T00:26:54.059Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 50
File: components/tx_ultimate_easy/tx_ultimate_easy.cpp:54-59
Timestamp: 2024-12-22T00:26:54.059Z
Learning: The default value for gang_count_ in TxUltimateEasy is already initialized to 1 in the header file, removing the need for additional constructor initialization.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
🔇 Additional comments (18)
ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml (1)
19-19: Systematic tag and build-flag renaming is consistent and correct.The refactoring from
TAG_STD_*→TAG_*,TX_ULTIMATE_EASY_STANDARD_*→TX_ULTIMATE_EASY_*, and preprocessor symbol updates align with the dependency chain. Package include references and build flags are properly set.Also applies to: 22-22, 36-36, 43-43, 81-86, 89-89
ESPHome/TX-Ultimate-Easy-ESPHome_media_player.yaml (1)
15-15: Tag and build-flag refactoring is complete and consistent.All tag references updated from
TAG_STD_MEDIA_PLAYER→TAG_MEDIA_PLAYER, build flag corrected (also fixing the typoULTIATE→ULTIMATE), and preprocessor guards properly check for required dependencies (COMMON and HW_SPEAKER).Also applies to: 18-18, 23-23, 60-60, 73-76, 83-88, 91-91, 102-102
ESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml (1)
17-17: Tag and build-flag refactoring is consistent and correctly updates dependencies.The transition from
TAG_STD_HW_AUDIO→TAG_HW_AUDIO, build-flag standardization, and preprocessor check update toTX_ULTIMATE_EASY_COMMONare all properly aligned.Also applies to: 22-22, 35-35, 40-40
ESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yaml (4)
604-619: Logging tag updates are systematic and complete.All ESP_LOGCONFIG, ESP_LOGE, ESP_LOGD, ESP_LOGI, and ESP_LOGW calls have been updated to use the new
${TAG_HW_LEDS}substitution consistently. The refactoring is thorough across the entire logging context (transition times, restore modes, attribute handling, effect handling, and error conditions).Also applies to: 641-789
631-631: Logging hierarchy is correct and consistent with other hardware packages.Line 631 correctly uses
ESPHOME_PROJECT_NAMEfor a high-level summary header, which aligns with the established logging pattern across all hardware packages in the project. Detailed configuration logs (e.g., lines 604–619 in the same file) use component-specific tags like${TAG_HW_LEDS}, while summary headers consistently useESPHOME_PROJECT_NAME. This is confirmed in hw_audio.yaml:40 and hw_buttons.yaml:249, which follow the same pattern. No changes needed.
626-627: Package dependency naming is correctly aligned. The flagTX_ULTIMATE_EASY_COMMONis properly defined inESPHome/TX-Ultimate-Easy-ESPHome_common.yaml(line 88, underplatformio_options.build_flags), and the package check references the correct file name. The flag is used consistently across all dependent modules, and the previous flagTX_ULTIMATE_EASY_CORE_COMMONhas been fully migrated.
35-35: Logging tag and build flag refactoring successfully completed with no stale references.The systematic renaming has been thoroughly applied:
TAG_HW_LEDScorrectly substituted (line 35)TX_ULTIMATE_EASY_HW_LEDSbuild flag properly set (line 40)- Package dependency correctly updated to
TX_ULTIMATE_EASY_COMMON(line 626) with matching definition in common.yaml- Error message references correct package file (line 627)
- All logging calls use the new tag name
Search confirmed zero remaining references to old names (
TX_ULTIMATE_EASY_CORE_HW_LEDSorTAG_CORE_HW_LEDS) across the codebase. No other files depend on these old identifiers.ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml (2)
39-39: Tag and build flag renaming applied consistently.The substitution tag and build flag changes from
core_hw_buttonstohw_buttonsare reflected correctly throughout the file with consistent naming.Also applies to: 65-65
244-246: Build flag is properly defined in the renamed common.yaml package.The verification confirms that
TX_ULTIMATE_EASY_COMMONis correctly defined at line 88 ofESPHome/TX-Ultimate-Easy-ESPHome_common.yamlwith the compiler directive-D TX_ULTIMATE_EASY_COMMON. The preprocessor check at lines 244-246 ofhw_buttons.yamlproperly references this flag, and the same pattern is consistently used across all related files (hw_leds.yaml, hw_relays.yaml, hw_touch.yaml, etc.). No issues detected.ESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yaml (5)
289-292: Logging tag updates look consistent.All
ESP_LOG*calls have been properly updated to reference${TAG_HW_TOUCH}instead of the previous tag. The log levels and messages are appropriate.Also applies to: 375-377, 395-398, 404-404, 433-435
383-386: I'll help you verify thefire_ha_eventAPI usage in the ESPHome configuration. Let me search for the function definition and examine the component structure.
<function_calls>
#!/bin/bashSearch for fire_ha_event function definition
echo "=== Searching for fire_ha_event function definition ==="
find . -type f ( -name ".cpp" -o -name ".h" ) | xargs grep -l "fire_ha_event" 2>/dev/null | head -10echo -e "\n=== Searching for tx_ultimate_easy component ==="
find . -type d -name "tx_ultimate_easy" 2>/dev/nullecho -e "\n=== Looking for component structure ==="
find . -type f -name "*.h" | xargs grep -l "tx_ultimate_easy" 2>/dev/null | head -10
</function_calls>I need to wait for the shell script results to verify the
fire_ha_eventfunction. Please execute the script above to gather information about the API definition and component structure.
299-301: The preprocessor check change is correct and intentional—TX_ULTIMATE_EASY_COMMON is properly defined in common.yaml and is a standardized dependency across all hardware modules.Verification confirms that
TX_ULTIMATE_EASY_COMMONis defined inESPHome/TX-Ultimate-Easy-ESPHome_common.yamlas a build flag (-D TX_ULTIMATE_EASY_COMMON). This change is part of a consistent architectural pattern: all hardware modules in the project (media_player, hw_vibration, hw_speaker, hw_relays, hw_leds, hw_buttons, hw_audio, and hw_touch) use the same dependency check for common.yaml. This standardization confirms that common.yaml is an intentional universal dependency for all hardware components.
17-17: No issues found. The renamed substitutions and build flags have been properly updated throughout the codebase.The verification confirms that:
- No references to the old
TAG_CORE_HW_TOUCHorTX_ULTIMATE_EASY_CORE_HW_TOUCHidentifiers remain in the codebase- The new
TAG_HW_TOUCHsubstitution is defined and used consistently across all logging statements- The new
TX_ULTIMATE_EASY_HW_TOUCHbuild flag is properly applied in both the header/cpp files and the YAML configuration- All references are syntactically correct and consistent
410-410: TheTX_MODEL_FORMAT_EU_TEXTsubstitution is properly defined and accessible.The substitution is defined in
common.yaml(line 22) as"EU (Square, T5-xC-86)"and is included beforehw_touch.yamlincore.yaml(lines 16–19), ensuring availability when the lambda code executes. The comparison logic at lines 410 and 422 is correct and follows the same pattern used elsewhere in the codebase. Additionally,hw_touch.yamlincludes a C++ preprocessor guard (#if !defined(TX_ULTIMATE_EASY_COMMON)) that will error ifcommon.yamlis not included, providing compile-time validation of the dependency.ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml (4)
818-818: Logging tag refactoring is consistent and complete.All ESP_LOG* calls have been systematically updated from the old tag to
${TAG_HW_RELAYS}. The string interpolation format is consistent, and logging behavior is preserved. No apparent orphaned references to the old tag name detected.Also applies to: 959-966, 998-1003, 1011-1065, 1104-1148, 1331-1332, 1382-1389, 1437-1444, 1501-1508, 1542-1549, 1606-1613, 1647-1654, 1711-1716, 1750-1755
1-13: File header and purpose remain clear.The file header and purpose statement are unchanged, maintaining clarity that this is the ESPHome Hardware Relays configuration. The renaming of tags and build flags does not affect documentation or intent.
26-26: Build flag alignment is correct and complete.The build flag
TX_ULTIMATE_EASY_HW_RELAYS(line 31) and substitution tagTAG_HW_RELAYS: tx_ultimate_easy.hw.relays(line 26) are properly defined. Related required flags (TX_ULTIMATE_EASY_COMMONandTX_ULTIMATE_EASY_HW_LEDS) are defined in their respective YAML files, and preprocessor guards (lines 1071–1076) correctly validate their presence. No separate C++ component files for relays exist—all relay logic is inline in the YAML configuration. No remnants of the old naming convention remain.
1071-1076: Manual verification required—repository access unavailable.The repository clone failed, preventing automated verification of the preprocessor guard definitions. To confirm these changes are correct, manually verify that:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yamldefinesTX_ULTIMATE_EASY_COMMONin itsesphome.platformio_options.build_flagssectionESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamldefinesTX_ULTIMATE_EASY_HW_LEDSin itsesphome.platformio_options.build_flagssection- Old guard names (
TX_ULTIMATE_EASY_CORE_COMMONandTX_ULTIMATE_EASY_CORE_HW_LEDS) no longer appear in build_flags
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml (1)
125-137: Event emission viaCustomAPIDeviceis functional but consider migration path.The
button_actionscript emits Home Assistant events usingesphome::api::CustomAPIDevice::fire_homeassistant_event(). While this works, note thathw_touch.yamlhas migrated to usingesphome::tx_ultimate_easy::fire_ha_event()for similar event emission.For consistency across the codebase, consider whether
button_actionshould also use the new centralizedfire_ha_event()API in a future refactor. For now, this implementation is acceptable and functional.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml(6 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml(5 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml(17 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml(6 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yaml(4 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml(6 hunks)versioning/VERSION(1 hunks)versioning/VERSION_YAML(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- versioning/VERSION
- versioning/VERSION_YAML
🧰 Additional context used
🧠 Learnings (15)
📓 Common learnings
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
📚 Learning: 2025-08-11T22:06:11.073Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml
📚 Learning: 2025-08-10T21:47:55.413Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml
📚 Learning: 2025-08-05T19:20:33.157Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:72-76
Timestamp: 2025-08-05T19:20:33.157Z
Learning: In the TX Ultimate Easy project, the `attr_light_output_1` global variable in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml is intentionally saved but not restored on boot because the restoration logic will be implemented in the hw_leds area in the near future. The `light_attributes_restore` script consumer is planned to be in the hw_relays area while the script itself remains in hw_leds as part of the ongoing storage optimization work.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml
📚 Learning: 2025-08-05T19:18:45.684Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:547-561
Timestamp: 2025-08-05T19:18:45.684Z
Learning: In the TX Ultimate Easy project's light_attributes_restore script in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml, the user intentionally chose to restore only brightness and RGB attributes without turning the light on. The design uses C++ lambdas instead of ESPHome YAML functions specifically to avoid automatically turning lights on during restoration, allowing users to manually control the on/off state while preserving visual settings.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml
📚 Learning: 2025-07-29T08:10:32.072Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 112
File: .github/workflows/validate_esphome_dev.yml:52-210
Timestamp: 2025-07-29T08:10:32.072Z
Learning: Media player functionality is now supported by both Arduino and IDF frameworks in TX Ultimate Easy ESPHome configurations, removing the previous Arduino-only limitation.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml
📚 Learning: 2025-08-06T21:11:16.509Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:1356-1358
Timestamp: 2025-08-06T21:11:16.509Z
Learning: In the TX Ultimate Easy project's relay light mode selectors in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml, the fallback value for active_index().value_or(1) is intentionally set to 1, which corresponds to the first active light mode (Bottom for EU, Left for US) rather than 0 (Disabled). This ensures the default behavior maintains LED functionality rather than disabling lights on cold boot.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2025-08-10T19:32:07.897Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:1326-1333
Timestamp: 2025-08-10T19:32:07.897Z
Learning: In the TX Ultimate Easy project's relay light modes in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml, "Disabled" mode intentionally decouples LED control from relay state changes, allowing users to control the LEDs independently via other means (e.g., Home Assistant). When transitioning TO "Disabled" mode at runtime, lights should turn off. When transitioning FROM "Disabled" to another mode, lights should update based on the current relay state. These transitions should only occur during runtime mode changes, not during boot/restore, to preserve user-defined light states.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2024-12-26T21:18:44.593Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 73
File: ESPHome/TX-Ultimate-Easy-ESPHome_addon_media_player.yaml:14-20
Timestamp: 2024-12-26T21:18:44.593Z
Learning: In the TX Ultimate Easy ESPHome setup, the i2s_dout_pin for audio output is defined in respective speaker or media_player components rather than in the core_hw_audio package.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml
📚 Learning: 2024-12-21T22:36:10.732Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 50
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_buttons.yaml:201-222
Timestamp: 2024-12-21T22:36:10.732Z
Learning: The user clarified that handling millisecond overflow for button press duration is unnecessary because the relevant logic only runs if current_time is strictly greater than the recorded start time.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml
📚 Learning: 2024-12-19T22:29:32.736Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 31
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_vibration.yaml:82-88
Timestamp: 2024-12-19T22:29:32.736Z
Learning: Due to "restore_mode: ALWAYS_OFF" and a turn-off step on OTA, the vibration motor is automatically shut off in restart/OTA scenarios, making additional race-condition handling unnecessary.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml
📚 Learning: 2025-08-06T20:53:35.572Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:558-576
Timestamp: 2025-08-06T20:53:35.572Z
Learning: In the TX Ultimate Easy project, brightness values are already clamped using std::min(attr.brightness, uint8_t(100)) in the pack_light_attributes() and unpack_light_attributes() functions in components/tx_ultimate_easy/tx_ultimate_easy_light.cpp. RGB values are naturally constrained by uint8_t casting and bit masking operations. No additional clamping is needed at the calling sites in the ESPHome YAML files.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2025-08-08T12:08:27.935Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:0-0
Timestamp: 2025-08-08T12:08:27.935Z
Learning: In TX Ultimate Easy, the default packed dual light attributes constant must be 0x64FFFFFF64FFFFFF (16 hex digits) across YAML substitutions (LIGHT_DUAL_ATTRS_DEFAULT) and C++ (DEFAULT_DUAL_LIGHT_ATTRS_PACKED). Avoid leading zeros that would push beyond 64 bits.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2024-12-22T00:26:54.059Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 50
File: components/tx_ultimate_easy/tx_ultimate_easy.cpp:54-59
Timestamp: 2024-12-22T00:26:54.059Z
Learning: The default value for gang_count_ in TxUltimateEasy is already initialized to 1 in the header file, removing the need for additional constructor initialization.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2024-12-24T22:40:00.309Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 71
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_speaker.yaml:20-21
Timestamp: 2024-12-24T22:40:00.309Z
Learning: The BLE addon uses a unique speaker component named mp_speaker and removes the media_player component entirely, so no rename from mp_speaker to mp_media_player is required there.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ Arduino Core (latest)
🔇 Additional comments (17)
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml (5)
32-32: Verifyhomeassistant_services: trueis required for event emission.The API configuration has been updated to enable Home Assistant services. Ensure that the tx_ultimate_easy C++ component's
fire_ha_eventimplementation correctly leverages this setting to emit events to Home Assistant.Also applies to: 36-36
82-82: Verify ESPHome minimum version requirement.The
min_versionhas been updated to 2025.11.0. Confirm that this version bump is necessary for the newhomeassistant_servicesAPI feature or other changes in this PR, and document the reason if it's a breaking change.
186-191: String comparison logic is correct.Line 187 correctly uses
current_option()to get the model format as a string before comparing. The logic is sound and aligns with the approach used in other files (hw_speaker, hw_vibration, hw_touch).
357-358: Device name caching integration looks correct.The text_sensor now returns
esphome::tx_ultimate_easy::cached_device_name. This assumes the variable is properly declared asexternin the tx_ultimate_easy_api.h header and initialized during wifi connection.Confirm that
cached_device_nameis declared asextern std::stringin the tx_ultimate_easy_api.h component header, and that it is initialized early enough to prevent stale state.
366-382: Device name generation on wifi connect is well-implemented.The logic correctly filters alphanumeric characters (converting to lowercase) and replaces non-alphanumeric sequences with underscores while avoiding consecutive underscores. This is a robust approach for generating valid device identifiers on first connection.
One minor observation: The cache is populated only once (when
cached_device_name.empty()). Ensure this is the intended behavior and that manual device name changes in Home Assistant do not require re-initialization.ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml (2)
81-89: Preprocessor guard naming is consistent.The error checks have been updated to reference
TX_ULTIMATE_EASY_COMMONandTX_ULTIMATE_EASY_HW_AUDIO, replacing the oldTX_ULTIMATE_EASY_CORE_COMMONnaming. This is consistent with the build flag changes in the file.
134-134: String comparisons usingstrcmpare appropriate.The conditional checks correctly use
strcmpto comparecurrent_option()string results against literal values. The use of logical OR for multiple matching options ("On press" OR "Always", "On release" OR "Always") is correct and idiomatic.Also applies to: 146-149, 159-162
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml (1)
224-237: Use ofcurrent_option()for displaying selector state is correct.Lines 224-237 correctly retrieve the current option text from button action selectors and display them in config logs. The pattern is consistent across this file and others.
ESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml (1)
17-17: Tag, build flag, and strcmp logic are all consistent.This file follows the standardized naming pattern:
- TAG renamed to TAG_HW_VIBRATION
- Build flag updated to TX_ULTIMATE_EASY_HW_VIBRATION
- All logging migrated to new tag
- Preprocessor guard correctly references TX_ULTIMATE_EASY_COMMON
- strcmp conditionals for "On press", "On release", "Always", "Disabled" are correct
Also applies to: 40-40, 67-76, 83-88, 98-98, 110-113, 123-126
ESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yaml (3)
383-386: Migration to centralizedfire_ha_event()API is clean.The
on_multi_touch_releaseevent emission has been migrated toesphome::tx_ultimate_easy::fire_ha_event("touch", "multi_touch", {...}). The payload structure includes action ("release") and position.Confirm that the
fire_ha_event()function signature accepts domain (string), type (string), and data (map), and that it automatically includes device_name, firmware, and other enriched context in the emitted event.
410-417: Swipe event direction logic correctly maps model format.The swipe events use model-aware direction mapping:
- EU model: swipe_left → "left", swipe_right → "right"
- US model: swipe_left → "down", swipe_right → "up"
This correctly accounts for the 90° rotation between EU (square) and US (rectangle) layouts. The
current_option()comparison is correct.Also applies to: 423-430
375-405: Long-touch and press event logging is consistent.Logging for
on_long_touch_release,on_press, andon_releaseevents have all been updated to useTAG_HW_TOUCH. Validation of touch position bounds is preserved and appropriate.ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml (5)
969-990: Use ofcurrent_option()for button action retrieval is appropriate.Lines 969, 976, 983, 990 correctly call
current_option()to retrieve the current button action as a string, enabling comparison with action text constants. This replaces any previous state-based access and is consistent across the file.
1013-1023: Relay mode and LED mode logging correctly usescurrent_option().The dump_config script retrieves and displays current relay modes and light modes using
current_option(), with model-aware selection (ternary operator) for EU vs US light mode selectors. The logic is sound and maintains readability.Also applies to: 1050-1064
1071-1080: Preprocessor guards are updated and consistent.The
#if !defined(...)checks have been updated to referenceTX_ULTIMATE_EASY_COMMONandTX_ULTIMATE_EASY_HW_LEDS, matching the build flag renames. The error messages are clear and helpful.
1308-1327: Light mode retrieval usingcurrent_option()is correct.The
show_relay_statusscript correctly retrieves light mode for each relay usingcurrent_option()on the model-appropriate selector (EU or US) based onis_us_model. The ternary logic is clear and maintains consistency.
1382-1389: Light mode transition logging is comprehensive and uses updated tag.All relay light mode transitions (TO/FROM Disabled) have been updated to use
TAG_HW_RELAYS. The static local variable pattern for trackingprevious_modeper relay is maintained and correct. Transition logic (turning off lights when entering Disabled, updating based on relay state when leaving Disabled) is preserved.Also applies to: 1437-1444, 1501-1508, 1542-1549, 1606-1613, 1647-1654, 1711-1755
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml (1)
358-358: Centralized device naming pattern is clean, but add defensive checks for initialization order.The
wifi.on_connecthandler at lines 366–382 correctly initializescached_device_nameby normalizingApp.get_name()(lowercase alphanumerics + underscores). The logic properly avoids consecutive underscores, which is good.However, the text_sensor at line 358 will return an empty string if accessed before WiFi connects. Consider:
- Adding a fallback or validation in the text_sensor lambda to warn if
cached_device_nameremains empty- Or adding a note in documentation about this runtime dependency
Example defensive check:
lambda: |- if (esphome::tx_ultimate_easy::cached_device_name.empty()) { return {"<uninitialized>"}; // Safe fallback } return {esphome::tx_ultimate_easy::cached_device_name};Also applies to: 366-382
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml(7 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml(3 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml(6 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yaml(12 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml(18 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml(7 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yaml(5 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml(7 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_media_player.yaml(5 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- ESPHome/TX-Ultimate-Easy-ESPHome_hw_audio.yaml
- ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml
- ESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yaml
🧰 Additional context used
🧠 Learnings (16)
📓 Common learnings
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 111
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:121-129
Timestamp: 2025-07-09T22:37:04.600Z
Learning: In ESPHome, to fire Home Assistant events from C++ lambda functions, the correct approach is to create a stack variable of type `esphome::api::CustomAPIDevice` and call `fire_homeassistant_event()` on it, not to use the API server component directly.
📚 Learning: 2025-08-11T22:06:11.073Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_media_player.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml
📚 Learning: 2025-08-10T21:47:55.413Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yamlESPHome/TX-Ultimate-Easy-ESPHome_media_player.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml
📚 Learning: 2024-12-26T21:18:44.593Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 73
File: ESPHome/TX-Ultimate-Easy-ESPHome_addon_media_player.yaml:14-20
Timestamp: 2024-12-26T21:18:44.593Z
Learning: In the TX Ultimate Easy ESPHome setup, the i2s_dout_pin for audio output is defined in respective speaker or media_player components rather than in the core_hw_audio package.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_media_player.yaml
📚 Learning: 2025-08-05T19:20:33.157Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:72-76
Timestamp: 2025-08-05T19:20:33.157Z
Learning: In the TX Ultimate Easy project, the `attr_light_output_1` global variable in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml is intentionally saved but not restored on boot because the restoration logic will be implemented in the hw_leds area in the near future. The `light_attributes_restore` script consumer is planned to be in the hw_relays area while the script itself remains in hw_leds as part of the ongoing storage optimization work.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml
📚 Learning: 2025-08-10T19:32:07.897Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:1326-1333
Timestamp: 2025-08-10T19:32:07.897Z
Learning: In the TX Ultimate Easy project's relay light modes in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml, "Disabled" mode intentionally decouples LED control from relay state changes, allowing users to control the LEDs independently via other means (e.g., Home Assistant). When transitioning TO "Disabled" mode at runtime, lights should turn off. When transitioning FROM "Disabled" to another mode, lights should update based on the current relay state. These transitions should only occur during runtime mode changes, not during boot/restore, to preserve user-defined light states.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2025-08-05T19:18:45.684Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:547-561
Timestamp: 2025-08-05T19:18:45.684Z
Learning: In the TX Ultimate Easy project's light_attributes_restore script in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml, the user intentionally chose to restore only brightness and RGB attributes without turning the light on. The design uses C++ lambdas instead of ESPHome YAML functions specifically to avoid automatically turning lights on during restoration, allowing users to manually control the on/off state while preserving visual settings.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml
📚 Learning: 2025-08-06T21:11:16.509Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:1356-1358
Timestamp: 2025-08-06T21:11:16.509Z
Learning: In the TX Ultimate Easy project's relay light mode selectors in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml, the fallback value for active_index().value_or(1) is intentionally set to 1, which corresponds to the first active light mode (Bottom for EU, Left for US) rather than 0 (Disabled). This ensures the default behavior maintains LED functionality rather than disabling lights on cold boot.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml
📚 Learning: 2025-08-06T20:53:35.572Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:558-576
Timestamp: 2025-08-06T20:53:35.572Z
Learning: In the TX Ultimate Easy project, brightness values are already clamped using std::min(attr.brightness, uint8_t(100)) in the pack_light_attributes() and unpack_light_attributes() functions in components/tx_ultimate_easy/tx_ultimate_easy_light.cpp. RGB values are naturally constrained by uint8_t casting and bit masking operations. No additional clamping is needed at the calling sites in the ESPHome YAML files.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2025-08-08T12:08:27.935Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:0-0
Timestamp: 2025-08-08T12:08:27.935Z
Learning: In TX Ultimate Easy, the default packed dual light attributes constant must be 0x64FFFFFF64FFFFFF (16 hex digits) across YAML substitutions (LIGHT_DUAL_ATTRS_DEFAULT) and C++ (DEFAULT_DUAL_LIGHT_ATTRS_PACKED). Avoid leading zeros that would push beyond 64 bits.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2024-12-22T00:26:54.059Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 50
File: components/tx_ultimate_easy/tx_ultimate_easy.cpp:54-59
Timestamp: 2024-12-22T00:26:54.059Z
Learning: The default value for gang_count_ in TxUltimateEasy is already initialized to 1 in the header file, removing the need for additional constructor initialization.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml
📚 Learning: 2025-07-29T08:10:32.072Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 112
File: .github/workflows/validate_esphome_dev.yml:52-210
Timestamp: 2025-07-29T08:10:32.072Z
Learning: Media player functionality is now supported by both Arduino and IDF frameworks in TX Ultimate Easy ESPHome configurations, removing the previous Arduino-only limitation.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yamlESPHome/TX-Ultimate-Easy-ESPHome_media_player.yaml
📚 Learning: 2025-07-09T22:37:04.600Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 111
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:121-129
Timestamp: 2025-07-09T22:37:04.600Z
Learning: In ESPHome, to fire Home Assistant events from C++ lambda functions, the correct approach is to create a stack variable of type `esphome::api::CustomAPIDevice` and call `fire_homeassistant_event()` on it, not to use the API server component directly.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml
📚 Learning: 2024-12-21T22:36:10.732Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 50
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_buttons.yaml:201-222
Timestamp: 2024-12-21T22:36:10.732Z
Learning: The user clarified that handling millisecond overflow for button press duration is unnecessary because the relevant logic only runs if current_time is strictly greater than the recorded start time.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml
📚 Learning: 2024-12-24T22:40:00.309Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 71
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_speaker.yaml:20-21
Timestamp: 2024-12-24T22:40:00.309Z
Learning: The BLE addon uses a unique speaker component named mp_speaker and removes the media_player component entirely, so no rename from mp_speaker to mp_media_player is required there.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_media_player.yaml
📚 Learning: 2024-12-19T22:29:32.736Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 31
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_vibration.yaml:82-88
Timestamp: 2024-12-19T22:29:32.736Z
Learning: Due to "restore_mode: ALWAYS_OFF" and a turn-off step on OTA, the vibration motor is automatically shut off in restart/OTA scenarios, making additional race-condition handling unnecessary.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ Arduino Core (dev)
🔇 Additional comments (12)
ESPHome/TX-Ultimate-Easy-ESPHome_hw_buttons.yaml (3)
223-232: Use ofcurrent_option()is correct for ESPHome select templates.The migration to
current_option()(lines 223–232) is the proper way to retrieve selected values in ESPHome. This is consistent with the pattern used across the codebase and aligns with the learnings from PR 120.
239-239: Build guard macro dependency must be satisfied.Line 239 checks
#if !defined(TX_ULTIMATE_EASY_COMMON), which now depends on the updated flag name from common.yaml. Ensure the guard check is defined in all code paths that include this file.
127-132: Critical issue found: firmware field is hardcoded as a string literal instead of using the macro value.In
tx_ultimate_easy_api.cpp, thefire_ha_event()function adds event enrichment fields correctly fordevice_name,domain, andtype. However, there's a critical bug on this line:data["firmware"] = "TX_ULTIMATE_EASY_FIRMWARE_VERSION";This passes the literal string
"TX_ULTIMATE_EASY_FIRMWARE_VERSION"instead of expanding the macro. It should be:data["firmware"] = TX_ULTIMATE_EASY_FIRMWARE_VERSION;Without the quotes, the preprocessor will substitute the actual firmware version (defined at the top of the header as
#define TX_ULTIMATE_EASY_FIRMWARE_VERSION "unknown"or a specific version). Currently, all fired events will reportfirmware="TX_ULTIMATE_EASY_FIRMWARE_VERSION"as a literal string instead of the actual version value.The original review comment was correct in identifying the need to verify event enrichment — device_name enrichment works as expected via the
cached_device_namevariable, but the firmware version is broken.⛔ Skipped due to learnings
Learnt from: edwardtfn Repo: edwardtfn/TX-Ultimate-Easy PR: 120 File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45 Timestamp: 2025-08-11T22:06:11.073Z Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.Learnt from: edwardtfn Repo: edwardtfn/TX-Ultimate-Easy PR: 111 File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:121-129 Timestamp: 2025-07-09T22:37:04.600Z Learning: In ESPHome, to fire Home Assistant events from C++ lambda functions, the correct approach is to create a stack variable of type `esphome::api::CustomAPIDevice` and call `fire_homeassistant_event()` on it, not to use the API server component directly.Learnt from: edwardtfn Repo: edwardtfn/TX-Ultimate-Easy PR: 120 File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119 Timestamp: 2025-08-10T21:47:55.413Z Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.Learnt from: edwardtfn Repo: edwardtfn/TX-Ultimate-Easy PR: 120 File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:72-76 Timestamp: 2025-08-05T19:20:33.157Z Learning: In the TX Ultimate Easy project, the `attr_light_output_1` global variable in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml is intentionally saved but not restored on boot because the restoration logic will be implemented in the hw_leds area in the near future. The `light_attributes_restore` script consumer is planned to be in the hw_relays area while the script itself remains in hw_leds as part of the ongoing storage optimization work.ESPHome/TX-Ultimate-Easy-ESPHome_hw_touch.yaml (2)
383-386: Swipe direction mapping logic is correct but verify initialization timing.The touch panel event handlers now use
fire_ha_event()instead of YAML homeassistant.event blocks. The swipe direction mapping (lines 410–417 and 423–429) correctly adapts based on model format:
- EU: horizontal swipes map to "left"/"right"
- US: horizontal swipes map to "down"/"up"
However, this depends on
sl_tx_model_format->current_option()being initialized. Verify that:
- Model format selection is guaranteed to be initialized before touch events fire (typically done in boot_initialize_touch_format at line 235)
- If called before initialization,
current_option()has a safe return value (not null/empty)Consider adding a safety check or assert if the model format is not yet available.
Also applies to: 410-417, 423-429
299-304: Guard macro and package reference consistency verified.The required package check at lines 299–304 correctly references
TX_ULTIMATE_EASY_COMMON, aligning with the common.yaml changes. The error message is clear.ESPHome/TX-Ultimate-Easy-ESPHome_hw_relays.yaml (2)
1013-1024: Extensive use of current_option() assumes selects are initialized — add safety checks where appropriate.Lines 1013–1024 and 1050–1064 extensively use
current_option()to retrieve relay mode and light mode settings. This is the correct ESPHome pattern, but it assumes the select entities have been initialized.Consider adding defensive checks in log statements if selects might not have state yet:
// Example defensive approach ESP_LOGCONFIG("${TAG_HW_RELAYS}", " Relay 1: %s", sl_relay_1_mode->has_state() ? sl_relay_1_mode->current_option() : "Unknown");(Note: This pattern is already present at some call sites, e.g., line 1013-1014, which is good.)
Current implementation already includes these checks in most places, which is solid defensive coding.
Also applies to: 1050-1064
1071-1076: TheTX_ULTIMATE_EASY_HW_LEDSbuild guard is already properly defined in the hw_leds component.The guard is defined at line 40 of
ESPHome/TX-Ultimate-Easy-ESPHome_hw_leds.yamlusing the correct ESPHome preprocessor syntax (- -D TX_ULTIMATE_EASY_HW_LEDS). The check at line 1074 in hw_relays.yaml will succeed as long as hw_leds is included first, which the earlier check at line 1071-1072 ensures.Likely an incorrect or invalid review comment.
ESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml (2)
98-98: String comparisons with strcmp() are correct — verify literals match select options exactly.The use of
strcmp()withcurrent_option()is a safe and appropriate pattern for string comparisons in ESPHome C++ lambdas. The logic correctly handles:
- Line 98: Skip if NOT "Disabled"
- Lines 110–111: Vibrate if "On press" OR "Always"
- Lines 123–124: Vibrate if "On release" OR "Always"
Verify that the string literals exactly match the select options (lines 140–143):
- "Disabled" ✓
- "On press" ✓
- "On release" ✓
- "Always" ✓
All string literals match. The implementation is correct and follows ESPHome best practices.
Also applies to: 110-111, 123-124
83-85: Guard macro dependency satisfied.Line 83–85 checks
TX_ULTIMATE_EASY_COMMON, which aligns with the updates to common.yaml. This is consistent across the codebase.ESPHome/TX-Ultimate-Easy-ESPHome_media_player.yaml (1)
15-15: Package reference rename is correctly implemented—no verification issues found.The package file
TX-Ultimate-Easy-ESPHome_hw_speaker.yamlexists and is properly referenced. Build guardsTX_ULTIMATE_EASY_HW_SPEAKERandTX_ULTIMATE_EASY_COMMONare correctly defined in their respective package files with-Dcompiler flags. Old references tostandard_hw_speakerremain only in comments and documentation (safe). The include statement and error message at line 18 both use the correct new filename.ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml (2)
36-36: Verifyhomeassistant_services: trueenables fire_ha_event API correctly.Verified. The
fire_ha_event()implementation correctly usesesphome::api::CustomAPIDeviceto fire Home Assistant events through the ESPHome API server. Withhomeassistant_services: trueenabled at line 36, the API server component is active and all event calls from buttons, touch, and relay components properly integrate. Event structure adds device metadata (device_name, firmware, domain, type) to user-provided data before firing as "esphome.tx_ultimate_easy" event.
32-32: Based on my verification, I can now provide the rewritten review comment.
Build flag migration is complete; timing behavior is intentional and safe.
The build flag change from
TX_ULTIMATE_EASY_CORE_COMMONtoTX_ULTIMATE_EASY_COMMONhas been properly applied across all dependent files. No orphaned references remain, and all files use the new flag consistently with#if !defined(TX_ULTIMATE_EASY_COMMON)guards.Regarding the text_sensor timing: The implementation uses lazy initialization with an idempotent guard (
if (cached_device_name.empty())). The sensor will return an empty string only before WiFi connects, after which it's populated onwifi.on_connectand the update_interval is set tonever. This is a safe, intentional pattern for a diagnostic entity and requires no changes.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml (1)
142-149: Verify the integration ofinit_device_name_cache()and ensurecached_device_nameis initialized before the firstfire_ha_event()call.The
fire_ha_event()function andcached_device_namevariable are properly declared and implemented in the component (lines 74-75 and 18 oftx_ultimate_easy_api.h), and the implementation correctly usesesphome::api::CustomAPIDeviceto fire Home Assistant events.However, there is a critical timing issue:
cached_device_nameis initialized in the WiFion_connecthandler (lines 355-367), which executes after the boot sequence. Theapi_send_ha_event_boot("start")script is called duringon_bootat priority 700 (line 173), before WiFi connects and beforecached_device_nameis populated. This means the first boot event will be sent with an emptydevice_namefield.Recommendation: Initialize
cached_device_namefromApp.get_name()during theon_bootsequence (e.g., inboot_initializeat priority 700) rather than deferring it towifi.on_connect. This ensures the device name is available for all boot events.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
.test/esphome_ard_hw_relays.yaml(1 hunks).test/esphome_ard_hw_speaker.yaml(1 hunks).test/esphome_ard_hw_vibration.yaml(1 hunks).test/esphome_idf_hw_relays.yaml(1 hunks).test/esphome_idf_hw_speaker.yaml(1 hunks).test/esphome_idf_hw_vibration.yaml(1 hunks)ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml(8 hunks)
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 111
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:121-129
Timestamp: 2025-07-09T22:37:04.600Z
Learning: In ESPHome, to fire Home Assistant events from C++ lambda functions, the correct approach is to create a stack variable of type `esphome::api::CustomAPIDevice` and call `fire_homeassistant_event()` on it, not to use the API server component directly.
📚 Learning: 2025-08-10T21:47:55.413Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
Applied to files:
.test/esphome_idf_hw_vibration.yaml.test/esphome_ard_hw_relays.yaml.test/esphome_idf_hw_relays.yaml.test/esphome_ard_hw_vibration.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-08-11T22:06:11.073Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Applied to files:
.test/esphome_ard_hw_relays.yaml.test/esphome_idf_hw_relays.yaml.test/esphome_ard_hw_speaker.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2024-12-26T21:18:44.593Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 73
File: ESPHome/TX-Ultimate-Easy-ESPHome_addon_media_player.yaml:14-20
Timestamp: 2024-12-26T21:18:44.593Z
Learning: In the TX Ultimate Easy ESPHome setup, the i2s_dout_pin for audio output is defined in respective speaker or media_player components rather than in the core_hw_audio package.
Applied to files:
.test/esphome_ard_hw_relays.yaml.test/esphome_idf_hw_relays.yaml.test/esphome_ard_hw_vibration.yaml.test/esphome_idf_hw_speaker.yaml.test/esphome_ard_hw_speaker.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-08-05T19:20:33.157Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:72-76
Timestamp: 2025-08-05T19:20:33.157Z
Learning: In the TX Ultimate Easy project, the `attr_light_output_1` global variable in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml is intentionally saved but not restored on boot because the restoration logic will be implemented in the hw_leds area in the near future. The `light_attributes_restore` script consumer is planned to be in the hw_relays area while the script itself remains in hw_leds as part of the ongoing storage optimization work.
Applied to files:
.test/esphome_ard_hw_relays.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2024-12-24T22:40:00.309Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 71
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_speaker.yaml:20-21
Timestamp: 2024-12-24T22:40:00.309Z
Learning: The BLE addon uses a unique speaker component named mp_speaker and removes the media_player component entirely, so no rename from mp_speaker to mp_media_player is required there.
Applied to files:
.test/esphome_idf_hw_speaker.yaml.test/esphome_ard_hw_speaker.yaml
📚 Learning: 2025-07-29T08:10:32.072Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 112
File: .github/workflows/validate_esphome_dev.yml:52-210
Timestamp: 2025-07-29T08:10:32.072Z
Learning: Media player functionality is now supported by both Arduino and IDF frameworks in TX Ultimate Easy ESPHome configurations, removing the previous Arduino-only limitation.
Applied to files:
.test/esphome_ard_hw_speaker.yamlESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-08-05T19:18:45.684Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:547-561
Timestamp: 2025-08-05T19:18:45.684Z
Learning: In the TX Ultimate Easy project's light_attributes_restore script in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml, the user intentionally chose to restore only brightness and RGB attributes without turning the light on. The design uses C++ lambdas instead of ESPHome YAML functions specifically to avoid automatically turning lights on during restoration, allowing users to manually control the on/off state while preserving visual settings.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-08-06T21:11:16.509Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:1356-1358
Timestamp: 2025-08-06T21:11:16.509Z
Learning: In the TX Ultimate Easy project's relay light mode selectors in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml, the fallback value for active_index().value_or(1) is intentionally set to 1, which corresponds to the first active light mode (Bottom for EU, Left for US) rather than 0 (Disabled). This ensures the default behavior maintains LED functionality rather than disabling lights on cold boot.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-07-09T22:37:04.600Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 111
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:121-129
Timestamp: 2025-07-09T22:37:04.600Z
Learning: In ESPHome, to fire Home Assistant events from C++ lambda functions, the correct approach is to create a stack variable of type `esphome::api::CustomAPIDevice` and call `fire_homeassistant_event()` on it, not to use the API server component directly.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
🔇 Additional comments (7)
.test/esphome_idf_hw_relays.yaml (1)
5-5: Test file aligned with package rename.This mirrors the corresponding change in
.test/esphome_ard_hw_relays.yamland maintains consistency across test variants (Arduino and IDF).Verification of the include file path can be confirmed by the script from the Arduino test file review.
.test/esphome_ard_hw_relays.yaml (1)
5-5: File rename verified—the new include path resolves correctly.The renamed file
TX-Ultimate-Easy-ESPHome_hw_relays.yamlexists atESPHome/and is consistently referenced in both.test/esphome_ard_hw_relays.yamland.test/esphome_idf_hw_relays.yaml. No orphaned references to the oldstandard_hw_relaysnaming remain in the test files..test/esphome_ard_hw_speaker.yaml (1)
5-5: Refactoring successfully completed; no issues found.The renamed include file exists at
ESPHome/TX-Ultimate-Easy-ESPHome_hw_speaker.yaml, there are no orphaned references to the oldstandard_hw_speaker_packagekey, and the only mention of the old file path is in a comment withinTX-Ultimate-Easy-ESPHome_advanced.yaml(harmless). The new package is correctly referenced in related configuration files..test/esphome_idf_hw_vibration.yaml (1)
5-5: Target YAML file confirmed to exist.The included file
TX-Ultimate-Easy-ESPHome_hw_vibration.yamlexists atESPHome/TX-Ultimate-Easy-ESPHome_hw_vibration.yaml. The include path is correctly configured and will resolve properly from the.test/directory.ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml (3)
201-201: The extern declaration is properly in place and correctly scoped.The verification confirms that
esphome::tx_ultimate_easy::cached_device_nameis:
- Declared as
extern std::stringin the public header (components/tx_ultimate_easy/tx_ultimate_easy_api.h)- Defined and initialized in the implementation file (
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp)- Properly scoped within the
esphome::tx_ultimate_easynamespace- Used correctly in the component's event firing logic
No issues found. The variable is accessible from the YAML custom component code and follows proper C++ extern patterns.
34-36:homeassistant_services: trueis the correct flag to enable HA event emission.Per ESPHome's official API documentation, this flag under the
api:section correctly enables Home Assistant event/service support for C++ functions likefire_homeassistant_event()andcall_homeassistant_service(). The flag defaults to false but is the only configuration required when using these functions (it is automatically enabled if using built-in homeassistant.service/homeassistant.event actions).
81-81: The min_version requirement for ESPHome 2025.11.0 is justified and necessary.The project includes custom C++ components that define automation triggers (
tx_ultimate_easy_touchwith 7 customTrigger<TouchPoint>instances) and Home Assistant event firing (tx_ultimate_easy_api). ESPHome 2025.11.0 (released November 19, 2025) introduced breaking changes to the trigger/action/condition framework and automation APIs. The custom triggers exposed via YAML automation (on_touch_event,on_press,on_release,on_swipe_left,on_swipe_right,on_multi_touch_release,on_long_touch_release) require compatibility with the updated automation framework. Additionally, thehomeassistant_services: truesetting and event firing rely on 2025.11.0's improved event processing. This version bump aligns with the feature requirements of the custom component architecture.
To optimize memory
To avoid crashing on boot
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
components/tx_ultimate_easy/tx_ultimate_easy_api.h (1)
1-1: Update the file comment to reflect actual purpose.The comment states "Generic flag system" but this file provides the public API for Home Assistant event handling and device name caching.
-// tx_ultimate_easy_api.h - Generic flag system for TX Ultimate Easy +// tx_ultimate_easy_api.h - Public API for TX Ultimate Easy componentcomponents/tx_ultimate_easy/tx_ultimate_easy_api.cpp (1)
17-30: Consider trimming trailing underscores.If the raw device name ends with non-alphanumeric characters (e.g., "TX-Ultimate-Easy!"), the result will have a trailing underscore ("tx_ultimate_easy_"). While not critical, this could be cleaned up.
Apply this diff to trim trailing underscores:
} } + // Remove trailing underscore if present + if (!cached_device_name.empty() && cached_device_name.back() == '_') { + cached_device_name.pop_back(); + } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml(12 hunks)components/tx_ultimate_easy/tx_ultimate_easy_api.cpp(1 hunks)components/tx_ultimate_easy/tx_ultimate_easy_api.h(1 hunks)
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 111
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:121-129
Timestamp: 2025-07-09T22:37:04.600Z
Learning: In ESPHome, to fire Home Assistant events from C++ lambda functions, the correct approach is to create a stack variable of type `esphome::api::CustomAPIDevice` and call `fire_homeassistant_event()` on it, not to use the API server component directly.
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
📚 Learning: 2025-08-11T22:06:11.073Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Applied to files:
components/tx_ultimate_easy/tx_ultimate_easy_api.hcomponents/tx_ultimate_easy/tx_ultimate_easy_api.cppESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-08-10T21:47:55.413Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
Applied to files:
components/tx_ultimate_easy/tx_ultimate_easy_api.hcomponents/tx_ultimate_easy/tx_ultimate_easy_api.cppESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-07-09T22:37:04.600Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 111
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:121-129
Timestamp: 2025-07-09T22:37:04.600Z
Learning: In ESPHome, to fire Home Assistant events from C++ lambda functions, the correct approach is to create a stack variable of type `esphome::api::CustomAPIDevice` and call `fire_homeassistant_event()` on it, not to use the API server component directly.
Applied to files:
components/tx_ultimate_easy/tx_ultimate_easy_api.hcomponents/tx_ultimate_easy/tx_ultimate_easy_api.cppESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2024-12-23T03:35:56.090Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 56
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_touch.yaml:18-147
Timestamp: 2024-12-23T03:35:56.090Z
Learning: The user clarified that the proposed YAML anchor refactoring approach will not work with ESPHome, and they intend to maintain the current implementation despite code duplication.
Applied to files:
components/tx_ultimate_easy/tx_ultimate_easy_api.cppESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-08-05T19:20:33.157Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:72-76
Timestamp: 2025-08-05T19:20:33.157Z
Learning: In the TX Ultimate Easy project, the `attr_light_output_1` global variable in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml is intentionally saved but not restored on boot because the restoration logic will be implemented in the hw_leds area in the near future. The `light_attributes_restore` script consumer is planned to be in the hw_relays area while the script itself remains in hw_leds as part of the ongoing storage optimization work.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-08-05T19:18:45.684Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:547-561
Timestamp: 2025-08-05T19:18:45.684Z
Learning: In the TX Ultimate Easy project's light_attributes_restore script in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml, the user intentionally chose to restore only brightness and RGB attributes without turning the light on. The design uses C++ lambdas instead of ESPHome YAML functions specifically to avoid automatically turning lights on during restoration, allowing users to manually control the on/off state while preserving visual settings.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-07-29T08:10:32.072Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 112
File: .github/workflows/validate_esphome_dev.yml:52-210
Timestamp: 2025-07-29T08:10:32.072Z
Learning: Media player functionality is now supported by both Arduino and IDF frameworks in TX Ultimate Easy ESPHome configurations, removing the previous Arduino-only limitation.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2024-12-26T21:18:44.593Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 73
File: ESPHome/TX-Ultimate-Easy-ESPHome_addon_media_player.yaml:14-20
Timestamp: 2024-12-26T21:18:44.593Z
Learning: In the TX Ultimate Easy ESPHome setup, the i2s_dout_pin for audio output is defined in respective speaker or media_player components rather than in the core_hw_audio package.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
📚 Learning: 2025-08-06T21:11:16.509Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml:1356-1358
Timestamp: 2025-08-06T21:11:16.509Z
Learning: In the TX Ultimate Easy project's relay light mode selectors in ESPHome/TX-Ultimate-Easy-ESPHome_standard_hw_relays.yaml, the fallback value for active_index().value_or(1) is intentionally set to 1, which corresponds to the first active light mode (Bottom for EU, Left for US) rather than 0 (Disabled). This ensures the default behavior maintains LED functionality rather than disabling lights on cold boot.
Applied to files:
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml
🧬 Code graph analysis (1)
components/tx_ultimate_easy/tx_ultimate_easy_api.h (1)
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp (4)
initialize_cached_device_name(17-30)initialize_cached_device_name(17-17)fire_ha_event(33-55)fire_ha_event(33-33)
🪛 Cppcheck (2.18.0)
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp
[information] 4-4: Include file
(missingInclude)
[information] 5-5: Include file
(missingInclude)
[information] 6-6: Include file
(missingInclude)
[information] 7-7: Include file
(missingInclude)
[information] 8-8: Include file
(missingIncludeSystem)
[information] 9-9: Include file
(missingIncludeSystem)
[information] 10-10: Include file
(missingIncludeSystem)
[information] 3-3: Include file
(missingInclude)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ Arduino Core (latest)
🔇 Additional comments (16)
components/tx_ultimate_easy/tx_ultimate_easy_api.h (3)
16-39: LGTM!The cached device name approach and initialization function are well-documented and correctly declared.
41-71: LGTM!The watchdog utility function is well-implemented with clear documentation about its blocking behavior and appropriate usage patterns.
73-92: LGTM!The event firing API is well-designed. Taking the data map by value allows the function to inject core fields without modifying the caller's map, which is the correct approach.
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp (2)
5-7: LGTM! The stringification fix is correctly applied.The STRINGIFY macros correctly handle the firmware version macro, converting numeric versions like "9999.99.9" to string literals at compile time. This resolves the previous compilation error.
Based on learnings and past review resolution.
32-55: LGTM!The event firing implementation correctly uses the
CustomAPIDevicepattern and properly stringifies the firmware version. The structured logging with conditional verbosity is well-implemented.Based on learnings: ESPHome event firing pattern is correct.
ESPHome/TX-Ultimate-Easy-ESPHome_common.yaml (11)
76-79: Verify ESP32 advanced framework settings are compatible.The changes introduce
loop_task_stack_size: 16384andsdkconfig_optionswithin the advanced section. Confirm these settings are supported in ESPHome 2025.11.0 and don't conflict with esp-idf framework configuration.
91-92: Confirm TX_ULTIMATE_EASY_FIRMWARE_VERSION build flag is used in C++.The new build flag
TX_ULTIMATE_EASY_FIRMWARE_VERSION="${version}"is defined but not directly used in this YAML file. Verify it's consumed by the C++ component (likely in preprocessor conditionals or logging macros).
185-189: Good use of current_option() instead of indexed access.The change from accessing via index to
current_option()is correct for template select components and improves clarity. The logic for detecting US model format is sound.
282-290: Device name initialization via single-mode script is sound.The
update_device_namescript usesmode: single, ensuring the initialization runs only once even if WiFi connects/reconnects. The dependency oninitialize_cached_device_name()being idempotent (checksempty()) is appropriate. This follows the previous review feedback to move sanitization logic to C++.
359-368: WiFi on_connect flow for device name and version initialization looks correct.The on_connect handler publishes the firmware version and executes the single-mode update_device_name script. Since update_device_name guards against re-execution with the
empty()check, this flow is safe even across WiFi reconnects.Verify that the script execution order (publish tx_fw_version before update_device_name) does not cause any race conditions when WiFi reconnects occur in rapid succession.
14-32: TAG substitution rename is consistently applied.All references from TAG_CORE_COMMON to TAG_COMMON are present throughout logging statements. The substitution definition on line 32 is clear.
203-241: Logging now correctly uses cached_device_name and updated TAG.The dump_config script now logs
cached_device_namevia the C++ cache (line 206) instead of deriving it from YAML. All logging uses the updated TAG_COMMON substitution. This is an improvement over the previous approach.
282-290: The C++ component properly exports bothcached_device_nameandinitialize_cached_device_name(). The global is declared asextern std::string cached_device_namein the header and defined in the implementation. The function is properly declared and implemented with initialization guards. No changes needed.
36-36: Remove the verification request—homeassistant_services: trueis supported in ESPHome 2025.11.0.The
homeassistant_servicesoption is a valid boolean setting under theapi:configuration in ESPHome 2025.11.0 and is properly configured in your example. It defaults tofalseand is automatically enabled when usinghomeassistant.serviceorhomeassistant.eventactions, but can be set manually to explicitly compile Home Assistant service-call support.
153-153: No action required. Thefire_ha_event()function is properly implemented in the tx_ultimate_easy component with the correct signature and is correctly called from the YAML lambda. The function exists atcomponents/tx_ultimate_easy/tx_ultimate_easy_api.cpp:33-55with signaturevoid fire_ha_event(const std::string &domain, const std::string &type, std::map<std::string, std::string> data = {}), and it correctly usesesphome::api::CustomAPIDeviceto fire Home Assistant events, following the ESPHome best practice pattern.
85-85: All features are properly supported and implemented.Verification confirms:
homeassistant_services: trueis supported in ESPHome 2025.11.0 (available since 2025.8.0)fire_ha_event()function is properly exported with correct signature matching the YAML usageinitialize_cached_device_name()is implemented with documented behaviorcached_device_nameis declared as a module-level global string- ESP32 advanced settings (
loop_task_stack_size,sdkconfig_options) are standard ESPHome featuresTX_ULTIMATE_EASY_FIRMWARE_VERSIONbuild flag is correctly used in the componentThe min_version bump to 2025.11.0 is justified and all APIs are compatible with this version.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp(1 hunks)
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
📚 Learning: 2025-07-09T22:37:04.600Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 111
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:121-129
Timestamp: 2025-07-09T22:37:04.600Z
Learning: In ESPHome, to fire Home Assistant events from C++ lambda functions, the correct approach is to create a stack variable of type `esphome::api::CustomAPIDevice` and call `fire_homeassistant_event()` on it, not to use the API server component directly.
Applied to files:
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp
📚 Learning: 2025-08-11T22:06:11.073Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml:42-45
Timestamp: 2025-08-11T22:06:11.073Z
Learning: In the TX Ultimate Easy project, temporary external component references to unmerged PRs (like `github://pr#10195`) are intentionally used during development in ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml and will be updated or removed before release.
Applied to files:
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp
📚 Learning: 2025-08-10T21:47:55.413Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 120
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_common.yaml:112-119
Timestamp: 2025-08-10T21:47:55.413Z
Learning: In the TX Ultimate Easy project, when using ESPHome external components with `ref: v${version}`, the version comes directly from VERSION_YAML without any prefix. Development versions (like 2025.8.2dev) won't have corresponding tags until release, but ESPHome handles this gracefully during development builds.
Applied to files:
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp
📚 Learning: 2024-12-23T03:35:56.090Z
Learnt from: edwardtfn
Repo: edwardtfn/TX-Ultimate-Easy PR: 56
File: ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_touch.yaml:18-147
Timestamp: 2024-12-23T03:35:56.090Z
Learning: The user clarified that the proposed YAML anchor refactoring approach will not work with ESPHome, and they intend to maintain the current implementation despite code duplication.
Applied to files:
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp
🪛 Cppcheck (2.18.0)
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp
[information] 4-4: Include file
(missingInclude)
[information] 5-5: Include file
(missingInclude)
[information] 6-6: Include file
(missingInclude)
[information] 7-7: Include file
(missingInclude)
[information] 8-8: Include file
(missingIncludeSystem)
[information] 9-9: Include file
(missingIncludeSystem)
[information] 10-10: Include file
(missingIncludeSystem)
[information] 3-3: Include file
(missingInclude)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ Arduino Core (dev)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ IDF Core (latest)
- GitHub Check: 🏗️ IDF Core (dev)
- GitHub Check: 🏗️ Arduino Core (latest)
- GitHub Check: 🏗️ Arduino Core (dev)
🔇 Additional comments (2)
components/tx_ultimate_easy/tx_ultimate_easy_api.cpp (2)
5-7: STRINGIFY macros correctly implemented.The two-level macro expansion pattern properly converts the firmware version to a string literal at compile time, handling versions with dots correctly.
51-52: Correct ESPHome event firing pattern.The implementation correctly uses a stack-allocated
CustomAPIDeviceto fire Home Assistant events, which aligns with ESPHome best practices.Based on learnings, this is the correct approach for firing HA events from C++.
1 participant
Summary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.