Lost in templates and quotation marks for Netatmo attributes

QbaF · November 30, 2019, 1:06am

Hi, most probably it is a newbie question but please help as I made few templates accordingly (in my opinion) to docs - also for Attributes add-on, and no one is working.
I am trying to obtain a sensor for attribute current_temperature for climate.netatmo_bedroom. I did tried following ones and everyone did end with error. The question is where are the errors?

1

 - platform: attributes
   friendly_name: "Current Temp"
   attribute: current_temperature
   unit_of_measurement: "°C"
   entities:
     - climate.netatmo_bedroom

2

  - platform: template
    sensors:
      netatmo_valve_bedroom_current_temperature:
        friendly_name: "Netamo Valve Sypialnia temp"
        value_template: '{{ state_attr('climate.netatmo_bedroom', 'current_temperature') }}'

3

 - platform: template
   sensors:
     netatmo_valve_bedroom_current_temperature:
       friendly_name: "Netamo Valve Sypialnia temp"
       value_template: '{{ state_attr("climate.netatmo_bedroom", "current_temperature") }}'

4

 - platform: template
   sensors:
     netatmo_valve_bedroom_current_temperature:
       friendly_name: "Netamo Valve Sypialnia [temp]"
       value_template: '{{ states.climate.netatmo_bedroom.attributes.current_temperature }}'

tom_l · November 30, 2019, 2:24am

There is no attribute platform that I know of. Where is this documented? Also you specified “entities” instead of “entity_id”. Use the template platform and:

- platform: template
    sensors:
      netatmo_valve_bedroom_current_temperature:
      friendly_name: "Current Temp"
      unit_of_measurement: "°C"
      entity_id:     #### not "entities"
        - climate.netatmo_bedroom
      value_template: "{{ state_attr('climate.netatmo_bedroom', 'current_temperature') }}"

Single quotes inside double quotes for one line templates. Otherwise your open and close quotes give this:

- platform: template
    sensors:
      netatmo_valve_bedroom_current_temperature:
        friendly_name: "Netamo Valve Sypialnia temp"
        value_template: '{{ state_attr('          ### see the problem? ###

This actually looks Ok to me. What was the error?

 - platform: template
   sensors:
     netatmo_valve_bedroom_current_temperature:
       friendly_name: "Netamo Valve Sypialnia temp"
       value_template: '{{ state_attr("climate.netatmo_bedroom", "current_temperature") }}'

Again, looks ok, though this is not the best format to use. The format you used in 3. was better as it does not error if the climate component is unavailable, say right after a restart. What was the error?

- platform: template
   sensors:
     netatmo_valve_bedroom_current_temperature:
       friendly_name: "Netamo Valve Sypialnia [temp]"
       value_template: '{{ states.climate.netatmo_bedroom.attributes.current_temperature }}'

Edit: examples 3 and 4 have a space before - platform: template remove it and adjust the indentation.

QbaF · November 30, 2019, 3:15am

1

This is an add-on documented here

2

Understood, thanks

3

Invalid config for [sensor]: required key not provided @ data['platform']. Got None. (See /config/configuration.yaml, line 18). Please check the docs at https://home-assistant.io/integrations/sensor/

4

other sensors do works with this space, without that space I do have an error in previous sensors

Error loading /config/configuration.yaml: while parsing a block mapping
  in "/config/sensors.yaml", line 2, column 1
expected <block end>, but found '-'
  in "/config/sensors.yaml", line 47, column 1

RMRK: Problem found @tom_l I did have sensor line in one of the first rows (for systemmonitor, strange it works [or I didn’t notice]). It occurs in process of switching from configuration.yaml to sensors.yaml
Thanks for cooperation it really helped not only in this case but also for future.

I think this topic could be deleted (as a newbie no idea if it is possible/doable/expected). Anyway thanks and like I learned about at least about quotations that was not clear for me.

tom_l · November 30, 2019, 3:31am

Ah ok, sorry I missed that in your description.

Glad you got it solved and no need to delete it. It may be useful to someone in future.

123 · November 30, 2019, 4:35am

I’m failing to see the advantage that add-on has over using a standard Template Sensor. For the second example it provides:

  - platform: attributes
    friendly_name: "Last changed"
    attribute: last_triggered
    icon: 'mdi:clock'
    time_format: '%e %B - %H:%M:%S'
    entities:
      - automation.temp_changed

The equivalent value_template is this:

{{ state_attr('automation.temp_changed', 'last_triggered').timestamp() | timestamp_custom('%e %B - %H:%M:%S') }}

For your example:

 - platform: attributes
   friendly_name: "Current Temp"
   attribute: current_temperature
   unit_of_measurement: "°C"
   entities:
     - climate.netatmo_bedroom

The equivalent Template Sensor is simply this:

     current_temp:
       friendly_name: "Current Temp"
       unit_of_measurement: "°C"
       value_template: "{{ state_attr('climate.netatmo_bedroom', 'current_temperature') }}"

anon43302295 · November 30, 2019, 5:02am

Saves writing the same template over and over again. I use that custom component to monitor anything with batteries battery level, and when I get another device I just add the entity id to the bottom of the list.

123 · November 30, 2019, 12:18pm

The custom component’s first example shows a single sensor that monitors several batteries. Adding another device to an equivalent Template Sensor would simply be a matter of adding its entity_id to the template.

As for QbaF’s use of the custom component, it is monitoring temperature which, as shown above, is easily handled by a Template Sensor.

I do understand the custom component’s appeal (convenience; avoids writing a template). Nevertheless, the job can be done with a Template Sensor and the result may even be more compact (and certainly more flexible).

anon43302295 · November 30, 2019, 2:20pm

No, I think you’re missing how it works, 4 template sensors for battery attributes would be

battery_1:
       friendly_name: "Battery 1"
       unit_of_measurement: "%"
       value_template: "{{ state_attr('something1' , 'battery') }}"

battery_2:
       friendly_name: "Battery 2"
       unit_of_measurement: "%"
       value_template: "{{ state_attr('something2' , 'battery') }}"
battery_3:
       friendly_name: "Battery 3"
       unit_of_measurement: "%"
       value_template: "{{ state_attr('something3' , 'battery') }}"

battery_4:
       friendly_name: "Battery 4"
       unit_of_measurement: "%"
       value_template: "{{ state_attr('something4' , 'battery') }}"

But with the attributes sensor would be

  - platform: attributes
    friendly_name: battery
    attribute: battery 
    icon: 'mdi:battery'
    entities:
      - something1
      - something2
      - something3
      - something4

Which is significantly less code, and when multiplied over 20 devices makes a real difference.

123 · November 30, 2019, 2:29pm

Entirely possible.

That configuration you’ve shown creates one sensor or four sensors (one for each of the four entities listed)?

EDIT
If it generates four separate sensors, then I understand its benefit. It simplifies the configuration of multiple sensors that share a common functionality (temperature, battery_level, etc).

Mariusthvdb · November 30, 2019, 2:47pm

would have loved to have known of this before, I have a huge amount of template sensors that brake out all attributes of the binary_sensors the Hue custom component makes… Will certainly try out this.

Would be even cooler if we could set a list of attributes like:

  - platform: attributes
    friendly_name: battery # (this would be an issue, could be made temptable maybe)
    attribute: battery, lux, light_level, dark, reachable, on
    icon: 'mdi:battery'  #(as would this)
    entities:
      - binary_sensor.hue1
      - binary_sensor.hue
      - binary_sensor.hue
      - binary_sensor.hue

breaking out all of these:

cant find it in the docs, but would you know if that could be done?

If not, ill create a feature request.

This sole component would save me a few hundred lines of identical templates… (for 13 of these sensors.)

anon43302295 · November 30, 2019, 3:49pm

@123 Four sensors, the friendly name bit is tagged on the end of the friendly name of the original sensors. Works really well.

@Mariusthvdb AFAIK it’s one attribute per sensor, but you could use yaml anchors to create as many as you want with very few extra lines or add a feature request