ysard / ebusd_configuration_chaffoteaux_bridgenet

Configuration & reverse engineering for the ebusd demon adapted to the boiler Chaffoteaux Mira C Green
GNU General Public License v3.0
16 stars 2 forks source link

Temperatures computed and LWT temperatures #7

Open ogkita opened 1 month ago

ogkita commented 1 month ago

Hola @ysard, @wrongisthenewright.

This topic for computation temperatures discursion ;-)

Yes, I have read the installer document, about 20 or 25 times... I even generated the translated version from the Italian... It helped a bit, but do not think it helped a lot.

In the document, it explains how it works in heating mode. The formula... understood and there are no doubts. I hope to be able to check the values it calculates and uses next winter.

Now, in cooling mode I have not found in the document the formula that applies. I understand that it cannot be the same as the slope configured has nothing to do, in the case of heating it goes from 0.2 to 1 and in cooling it goes from 0 to 30. They are very different values and I think that the same formula does not support these variations:

For heating: image

For cooling: image

For heating. Simplifying and using only external probe:

Tset_term = Tmand_min +SL*( Tamb_set -Text)+OF. dove:

image

II must wait to winter to check if this is correct.

For cooling. Remember that I have not found the formula that applies in the document you indicate. Just changing the external temperature and the slope in the above formula we have:

image

I think it is not correct

The algorithm is influenced by various offset that must be taken into account when checking the temps. There is a heating (par 12.2.a1) and a cooling (par 12.4.2) compensation offset for LWT at HP level, this helps to deliver the right water temp at the zone manager in case the water gets cooled (in heating mode) or heated (in cooling mode) while the water is in transit from the HP to the zone manager for poor insulation or very long tubing.

It may be as you indicate, the point is that to simplify everything I have the offset parameters set to 0.

7f2b 7571 7572 7573

In addition, I have checked the following values in the menu and they are all set to 0:

For heating, these should not affect the cooling system: 4.2.3 4.2.4 5.2.3 5.2.4 6.2.3 6.2.4

For cooling, these are now the ones that should be affected: 4.5.4 5.5.4 5.5.4

7.3.0

Remember I configured this params at 0,

Finally, I believe that by simply applying your formula and making the temperature delivery fixed, we are losing some feature of the system.....

Another thing I have done is to ask different AI if they would give me a formula for heating and a formula for cooling using this data:

Current: External temperature. External humidity. Wind speed.

Forecast 3h: Outside temperature. External humidity. Wind speed.

Room: Current temperature. Target temperature.

Factors: Housing insulation level: 0-10, in order to be able to set several. Outside influence on the calculation: 0-10, so that several can be configured. Room influence on the calculation: 0-10, so that several can be configured.

Let's say that this could be as complicated as we want and the more data we have, the more optimal it will be...

Well, sorry for the talk... We are still working on it!

Thanks, Oscar

wrongisthenewright commented 1 month ago

This topic for computation temperatures discursion ;-)

Now, in cooling mode I have not found in the document the formula that applies. I understand that it cannot be the same as the slope configured has nothing to do, in the case of heating it goes from 0.2 to 1 and in cooling it goes from 0 to 30. They are very different values and I think that the same formula does not support these variations:

I was wrong, you're right, the cooling curves are different from heating.

these came from Italian manual low temp (fancoils) and high temp (underfloor cooling)

image

It's obviously an inversely proportional slope with imposed limits (limits btw that are function of the chosen slope) , the formula should be:

Tset_cooling = T_mand_min + SL/100*(40°C- Text)+OF.

So if you're on underfloor config, with a min temp of 18, no offset, slope 5 and ext temp of 30°C the value is: Tset_cooling = 18°C + 5/100*(40°C - 30°C) + 0 = 18.5°C

in case of fancoil config, with a min temp of 7, no offset, slope 25 and ext temp of 30°C the value is: Tset_cooling = 7°C + 25/100*(40°C - 30°C) + 0 = 9.5°C

Both values matches the graph.

It may be as you indicate, the point is that to simplify everything I have the offset parameters set to 0.

OK, this simplify the calculations, but the offset are there for a purpose, so you'll need to take them into account if you'll need to use them.

Finally, I believe that by simply applying your formula and making the temperature delivery fixed, we are losing some feature of the system.....

Choosing the right algorithm is not a matter of losing features, is mostly related to cost/savings and overall system configuration, in my case, given my needs and my home configuration I use a different configuration for cooling and heating.

In winter (heating) I use full automatic calculations with external and ambient probe. Having an hibrid system, once the energy manager has all the parameters chooses the LWT and then chooses to use either the boiler, the HP or both to get that temp, all based on the energy tariffs I inserted. In this way I always get the max savings in every instant.

In summer (cooling) I use a fixed temp configuration at the lower temp possible (7°C). If I'd have chosen the automatic calculations I may have had some extra saving because the HP could have run at lower frequencies (HP tend to perform better in term of COP/EER in the middle range of functioning frequencies), but I don't mind losing some KWh here and there because I have a PV and battery systems at home , so in summer I get my electric energy for free from the sun.

Please also be careful that the algorithm for LWT is only part of the equation. What you have to keep in mind is that HVAC systems treat thermal energy, not temperatures. There is also EWT to keep track of and the delta from LWT and EWT is proportional to the transferred energy. You can convey the same amount of energy with different medium (water) temperatures. You can heat an home to 20°C with the water at 40°C or with the water at 60°C, it depend on the thermal inertia of the home, the amount of water that flow (more water flow usually means more energy transfer) the exchange surface between water and air etc..

In heating keeping the LWT as low as possible is usually better for energy efficiency: for HP it means lower operating frequencies and thus better COP (the Nimbus COP can varies from 4/5+ at mid range to 2/3 at more than 60Hz). For boiler (at lease condensating ones) enhance the thermal energy recovery from exhaust fumes.

Another thing I have done is to ask different AI if they would give me a formula for heating and a formula for cooling using this data:

Interesting, but let's also take into account that the heating system of a home is one of it's core features. Commercial HVAC products may be overpriced and lacking some "finesse" but these are embedded system tested and mantained by professionals. I wouldn't leave the comfort of my home in the hand of a DIY algorithm that may run on an off the shelf HW that breaks down in the middle of the winter because some nerd put out the wrong update.

I'm into home automation allright and my being here it's a proof of that, but my heating is solely managed by the Ariston thermostat, the calculations made by the machine and my only intervention (apart from gathering metrics for reporting) is limited to change energy tariffs based on my contracts and PV production in winter.

wrongisthenewright commented 1 month ago

Hello Oscar,

Finally, I believe that by simply applying your formula and making the temperature delivery fixed, we are losing some feature of the system.....

Sorry I was pondering on other topics and came back here...if you're referring to losing feature of the system by forcing it to accept you externally calculated temps I don't think you'll lose anything. If the system accept your calculated temp (you can check it in par 17.14.1, I think) then every other aspect is derived from there and, obviously, from the other parameters like tipe of modulation for the pump, silent mode etc.

If the system is forced (by your writing messages) to reach a target temp that you send, then the machine set the compressor frequency to go there, the pump modulation follows along etc.

As I wrote before I don't think it's wise to do so, in my house I'd prefer to have the sensys thermostats for all zones placed in the appropriate rooms (the colder in winter and/or hotter in summer) and start from there, then I'd put in the various rooms without sensys some mechanism to shut off the heating/cooling for that room if need be, as an exampre closing an actuated valve or shutting off the relative fancoil, but that with a phisical, dedicated and purpose built thermostat, not an ESP with a temp sensor. In this way the system can run autonomously, without fear of losing something for a bad firmware upgrade.

ogkita commented 1 month ago

Hi @wrongisthenewright

Sorry I was pondering on other topics and came back here...

Don't worry, I got off to a bad start with the topics ;-)

Tset_cooling = T_mand_min + SL/100*(40°C- Text)+OF.

So if you're on underfloor config, with a min temp of 18, no offset, slope 5 and ext temp of 30°C the value is: Tset_cooling = 18°C + 5/100*(40°C - 30°C) + 0 = 18.5°C

in case of fancoil config, with a min temp of 7, no offset, slope 25 and ext temp of 30°C the value is: Tset_cooling = 7°C + 25/100*(40°C - 30°C) + 0 = 9.5°C

Thank you for clarifying the cooling formula. Now I have 3 external temperatures (weather, external probe and hp), for T_mand_min = 18, your formula result is:

27,8 18,60 28,5 18,60 29,5 18,50

and I can see the computed temperature is in all zones 18.6 °C. Makes sense.

I still don't understand why the setpoint in the heat pump is 16.6, as I have all offsets at 0, or so I think. I have also noticed that this value changes if one zone or several zones are working, it must apply some "factor" to avoid that if there is a lot of demand the system is not efficient...

Sorry I was pondering on other topics and came back here...if you're referring to losing feature of the system by forcing it to accept you externally calculated temps I don't think you'll lose anything. If the system accept your calculated temp (you can check it in par 17.14.1, I think) then every other aspect is derived from there and, obviously, from the other parameters like tipe of modulation for the pump, silent mode etc.

If the system is forced (by your writing messages) to reach a target temp that you send, then the machine set the compressor frequency to go there, the pump modulation follows along etc.

I will start by applying the algorithm to the fixed temperature and see how it differs from the Ariston computed.

As I wrote before I don't think it's wise to do so, in my house I'd prefer to have the sensys thermostats for all zones placed in the appropriate rooms (the colder in winter and/or hotter in summer) and start from there, then I'd put in the various rooms without sensys some mechanism to shut off the heating/cooling for that room if need be, as an exampre closing an actuated valve or shutting off the relative fancoil, but that with a phisical, dedicated and purpose built thermostat, not an ESP with a temp sensor. In this way the system can run autonomously, without fear of losing something for a bad firmware upgrade.

The problem is my installation. I have:

Zone 1: Thermostat 1, commands over TA1 Zone 2: Thermostat 2, commands over TA2 Thermostat 3, commands over TA2 Zone 2: Thermostat 4, commands over TA3 Thermostat 5, commands over TA3 Thermostat 6, commands over TA3

Ariston thermostats only support one thermostat over 1 zone, in my installation I need several thermostat over 1 zone...

Please don't ask me why this is so, the installer let me know at the last minute and I had to find my own way to get something decent. ....

I have recently contacted Ariston to see if they have "solved" the problem and I am still waiting for a reply. I don't have much hope for it.

ysard commented 1 month ago

In this way the system can run autonomously, without fear of losing something for a bad firmware upgrade.

Well, you know, there are a few (BTW rare and underpaid) people who know how to develop tested and reliable firmwares :grinning: :satisfied:

wrongisthenewright commented 1 month ago

In this way the system can run autonomously, without fear of losing something for a bad firmware upgrade.

Well, you know, there are a few (BTW rare and underpaid) people who know how to develop tested and reliable firmwares 😀 😆

In Italian we say “presenti esclusi” that means something like I was speaking in general and not referring to someone “present” here :-D

ogkita commented 1 month ago

Yes, everything has its advantages and disadvantages... Having everything integrated in one place means that you can manage everything from one app, all "things" talk to others.

The issue in updates... it doesn't have to fail, but tell that to MS... ;-). In any case, having a good backup/restore plan and doing only critical or tested updates is a good option. Here we say "if something is working do not touch" ;-)

I like to have always a plan B or C with less "domotic" or even manual.

ogkita commented 1 month ago

Regarding temperature computing... ;-)

Things I have seen in cooling mode that I think also applies to heating (zone 1 parameters only and applies to all).

When you use thermoregulation 1, fixed temperature.

You set parameter 7071 with the temperature you want (using whatever data to calculate it) and the system automatically sets that value in parameter 6197.

When using thermoregulation 2, External probe

The system ignores parameter 7071 and automatically calculates and sets that value in parameter 6197.

In other words, in the end the system has the values in the parameters 6197 6297 6397 and with these it calculates the parameter 6047.

Computation of parameter 6047.

1.- 6047 = The minimum value of 6197 6297 6397. 2 - Apply configuration of menu 7.3.0. 2.1- If 7.3.0>0. 2.1.1 Fancoils. 6047 = 6047 - menu 7.2.1 (I think this is parameter 7f2b). 2.1.2 floor cooling. 6047 = 6047 - 2 - menu 7.2.1 (I think this is the parameter 7f2b) 2.2.- If 7.3.0=0 2.2.1 Applies an automatic "computation" based on the number of zones are demanding and the type of zone management module (MGZ).

Now I research what happen with LWT, I thing this value is 6047 param with some computation..., maybe the system is using here delta_T???

If the system accept your calculated temp (you can check it in par 17.14.1, I think) then every other aspect is derived from there and, obviously, from the other parameters like tipe of modulation for the pump, silent mode etc.

You are right, it seems to be all about the XXX parameter 6047...

wrongisthenewright commented 1 month ago

Regarding temperature computing... ;-)

You set parameter 7071 with the temperature you want (using whatever data to calculate it) and the system automatically sets that value in parameter 6197.

I agree on this, similar approach should be detected on heating, only 7071 became 6571. I haven't made any test so I don't know if the system applies to this value the HP "general" offset and the specific zone offset.

When using thermoregulation 2, External probe

Or External+Ambient probe for that matter

The system ignores parameter 7071 and automatically calculates and sets that value in parameter 6197.

Yes, it calculates 6197 as the minimum of the various zones, in heating the reverse is true (the maximum of 6571,6572, 6573)

Computation of parameter 6047.

I think the "formula" is like this:

6047 = min (6197 +/- 7571, 6297 +/- 7572, 6397 +/- 7573) +/- 7f2b

calculate the target for each zone, applies the specific offset, detect the minimum for all zones then applies the "general" offset.

Now I research what happen with LWT, I thing this value is 6047 param with some computation..., maybe the system is using here delta_T???

*edit: in my prevuois reply I confused LWT and EWT.

the machine tries to keep LWT at the value of 6047, see graph below, is my HP in cooling mode this evening

image

orange line is 6047, blue line LWT. as you can see the LWT goes below 6047 then the machine lower its frequency and the line goes up again (the fancoils are heating the water with ambient air to lower the ambient air temperature), when the LWT goes ovr the 6047 line then the machine crank up the frequency again to lower LWT, and so on. The "saw line" aspect is due mostly to my FC meeting their setpoint and thus shutting off, then starting again after some minutes as the ambient air goes over the setpoint again. During heating season where I apply the fully automated algorithm (and where my underfloor heating stays on for almos all day) LWT is almost always perfectly matching 6047 line. On the right of the graph, around 22,00 I turned off cooling, the 6047 goes to the default value of 58°C and the LWT probe measure the temp as it inexorably tend to align with external air temp (LWT probe in my HP -monoblock- is in the external unit).

wrongisthenewright commented 3 weeks ago

Only to report that I think I've found the reasons behind the 3 different ext temps:

the HP internal probe is mandatory, it is used to calculate when to do the defrost in heating mode. Par. 16.9 of the professional manual shows the algorithm; given that in some installation the HP can be used without internet and without external probe this is the only way the machine can calculate when do the defrost

external probe, if present is used to do the target temp computation, but, i think, not the defrost

in apsence of external probe internet weather temp is used to do the target temp calculation, also in this case i think it's not used to decide on defrost (eg. resource temporarily unavailabe/ false reading)