Good job guys. I am also very interested just lacking time. You can use the Rx and Tx (from usb) of the ESP8266. connect a diode from the Tx output" Edocan" to Rx input ESP. (pull only to gnd) I use this myself for ESP8266 to RS485 to MODBUS.
Normale there is a resistor between USB TX to ESP8266 RX.
Normale there is a resistor between USB TX to ESP8266 RX.
Hi guys. I stumbled uppon your project as someone mentioned my name on a forum. You guys are doing the same as me and some others started a year ago with the panasonic heatpump. Now a year later we are very succesfull and have a large user community for the project. I'm reading you are facing the same problems we had before. We now even have our own board which can be easily connected to the panasonic heatpump. See https://www.tindie.com/products/thehognl/heishamon-v31-communication-pcb/ And the thing is, this board is almost 1on1 compatible with your mitsubishi heatpump as it seems. It only uses the older esp8266 instead of the esp32 but that would be no problem. Panasonic is even using the same 5 pin JST connector of the mitshubishi ! So, to conclude, if I can help you in any way let me know. I would be pleased to send one of you guys a heishamon PCB with cable so you can test it out (you only need to switch some pins as the pin order is different).
Hi Igor, welcome as well!. That looks impressive what you have made. I make custom circuit boards, but don't know if I will make it for this project. The idea to include temperature sensors is great. I now have a separate esp for that.
@BartGijsbers I mean, you can use the heishamon pcb without a problem when you install the esp8266 code on it (with some minor changes I will provide, we use gpio5 to enable lever shifting mosfets after boot and use serial.swap so we do not need to use the normal tx/rx). If there is a mitsu user near Arnhem/Nijmegen (Netherlands) I will be happy to come over and test this.
Yes this is why we did this in the first place. However the replacing GPIO's after swapping need some special care also or else the esp8266 will not boot up. So GPIO5 is used to enable the mosfets for level shifting after boot. This is also described in the esp8266 hardware design guide page 11 and 12 (https://www.espressif.com/sites/default/files/documentation/esp8266_hardware_design_guidelines_en.pdf)
I am ok to send you a pcb and a cable if you PM me your adres. It however needs a USB-TTL cable to program (or OTA afterwards). Do you have that? Or else I need to program your software first on it so you can OTA update it later.
I am ok to send you a pcb and a cable if you PM me your adres. It however needs a USB-TTL cable to program (or OTA afterwards). Do you have that? Or else I need to program your software first on it so you can OTA update it later.
Ok great, let me know when you want to test. The problem we had with the pana is that they pulled the GPIO15 high (on their side RX while TTL communications state that the TX side (wemos gpio15) is the one who should pull it high and not the RX side). This caused the wemos not to boot while connected to the heatpump so we needed that mosfet enable solution after boot.
Great project guys, much appreciated. I'd like to help out where I can (I'm a professional software developer), but the hardware part is not really my cup of tea. Would anyone care to give some more pointers on that? And if there is any possibility to ruin the heatpump with this?
Welcome Tim. At this moment we have the gateway software running on a "standard" esp32 development board. The next step is to have it run on a standard esp8266 development board (wemos D1 mini). After that we can try if the software runs on the heishamon board. We don't know if we can ruin the heatpump. With setting commands we are very carefully and only write settings which we have reversed engineered. This reverse engineering is done by listening to communication between a melcould interface and the heatpump. Here you can see what we have found so far: https://github.com/m000c400/Mitsubishi-CN105-Protocol-Decode. In my code we have implemented that: https://github.com/BartGijsbers/CN105Gateway-production
Hi @BartGijsbers , I've built a board based on a ESP32 just like you to get started :-) I wanted to double check the pinout on the Ecodan, do you happen to have the color/pinout mapping? My cable has the following cables: red/brown/orange/yellow/green. I've read somewhere that pin1 is 12V?
Also, I'll fork your code on Github to make some changes. I'm using platform.io and it's quite picky regarding C-style forward declarations (whereas the arduino studio works around that in the background).
Alright, I'll use the .ino extension (did not even know that it worked that way!). The colors on the picture on your Github differ from mine, I'll double check it with the connector position to make sure! Would it be an idea to include the platformio.ini so we all share the same config?
Thanks Albert. I will try to make the connection to the Ecodan tomorrow, should not be too hard. Meanwhile I've got the code of Bart compiling on my Mac (I've created a tiny pull request to fix an include with Windows path separators). Once I get it up&running I'll make some more major changes because I want to follow the homie specification for MQTT (I'm using OpenHab which has support for Homie). Currently the code is all contained in a single file; maybe it is an idea to split the CN105 logic in a separate library so people can integrate it how they see fit?
We found some more details relating to the ForceDHW and the use of set command 0x34 (byte0). Think you have to set byte1 to 0x01 (flag?) and then byte3 : 1=Force or 0=Normal.
I found this too, bytes 1 and 3 set, I couldn't turn it off though. I also tried byte 1 to 0x01, and tried setting byte 4,5,6,7,8,9... etc in sequence, but didn't seem to find anything
One thing to mention is that in my first "ForceDHW" code, I also set byte 5 to 0x01 (so 1,3 and 5). This resulted in the HP going in holiday mode when you setting it to standby. This was seen by Albert, I could not reproduce it on my machine.
Hi All,
I've adapted the code for Elegoo Mega 2560 R3 with Ethernet Shield to control MSZ-AP25VG-E1 (I assume the unit is compatible).
The IP/MQTT side works properly but I don't see communication with the pump.
I assume that the code uses UART1; or do I've to set something to select the serial port?
Thank you!
Not sure if this will work. The program is written in the Arduino framework, but I am running it on an ESP32 chip. I also think the heatpumps and airco units use a little bit different protocol. Please look at: https://github.com/SwiCago/HeatPump and https://web.archive.org/web/20171007190023/https://nicegear.co.nz/blog/hacking-a-mitsubishi-heat-pump-air-conditioner/
I think similar to Giacomo, I have wifi/webserver/MQTT all working with the Wemos D1 mini (https://www.amazon.com/gp/product/B081PX9YFV/) but no serial. I've tried with and without pullup resistors (10Kohm from both Tx and Rx to 5V), status report web page still says DISCONNECTED. My indoor units are MSZ-GLxxNA, which seem like they should be supported. I'm using the latest mitsubishi2mqtt (https://github.com/gysmo38/mitsubishi2MQTT).
Interesting quote from https://github.com/SwiCago/HeatPump: "Note: some people report problems with Wemos D1 due to usb serial pulling RX high when usb idle! Fix is to cut a trace, so maybe use an alternative, if following the above blog links.". Can anybody point me at details? My USB serial definitely will be idle when installed, and I'm using Wemos D1 mini.
10 replies
Hi all. I'm about to have 4 MHI heat pumps installed at my house, and 4 at my parents home. 8 x $200 AUD is a bit much to swallow for the official Mitsubishi WiFi adapters, so I'm dusting off my Diploma of Engineering Computer Systems skills and building a bunch of ESP32 based CN105 controllers.
My plan is to get some WT32-ETH01 modules with 5V input (eg: https://www.aliexpress.com/item/1005002023196214.html), and hopefully use Tasmota for MQTT integration (https://templates.blakadder.com/wireless_tag_WT32-ETH01.html). Has anyone looked at adding the CN105 protocol as a Tasmota module (https://tasmota.github.io/docs/Modules/)?
My plan is to get some WT32-ETH01 modules with 5V input (eg: https://www.aliexpress.com/item/1005002023196214.html), and hopefully use Tasmota for MQTT integration (https://templates.blakadder.com/wireless_tag_WT32-ETH01.html). Has anyone looked at adding the CN105 protocol as a Tasmota module (https://tasmota.github.io/docs/Modules/)?
2 replies
