Athom - Smart Plug v2 - Development

[Roving-Ronin]

Probably a good idea that we create a chat/thread where any proposed changes to the athom-smart-plug-v2.yaml can be raised and debated

[dexn]

I just realised discussions opened after I replied to the pull request.
#43

Would still query as above, re changing WiFi to Db that means nothing for most users, versus a % system that everyone can understand. Doing this as one person claims it doesn't work, when it in fact does work fine in HA (in use over a year) as demonstrated above.

@Roving-Ronin Sorry. It does seem to work now. For some unknown reason last month, my HA was saying it was an incorrect unit of measurement for wifi signal. I've updated since and that issue is resolved, so I don't know where my issue was caused.

In Australia also its a 20A circuit for GPO's, with up to 10 outlets upon that circuit, not 10A max.

Also with our Australian power, we have 20A circuits but 10A sockets.

[dexn]

@Roving-Ronin @tarontop
My mistake, the wifi error is still there. I was looking in the wrong place.

[Roving-Ronin]

@dexn Hmm OK I am getting those in the logs also. Bit of a cosmetic though, logs but no throwing errors / breaking stuff though.

@tarontop Aiden, is it worth aligning the v2 plug config with the ESP32 plug config, as I note the 8266 version still has 'preferences: flash_write_interval: 1min' whilst the ESP32 has '5min'. IMHO changing the v2 config also to 5min would be a good option. I've personally been running my v2's on 5min for over a year and no issues / data lost. Running at 5min instead of 1min would also reduce the wear on the flash_memory prolonging the lifespan of these plugs.

[tarontop]

good suggestion, it has been changed

[Roving-Ronin]

@tarontop Hi Aiden, Do you want to add the sensors, so users can easily see/check the project version they are running and if they need/want to update when a newer version is released?

If so the code to add would be:

text_sensor:

  #  Creates a sensor of the name of installed project
  - platform: template
    name: 'Project Name'
    id: gas_meter_project
    icon: "mdi:label-outline"
    entity_category: diagnostic
    lambda: |-
      return {"${project_name}"};
    update_interval: 6h

  #  Creates a sensor of the version of installed project
  - platform: template
    name: 'Project Version'
    id: gas_meter_version
    icon: "mdi:label-outline"
    entity_category: diagnostic
    lambda: |-
      return {"${project_version}"};
    update_interval: 6h

Appearing like this (ignore the version numbers below, this is showing my 'customised' version I run):

[dexn]

@Roving-Ronin Maybe have 'disabled_by_default' on also so it's not shown in HA again.

[tarontop]

Add optional power restore mode
#46

[raidnet-ms]

@Roving-Ronin that would be great if only remote package would allow the compilation of included files.

Unfortunately that only works if you already have those include files in local. They will not be updated from the remote package.

I also had a chat with @jesserockz about this issue and he provided me with a workaround: you should set each include as a remote package.
In my opinion this cause the decluttering useless if you are using it properly because your yaml will get bigger and the logic behind nesting folders get lost. Decluttering really help the community to understand and simplify the knowledge of the package content (IMHO).

With this June esphome version, hardware manufacturer will be allowed to provide the bin file for update.

Unfortunately in my opinion this does not match with the community expectations and your example perfectly does match the case.

[Roving-Ronin]

@raidnet-ms Sorry I'm not following what your saying. Are you saying that the additional include! for packages (such as for load baseline sensors, then another for loading ces7766 sensors requires these extra packages) to be pulled from the local /esphome folders ?

[Roving-Ronin]

For what purpose...? I am currently editing a bunch of them and updating my devices, all without problem.

substitutions:
  name: "gpo-ups-server"
  friendly_name: "UPS - Servers"
  device_description: "Athom Plug v2 - Phase C / GPO 1 - Servers & NAS"
  # Allows ESP device to be automatically lined to an 'Area' in Home Assistant. Typically used for areas such as 'Lounge Room', 'Kitchen' etc
  room: "Network Rack"
  # The phase in the home power supply, upon which this plug is utilsed. 1p = A. 3p = A, B or C.  (myHome GPO1 = Phase C, GPO2 = Phase A, GPO3 = Phase B)
  power_circuit: "GPO 2"  
  relay_restore_mode: ALWAYS_ON  

esphome:
  name: "${name}"
  name_add_mac_suffix: false

esp8266:
  board: esp8285
  restore_from_flash: true

packages:
  remote_package:
    url: https://github.com/Roving-Ronin/myHomeAssistant/
    ref: main 
    files: [esphome/athom-smart-plug-v2.yaml]
    refresh: 1d # optional

Here's an example config of a plug on my local ESPHome instance. It calls the athom-smart-plug-v2.yaml file (that is specific to that vendor/product... i.e. there's a different one for v3, as that has a few variations for the ESP32).
Within this yaml file it in turn calls :

dashboard_import:
  package_import_url: github://roving-ronin/myhomeassistant/esphome/athom-smart-plug-v2.yaml@main
  import_full_config: false

packages:
  base-config:         !include common/base-configuration.yaml
  wifi-config:         !include common/network-wifi.yaml
  athom-power-sensors: !include common/sensor-athom-power-plug.yaml

that is the base-configuration that ALL esphome devices use (i.e. set name/room/common sensors/time setting etc). It then also calls the wifi-config that sets up the WiFi components and sensors (as opposed to ethernet connected ESPs that have a different config). Lastly all the common sensors and components (such as CSE7766 / voltage / power etc) are setup by the sensor-athom-power-plug.yaml that is pulled.
100% of these are sitting remotely on Github. If anyone wants to add extra sensors etc, apart from the usual manner of forking the repo and making their own version, they can simply add/change substitutions and add additional settings to components. Remember that any setting defined in the package is not 'mandatory' so if you want to override that setting, a user just needs to add that to their own local config and it will take precedent over the Github setting. Or else the remove! command can be used to remove a component on Github that is not wanted.

Just reflashed this, all off GitHub and no issues:

[raidnet-ms]

Because you already have those local packages in local, so you can compile.

If Athom had to edit the base file on their side, how would you manage to get that update?

Try to delete a local yaml from your device. You will notice it will not be included from the repo.

[Roving-Ronin]

@raidnet-ms Huh... Every ESPHome device must have a single yaml file installed upon your/home server, this being the name-of-device.yaml file that contains the basic configuration. As above an example of this was given:

  name: "gpo-ups-server"
  friendly_name: "UPS - Servers"
  device_description: "Athom Plug v2 - Phase C / GPO 1 - Servers & NAS"
  # Allows ESP device to be automatically lined to an 'Area' in Home Assistant. Typically used for areas such as 'Lounge Room', 'Kitchen' etc
  room: "Network Rack"
  # The phase in the home power supply, upon which this plug is utilsed. 1p = A. 3p = A, B or C.  (myHome GPO1 = Phase C, GPO2 = Phase A, GPO3 = Phase B)
  power_circuit: "GPO 2"  
  relay_restore_mode: ALWAYS_ON  

esphome:
  name: "${name}"
  name_add_mac_suffix: false

esp8266:
  board: esp8285
  restore_from_flash: true

packages:
  remote_package:
    url: https://github.com/Roving-Ronin/myHomeAssistant/
    ref: main 
    files: [esphome/athom-smart-plug-v2.yaml]
    refresh: 1d # optional

This can either contain 100% of the code required to configure the device (stored in /esphome directory in a HA for instance).
Optionally users can add in statements to include additional packages that reference the LOCALLY stored yaml files they want to merge. (i.e. if you have a /esphome/common directory and in there you had base-sensors.yaml for example).
Another option is you can store everything on Github and pull all these components and sensor configurations from there, allowing centralised management and updating. Finally you can run a combination of the two, pulling some local and some config from a remote location like GitHub.

Beyond the above example I can assure you there is NOTHING else on my ESPHome server, it is all pulled off the remote site (Github) and merged. Suggest you copy the above yaml into a spare v2 plug on your ESPHome instance, update the name etc substitutes, install and see it all works (and nothing beyond that basic config on your local server).