Mitsubishi Heat Pump

Super! Thanks a lot.

Hi again, Sorry to keep bugging you, but I now have a new issue. Whenever a power cut happens, the D1 does not reboot once the power is back. In order to get it to reboot, I need to press the tiny reset switch. Hopefully, automatic reboot upon powering can be enabled by some software switch. Do you know?

Just to be more precise: the behavior mentioned above was observed when the D1 is powered through the USB port. I have not connected it to the heatpump yet. I don’t suppose this really makes a difference, but I thought I should mention it anyway.

So you are saying you need to press the reset button after you plugin the USB cable? I never seen such behaviour … i.e. I’m using a couple of D1s powered by an old phone charger and they boot up fine every time … Im not aware of any setting that would prevent booting up when powered (and would be surprised if such setting would exist). Can you try powering your D1 using a phone charger or something similar that has micro USB connector to give it a try?

Thanks God, you’re right!
When powered by a phone charger, my D1 does boot allright.
So, it looks like using a USB port on my Windows computer as a power source has some undesirable side effects.
Thanks again for all your help!

Hi again,

I tried plugging my D1 Mini into my heatpump this morning. There is a red male connector on the board that looks just like the pictures I have seen of the CN105. The board is not so easily accessible without unplugging a lot of connections, and «i struggled a bit to insert the female plug into the red male connector.

First thing I did was test the voltage between the GND and 5V wires coming out of my female connector and I read a clean 5 volts there. So far so good. I then proceeded to soldering all four wires to the D1: GND, 5V, RX and TX.

Turning on the heatpump, the D1 booted allright. I used MQTT Explorer to monitor the messaging.

Unfortunately, I am not receiving the status message you mentioned:

{"roomTemperature":23.0,"wideVane":"|","power":"OFF","mode":"AUTO","fan":"QUIET","vane":"AUTO","iSee":false,"temperature":24.0}

The heatpump responds normally to its native remote control, but does not produce any messages when it receives infrared commands. And the heatpump does not respond to my OH commands, but the MQTT command appears to be received and acknowledged by D1 mini.

I am attaching a screen capture of MQTT Explorer that shows the result of sending a power ON command through the OH interface.

As I understand it, the “settings” message was published by OH while the %taskname% %valname" message was published by the D1 mini. Maybe there is something wrong in the latter message: %taskname% and %valname% look like variable names that sould have been replaced by the relevant values. These variable names appear to originate from the controller definition in the ESP device. I was assuming that they would get instanciated automatically, but maybe that is not correct?

Would suggest to first focus on the ESPEasy/AC part - by starting MQTT client and subscribing to # until you see the

{"roomTemperature":23.0,"wideVane":"|","power":"OFF","mode":"AUTO","fan":"QUIET","vane":"AUTO","iSee":false,"temperature":24.0}

so putting OH a side until you do so.

Please check if your AC is setup and enabled?

You can turn on (Tools | Advanced) Web Log Level: to Debug More and check the log

1937677351: M-AC: didTransition: WaitingForScheduledStatusUpdate -> UpdatingStatus
1937677352: M-AC: US: 0
1937677353: M-AC - OUT: FC 42 1 30 10 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7B 
1937677652: M-AC - IN: FC 62 1 30 10 2 0 0 0 9 7 3 0 0 0 3 B0 0 0 0 0 
1937677653: M-AC: didTransition: UpdatingStatus -> StatusUpdated
1937677653: M-AC: didTransition: StatusUpdated -> UpdatingStatus
1937677653: M-AC: US: 1
1937677654: M-AC - OUT: FC 42 1 30 10 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7A 
1937677866: M-AC - IN: FC 62 1 30 10 3 0 0 E 0 0 B1 0 0 0 0 0 0 0 0 0 
1937677866: M-AC: didTransition: UpdatingStatus -> StatusUpdated
1937677867: M-AC: didTransition: StatusUpdated -> ScheduleNextStatusUpdate
1937677867: M-AC: didTransition: ScheduleNextStatusUpdate -> WaitingForScheduledStatusUpdate
1937678951: M-AC: didTransition: WaitingForScheduledStatusUpdate -> UpdatingStatus
1937678952: M-AC: US: 0
1937678953: M-AC - OUT: FC 42 1 30 10 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7B 
1937679252: M-AC - IN: FC 62 1 30 10 2 0 0 0 9 7 3 0 0 0 3 B0 0 0 0 0 
1937679253: M-AC: didTransition: UpdatingStatus -> StatusUpdated
1937679253: M-AC: didTransition: StatusUpdated -> UpdatingStatus
...

Thanks! Here is a capture of my current task setting.

Will try the debug , but I am not sure what to look for there.

I did turn on «Debug More" and what I see in the log does look like an important error:

1113871: M-AC: didTransition: Connecting -> ReadTimeout
1113871: M-AC: didTransition: ReadTimeout -> Connecting
1113871: M-AC: Connect 2400
1113872: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1115971: M-AC: didTransition: Connecting -> ReadTimeout
1115971: M-AC: didTransition: ReadTimeout -> Connecting
1115971: M-AC: Connect 9600
1115972: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1118070: M-AC: didTransition: Connecting -> ReadTimeout
1118071: M-AC: didTransition: ReadTimeout -> Connecting
1118071: M-AC: Connect 2400
1118072: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1120170: M-AC: didTransition: Connecting -> ReadTimeout
1120171: M-AC: didTransition: ReadTimeout -> Connecting
1120171: M-AC: Connect 9600
1120172: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1122270: M-AC: didTransition: Connecting -> ReadTimeout
1122271: M-AC: didTransition: ReadTimeout -> Connecting
1122271: M-AC: Connect 2400
1122272: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1124371: M-AC: didTransition: Connecting -> ReadTimeout
1124371: M-AC: didTransition: ReadTimeout -> Connecting
1124371: M-AC: Connect 9600
1124372: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1126470: M-AC: didTransition: Connecting -> ReadTimeout
1126471: M-AC: didTransition: ReadTimeout -> Connecting
1126471: M-AC: Connect 2400
1126472: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1128570: M-AC: didTransition: Connecting -> ReadTimeout
1128571: M-AC: didTransition: ReadTimeout -> Connecting
1128571: M-AC: Connect 9600
1128572: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1130670: M-AC: didTransition: Connecting -> ReadTimeout
1130671: M-AC: didTransition: ReadTimeout -> Connecting
1130671: M-AC: Connect 2400
1130672: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1132771: M-AC: didTransition: Connecting -> ReadTimeout
1132771: M-AC: didTransition: ReadTimeout -> Connecting
1132771: M-AC: Connect 9600
1132772: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1134870: M-AC: didTransition: Connecting -> ReadTimeout
1134871: M-AC: didTransition: ReadTimeout -> Connecting
1134871: M-AC: Connect 2400
1134872: M-AC - OUT: FC 5A 1 30 2 CA 1 A8
1136970: M-AC: didTransition: Connecting -> ReadTimeout
1136971: M-AC: didTransition: ReadTimeout -> Connecting
1136971: M-AC: Connect 9600

Is this about the connection between the D1 and the heatpum processor?

It seems as your AC is not responding, there are only OUT packets. Can you double check your TX/RX wires and pins they are connected to?

Also - please make sure to disable Enable Serial port: in Tools | Advanced !

Screenshot 2021-01-03 at 20.51.25

I disconnected the CN105 and rechecked the pins. They looked OK.

In the advanced tools, the serial port was enabled. I disabled it.

The log now looks more like it should, I believe:

69374: M-AC - OUT: FC 42 1 30 10 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7B
69673: M-AC - IN: FC 62 1 30 10 2 0 0 0 8 B 0 0 0 0 3 A8 0 0 0 0
69674: M-AC: didTransition: UpdatingStatus -> StatusUpdated
69674: M-AC: didTransition: StatusUpdated -> UpdatingStatus
69674: M-AC: US: 1
69675: M-AC - OUT: FC 42 1 30 10 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7A
69973: M-AC - IN: FC 62 1 30 10 3 0 0 8 0 0 A5 0 0 0 0 0 0 0 0 0
69974: M-AC: didTransition: UpdatingStatus -> StatusUpdated
69974: M-AC: didTransition: StatusUpdated -> ScheduleNextStatusUpdate
69975: M-AC: didTransition: ScheduleNextStatusUpdate -> WaitingForScheduledStatusUpdate
71373: M-AC - IN: FC 62 1 30 10 2 0 0 0 8 B 0 0 0 0 3 A8 0 0 0 0
71374: M-AC: didTransition: UpdatingStatus -> StatusUpdated
71374: M-AC: didTransition: StatusUpdated -> UpdatingStatus
71375: M-AC: US: 1
71375: M-AC - OUT: FC 42 1 30 10 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7A
71673: M-AC - IN: FC 62 1 30 10 3 0 0 8 0 0 A5 0 0 0 0 0 0 0 0 0
71674: M-AC: didTransition: UpdatingStatus -> StatusUpdated
71674: M-AC: didTransition: StatusUpdated -> ScheduleNextStatusUpdate
71674: M-AC: didTransition: ScheduleNextStatusUpdate -> WaitingForScheduledStatusUpdate
74775: M-AC: US: 1
74775: M-AC - OUT: FC 42 1 30 10 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7A
75073: M-AC - IN: FC 62 1 30 10 3 0 0 8 0 0 A5 0 0 0 0 0 0 0 0 0
75074: M-AC: didTransition: UpdatingStatus -> StatusUpdated
75074: M-AC: didTransition: StatusUpdated -> ScheduleNextStatusUpdate
75074: M-AC: didTransition: ScheduleNextStatusUpdate -> WaitingForScheduledStatusUpdate
76172: M-AC: didTransition: WaitingForScheduledStatusUpdate -> UpdatingStatus

And even more importantly, it looks like MQTT updates are now being provided, as seen in MQTT Explorer. See screen capture:

Look like we are real close now, thanks to your great advice.

I can now report that the commands sent through the infrared remote (e.g. power ON, set temperature to 22) are being echoed in an update state published in MQTT.

On the OH side, the received updates are working, in the sense that if I change a setting with the infrared remote, the corresponding setting gets updated in the OH interface.

However, at this point, the commands sent through OH are not working yet.

Thanks again.

Great to hear - now the hard part is over :partying_face:

What is your OH MQTT config?

Here is my mqtt.things:

Bridge mqtt:broker:mosquit "MQTT Broker" [ host="127.0.0.1" ] {
  Thing topic ESP_Easy1 {
    Channels:
      Type number:acRoomTemperature [ stateTopic="ESP_Easy1/Thermopompe-CdM/settings", 
                                      transformationPattern="JSONPATH:$.roomTemperature" ]

      Type number:acTemperature [ stateTopic="ESP_Easy1/Thermopompe-CdM/settings", 
                                  transformationPattern="JSONPATH:$.temperature", 
                                  commandTopic="ESP_Easy1/Thermopompe-CdM/settings/cmd", 
                                  formatBeforePublish="Thermopompe-CdM,temperature,%d" ]

      Type string:acPower [ stateTopic="ESP_Easy1/Thermopompe-CdM/settings", 
                            transformationPattern="JSONPATH:$.power", 
                            commandTopic="ESP_Easy1/Thermopompe-CdM/settings/cmd", 
                            formatBeforePublish="Thermopompe-CdM,power,%s" ]

      Type string:acMode [ stateTopic="ESP_Easy1/Thermopompe-CdM/settings", 
                           transformationPattern="JSONPATH:$.mode", 
                           commandTopic="ESP_Easy1/Thermopompe-CdM/settings/cmd", 
                           formatBeforePublish="Thermopompe-CdM,mode,%s" ]

      Type string:acFan [ stateTopic="ESP_Easy1/Thermopompe-CdM/settings", 
                          transformationPattern="JSONPATH:$.fan", 
                          commandTopic="ESP_Easy1/Thermopompe-CdM/settings/cmd", 
                          formatBeforePublish="Thermopompe-CdM,fan,%s" ]

      Type string:acVane [ stateTopic="ESP_Easy1/Thermopompe-CdM/settings", 
                           transformationPattern="JSONPATH:$.vane", 
                           commandTopic="ESP_Easy1/Thermopompe-CdM/settings/cmd", 
                           formatBeforePublish="Thermopompe-CdM,vane,%s" ]

      Type string:acWideVane [ stateTopic="ESP_Easy1/Thermopompe-CdM/settings", 
                               transformationPattern="JSONPATH:$.wideVane", 
                               commandTopic="ESP_Easy1/Thermopompe-CdM/settings/cmd", 
                               formatBeforePublish="Thermopompe-CdM,wideVane,%s" ]
  }
}

Basically, I copied your stuff changing “FF_Nik_Room” for “ESP_Easy1” and “ac” for “Thermopompe-CdM”.

And here are my relevant items:

Number ESP_Easy1_ac_room_temp "Room temperature [%.1f °C]" <temperature> { channel="mqtt:topic:mosquit:ESP_Easy1:acRoomTemperature" }
Number ESP_Easy1_ac_temp "Temperature [%.1f °C]" <heating> { channel="mqtt:topic:mosquit:ESP_Easy1:acTemperature" }
String ESP_Easy1_ac_power "Power []" { channel="mqtt:topic:mosquit:ESP_Easy1:acPower" }
String ESP_Easy1_ac_mode "Mode []" <fan_ceiling> { channel="mqtt:topic:mosquit:ESP_Easy1:acMode" }
String ESP_Easy1_ac_fan "Fan" <fan> { channel="mqtt:topic:mosquit:ESP_Easy1:acFan" }
String ESP_Easy1_ac_vane "Vane" <flow> { channel="mqtt:topic:mosquit:ESP_Easy1:acVane" }
String ESP_Easy1_ac_widevane "Wide Vane" <flow> { channel="mqtt:topic:mosquit:ESP_Easy1:acWideVane" }

And my relevant part sitemap portion:

     Frame label="Thermopompe CdM" {
	Text item=ESP_Easy1_ac_room_temp label="CdM: actuel"
	Setpoint item=ESP_Easy1_ac_temp label="CdM:cible [%.1f \u00B0C]" minValue=16 maxValue=31 step=1
	Switch item=ESP_Easy1_ac_power mappings=[OFF="Off", ON="On"]
	Switch item=ESP_Easy1_ac_mode mappings=[COOL="Cool", HEAT="Heat", DRY="Dry", FAN="Fan", AUTO="Auto"]
	Selection item=ESP_Easy1_ac_fan mappings=[1="1", 2="2",3="3",4="4",AUTO="AUTO",QUIET="QUIET"]
	Selection item=ESP_Easy1_ac_vane mappings=[1="1", 2="2",3="3",4="4",5="5",AUTO="AUTO",SWING="SWING"]
	Selection item=ESP_Easy1_ac_widevane	mappings=["<<"="<<","<"="<","|"="|",">"=">",">>"=">>",SWING="SWING"]
	}
1 Like

You should not change the content of formatBeforePublish, this defines the payload and must stay the same, i.e.

formatBeforePublish="MitsubishiHP,power,%s"

Yes, I should have thought better. The problem, I guess, is that I do not have a very clear view of how the whole thing works.

Anyway, now my OH interface is working perfectly well. Huge thanks to you for all the fantastic help!

I can now replace the cover on my heatpump. My ID is to leave the D1 mini inside the heatpump, underneath the cover. I suppose that the wifi is good enough to reach in there. But I need to ensure that nothing will mess up with the electrical contacts of the D1. Are you leaving your D1 in your heatpump? If so do your cover it with something (maybe just electrical tape) to prevent any electrical accident?

I found a small spot that I thought is dry and safe from any humidity, also no metal around … and put/tucked D1 there and closed the cover. So I guess you will need to trust your own judgment on this, specially since it depends on the type of AC how much space is left and where …

One more thing - I turned on the CPU Eco Mode in Tools | Advanced, not sure how much effect it has, but should reduce the D1 module heating … just FYI … not that I had any problem with heating in the first place …

OK will follow your advice. That closes chapter 1 of my heatpump stuff. Chapter 2 will be opened a bit later. It is about another Mitsubishi indoor unit that is being fed by the same exterior unit. Since both units are same brand, same generation, one might think that doing the second will be straightforward, but I do have a couple of concerns. First. this second unit has a completely diffrent layout because rather than a floor model, it is a “cassette”-type unit, embedded in the ceiling of my solarium. The second difference is that rather than being operated by an infrared remote, it has a wired wall-mounted remote. If there is a CN105 plug on the board of that unit, it may already be occupied by that existing wired remote. I don’t know if it is possible to “Y” two such connections together. Anyway, I will try to look into that in a few weeks from now.
Cheers, --Pierre