I’ve had a false positive with my power usage based approach:
The usage on the left is from my electric oven. On the right it’s the ironing board. By chance the iron board pattern triggered my automation for my dishwasher 
But i’m still happy with it.
Just to add my personal use case as well:
I have an EV and I would like to track it’s monthly consumption (30 days).
I have a wallbox which I use to know how much I charged as well as an input number to manually set the charged amount outside of my home.
However for the real consumption I would have to add the difference of the battery level from 30 days ago and now. So if 30 days ago I had 80% battery and now I have 50% I consumed 30% of 60kWh, so I have to add another 18kWh to the total consumption.
This just silly. I am new to Home Assistant and the first thing I want to do (let me starting simple and easy) is this thing.
I installed an electric boiler that I allow to heat up within a time slot early in the afternoon. From 13:00 to 15:00, when power is cheap and solar power is likely high. I want to see each day how many kWh went into the boiler. This tells me the stand-by usage when I did not use any hot water and it tells me how much I used when when I did use hot water, like shower. So I need a sample in the morning and one after 3 pm. Or just samples every day at 3 pm. The hike will tell me what I want to know.
It records a load of samples without me ever asking for it but I can't get a value from it easily?
Explain what source sensors you have (with actual entity IDs and the units of the data that they provide) and what information you need. If it's possible to do, we can suggest ways to do it.
I want to snap-shot total power usage values from a smart plug.
Since yesterday I learned this can be done using retained MQTT topic values, inputs (meh, seems abusive, these are for UI interaction) or custom components like hass-variables.
The latter seems the most appropriate but I cannot get my head around the yaml yet. When I use the UI to create a variable, I get confusing questions. Like what device (?).
What I expect is just a key-value dictionary that I can access from automation code. It feels like HA and me live in different worlds.
By now I have MQTT working and I integrated that hass-variable components. The latter makes no sense to me at all.
It sounds like you have expectations of how it should work that are different from how it actually works. If you provide the information I asked for in my previous post you might get some help...
Thanks for trying to help. I don't see what the exact entity name is going to add to the conversation but here it is.
{{ states("sensor.fibaro2_electric_consumption_kwh") }}
This is what I want to get, store and retrieve later from another automation.
I found another add-on that makes somewhat more sense to me: home-assistant-variables by snarky-snark. It allows me to define persistent variables in the configuration file (I made an include to var.yaml for that which suits me fine). It seems well documented but I have not succeeded in applying the examples yet. An additional frustration is that HA screws up my yaml. When I save and come back it has changed the order of lines and deleted code it did not understand. This is just unforgivable, it should state any problems with it and let me fix it instead. These people are nuts.
Anyway, any tips are most welcome.
HA does not modify user config/yaml. If you’re using the ui with automations, that would be the only exception but it wouldn’t let you save invalid yaml.
It means I don't have to make up example entity IDs in my suggestions and then trust you to update them correctly if you try it, and it also means I don't waste time coming up with a suggestion to find it doesn't work because you don't know the difference between energy and power.
Pop this in your config (making sure you only have one template: heading, which might be in an !included file):
template:
- triggers:
- trigger: time_pattern
hour: 15
minute: 0
sensor:
- name: Energy Reading 1500
unique_id: 31584469-5b1b-495b-b0f0-7f9c9a2faab8
state: "{{ states('sensor.fibaro2_electric_consumption_kwh') }}"
attributes:
day0: "{{ states('sensor.fibaro2_electric_consumption_kwh')|float(0) }}"
day1: "{{ this.attributes['day0'] }}"
day2: "{{ this.attributes['day1'] }}"
day3: "{{ this.attributes['day2'] }}"
day4: "{{ this.attributes['day3'] }}"
day5: "{{ this.attributes['day4'] }}"
day6: "{{ this.attributes['day5'] }}"
day7: "{{ this.attributes['day6'] }}"
day8: "{{ this.attributes['day7'] }}"
day9: "{{ this.attributes['day8'] }}"
day10: "{{ this.attributes['day9'] }}"
and I'll record the last ten days' 3pm readings as attributes. You can access the values like this:
{{ state_attr('sensor.energy_reading_1500','day6') }}
Alternatively, you can query the database with an SQL sensor.
If you want constructive help on this, please explain how you have installed HA, on what device, and how you are editing YAML. In general, if you are seeking help, please answer the questions you are asked.
YAML edited via the UI is stored internally as JSON and won't be restored character-for-character as you typed it. If you edit with an external editor, this won't happen. I have HA installed in a Docker container on my NAS and use vim via ssh to edit my YAML, and it does not get changed.
Those should use .get, otherwise they will error in the logs
You cranked that out from the top of your head did you?
I get the idea though. After tinkering with it (time_pattern attributes must be plural and the order of setting attribute values must be reversed to have the desired effect) it looks like it does a nice job but it does not address the core of the question: these virtual sensor objects are not persistent. Any new attributes are gone whenever the template is reloaded.
It gave me a nice excercise though so thanks anyway.
And once I find an elegant way to persist data over restarts (like get to grips with that snarky-snark component) I may combine that with this method to get what I had in mind.
- triggers:
- trigger: time
at: '15:00:00'
sensor:
- name: boiler_energy_consumption_history
unique_id: boiler_energy_consumption_history
unit_of_measurement: "kWh"
attributes:
day7: "{{ this.attributes['day6'] }}"
day6: "{{ this.attributes['day5'] }}"
day5: "{{ this.attributes['day4'] }}"
day4: "{{ this.attributes['day3'] }}"
day3: "{{ this.attributes['day2'] }}"
day2: "{{ this.attributes['day1'] }}"
day1: "{{ this.attributes['day0'] }}"
day0: "{{ states('sensor.fibaro2_electric_consumption_kwh') | float(0) }}"
today: "{{ this.attributes['day0'] - this.attributes['day1'] }}"
yesterday: "{{ this.attributes['day1'] - this.attributes['day2'] }}"
2_days_ago: "{{ this.attributes['day2'] - this.attributes['day3'] }}"
3_days_ago: "{{ this.attributes['day3'] - this.attributes['day4'] }}"
4_days_ago: "{{ this.attributes['day4'] - this.attributes['day5'] }}"
5_days_ago: "{{ this.attributes['day5'] - this.attributes['day6'] }}"
6_days_ago: "{{ this.attributes['day6'] - this.attributes['day7'] }}"
state: >
{{ "Today : " ~ this.attributes['today' ] + this.attributes['unit_of_measurement'] }}
{{ "Yesterday : " ~ this.attributes['yesterday' ] + this.attributes['unit_of_measurement'] }}
{{ "2 days ago: " ~ this.attributes['2_days_ago'] + this.attributes['unit_of_measurement'] }}
{{ "3 days ago: " ~ this.attributes['3_days_ago'] + this.attributes['unit_of_measurement'] }}
{{ "4 days ago: " ~ this.attributes['4_days_ago'] + this.attributes['unit_of_measurement'] }}
{{ "5 days ago: " ~ this.attributes['5_days_ago'] + this.attributes['unit_of_measurement'] }}
{{ "6 days ago: " ~ this.attributes['6_days_ago'] + this.attributes['unit_of_measurement'] }}
They restore state on reload. I.e. they persist
That would be great but it's not what I see. When I reload the configuration the attributes are gone, as witnessed in realtime in developer tools under states.
Or is that because I changed the template that defines the sensor?
Could elaborate on this please?
petro> Those should use .get, otherwise they will error in the logs
Trigger based template sensors restore state on restart or reload. They restore the main state and any attributes.
Restoring state will not happen if the restored state is unknown or unavailable.
Yes. I came up with it here and modified it for your application.
If you're suggesting it's AI-created, absolutely not. A bit of familiarity and a thought process matched to how the system works, and this sort of thing isn't rocket science.
Heh considering Troon is one of the most prolific template authors on the site. Not suprised.
I would like to initialize my attributes.
The code I posted above does not work because day7 gets the value of day6 when day6 does not exist yet. It appears this just fails silently on a per attribute assignment basis. The assignment of day0 is the first to succeed because it gets the current energy value. This is then the only attribute showing up in the state monitor in developer tools.
It appears {% if %} constructs are not allowed within sensor definitions. And when I create a separate template for initialization, it looks like the object is just recreated in both scripts, that does not work.
I also found "yaml if statements" which are not supported either.
Any ideas?
They 100% are, as are in-line if expressions.
Please note that sensors with defined unit_of_measurement must return a numeric state... the way the state is defined in your most recent example will never work.
To address the actual issue described in your first post... you may want to take a look at the custom integration, Measure It, which combines some of the features of History Stats, Utility Meter, and Template Sensors.
Or, if you don't actually need these values to exist statically, you could use the recorder.get_statistics action.
Right, that's why I mentioned here:
So your issues with the template sensor are because you're not using .get('day9') in lieu of ['day9'] and because you're using unit_of_measurement with a non-numeric state (as @Didgeridrew pointed out).
I suggest you look in your logs when creating template entities to see all errors associated with the entity you're attempting to create/reload.
I found I can use Jinja in the state definition but not in the attributes definitions.
Which would suit me. I figured I could do the attribute value juggling under "state: >" . But anything I try in that regard renders the state either unknown or unavailable.
The idea is:
state: >
{% this.attributes['day7'] = this.attributes.get('day6') %}
and then finally use {{ }} to create the actual state value based on the (manipulated) attribute values.
Is that even possible?