At the end of each day I store what is yesterday’s oil cost value in an input_number for display on a dashboard for comparison with what’s going on today.
If I tap it, it opens up and I have the ability to change the value. I don’t want to do that - I just want a fixed value that cannot be changed at the GUI.
What’s the best way to implement that?
The simplest thing - disable tapping if you need to disable showing more-info for this entity.
Ofc this should be done for every card containing this value.
But still you may view (& edit) this entity from settings->entities.
Additionally for disabling the tapping, you may disable the “slider” or “input” controls by card-mod (only in cards, not in more-info) for this entity.
Or use a trigger based sensor, not an input number as that is meant for input.
1 Like
Alternative:
There’s a way to do this without using an Input Number. If the oil cost is a cumulative value, the History Stats integration can do it for you. If it’s an end-of-day spot value, a Trigger-based Template Sensor can trigger at 23:59:59 and report it. The resulting sensor entity is, as are all sensors, read-only.
You can optionally then the sensor’s value into the Utility Meter integration and get long-term daily/weekly/monthly/yearly statistics (that are exempt from the database’s periodic purge cycle).
1 Like
I’ve not come across trigger based sensors. I will look into it.
Or use an entities card and set the type to simple-entity. I think this is by far the simplest.
1 Like
Debatable: a template sensor is simple enough, you can lose the automation, delete the input helper and you don’t need a special card to hide that you have an editable entity that should not be editable.
It all depends, it is up to the OP to choose (/ disappoint / try another / …). At least HA gives this diversity.
1 Like
I won’t be disappointed if he uses your card suggestion 
I’m struggling.
I already have loads of Template entities defined in my configuration.yaml file in the form…
template:
sensor:
- name: name1
state: >
{{blah blah}}
- name: name2
state: >
{{blah blah}}
but when I try to add a trigger sensor the little red checkdot tells me there’s bad indentation. Can I mix a trigger template sensor with all my existing (non-trigger) template sensors?
Note: I also have another section of template sensors in my yaml file of the form
sensor:
platform: template
sensors:
my_sensor_name:
Don’t ask me why? Probably incompetance when first getting into HA.
This is what my file currently looks like - I’ve tried lots of permutations but cannot get away from the little red validation dot telling bad indentation or something!
template:
sensor:
.
.
.
- name: oil_cost_today
state: >
{{states('sensor.oil_litres_today') | float * states('input_number.last_oil_price') | float}}"
- name: name2
state: >
{{blah blah}}
.
.
.
- trigger:
- platform: time_pattern
hours: 0
minutes: 0
seconds: 55
sensor:
- name: oil_cost_yesterday
unique_id: sunny_bc_00001
state: {{states('sensor.oil_cost_today')}}
unit_of_measurement: Hrs
I’ve just thought, another way round it is to have a template entity just based on the Input_number entity and use that one for the dashboards. since I already have the automation that populates the input_number, that would fit in my yaml template section just fine. Actually I have quite a few like this not just the one cited!
template:
- sensor:
- name: name1
state: >
{{blah blah}}
- name: name2
state: >
{{blah blah}}
- trigger:
- platform: blah
sensor:
- name: name3
state: >
{{ blah blah }}Thanks Tom, that worked. Bit of a pain though as the block tab thing didn’t indent the rest properly so I had to do each line individually.
Can I add more sensors under the one trigger:?
Yes.
template:
- sensor:
- name: name1
state: >
{{blah blah}}
- name: name2
state: >
{{blah blah}}
- trigger:
- platform: blah
sensor:
- name: name3
state: >
{{ blah blah }}
- sensor:
- name: name4
state: >
{{blah blah}}
- name: name5
state: >
{{blah blah}}Why a Time Pattern Trigger?
I believe you said you wanted to record the price at the end of the day (that’s why I had suggested at 23:59:59). Has the requirement changed?
Tom
That looks odd. Like the last sensor is not driven by the trigger. I mean several sensors that all get updated on the one trigger.
123 Taras
I believe you said you wanted to record the price at the end of the day (that’s why I had suggested at 23:59:59). Has the requirement changed?
No, the requirement hasn’t changed. I just got it wrong and it’s gone midnight now!
OK
In addition, the Trigger-based Template Sensor can multiply litres by price making the Template Sensor non essential.
Is there some other purpose for the Template Sensor?
Sorry I misunderstood. Yes you can add more sensors to the triggered sensor like this:
template:
- sensor:
- name: name1
state: >
{{blah blah}}
- name: name2
state: >
{{blah blah}}
- trigger:
- platform: blah
sensor:
- name: name3
state: >
{{ blah blah }}
- name: name4
state: >
{{ blah blah }}
123 Taras
OK
In addition, the Trigger-based Template Sensor can multiply litres by price making the Template Sensor non essential.
Is there some other purpose for the Template Sensor?
On my dashboards I have several values - today’s boiler runtime, litres, kWh and cost shown against yesterday’s values. Today’s values creeping up during the day.
Tom
Sorry I misunderstood. Yes you can add more sensors to the triggered sensor like this:
That looks more like it; I’ll give it a go. Thanks. - Yep, that was all accepted. Just got to wait 23 Hrs now.
It’s possible that your application could benefit from the History Stats integration. For example, I use it to track my furnace’s daily runtime. By day’s end it displays the furnace’s total daily runtime. It automatically resets at midnight.
To prevent losing the day’s runtime (when it resets) I use the Utility Meter integration to automatically keep track of daily/weekly/monthly/yearly furnace runtime.