Upgrading the heatpump to FTC6

What was the existing system

Our Mitsubishi Ecodan PUHZ-HW140VHA2-BS 14kW heat-pump was installed in 2011 with an FTC2 control unit when this house was built.

Upstairs and downstairs heatmiser UH1 manifolds are controlled by room thermostats, these are connected together using an RS485 bus. The PC software provided by heatmiser turned out to be written for a 32bit Windows 7 PC and required an ethernet to RS485 bridge to work; this never worked satisfactorily, so when I redeveloped the home automation system in 2017 I included server software to interface to Heatmiser's specification. This enabled schedules to be set for the room thermostats. Room thermostats provided a means of controlling when the heatpump runs.

Over the years a schedule for running it has evolved, based on very little information and control via heatmiser room thermostats.

Hot water was controlled via a conventional time-clock programmer as with a gas boiler.

The remote control unit, which includes a zone thermostat was installed next to the heating cylinder where any temperatures measured were useless.

What was the replacement

Towards the end of 2024 the HP installer was presented with a requirement to:

• Have heat generation (and electricity consumption) available digitally so that it could be logged.
• Provide better control over hot water.
• Control the system digitally.
• Move the remote control unit to a useful central position (main room).
• Consolidate all mains circuits associated with the HP on the same circuit (so that electricity measurement includes all controls).
• Provide digital information about the solar hot water system.

For further information about the technical detail of the installation see heating upgrade

An upgrade to a Mitsubishi FTC6 controller was suggested, which was taken up. Most users would probably have gone for installing an interface to MelCloud, which enables control via a phone app. I didn’t do this as:

• Cloud servers have a few weaknesses so are avoided:
  • Do not work if broadband fails
  • Dependent on manufacturer to continue support.
  • Each manufacturer follows different standards
  • Unknown (hidden) energy use
  • Prone to attack from bad actors
  • Just way over complicated for storage of simple sensor readings.
• It would prevent a direct data feed.
• All home data in a single system, rather than a proliferation of apps.

A MODBUS interface is available which was fitted instead, this gave the opportunity to either:

• Fit a third party unit with its own cloud based software (the fallback position)
• Write a MODBUS interface which publishes data to an MQTT broker. (MQTT has been adopted by many home automation systems).

The result is that I have been logging Modbus data to a Questdb database since late november. Since then daily graphics have been available to see how the HP is performing.

What has been learned?

• Controlling the HP using using room thermostats leads to cycling which reduces heat output and still uses a similar amount of electricity. So I am now setting room thermostats in main rooms well above what is likely to be reached, relying on the flow temperature setting in the HP, which is on Weather Compensation.
• HP gives enough data to calculate heat loss rate and degree days.
• There is little point in trying to heat difficult to heat rooms (lean-to and main bedroom) outside the main schedule.
• Ideal heating periods are long and unbroken.

Example Good Heating session

The table to the left shows summary analysis of 25 hours starting at 23:00 on 14th Jan. and ending at 00:00 on 16th Jan. This covers 15th Jan completely and includes the end of the previous day because cheap rate electricity is available from 23:30

The summary table at the top shows:

• Space heating - heat produced, electricity consumed, COP being the ratio of these
• Hot water - heat producedm electricity consumed and COP
• Unaccounted - Electricity reported as consumed by the heatpump when it is idle (currently some of this is suspected as a measuring error)
• Degree Days - Heat produced divided by the mean difference between room temperature and ambient temperatur
• Hourly Heat Loss - Heat produced divided by time
• Hourly Heat loss rate - Heat produced divided by time and the mean temperature difference
• The Detail table button reveals a table showing details for each heating session
• CSV Detail shows the same as detail table, but in a csv format which pastes well into a spreadsheet

The graph below shows:

• Red line shows heat power in kW
• Blue line shows electrical power consumption in kW
• Solid yellow shows space heating periods
• Pink and purple show hot water periods (purple shows where these are forced).

Continuous heating session

Here heating runs continuously between 23:30 and 05:30 (taking advantage of Octopus IOG). Ambient temperature between 6 and 8 C, flow temperature between 32.5C and 36C. Hot water heating follows on directly from other heating so there is no initial temperature drop and a reasonable COP of 2.5 is achieved

Example Bad Heating session in cold weather

Here the ambient temperature at night was 0C and it was cold all day. The flow temperature was higher (see table above) Heating sessions later in the day were triggered by the lean-to and main bedroom temperatures dropping below their room thermostat settings.

The flow temperature seems to hit the flow temperature set point and cause the HP to shut down for a short period before starting again. To what extent does this reduce COP? Note that the good session had a heat output of 41kWh, whereas the main session here had 58kWh.

In high temperatures

Example from 5th December before electricity readings were available, with ambient temperature 12C shows cycling with flow temperature 29C. About 27kWh of heat was produced.

What didn’t go so well

Initial software development

This is being written up separately, as it has had its fair share of issues, which are not relevant to a HP interest.

Electricity Readings

I had thought that simply installing a split core current transformer (CT) to measure current, and from this power and energy would be good enough. This has been fraught with problems:

• Software problems prevented electricity readings from working until Jan 5th.
• Though electricity whilst heating is credible, an idle current of about 1.1A is reported, at first this was thought to be a software issue. But I have now measured it with 2 alternative methods:
  • Efergy E2 meter borrowed from TECs
  • True RMS Mini-clamp meter
  Also I have used this CT on other circuit and it roughly matches readings from the others.

There is space in our consumer unit for a direct meter on the HP circuit, (the circuits used previously for CCTV and FTC2 (hp controller) are no longer used), these slots could accommodate a DIN rail direct meter, with MODBUS interface. This may (or may not) give different readings.

Hot Water

It is disappointing that the FTC6 doesn’t support timed based scheduling of hot water, but it does have a Force DHW flag, which turns on water heating, but it won’t turn off until its target temperature is reached. This has just meant that a scheduled job has been written to ensure water is heated at 4:30 which is in the middle of the heating schedule, and also fits the electricity tariff.

What next

1. Fit a MODBUS electricity meter to the HP supply.
2. Change lean-to and main bedroom thermostat schedules to avoid low efficiency heating.
3. Build an insulated box around where cables emerge from floor in lean-to - known to be a big heat leak. Can thermal mass be added? E.g bricks?
4. From forecasts available from OpenWeatherStation produce a daily heat requirement forecast, which can be used to schedule the HP.
5. Ensure that flow temperature control can be automated reliably.
6. Determine the best flow temperatures to use in higher temperature situations (suspect this is about 30C), and use the forecast to determine a shorter heating period.
7. Determine the best flow temperature to use for high temperature situations.
8. The RESOL/VELUX solar thermal controller has also been replaced with one with a VBUS feed, which needs interfacing to the TM4C board. An ethernet convertor is available for this (£200), but a fairly simple circuit can be built to convert to TTL serial levels which can then feed the TM4C directly. This will provide information about solar water heating mainly in the summer. It will also provide temperatures at the top and bottom of the hot water tank.