Putting the "£" in front of the number?

Configuration
1

I see that this question has been discuses many time here already. But I’ve not got any solutions to work for me!
I am not sure which end of the transaction (or maybe both?) need fixing. This is the YAML that does the summing of three numbers and writes to an Entity Card (incidently, if anyone could suggest how to simplify the syntax that would be great):

- service: input_number.set_value
  target:
    entity_id: input_number.cost_today
  data:
    value: >
      {{'£{:,.2f}'.format(
        (
           float(states('sensor.smart_meter_electricity_import_standing_charge'))  +
           float(states('input_number.cost_today_night_component')) +
           float(states('input_number.cost_today_day_component'))
         )
       ) }}

… which in the Developer Tools | Template Editor, shows as I would like i.e. “£12.23”.
The other end of the transaction is the Entities Card:

type: entities
entities:
# Lines removed for brevity
  - entity: input_number.cost_today
    type: simple-entity
title: 'Glow Smart Meter: Electricity'

The end result is “12.34£”. The “£” is at the end not the beginning. How can I correct this?
Regards, Martin

4

Create a template sensor that will display the input_number using the following settings:

image
image705×1075 28.7 KB

That way you will always have the benefit of having the number as a number, and the unit will be displayed automatically when rendered by Home Assistant.

Note - input_number doesn’t appear to support device_class (Input Number - Home Assistant) hence why I’m suggesting to create a sensor.

1 Like
5

Sorry to be so dense!! But how/were is a Template Sensor created?
Do I need to create a file somewhere…

6

Templates can be created in configuration.yaml:

#
template:
  - sensor:
7

Or in the UI, under Helpers.

image
image566×756 33.3 KB

State template there is:

{{ states('sensor.smart_meter_electricity_import_standing_charge')|float(0)  +
   states('input_number.cost_today_night_component')|float(0) +
   states('input_number.cost_today_day_component')|float(0) }}
8

Okay. Thank you. Now I “see” how you have created a Template Sensor in the UI.
However, I’m still a little confused (make that a lot!).
In the preview section at the bottom of the image you pasted, it says: “This template listens…”. I don’t want it to “listen”. I just want a variable that I can write to from an automation and that is viewable in an Entity Card. It is the Automation that does the addition of the three sensors.
If I leave the State template field empty, in the hope that it will be populated by my Automation writing to it, it throws an error.
Regards, M.

9

Oh, you only want to calculate it at specific times? Two options then:

  1. Trigger-based template sensor — needs setting up in YAML, can replace the automation.
  2. Input number helper populated by your automation, template sensor mirroring it with the device_class set as above. Just use a state template of {{ states('input_number.cost_today') }}.
10

I just went through this same frustration. My goal was to have an automation use some numbers from other entities, do some math on them, and display the result in the UI. Seems simple enough, right?

Using an input_number template would certainly work, but when it’s displayed in the UI it’s presented as a box into which the user can type, well, input. Not what I wanted.

I could have created an input_number template, then another template which takes its value from that first one whenever it changes. This would also work, but it seems silly to create two templates just to maintain and display one.

These limitations steered me to trigger-based templates. Since these can do similar logic to what an automation can, this seemed like the simplest solution. Unfortunately I found documentation on these very limited, and even a couple of AI bots struggled to get the syntax correct.

It’s kind of an odd-ball project, but I’ll post my YAML here in case anyone is interested. I have three sump pumps. The sumps are kinda small and the pumps large, so they don’t stay running long. Each time one kicks on, it pumps a fixed amount of water before it kicks off a few seconds later. I wanted to know how many gallons they’ve pumped today:

#
template:
  - trigger:
      - platform: state
        entity_id: 
          - binary_sensor.east_pump_cycle_on
          - binary_sensor.west_pump_cycle_on
          - binary_sensor.bkup_pump_cycle_on
        to: 'on'
      - platform: time
        at: '23:59:30'
    sensor:
      - name: "Gallons Pumped Today"
        unique_id: gallons_pumped_today
        state: >
          {% set current_value = states('sensor.gallons_pumped_today') | float(0) %}
          {% if now().hour == 23 and now().minute == 59 %}
            0
          {% elif trigger.entity_id == 'binary_sensor.east_pump_cycle_on' %}
            {{ (current_value + 4.625) }}
          {% elif trigger.entity_id == 'binary_sensor.west_pump_cycle_on' %}
            {{ (current_value + 8.125) }}
          {% elif trigger.entity_id == 'binary_sensor.bkup_pump_cycle_on' %}
            {{ (current_value + 8.125) }}
          {% endif %}
        unit_of_measurement: "G"

I could walk you through the code, but this post is already getting long. If anyone is interested in why things were done this way, I’ll respond. Or, if someone has a better way, I’d like to hear it.

One thing I will add is that creating lots of template entities risks spamming the Recorder database. Be sure to review your Recorder excludes and includes after creating any new entities!

11

As the OP, I feel like I’m going around in circles on this project! So, I agree - I’ll quit now and leave the £ sign as a postfix.
But I am very interested in your comment Re: Recorder Database. Can you expand or point me to more info. The trigger I’m using in the Automation that has led me to this point is my Smart Meter Electricity Import which I understand could trigger every 10sec. Am I in the area that you are cautioning about?
Regards, M.

12

My option 2 above is an easy solution…

13

Thank you “Troon” for making me think-again…
But if I understand correctly what you are suggesting, isn’t the argument against that approach just what Tom highlighted in Para. 3. above?
Additionally, it is not just one sensor I wish to display there are three - six helpers!!
I’ll never remember what all those are doing :thinking:
Regards, M.

14

The Recorder database is where all the “history” and “statistics” data are stored. The problem is, HA is advertised to work well on a Raspberry Pi platform using an SD card to store the data. And it does work well. Until the continual database writes wear out or fill up the SD card. Personally, mine has been running for over five years now on an SD card. Other folks run HA on different hardware platforms, and even different database engines. For them, the Recorder database is a non-issue.

For some reason this isn’t well explained to new users. It’s very easy to shoot yourself in the foot, just following the recommended installation instructions and taking the defaults.

What I think needs to be stressed is that users should carefully select their Recorder settings in configuration.yaml, and consider whether each entity they add should be included or excluded. There’s a good thread on this here.