Integration keeps spamming errors about bdrthermostatha HOT 3 CLOSED

Dear Marck, as pointed out in the disclaimer, the integration does not work for the new Remeha API and smartphone app due to its recent changes. I am not able to research and test new Remeha app, thus I am sorry but can not fix it. However please go through other issues and you will find links to working Remeha integration.

from bdrthermostatha.

It's not that the integration doesn't work (it works for now), but I get loads of spam. I ignored it for now with:

logger:
  logs:
    custom_components.bdr_thermostat.climate: fatal

Also I would suggest making the disclaimer more clear and/or making this a public archive and adding the other repos for Remeha.

That said, if anyone encounters this issue and doesn't want to scroll to the other issues: these are some adjustments to this repo that might work for you. Feel free to add more repos if you find them.

• GTW-16 thermostat: https://github.com/jghaanstra/BDRthermostatHA
• Integration for the new Remeha Home from @msvisser: https://github.com/msvisser/remeha_home

from bdrthermostatha.

Hi,

I digged a little bit deeper into this since I also got the log messages while having/using the old Remeha API.

2023-02-12 12:16:27.206 ERROR (MainThread) [custom_components.bdr_thermostat.climate] {'mode': 'manual', 'fireplaceModeOn': False, 'roomTemperature': {'value': 21.0, 'unit': '°C', 'min': 0.0, 'max': 50.0}, 'roomTemperatureSetpoint': {'value': 12.0, 'unit': '°C', 'min': 0.0, 'max': 60.0, 'increment': 0.1}, 'zoneActivity': 'standby', 'timeProgram': 1}
This originates from from line 106 in climate.py. It seems to be used for debugging but writes to the error logger.

Remeha eTwist provides for BurningHours the unit "hours" which is not known to HA. This can easily be fixed by setting it to "h", but I do not know if this would be compatible for the other brands.

Error and Status are marked with state_class.measurement and HA expects some unit information. Since this sensor provide no no measurements removing the state class for this sensor will resolve this issues.

The issue with receiving is not that simple because which value should be provided for the case the Integrations can't deliver it. I also observed this very rarely. This could be solved using an extra sensor in HA to filter such values, but than you can't see that something is wrong on the interface.

from bdrthermostatha.