Given there might be a few of us now looking down this route because of the current MelCloud issues would someone like @Dan_Nichols be able to give a very simple set of instructions for getting this set up.
The instructions on GitHub are understandably trying to be product agnostic but a list of exactly what to buy where and how to put it together (with some photos) and how to set up code would make it easier for anyone new.
Also I’m assuming there would be no way to connect both the MelCloud dongle and local CN105 controller? I guess there is a danger of messages conflicting between the two or voltage level issues?
There might be reasons to still want to use MelCloud as well, the main one for me at the minute is to allow Mitsubishi to look into my hot water heat up issues.
@ajdunlop I will make some time to provide as much detail as I can. It’s one of those that I would describe as daunting until you’ve done it (if you know what I mean). I’ll start by providing a list of required hardware and follow up with some instructions/pictures of one of my assembled modules (warning its not a consumer level finished product!).
I’m the maker & seller, I made my own based on the ESP8266 because:
A) Limited availability of official WiFi unit for my FTC5 or at a reasonable price
B) Avoid relying on MELCloud
I made it available on eBay to those who don’t want to have the hassle of sourcing hardware from China, make up cables and then wire up to a microcontroller.
So nice pre-fab device in a 3D printed case.
Polling of the heat pump itself is every 1 minute and also when a change is made. It then is published to the MQTT topics.
The Read/Writing operation takes about 10s over the CN105 connection and the data available isn’t very high accuracy so it seemed a sensible interval
Serial communication is likely to become unreliable and corrupt with multiple devices trying to use it at the same time.
It’s like trying to send two trains down the same track, sometimes you might be lucky and one makes it successfully without crashing into the other.
The more often you despatch a train, the more likely they are to collide.
Could you have something with two sets of UART pins to run Ecodan2MQTT(made up name) that sits in the middle between CN105 and the MelCloud dongle. All TX from the heat pump would be processed by Ecodan2MQTT and also passed through to the MelCloud dongle. Then messages going the other way back to the FTC could be controlled to avoid clashes.
I have very little idea about how this all works and what hardware you would run it on (I assume all ESP32s would only have one set of UART pins)
The ESP32 chip has 3 UART controllers (also referred to as port), each featuring an identical set of registers to simplify programming and for more flexibility. Reference here
I’ve been reading this thread along with others where people have HA-based or home-brewed monitoring for a while with interest. It’s a long while since I did any electronics and it is taking a while to build up my confidence to tackle this.
I’ve been googling a lot more over the past few weeks trying to increase my knowledge before I begin to plug anything into anything else, and I have come across CN105 splitters, though they are in the American HVAC market where the split units all have CN105 connectors. There are a number of sites where the Wemos D1 mini is being used (as it can be tucked into the tight space) to provide individual room control using HA – this looks like the path that Fp1 has gone down, and good luck to you providing this as a pre-built option.
I’ve had an ESP32 board and expansion board for several months now waiting for me to attach a bunch of DS18B20s, and a couple of flow meters in the solar thermal pipework - I had added the intention to read the HP’s flow meter which was mentioned in a few forum posts here a while back, and now I am adding reading the MelCloud data stream to the list.
I found this forum post Mitsubishi Ecodan CN105 poort uitlezen (via ESP8266) - Modding, mechanica en elektronica - GoT where one user looks to have made a board which accepts the CN105 connection, and passes the signal to a ESP32, but also passes it through to the MelCloud wifi dongle. The forum is in dutch and google translate seemed to struggle with it so plenty isn’t quite clear to me. But it seems like it should be possible to have your data and send it. There are a couple of photos and a rough schematic, though these both show three sets of connection pins for some reason I haven’t fathomed yet.
There isn’t any encryption between the CN105 and the end device, but it may encrypted from the WiFi unit to MELCloud.
On the Dutch forum link above it appears that the ESP is tapping the communication between the CN105 and the official MELCloud dongle (mentions it being a monitor device)
No write/control aspect is mentioned.
It’s certainly possible to do this, if you only want read via MQTT
I’ve ordered one of your units Phil to have a play. I’ve started my journey to a cascaded Ecodan system by creating a single system cascade (with two controllers) so I can evaluate how it works and the monitoring/control options (two CN105 ports on that system now).
It should be possible to just buffer the data from MelCloud and relay it to the FTC, if there is no polling going on by the ESP its simply read a byte on one port and write it on another and if currently receiving a packet just buffer the incoming data until FTC is done sending. Unless the proprietary interace has a very strict timeout that should be pretty easy to implement.
But why the want to keep the proprietary interface? Is there some legal requirement? At least one type of these MelCloud controllers that I found a firmware dump for uses a chip with an from what I have gathered unpatched flaw that can be used to get access to your network, although only through wifi.
Reverse engineering it didn’t really go that far as it was mostly RTOS code and the interesting parts were loaded from either another bank of flash or external flash
Does the contract say via Melcloud? I think it’s left up to us to negotiate with our MMSP provider, which isn’t Mitsubishi, but I’m busy elsewhere so haven’t checked our contract yet.
Very clean and simple hardware solution with the Witty ESP8266 powered by 5V and with 5V GPIO pins (no voltage level changer required).
Nice and compact design to the case too.
Installation is a five minute job if you are comfortable/compentent to shutdown and isolate the controller power before removing the front panel. WiFi and MQTT setup is straightforward provided you are familiar with these technologies.
Couple of initial thoughts which may help others;
The project it stands today supports one ASHP per MQTT instance as the MQTT path is hardcoded to ‘Ecodan\ASHP’ which is fine for me testing with one unit. Code changes would be needed to add a second ASHP.
The project isn’t currently written to support Home Assistant’s MQTT integration out of the box. Manual MQTT sensors etc. could be defined in YAML using the current MQTT paths or the project could be extended to support MQTT automatic discovery MQTT - Home Assistant
@F1p let me know if I’ve got any of the above wrong.
Great summary i think and glad to hear about your experience, you make some excellent points.
A few to add based on other feedback too -
On setup, if you make a mistake on your MQTT settings the instruction sheet doesn’t mention the unit serves the settings webpage when connected to WiFi where you can make changes.
You are correct about the MQTT path and it wasn’t something i had considered - it’s something i will implement based on your feedback
Correct about using configuration.yaml, which examples are provided to just drop in, but as you say at the start - this is providing you are familiar with these technologies
@jamespreedy who has also installed one of your units has kindly shared his MQTT template which has helped me get some data into Home Assistant without spending hours writing YAML (makes my head hurt).
I noticed that you’ve implemented wifiManager and the website is available once connected to the home WiFi, useful if I need to re-configure WiFi or MQTT. I also spotted that you have implemented a virtual serial interface over telnet, could be useful for logging etc. but also nice to have the option to disable when not in use.
I have also learnt something about my single unit cascaded Ecodan system since installing your unit. I can now retrieve slave unit specific system data such as flow rate, compressor frequency etc. which is not available from the master unit in a cascaded configuration.
. I’d happily have a go but I’m very much a C/C++ novice and I suspect my Ecodan’s will need replacing before I’m finished!