What sensors and YAML do you add to every device?

ESPHome
1

I seem to be in the habit of adding the same “diagnostic” type sensors to all of my ESPHome devices to the point where I have now put them in a separate file that I then reference using an “include”.

Does anyone else do this and if so what kind of sensors are you adding?

text_sensor:
  - platform: version
    id: esphome_version
    name: "${device_name}  ESPHome Version"
    hide_timestamp: True
    entity_category: diagnostic

  - platform: wifi_info
    ip_address:
      id: ip_address
      name: "${device_name}  IP Address"
      entity_category: diagnostic
    mac_address:
      id: mac_address
      name: "${device_name} MAC"
      entity_category: diagnostic

sensor:
  - platform: uptime
    name: "${device_name} Uptime (Seconds)"
    id: uptime_seconds
    update_interval: 60s
    internal: true
    entity_category: diagnostic

  - platform: template
    name: "${device_name} Uptime (Minutes)"
    unit_of_measurement: "min"
    lambda: |-
      return id(uptime_seconds).state / 60.0;
    update_interval: 60s
    id: uptime_minutes
    entity_category: diagnostic

  - platform: wifi_signal
    id: wifi_signal_strength
    name: "${device_name} WiFi Signal"
    update_interval: 60s
    entity_category: diagnostic
1 Like
2

Yeah there seem to be plenty of people doing this. It seems common, although I have never been that organised.

1 Like
3

I’m keen to see what comes out of this thread.

I’m trying to strip back and simplify my HA/ESPHOME set-up which has grown unwieldy and cluttered in the wild.

One thing I was tinkering with was having a device level toggle (substitution) for internal: that you could activate/deactivate during development and debugging for a sub-set of sensors (typically intermediate ones such as the sources of copy sensors).

substitutions:
  internal_mode: "true"


##################################################
#Data Update Sensors. 
  #These were useful during dev. Might remove in prod.
  #All updated via other sensors.
##################################################
#Moisture
  - platform: template
    name: Moisture updated
    id: solar_plant_moisture_level_recieved
    internal: ${internal_mode}
1 Like
4

Will try this template in mine, I just used the default, I thought you were going to talk about the hardware sensors. I am excited to learn more about these yaml configurations.

5

I also have common sensors but not in a separate yaml. I recently started playing around with packages and breaking up my yaml files. I have a top level device yaml then seprate wifi & specific hardware yaml. The hardware yaml has the sensors but those could also be broken out I suppose.

For info sensors like signal strength I add state_class: ’ ’ so they don’t add to long term statistics.

6

I only use the wifi signal sensor and status binary sensor.

7

status, uptime, RRSI sensors, as well buttons restart & safe_mode.

Highly recommend to use packages to reuse configurations etc. and not include same staff in all and every device file.

8

Good idea. Mine just sort of grew organically as I added on diagnostic features:

sensor:

# WiFi sensor
  - platform: wifi_signal
    name: "HVAC WiFi Signal dBm"
    id: "hvac_wifi_signal_dbm"
    update_interval: 5.0min
    entity_category: "diagnostic"
    internal: true

# Reports the WiFi signal strength in %
  - platform: copy 
    name: "HVAC WiFi Signal"
    id: "hvac_wifi_signal"
    source_id: hvac_wifi_signal_dbm
    unit_of_measurement: '%'
    entity_category: "diagnostic"
    device_class: ""
    filters:
      - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);

# Retrieve ESPHome version information
text_sensor:
  - platform: version
    name: "HVAC ESPHome Version"
    id: hvac_esphme_version
    internal: true
    icon: 'mdi:chevron-right'

# Blink the on-board LED
output:
  - platform: esp8266_pwm
    id: onboard_led
    pin:
      number: GPIO2
      inverted: true 

interval:
  - interval: 3000ms
    then:
      - output.turn_on: onboard_led
      - delay: 250ms
      - output.turn_off: onboard_led

# Web Server Entry
web_server:
  port: 80
  include_internal: true

That bit blinking the LED gives me a local (at the device) indication that it’s alive and well.

I’ve read all the admonishments against leaving the web server active. However, my use cases are simple and I haven’t found that it impacts performance, even on old 8266’s.