Remove redundant friendly name occurances #652
Conversation
ESPHome now adds the friendly name to the start of the names provided in components, causing for example names like `Electricity Meter Electricity Meter - Total Energy Cost`.
ESPHome now names the ap with the defined friendly name by default.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
📝 WalkthroughWalkthroughThe pull request introduces modifications to various YAML configuration files, primarily focusing on simplifying naming conventions by removing the Changes
Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
components/basis.yaml (2)
Line range hint
13-13: Maintain consistent naming pattern across sensorsWhile you've removed the
${friendly_name}from several sensors, there's an inconsistency with the "Installed version" sensor still having the "Glow - " prefix. Consider updating it as well for consistency.- name: "Glow - Installed version" + name: "Installed version"Also applies to: 21-21, 25-25, 28-28
Line range hint
34-34: Remove redundant ${friendly_name} from WiFi Signal sensorSince ESPHome 2023.2+ automatically prepends the friendly_name, this will result in duplicate naming (e.g., "Electricity Meter Electricity Meter - WiFi Signal"). Consider removing the ${friendly_name} prefix.
- name: "${friendly_name} - WiFi Signal" + name: "WiFi Signal"components/pulse_meter.yaml (1)
93-94: Enhance filter documentation for clarityConsider expanding the comment to be more descriptive about the purpose of the multiplication factor.
- # Multiplication factor from W to kW is 0.001 + # Convert from Wh to kWh by multiplying by 0.001 (1 kWh = 1000 Wh)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
components/basis.yaml(2 hunks)components/pulse_meter.yaml(4 hunks)home-assistant-glow/esp32.yaml(1 hunks)home-assistant-glow/esp8266.yaml(1 hunks)
🔇 Additional comments (7)
components/basis.yaml (1)
41-41: LGTM: Valid addition of required time platform ID
The addition of the time platform ID is correct and well-documented by the comment above explaining its purpose for midnight energy resets.
home-assistant-glow/esp8266.yaml (2)
53-53: LGTM! Change aligns with PR objectives.
The removal of explicit SSID configuration helps eliminate redundant friendly name occurrence. The empty AP configuration is safe as ESPHome provides default AP behavior, and both captive portal and improv_serial are enabled for WiFi provisioning.
Let's verify if this change affects any existing documentation or examples:
#!/bin/bash
# Description: Check for any documentation or examples that might reference the old AP SSID configuration
# Expected: No references to the old configuration that need updating
# Search for AP SSID references in documentation
rg -l "friendly_name.*ssid|ssid.*friendly_name" --type md
# Search for AP configuration examples
rg -l "ap:\s*\n\s+ssid:" --type yamlLine range hint 19-19: Verify ESPHome version requirement.
The minimum version is set to 2024.6.0 which seems unusually high. This might prevent users from using the configuration if this version is not yet released.
Let's verify the latest ESPHome version:
home-assistant-glow/esp32.yaml (1)
55-55: Verify the impact of empty AP configuration
While removing the ${friendly_name} from the AP configuration aligns with the PR's goal of eliminating redundant names, we should consider:
- Security: An empty AP configuration might result in a default or predictable SSID, making it harder to identify the correct device during setup.
- User Experience: Without a descriptive SSID, users might struggle to identify the correct device during the initial configuration.
Let's verify the ESPHome documentation and common patterns for AP configuration:
Consider using a static, descriptive SSID instead of an empty configuration:
- ap: {}
+ ap:
+ ssid: "HAGlow-Setup" # Static, non-redundant name✅ Verification successful
Empty AP configuration is acceptable for ESPHome
The git history shows that the previous configuration used ${friendly_name} as the SSID, which aligns perfectly with the PR's objective to remove redundant friendly names. The empty AP configuration (ap: {}) is actually the recommended approach in ESPHome as it:
- Automatically generates a unique SSID based on the device name
- Maintains security by using a random password
- Still enables the captive portal for easy WiFi provisioning
The comments in both ESP32 and ESP8266 configurations confirm this is used for WiFi provisioning, and the empty configuration is consistently applied across both files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for AP configuration patterns in the repository and ESPHome examples
# Check for other AP configurations in the repository
echo "Searching for AP configurations in YAML files..."
rg -A 3 "^\s*ap:" --type yaml
# Check for any documentation files that might provide guidance
echo "Searching for documentation about AP configuration..."
fd -e md -e rst | xargs rg -l "wifi.*ap|access.?point"
Length of output: 813
Script:
#!/bin/bash
# Let's check the git history to understand the previous AP configuration
git log -p -- 'home-assistant-glow/esp32.yaml' | grep -A 5 "^+.*ap:"
# Also check if there are any related configuration examples or documentation
rg -B 2 -A 2 "wifi.*setup.*mode|fallback.*ap" --type yaml
Length of output: 474
components/pulse_meter.yaml (3)
50-50: LGTM! Name simplification aligns with ESPHome 2023.2 changes
The removal of ${friendly_name} from the sensor name is appropriate since ESPHome 2023.2 now automatically prepends the friendly name.
71-71: LGTM! Consistent naming approach for total energy sensor
The simplified name maintains clarity while avoiding duplication with ESPHome's automatic friendly name prepending.
85-85: LGTM! Daily energy sensor name simplified appropriately
The removal of ${friendly_name} maintains consistency with other sensor name changes.
JamesSwift
changed the title
|
Just a note, I haven't updated which branch the |
|
The CI swapped the ref during test builds and left it intact during release deployments. I'll take a closer look at your PR later and what label would fit best, breaking change if it affects the entity_id for example. ./Klaas |
|
I tested this with a few entities, but this also changes the entity id (breaking change) and I'm not sure yet whether I think that's a good change 🤔 ./Klaas |
|
Understandable. However, surely on any device that upgraded from before 2023.2 to newer they would have experienced an id change as a result of this unintended new behaviour. This change restores the intended behaviour. It's up to you though. |
|
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions. |
github-actions
bot
added
the
stale
Since 2023.2 ESPHome now prepends the
friendly_namespecified inesphome:to the name of any sensors or components. This has resulted in the names of the sensors being doubled up as inElectricty Meter Electricty Meter - WiFi Signal.This pull request removed the redundant friendly names to solve this issue.
Summary by CodeRabbit
New Features
Bug Fixes
Documentation