hekmon
commented
1 year ago Yes the example does show the price in cents because it is intended to be showed/printed on screen as a widget and not used as a source for the energy dashboard.
Switching it to euros would result in the loss of the visual sub cents values. On the other end, source prices used in the example are in € especially because their are designed to be used as input in the energy dashboard.
I know a lot of people are seeking to have a dynamic prices sensor to be applied to their single metering sensor (here and here). But using tempo I personnaly think this is a not-so-good approach: the only SoT (source of truth) of how many kWh you have consumed in each color and on/off peak are the Linky integrated counters. They are the one retreived by Enedis and transmitted to EDF for billing. They are the ones people should recover to applied (fixed) prices on each of them. Having a single global metering device and trying to apply on it a constantly changing price is an approximation at best.
Not even mentionning that you will lost this kind of details from HA:
This is why, for this example, everything related to prices (input numbers and template sensor) are in seperated github gists: they are not part of this integration. This integration is all about Tempo colors from RTE. And RTE has nothing to do with prices (EDF does). This example is here to show how someone can use its sensors (colors and off peak) to make something more. But I am fairly confident that if someone does need a dynamic prices sensor for the energy dashboard, it will be easy for him to adapt my example (by removing the * 100 like you said).
But I do not want to publish it in this form because I do not "believe" this is the right way of doing it :)
fcrozat
Currently, the example given for price per hour sensor is not in euro cents, not euro, which make it not usable on the Energy dashboard as price source.
I would suggest to drop the * 100 in the template yaml to have the proper price in €