What FTC software version are you running?
This is the info I have in HA, are you referring to something more specific for the FTC6?
In case can you suggest how I can check it up?
esp32-s3-devkitc-1
da Espressif
Firmware: 2024.8.3 (Sep 20 2024, 13:42:42)
It’s service code 190 in the FTC controller menu, I think it’s available in the latest version of code from github
Thank you, I get 1301 as answer,
Very old version, on 20.01 I believe for FTC6 now
Perhaps contact installer/Mitsubishi to request an update because of this behavior
I don’t have release notes for the different versions
Will do, thanks!
Any chance I can do it myself?
i ve been running in proxy mode for 3-4 weeks now with and m5stack atom lite. all perfect. thank you!
1 Like
Got in touch with the local assistance but they ask for 150 euro just to update the sotware… I guess I stay with the old one 
Is it ok to be that expensive?
Shouldn’t the installer update the software as they install the machine (for free) if it was alredy aboslete like in my case?
I lurked around these forums about a year ago when I got my Ecodan installed. I’m so impressed, having switched out MelCloud Wifi integration for @F1p 's hardware on Friday.
I’ve already got the system running a HA driven weather compensation curve with offsets by writing target temperatures in Flow Temperature mode, which has been a (very lame) dream for a long time.
The ultimate idea is to multiply the weather forecast by agile rates for a predicted £/kWh_heat across the coming day and to optimise the system off that - though my coding skills are going to have to get a lot better before that becomes a reality (unless someone else is already doing it?)
For now I’m just dropping the thermostat during the most expensive 4 hours, catching the 4-7 peak and an extra hour, which is sometimes advisable when power prices are spikey and ambient temperatures consistent. In days with 0-10 C swing range, I’d ideally be riding through short price spikes at lunch time.
I’m getting stuck on a few debugging queries though:
-
The HA thermostat card that auto-installed (zone1) always shows as “off.” It still reads/writes to the wireless thermostat over the RF allowing call for heat, so in effect it’s working, but is this normal behaviour? The “Ecodan ASHP Zone 1 Working” flag is always off as well. I’m running a single zone system.
-
I can’t seem to plot any of the data in the statistic history cards. I’ve given them a “state_class: measurement” attribute in Dev Tools, but it seems to wipe itself in a minute or so. Is there an elegant way to do this, or do I clone with a template sensor?
-
Will “Heating Flow” mode accept 0.5 degree increments? “ASHP - Manual Flow Setpoint” seems to be rounding to the nearest degree when automations write my targets across.
Hey David,
- No it isn’t normal - In the logic the Zone2 current temperature needs to be “0” (none connected) to tell the device/home assistant that it’s a single zone system - can you check if that is the case or did you remove the zone2 climate because you don’t have one?
In addition, the “zone x working” flags are only changed in the FTC for 2 zone users (Thanks Mitsi)
- What entity do you want to perform stats/history on - there are some challenges when doing this with CoP for example. You can do this in configuration.yaml like so:
- platform: statistics
name: "ASHP Weekly DHW CoP"
entity_id: sensor.ecodan_ashp_dhw_cop_yesterday
state_characteristic: mean
unique_id: ashpdhwcopweekly
max_age:
hours: 168
- Yes, by writes to the Number entity
I doubt it’s the problem but I think I remember seeing a setting in the controller menus that would round the set point to the nearest degree. It might be worth checking that that is set to allow half degrees steps.
Possibly. It’s still rounding. The number entity is returning to original settings on updaye. I’ll have a look at the weekend. Number entity also allows set to 60C, despite other sensors reporting being limited to 40C. This might be due to other stuff I deactivated - I’ll continue to play with it.
Thanks @F1p - zone 1 working properly now. I will be less liberal with my deactivations in future!
Stats - I’m just going to stick with standard histories, I think. I mostly use stats histories because it makes for prettier graphs. 
Is it possible to use this solition to switch between heat pump and electric booster heater operation? I currently have to manualle switch modes every night during winter due to noise.
I have a Ecodan EHST20 indoor unit with FYC5. Air to water.
1 Like
The number entity is returning to original settings on update
To just get some clarification - you mean when you write a 0.5 value, the FTC reverts it - where whole numbers are ok?
You can open a telnet connection to the bridge with a program like putty and observe the inner workings:
The value is being written to the FTC as hexidecimal * 100
1 Like
Thanks to @F1p for assisting I put in place the server mode and created the following 2 automations to manage the time slots for both DHW and heating/cooling.
The scope is: prohibit cooling in autumn/winter and enable heating; prohibit heting in late spring/summer and enabling cooling in both zone 1 and 2.
DHW must run on speific time which depends on season 1 or season 2 (very small difference).
Holiday mode must exclude DHW when turned on.
Forcing DHW manually must be kept active until the water reaches the desired T (in my case 49,5°C).
Here are the 2 automations just in case someone needs them.
alias: Automazione | Ecodan Server Mode controllo stagionale
description: >-
attiva/disattiva riscaldamenteo/raffrescamento e DHW in baes alla stagione ed
agli orari
triggers:
- minutes: /10
trigger: time_pattern
conditions: []
actions:
- choose:
- conditions:
- condition: template
value_template: |
{{ (now().month == 10 and now().day >= 20) or
(10 < now().month < 12) or
(now().month == 12) or
(now().month < 3) or
(now().month == 3 and now().day <= 15) }}
- condition: template
value_template: >
{{ (now().hour >= 14 and now().minute >= 30) or (now().hour < 12)
}}
sequence:
- target:
entity_id: switch.ecodan_heatpump_server_control_prohibit_dhw
action: switch.turn_on
data: {}
- conditions:
- condition: template
value_template: |
{{ (now().month == 3 and now().day >= 16) or
(3 < now().month < 10) or
(now().month == 10 and now().day <= 19) }}
- condition: template
value_template: >
{{ (now().hour >= 15 and now().minute >= 30) or (now().hour < 13
or (now().hour == 13 and now().minute < 30)) }}
sequence:
- target:
entity_id: switch.ecodan_heatpump_server_control_prohibit_dhw
action: switch.turn_on
data: {}
default:
- target:
entity_id: switch.ecodan_heatpump_server_control_prohibit_dhw
action: switch.turn_off
data: {}
mode: single
alias: Automazione | Controllo DHW con Forzatura e Modalità Vacanza
description: Automazione per gestire il DHW in base a condizioni aggiuntive
triggers:
- entity_id:
- switch.ecodan_heatpump_force_dhw
- switch.ecodan_heatpump_holiday_mode
trigger: state
- entity_id: climate.ecodan_heatpump_dhw_climate
attribute: current_temperature
above: 49.5
trigger: numeric_state
- minutes: /5
trigger: time_pattern
conditions: []
actions:
- choose:
- conditions:
- condition: state
entity_id: switch.ecodan_heatpump_force_dhw
state: "on"
sequence:
- target:
entity_id: switch.ecodan_heatpump_server_control_prohibit_dhw
action: switch.turn_off
data: {}
- wait_for_trigger:
- entity_id: climate.ecodan_heatpump_dhw_climate
attribute: current_temperature
above: 49.5
trigger: numeric_state
- target:
entity_id: switch.ecodan_heatpump_server_control_prohibit_dhw
action: switch.turn_on
data: {}
- conditions:
- condition: state
entity_id: switch.ecodan_heatpump_holiday_mode
state: "on"
sequence:
- target:
entity_id: switch.ecodan_heatpump_server_control_prohibit_dhw
action: switch.turn_off
data: {}
- wait_for_trigger:
- entity_id: switch.ecodan_heatpump_holiday_mode
to: "off"
trigger: state
- target:
entity_id: switch.ecodan_heatpump_server_control_prohibit_dhw
action: switch.turn_on
data: {}
mode: single
I’ve updated the proxy code to be plug and play. So it should be really easy now. It handles melcoud downtime by falling back to the esp automatically.
There’s also a pcb available which makes it really easy to run it in proxy
For more details Proxy HW · gekkekoe/esphome-ecodan-hp · Discussion #70 · GitHub
2 Likes
Hi, what a great job you guys have done!
Read the entire thread and seems like there’s no possibility so far to change heating curve shift nor adjust the flow setpoint, only set room temperature. Or I missed some part?
I have FTC6 v18.01 running in domoticz RPi3B+ with HA_MQTT auto discovery plugin.
Got the HP quite recently and haven’t got the MELcloud dongle and don’t know all the features there.
Is there also some way to get monthly/total consumtion information since domoticz can’t handle daily values. Or i’ll just have to adjust the HA classes so domoticz could be showing effective data.
Thought about buying the modbus converter for it ~200€, since there seems a lot more functionality
The curve temp cannot be set, but pretty much all other modes can be set. Room temp, flow temp,…
Just buy an atom s3 lite for about 10 euros and you are good to go. Melcloud is not needed at all, its only for ppl who really want to keep it.
Forgot to add that I’ve tried rbroker with ESP32 and now F1p with ESP8266 but neither of them showed up in domoticz as flow setpoint. I’m using also external temp sensors for Z1, Z2 is not in use.
I can see and change DHW setpoint, guess there is somewhat different presentation for those sensors in the code. I’ll give it another look in arduino and if i can pinpoint that location for flow setpoint.
I can change also the control mode flow/HC/room/cool etc… in domo. The status was reported correctly on rbroker variant but on F1p status always stays at flow.
You can try to use my solution and configure esphome to use mqtt instead of HA api. See MQTT Client Component — ESPHome
Domoticz does not like the sliders for temperature setting, I have climates for that and should be working (have multiple working reports from users).