question

I don't think radiators are slow in reacting to relay, the temperature sensor has too much mass so that it becomes too slow. A fast temperature sensor is usually used together with a smart pid controller with a self-learning system so it learns when radiators should be switched off before a temperature is reached and switched on before the minimum temperature is reached to get a more stable temperature (hysteresis). It is then often used in conjunction with an external outdoor sensor to take account of the external cooling effect

Thank you @Johnny Brusevold for your kind posting. However, a yes-no discussion isn't a very productive mode of interaction.

Let me point out though, that the RuuviTag sensors seem to react very quickly and precisely to changes in the surrounding temperature. I would say that even a slight difference of less than 1 °C is mediated in less than half a minute. (I guess that the sensor probably reacts similarly even to slighter temperature differences than 0,2 °C, but I didn't experiment with that aspect).

On the other hand, without a fan it takes quite some time before the radiator creates an increase in the air temperature of the device cabinet. It is in the radiator where that slowing down mass is in fact located. - Are we perhaps referring to different kinds of heating arrangements?

We wouldn't need a self-learning system, if the scale of the temperature controlled relay would be comparable to the exactitude of the RuuviTag.

The VRM team is busy with other important undertakings, but can we expect such an update in the future @mvader ? We are planning to purchase 6 Victron systems for our machine rooms next autumn and wouldn't like to go through multiple lengthy calibration schemes.

While setting up an environment for Venus OS based development, I made a few VRM GUI tweaks which illustrate the need to mirror RuuviTag measurements with one decimal exactitude on the scale for values of the temperature controlled relay settings.

To refine the graph along the time axis configure:
Settings > VRM online portal > Log interval to 1 min

The VRM Custom widget offers flexible methods of tuning the graph. In the Advanced view select:
Widgets > Custom Widget > Create custom widget > Select Device : RuuviTag

Use values: RuuviTag, Manually set one y-axis for all parameters, Temperature and insert Minimum and Maximum values.

Victron provided us an elegant machinery to monitor interaction between the equipment and the environment.

Finally got my modest Raspberry Pi 3B based development environment up and running.

While skimming through the qml source files it turned out that the GUI functionality related to the question is actually located in PageTemperatureSensorRelay.qml. I tweaked four sections (activation and deactivation MbSpinBox sections of the two relays) of the descriptive code like this:

                step: 0.1 /* Was 1 */
                decimals: 1 /* Was 0 */

This made c0Set, c0Clear etc. MbSpinBoxes work correctly and values appeared with one decimals on the menu browser page and its parent. The problem left was that while confirming the new value, the decimal part of the new reading gets lost.

As there are a number of competent developers in this community who are familiar with the Victron OS environment, I wonder if anybody could tell me where I should look for definitions of these values as integers to fix them (or any other workaround) so that I could get to the aim?

Wrote earlier:

I'm also aware that it could be possible to achieve the stated aim by applying a node-red ... solution.

Checked the Victron and Node-Red webinar videos and found that Victron employee @Dirk-Jan Faber made a presentation which actually illustrates in detail how this can be achieved:

https://youtu.be/_J2rVNLrDIg

However, this approach involves installation of supporting equipment and software, the large version of Venus OS and a couple of other tricks which makes it less usable for untrained users.

I wonder if anybody could tell me where I should look for definitions of these values as integers to fix them (or any other workaround).

The localsettings document at https://github.com/victronenergy/localsettings states:

D-Bus settings manager that interfaces between xml file on disk and D-Bus. It is a part of Venus. All programs that need non-volatile settings use this dbus service. And all code that changes settings from other processes, for example the GUI, do that via the D-Bus service of com.victronenergy.settings as well.

Non-volatile settings reside in /data/conf/settings.xml which is updated whenever a change is being made. It turned out that all my qml changes were correctly modified, but when the SetValue call modified the value the decimals were lost. The reason for this is that the file defines the values as integers, like this:

<ClearValue type="i" min="-100" max="100" default="0" silent="False">16</ClearValue>

So the workaround is to change the type argument's values to floats ("f"). After that everything works as expected. Apparently that wouldn't offend functionality of sensors with a precision of 1 degree.

With the ability to utilize 0.1 °C precision the modification was ready to be installed on the production unit:

Now the fluctuation of temperature diminished from 3.5 to 1.5 °C. With a better placing of the sensor the result could apparently be even better, but that falls outside the scope of this topc.