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
1 Like
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…