Update athom-smart-plug-v2.yaml

[loryanstrant]

Added ${friendly_name} to:

• Restart with Factory Defaults
• Safe Mode
• Connected SSID
• IP Address
• Mac Address

As these all have generic names in Home Assistant due to the lack of prefix, so end up with Entity IDs of sensor.ip_address, sensor.ip_address2, sensor.ip_address3, sensor.ip_address4, etc.

Also changed "Mac" to "MAC" (as it is an acronym, so should be in capitals).

[Roving-Ronin]

Since an update to HA later in 2022, the entity name is automatically prefixed by the friendly name.
i.e.
ssid:
name: 'WiFi SSID'
icon: mdi:wifi-strength-2
entity_category: diagnostic

Will automatically see the creation of an entity named: sensor.<friendly_name>_wifi_ssid. Example below for the athom v2 plugs I run

Additionally in the esp webserver page the line for this will be 'WiFi SSID', avoiding repeatative and screen space wasting repeating of <friendly_name> upon each line/sensor entry. i.e. <friendly_name> WiFi SSID' / <friendly_name> IP Address etc.
Example below of

See here for example of base config: https://github.com/Roving-Ronin/Home-Assistant/blob/main/esphome/gpo-dishwasher.yaml that then also calls the common settings used across multiple devices, with config here: https://github.com/Roving-Ronin/Home-Assistant/blob/main/esphome/common/common_athom_plug_v2.yaml

[loryanstrant]

Sorry, but that's not my experience.

Here is a brand new plug using the existing athom_plug_v2.yaml configuration:

I've used my own configuration to date to avoid this, but thought I'd do a PR to correct it at the source.
Here's an example of my config where I have put the friendly name in the missing places, and a device where I have used the baseline imported config from this repo:

I don't disagree with you about having the additional display name properties wasting space, so an alternative approach would be to use ID's in the config and allow us to put it in the substitutions.

[Roving-Ronin]

@loryanstrant I never referred to using the current athom 'public' yaml file, since later last year it has been rather useless, as it hasn't kept up with the introduction of friendly_name as a variable in HA (athom used this as their own unofficial variable prior to then, and people appear to be unwilling to differentiate between unofficial that now clashes with official, and update the yaml).

Suggest you refer to the 2 yaml config files that I linked to that shows how the 'friendly_name' official variable is supposed to be used, and how it can hence be incorporated into athom v2 plug yaml. These are simply of modification of the existing v1.1 athom yaml to bring it in line with HA 2022.10 (?) changes.

See here for example of base config: https://github.com/Roving-Ronin/Home-Assistant/blob/main/esphome/gpo-dishwasher.yaml that then also calls the common settings used across multiple devices, with config here: https://github.com/Roving-Ronin/Home-Assistant/blob/main/esphome/common/common_athom_plug_v2.yaml

For a bonus it also gives a more usable device uptime in days/hr/min/sec instead of xx,xxx seconds. ;-)

[loryanstrant]

Thanks for the suggestion and clarification.
And yes, the base config isn't ideal - which is why I also use my own (also with common settings across them), but last night I thought I'd do the community thing and try to improve it for others. :-)

[Roving-Ronin]

@loryanstrant worth a quick glance at #25 where it was previously attempted to update/improve it for all ;-)

[rossens]

Sorry off topic, does anyone here know if it's possible (safe) to change smart plug v2 update_rate from 10sec to something much faster, say 1sec?

athom-configs/athom-smart-plug-v2.yaml

Line 80 in 69a809c

update_interval: 10s

Also, is there a better/recommended place to ask such a question?

[felipecrs]

Sorry off topic, does anyone here know if it's possible (safe) to change smart plug v2 update_rate from 10sec to something much faster, say 1sec?

athom-configs/athom-smart-plug-v2.yaml

Line 80 in 69a809c

update_interval: 10s

Also, is there a better/recommended place to ask such a question?

If you want to react as fast as possible within the device itself, use on_raw_value. But yes, you can shorten update interval to 1s with no issue.