Feedback on ideas to reduce unnecessary calls to Hildebrand

[HandyHat]

Hey all,

I have been in contact with Hildebrand about various ways to reduce unnecessary calls to their API. Here are a few things I'm looking to implement:

• Changing the daily sensors to include the missing 30 minutes at the end of each day by allowing them to call the day before's data between 00:00 and 00:30. This should allow it to be used in the Energy Management dashboard, as well as allowing accurate aggregate sensors to be created through the Utility Meter integration (Aggregate Week and Month Values? (Improvement) #110). This should let the yearly sensors be removed, reducing a huge amount of stress on Hildebrand as the yearly sensors have to add up all of the 30 minute periods for the year so far every time they are called.

• Calling the daily sensor every time Home Assistant starts up/the Integration is reloaded, and then calling 30 minute periods and adding them to the daily sensor after that. This should remove the period of unavailability when the Integration initially starts up, and reduces unnecessary daily calls to Hildebrand

• Finally, I think it should be possible to disable some sensors by default, to reduce unnecessary calls to the API as the data may not be being used. Users that would like to use this data can then manually enable these sensors. I'm currently looking at disabling the tariff and standing rate sensors by default, as I'm assuming the majority of people using this integration are looking for their daily usage and cost.

I would love to receive feedback on these changes before implementing them - do you use the yearly sensor for anything else, or do you think other sensors should be disabled by default? Thanks for all your help and feedback.

[viking2010]

Hi

Thanks for all the investigations in to this integration with Hildebrand. Adding the missing 30 min at the end of the day would be great. I'm only using the yearly sensors at the moment as that's what was recommended in the setup information, but changing it to daily on start up and reducing unnecessary api calls sounds like a good thing.

I did initially use the tariff entity as a source of the correct amount per kWh, however the figure it comes back with excludes VAT at 5%, so a means to add the VAT figure in to the config would be handy.

Also a way to add in the daily standing charge cost to the figures within the Energy dashboard would also be useful, but I know I've read about other ways of being able to accomplish that, but not tried any of them yet.

Whilst that missing 30 mins at the end of the day would be good, someone else had mentioned about data not going in to the right hourly slots and being an hour out compared with the Bright app. Is there any way to resolve that?

I'd be happy to test any of the changes before you roll it out if needs be.
Cheers

[ColinRobbins]

Hi,
Thank you for investigating the issues.

I do use the yearly sensor. I found HA complained (via log entries) when using the daily sensor in the energy dashboard, as the sensor reset to zero each day, so does not meet HAs model of “increasing”.
So it depends if this issue can be overcome.

I am aware people do use the tariff data, when on tariffs that change during the day, so use it to trigger automations to switch stuff on/off. But being configurable would be OK. (The cost sensor should be available by default - and copes with standing charge). Maybe need to configure gas/elec separately.
Maybe configure the update interval - if on a fixed tariff, a once per day update is OK.

I am nervous about 30 minute time slots. It depends on how strict Glow are about getting new time. E.g. what if due to timing, HA calls Glow after 29.59, and not 30.00. Do you get old or new data? Can we be sure HAs timing is sufficiently accurate. (I think this may in part be the issue with #187)

Happy to be a tester…

[HandyHat]

Whilst that missing 30 mins at the end of the day would be good, someone else had mentioned about data not going in to the right hourly slots and being an hour out compared with the Bright app. Is there any way to resolve that?

Unfortunately, this is not possible because Home Assistant does not allow data to be backdated (although interestingly, 2022.4.0 includes a way for users to edit their long-term statistics data manually). There is a good discussion explaining why this delay exists in #45

I do use the yearly sensor. I found HA complained (via log entries) when using the daily sensor in the energy dashboard, as the sensor reset to zero each day, so does not meet HAs model of “increasing”.
So it depends if this issue can be overcome.

I would be interested in hearing more about this, as this issue should not occur because the sensor is correctly set to total_increasing, just like the monthly sensors, which allows the sensor to be reset to 0 (https://developers.home-assistant.io/docs/core/entity/sensor/#long-term-statistics)

Maybe configure the update interval - if on a fixed tariff, a once per day update is OK.

Perhaps the tariff polling interval could be part of the config entry - this would also allow people with no tariff data available to disable calling for it altogether.

E.g. what if due to timing, HA calls Glow after 29.59, and not 30.00. Do you get old or new data? Can we be sure HAs timing is sufficiently accurate. (I think this may in part be the issue with #187)

I believe in the code we will have to specify which 30 minute period we are asking for - if no data is provided for that period, we should be able to set a variable that causes the same 30 minute period to be asked for at the next polling interval (i.e. 5 mins) rather than having to wait the full 30 minutes and losing out on some data.

Thanks for all the feedback so far!

[andypburke]

I would definitely be interested in the last 30 mins being added to the Energy Management dashboard. @HandyHat is there any update on implementing this enhancement?

[HandyHat]

This has now been released in v1.0.0

[gavyb]

is there any further update on this @HandyHat ?

[HandyHat]

This has now been released in v1.0.0