OperationMode correction?

[BenPru]

The luxtronik controller returns under "0080 calculations.ID_WEB_WP_BZ_akt" the OperationMode=heating if the heatpump is effective heating.
But also if the heater of the compressor (0182 calculations.ID_WEB_LIN_VDH_out) is running. Not the compressor (0044 calculations.ID_WEB_VD1out) himself.
The heater of the compressor ensures a minimum temperature. In my case it runs about 2-3 times per hour.

I think the OperationMode heating should only report heating if the heatpump heats something productive in the building and not only himself. So I have a correction that overwrite the OperationMode in case of only running the heater of the compressor.

That do you think about this? Should we implement this in our core-module (python-luxtronik)?

[Bouni]

In my opinion we should not manipulate the parameters / calculations itself. We could introduce a new category, maybe call it extended or something like that, where we have values that have certain constrains.

I know that AIT has several parameters / calculations that have different meanings dpendent on heatpump type and some other constrains.

[BenPru]

Do you think we should add an optional param to the existing function or property or add another function?

At the moment I have 3 replacements:

• C80 Status: Show "heating" if the compressor heater is on. Not the compressor himself. Replace with "no request".
• C117 Line1: Show "heating" if the compressor heater is on. Not the compressor himself. Replace with "compressor_heater".
• C117 Line1: Show "heatpump coming" on shutdown. Replace with "heatpump_shutdown".

[kbabioch]

From my point of view there should be multiple "layers" offered by python-luxtronik:

• Obviously we need a low-level interface like we currently have (e.g. parameters, visibilities, calculations, etc.). The data can be represented by data types (like we currently do), but we should not introduce complexity on top of that by interpreting values differently than they are handled by the heat pump itself.
• On top of that there could be another layer that deals with those kind of issues and is a more high-level representation of the heat pump. It could also offer services / functions (e.g. something like (enable_hup, or enable_heatpump, set_temperature, etc.).

Git itself also is doing something similar, it has a plumbing commands and uses those to implement high-level porcelain commands.

[gerw]

The idea by kbabioch sounds interesting. In a certain way, we already have to layers (namely the raw values and the converted values). It would also great, if we could have some high-level functions for setting the parameters. On the other hand, it should not be too easy to mess around with (critical settings of) your heat pump, otherwise people will start to blame the python module for killing their heat pump....

By the way: how do you enable_hup? Is there a specific parameter to trigger the pump? From my understanding, it only starts if the temperature (of hot water or heating water) is too low.

[kbabioch]

On the other hand, it should not be too easy to mess around with (critical settings of) your heat pump, otherwise people will start to blame the python module for killing their heat pump....

Yeah, there should be some consideration to not change critical values too easily. On the other hand you can always kill your heat pump, if you try hard enough ;-).

By the way: how do you enable_hup? Is there a specific parameter to trigger the pump? From my understanding, it only starts if the temperature (of hot water or heating water) is too low.

That was just an example, I have no idea if and how it could be enabled explicitly. But once we figure it out, it should be easy for consumers of this library ;-). I would, for instance, be interested in something like enable_zwe to enable my heating rod to use some excess PV energy to heat up the water (see BenPru/luxtronik#4).

[gerw]

Yeah, there should be some consideration to not change critical values too easily. On the other hand you can always kill your heat pump, if you try hard enough ;-).

Of course, you can always take a sledge hammer -- and we can't hinder the users of this library from doing so...

Maybe a good rule of thumb is that we allow the change of all parameters which can be changed on the heat pump itself with standard user access. (And maybe also the hysteresis parameter. I do not understand why the regular user is not allowed to change these...)

I would, for instance, be interested in something like enable_zwe to enable my heating rod to use some excess PV energy to heat up the water (see BenPru/luxtronik#4).

Ok, but if you enable the heating rod, you need to either heat the warm water or the radiators since the heat pumps do not have a Pufferspeicher / storage tank for heat. (Maybe there are some models which have one??)

[kbabioch]

Ok, but if you enable the heating rod, you need to either heat the warm water or the radiators since the heat pumps do not have a Pufferspeicher / storage tank for heat. (Maybe there are some models which have one??)

You're right, in this case it should be more like make_hot_water(temperature) or something like this. In any case this was an example of why multiple layers might be needed.

Maybe a good rule of thumb is that we allow the change of all parameters which can be changed on the heat pump itself with standard user access. (And maybe also the hysteresis parameter. I do not understand why the regular user is not allowed to change these...)

That's probably a good approach.

The idea by kbabioch sounds interesting. In a certain way, we already have to layers (namely the raw values and the converted values).

I would argue that the raw values and the converted data types are a representation of the same layer. We could offer some control on whether values should be converted, but in the end they represent the same data. This is part of a the "low level" for me. On a high level I would like to offer functions that are based on low level parameters/calculations/visibilities, but are not necessarily linked to those values in a one to one relationship.

We could use this "high level" functionality to implement corrections like discussed here in this issue.