comparison external temp sensor vs temperature shown by the real TRV

[bsafh]

Quite interesting difference in the behavior from room to room ...

better thermostat seems to adapt to that.

[KartoffelToby]

sorry for asking such a stupid question but what exactly am I seeing here? I used grafana myself, unfortunately it broke due to an update, the target temperature and the valve position would still be interesting

[bsafh]

Yes, that would be great. Unfortunately, I was not able to access the valve position or the target temp from the grafana plugin. They are not listed as selectable entities. Perhaps they are not within the groups of data pushed to the InfluxDB.

These values are just the temperature from the external sensor and the temperature the real TRV reports as current actual temperature.

I can see those in RaspberryMatic of course and graph them there.

I'll look into this in the following days. Perhaps I can find a way to push target temp and valve state into InfluxDB. I have no Idea which data group they belong to - the TRV device shows the valve state as "diagnostic".

The target temperature is not offered by the real TRV device. That would need to come from the BT device - but I have not found a way to access that value in any way. Perhaps you can make that available to HA as entity?

Or I have to fiddle around with history_graph cards in HA.

[bsafh]

Some graphs for valve positions are displayed Here (from the RaspberryMatic GUI)

#459 (comment)

[bsafh]

I'll try it with Grafana later on.

The HA build-in graphs look like this:

Room "Schlafzimmer"
TRV 1 - real Thermostat

shows:
entity climate.hm_cc_rt_dn_keq0510114_2

• actual temperature measured by the TRV
• heating
• target temperature on the TRV
  

valve state for this TRV (same time range) sensor.hm_cc_rt_dn_keq0510114_valve_state

The corresponding BT TRV shows (same time scale)

The combined image in HA is this:

for a shorter time period

this short time the windows was opened, window detection seems to work

[bsafh]

same graph for another room

short time period

3 days:

[bsafh]

and a third room

[bsafh]

The Comet DECT does not show the valve state unfortunately:

[bsafh]

and my office:

[bsafh]

Some remarks

if the external temperature sensor malfunctions (giving too low values), BT will open up the valve to max and stay there.

The HomeMatic/HomeMatic_IP valves additionally have a technical restriction: they operate on 868MHz, which is (in Germany) highly regulated because it's a very narrow RF band with very long range with very many devices on it (weather stations, garage door opener, ... etc). Therefore - as far as I understand - any device using this (e.g. all my 12 TRVs) may not consume more than 1% (? but very little) of that bandwidth (which in total is 600kHZ (!!) for the Channels used by HomeMatic devices) and there are time slots - a device which used up it's "duty cycle" has to be silent for some time (up to 30 minutes or so). And yes, those laws are enforced ...

Polling the different states from all of the TRVs (actual temp, valve state, target temp, battery level) every few seconds or even every few minutes (as my HomeAssistant installation or one of the integrations seems to do) quickly uses up all available duty cycles - the result is that the devices are marked a unavailable in HA for extended periods of time (a few hours). Which confuses BT of course.

That's probably why in all the graphs with valve state or actual temperature measurements there are many gaps in the graphs ... :-( and I have no idea how to reduce the polling rate in HomeAssistant :-(

[bsafh]

The gaps in these diagrams denote the time periods when the "RaspberryMatic" shows "DutyCycle" of 99% and not responding to HA at all.

looking at the target temp directly on the RaspberryMatic VM, there seem to be quite frequent changes in target temp settings. This might overload RaspberryMatic, but I'm not sure

[bsafh]

Background info:

Environment

HomeAssistant 2022.9.6
HomeMatic(IP) local (https://github.com/danielperna84/custom_homematic) 1.17.0
better_thermostat custom component 1.0.0-beta22 https://github.com/KartoffelToby/better_thermostat
custom_schedule custom component (3.2.10) https://github.com/nielsfaber/scheduler-component

Debmatic in VM 3.65.8.95 / or also RaspberryMatic in VM (not the HA addon) 3.85.0.20220831 (both behave identically)
BidCos: HB-RH-ETH + RPI-RF-MOD

Runs in principle without any problems :-)

But:

I have 12 HomeMatic HM-CC-RT-DN thermostats (2 of which are grouped together within the RM, type HM-CC-VG-1).

They can also be controlled manually.

Only: every few hours, several times a day, the duty cycle rises to 99% and 2-6 of the 12 thermostats report "device communication disturbed" (it's always the same thermostats, and it's not the ones with the weakest radio link, presumably the ones most often controlled from HA).

I can also trigger this behaviour at will by manually adjusting 3-4 of the thermostat valves via the rotary wheel on the thermostat, which then of course triggers change messages to HA.

In HomeAssistant these are then displayed as "not available" - several minutes to hours.
Which makes regulating against Zigbee temperature sensors a bit tricky....

It can take over an hour for things to settle down again, and if there are further change requests, sometimes even several hours. Of course, this is neither useful for monitoring nor for any automation.

As far as I understand the 868 MHz radio technology, this behaviour means that the respective thermostats have used up their respective time slots for radio communication and now have to wait until they are allowed again. They are also not allowed to respond to requests during this time (as far as I have read, this behaviour is prescribed by law because of the extremely narrow radio band (600 kHz for the HomeMatic devices?, i.e. all together) and the many other devices (garage door openers, remote controls, weather stations, ...).

So: something in HomeAssistant (or one of the integrations) is causing too much radio traffic due to too many requests - something is probably retrieving values too frequently or sending changes too quickly one after the other.

And now the question:

Is there somewhere in HomeAssistant (perhaps in "custom_homematic"? or in debmatic? or BT?) where you can throttle the query frequency as soon as the DutyCycle goes high? Or throttle it in general?

Or can you at least find out what is constantly generating data traffic in HomeAssistant?

[KartoffelToby]

Are you on discord?

[bsafh]

Unfortunately not:-(

[bsafh]

any other ways to connect directly?

[KartoffelToby]

Write me a mail at [email protected]

[bsafh]

from the Homematic forum on this problem:

"Der Grund kann nur sein, dass zu häufig Befehle an die Geräte geschickt werden. Und dann ggf. an zusätzlichen Events, die die Geräte nur verschickt haben WEIL Befehle an sie gesendet wurden."

"The reason can only be that commands are sent to the devices too often. And then possibly at additional events that the devices have only sent BECAUSE commands were sent to them."

[bsafh]

duty cycle is definitely a problem here:

Duty Cycle very often at 100%

"Servicemeldungen" : number of "communication with TRV device failed" errors

[bsafh]

there seems to be quite frequent changes in the valve state (I can't find en entity for the target temperature in InfluxDB :-( )

temperature curves are

• value from the external temperature sensor in the room
• value of the "actual temperature" from the TRV

room with 2 TRVs

another room with 2 TRVs

my office

room with a possibly broken external temperature sensor

and another room with 1 TRV

[bsafh]

To be more precise: any HomeMatic device ist only allowed to communicate for 36 seconds per hour.