Can you add “| string()” to the template ?
Yep, the problem is the hole.
Try using a https://www.home-assistant.io/integrations/filter/ to remove the hole.
I can, and I did now. It seems to work, so I will have an eye on it.
{{states('counter.raingauge_pulses') | multiply(0.31) | string()}}
Seems it doesn’t work, even as STRING
Ok, I’ve added an “outlier” filter:
- platform: filter
name: "Energia Complessiva"
entity_id: sensor.energia_somma_piani
filters:
- filter: outlier
window_size: 4
radius: 50
and so far it seems it is removing the zeros:
sensor before filter:
sensor after filter:
finger crossed it may have fixed the issue! thanks!!
I was struggling with getting my utility meters to have the correct unit issue like others above. I was able to reuse an existing utility_meter name by
1 - Remove the sensor from HA
2 - Restarting HA
3 - Deleting that device out of the ../homeassistant/.storage/core.restore_state
file and then restarting HA.
4 - Once restarted, recreate the sensor with the same name and it was reset. I had to wait a minute or two for the energy meter to increase in value so the sensor would initialize.
For some reason, I didn’t understood the utility meter at the beginning and I added the “live” power, instead of the total energy sensor to the utility meeter sensor.
I now can read proper values!, but, I have an issue with the units, they are in Watts and not KW/h,
Deleting the sensor and adding it again on the config file doesn’t help. It remembers it,
I know changing the name will solve it… but… it has the same formatting as the others that are right and would’t want to change them: “sensor.kitchen_monthly_energy”
I guess I need to do what it’s mentioned above, but where is this file located, cant find it with the visual studio.
I’ve decided to PR a fix for this common mistake:
At least sync at startup!,
finally found the hidden file and manually changed the units!
Thanks for the work, others will appreciate.
(also another feature that should be implemented in the utility meeter is not to sum if one of the sensors that add the values is in “unknown state”, managed to do it after reading some trouble from others, but that is definitely a feature that should be default implemented. Probably not posible since the utility meeter doesnt know what sensors compose the sum function, maybe sum them inside the utility meeter instead of using another template)
Every state change seems a bit extreme. Why not just after a restart/reload of the integration?
it actually doesn’t cost much from a processing point of view (just a dictionary query -> O(1) )
It’s just that there seems to be more and more examples of that way of thinking, and they all do add up. My processor use has gone up with every update lately. Not by much, but for a device that is on 24/7 every little bit of power saving helps.
The utility meter can’t be changed without a restart, so checking then would seem to be the most efficient.
Small question: is it correct that since the new service UI in the Developer tools, I cannot call any method anymore on the utility_meter
?
You still have the option of switching to YAML mode
Thanks for the swift feedback - it was a PEBCAC problem.
Although, I don’t understand it completely yet: I don’t have an error anymore when calling the service but my sensor values don’t change. Am I missing something?
you don’t calibrate the utility_meter, you calibrate the sensors created by the utility meter.
So entity_id
in the service call should be sensor.production_electricity_house_yearly
Thx! That solved it - I was a bit confused as the example yaml used utility_meter.energy
.
Thanks again!
@iz3man I have exactly the same issue as you had; the calculation of the sensor rises from nowhere
Did id you solve this by using rest sensor instead? My template sensor looks like this:
- platform: template
sensors:
bv_energy_total_test:
friendly_name: 'BV Energy Total Test'
value_template: "{{ (states('sensor.shelly_bv1_energy')|float + states('sensor.shelly_bv2_energy')|float + states('sensor.shelly_bv3_energy')|float)|round(2) }}"
unit_of_measurement: "kWh"
and utility meters like this:
bv_daily_test:
source: sensor.bv_energy_total_test
cycle: daily
bv_monthly_test:
source: sensor.bv_energy_total_test
cycle: monthly
It t works for a short while, then it raises unexpectedly…