Aniket

Hey all, The issue here is that this integration is hitting rate limits imposed by Hildebrand as it is putting a lot of strain on their servers - the changes...

Hey @si458, I'm maintaining [a fork](https://github.com/HandyHat/ha-hildebrandglow-dcc) to pull data via the DCC which doesn't require glow hardware. As discussed [here](https://github.com/unlobito/ha-hildebrandglow/pull/36#issuecomment-915195357), once the MQTT version is stabler I'm going to look...

This may be the same issue I encountered [here](https://github.com/HandyHat/ha-hildebrandglow-dcc/commit/2c2d360af7701fca459356c5377fb15302a5dad2#diff-40dbdbc224a5a37c625aa9f106b61f50e1dacc2e7410b44083b9885e201dfb26R85), where the API throws an bad response code because it thinks you are trying to load data from the future.

The documentation (https://developers.home-assistant.io/docs/core/entity/sensor/#available-device-classes) indicates that sensors with a value of kWh or MWh should still have a device class of `energy`, so I think the bug here is that sensors...

Hey all, this looks like it may be an extension of the issue described in #305, as the root issue seems to be the data being delayed over a day,...

Hey @anubis-code, are there any errors being logged?

This should now be possible in v1.0.0 but I am unable to personally test it. Please give it a go and let me know if this does not work @ianfretwell...

v1.0.0 of the integration implements many of the ideas in #191 and should reduce the number of DNS lookups and the load on Hildebrand's servers. If you are still seeing...

As of v1.0.0, the tariff sensors are disabled by default and so this error should no longer be encountered.

The library that this integration uses as of v1.0.0 should account for the shift in daylight savings and so this issue should not occur any more. If it persists, please...