post some logging, it’s a lot colder in europe and the snow isn’t helping. Enable smart boost, it should help a bit. But I need more details from logging
Seems like it caught up, maybe just needed time to adjust. The night was also really cold at about -25c
@gekkekoe Just a quick question: what temperature is the setpoint actually setting (in my case with parallel buffer)? I guess it’s one of the feed temps, but is it “Feed Temp” or “Z1 Feed Temp”?
Because from what I understand when heat compensation curve is active and THW6+7 sensors are present, is that the FTC adjusts the feed temp in the primary circuit in such a way that the setpoint is reached in the secondary circuit (which would be „Z1 Feed Temp“).
Thanks
Hi, I just tried this project with my Ecodan (Zubadan) Mitsubishi split-system heatpump 10kW. Installation on an M5stack Atom S3 went just fine, I found a prefabricated cable on Aliexpress. The software was compiled from the yaml template on github with the options for ESP32-S3.
The unit connects and shows all values just fine. I have just one thing that keeps me scratching my head: I can’t get my remote thermometer to integrate. I have a PAR-WT50R-E in my living room that connects via the matching remote receiver PAR-WR51 . The FTC-6 is configured to use the temperature of the remote thermometer for room-temperature. This works just fine with Melcloud, the room is at 20°C and the heatpump runs just fine.
When I attach the S3 instead of the Melcloud adapter, the setting to use the remote thermometer is ignored, instead the unit shows 14° - that’s the temp in my basement where my indoor unit is located.
On the FTC-6, I see 20° from the Remote temperature, MelCloud also shows the room at 20°. On the ESP, I see 14°, that’s the local temperature where the FTC-6 is located in the indoor unit:
I tried to switch the temperature source to HA/Rest API because it’s using the same connector, but I do still see the 14° temp from my basement room.
Do I really need to get a second ESP32-S3 and connect it to some other room temperature source? I would prefer just to keep the stock remote unit from Mitsubishi.
Fwiw, my setup has a mixer and only one circle, too. It‘s what every shop builds by default because the planning guide from Mitsubishi always advises to have a tank. There are some people on a german forum who built the pump without a tank and in a design with radiators they do generally run into issues because the water mass is too low and they get too many cycles, especially in mild temperatures.
Hello everyone,
when I see your graphs, it really makes me want the same, because at my place I’m experiencing some strange behavior and significant defrost cycles. I don’t understand why — maybe a setting issue?
If you could help me, I’d really appreciate it. Thank you.
It seems I can’t get rid of these warnings. It constantly circles between a high and low setpoint. I really don’t think that receiving capacity is the problem here.
Why is the algorithm setting a heat flow temperature (12:28, 28°C) lower than the actual feed temp (which is the z1, the one going into my ufh) (29°C)??
For comparison: this is a course from yesterday, which was fully set on heat compensation curve:
Set-point was around 32/32,5°C.
@ulfish I think your that you should need around 29c, but your buffer tank return temp is too high. You should post graph of actual feed temp , actual return temp at the heatpump.
I use z1 feed/return to calculate temp, but I don’t think its working out for you. We probably need to use the main feed/return temp for buffer tank systems.
@mat0408 I don’t know where you live, but currently it’s defrost weather in most places in europe
@top_gun Did you follow all the step ? GitHub - gekkekoe/esphome-ecodan-remote-thermostat
If configured correctly the RC thermostat value should be reflected on the CN105 thermostats.
You can use the standard mitsubishi wireless thermostats, a lot of folks use them with my software.
So another mixer/buffer tank, hmm
@all ppl with buffer/mixer tank and single zone, try this build and report if its working better Release 2026-01-09.01 · gekkekoe/esphome-ecodan-hp · GitHub
This is what I get with the latest build from yesterday:
Temperature increases until it hits the 38°C max heating limit. … which seems quite high ![]()
These are feed and return from the UFH circuit:
and graph with set-point:
I really don’t understand the logic here. In my previous post you could see that the setpoint was always lower than the feed temp for heat compensation curve mode.
However, when using AA the setpoint seems to directly set the feed temp (going into the buffer).
So, what temperature is the setpoint actually setting, see my previous question:
Would it make any difference if I connect a remote thermostat on CNRF?? I remember you said, that this would give me the stopping condition…
Hmmm, at 15:30 I switched to heat compensation curve. Setpoint switched to about 32°C. But temperatures are very similar…
I think your issue is that you reached setpoint, heating should stop. Then I switch back to min delta T (since we reached setpoint). You could try setpoint bias of +0.5 or +1.0 , then it should be ok.
Do you have a stop condition ? ( A wireless thermostat or thermostat wired to in1/in6)
Is this just plain thermal inertia?
No, I don‘t have a wireless thermostat or anything wired to in1/in6 !!
What‘s with this??
I thought there is a stop condition…
Ok, let’s take this one as an example:
1.) Room Temp is still lower than target (20.4 vs 20.5)
2.) Actual Feed Temp is 37°C, i.e. the one going into the buffer tank
3.) AA calculates a Flow Temp of 32.9°C (which is probably the rounded value of return_temp (29°C) + target_delta_t (3,9°C)
4.) It recognizes that this flow temperature is 4.1°C lower than the actual feed_temp of 37°C and adjusts it to 36.5°C.
5.) On top comes that I’m limiting the flow (of z1) to 31°C.
In this example there is no problem of a missing (still to be clarified if it’s really missing) stopping condition.
I still have the feeling that the problem is inside the calculation of AA. Either the target_delta_t is way too low for buffer systems or the calculation has to be some mixture of the primary and secondary circuit temperatures.
Anyway, I don’t know what to do anymore. Close to giving up, which is a pitty, because your Vrekkie-Solver also depends on the usage of AA, right?
@ulfish
yes it is. btw what thermostat are you using?
So normally with buffer tank it works like this:
- thermostat detects demand, and triggers z1 water circulation pump
- this draws heat from the buffer tank, when buffer tank is below certain temp, the heatpump starts refilling it (start actual heating)
in your case:
- actual feed temp is 37
- current room temp 20.4c, room setpoint 20.5c
- is the 29c the actual return temp or z1 return temp?
calculated feed temp is 32.9c, but gets corrected to 36.5c. This is done because when you set a flow temp 1.5c below actual feed temp, the compressor stops.
When you are 0.1c from setpoint, the “error” is only 0.1. The algo will use the lows of your delta T bandwidth. You can see what it does in the simulator Delta-T Flow Calculator
So the issue is that, yes we still need heating, with flow temp of 32.9c but cannot set this value because of the higher buffer tank current temps. If I disable the flow temp adjust, then you will get short cycling.
The system will work fine, since it prevents the compressor from stopping, and it should stop when setpoint has been reached (stop condition). Your thermostat then should tell the heatpump that. heating should stop and the circulation pump will stop.
It’s just that the warnings are annoying, but are actually preventing you from short cycling.
But you are using the latest build ? It should use the actual heatpump feed/return, i would expect that it would have been a lot better? (Release 2026-01-09.01 · gekkekoe/esphome-ecodan-hp · GitHub)
I need to think if there’s an solution for this. We could disable flow adjust when detecting single zone + buffer tank for example
I’m only using those wall-mounted thermostats that control individual room circuits. So, nothing on in1/in6, nothing on CNRF. For AA I use the Aqara W100.
The 29°C is the actual return temp from the heatpump.
Yes, it’s the latest built.
Why can’t the algo do it like the heat curve does:
adjust the feed temp in the primary circuit in such a way that the setpoint is reached in the secondary circuit (which would be „Z1 Feed Temp“)?













