swicago / heatpump Goto Github PK

Hello,

I've got a Mitsubishi Ecodan Air/Water heatpump. It uses the same WiFi unit as the air/air units.

But I don't get any response from my unit. In the mqtt debug I see that the fc 5a 01 30 02 ca 01 a packet is sent. Could it be that I need a different connect packet?

I'm using a nodemcu with 10k pull-ups on the TX/RX

Are there any examples to convert between temperature units? I see a helper but am unsure how to use it. Thanks

Hi.

I have the European model with the special iSave mode that allows me to set the temperature to 10 degrees celsius. The library reports that as 16 degrees since that's the minimum, and it's not possible to programmatically set the target temp to 10 degrees either.

I tried looking through the code to see if it would be easy to make the necessary changes, but I really suck in C++ so I couldn't make heads or tails of it.

Would this be an easy fix? I would really appreciate it!

Jakob A posted this on nicegear some time back:

However, this model has an "i-save" mode, which allows you to set the temperature down to 10 C. I want to be able to set this mode, but looking at the code it doesn't look like it supports that.
Of course I tried to set it from the remote and see what happens, this is what I saw in the debug print outs:
isave 10 degrees, heat, fan auto, vane swing:
HP Packet: 0x62 : 02,00,00,01,01,0f,00,07,00,00,03,94,00,00,00,00 : 0xac

isave 16 degrees, heat, fan auto, vane swing:
HP Packet: 0x62 : 02,00,00,01,01,0f,00,07,00,00,03,a0,00,00,00,00 : 0xa0

heat 16 degrees, heat, fan auto, vane swing:
HP Packet: 0x62 : 02,00,00,01,01,0f,00,07,00,00,03,a0,00,00,00,00 : 0xa0

The only thing that changes, as far as I can see, is the 12th byte.
"94" for 10 degrees, "a0" for 16 degrees.
I tried setting the temperature to 31 C, and it changes to "be"

Thanks for all of the hard work, it's a great library.

Hi,

I'm seeing the following behavior. I don't know that it is related to the HeatPump software, but I just wanted to see if anyone else has noticed it.
When I use the remote, every other press of the temp up or down results in the temp jumping up to the max. I noticed this while testing converting the temp from C to F.
Here is the MQTT output. c__temp is the original temp
lrheatpump {"power":"ON","mode":"HEAT","c_temp":18,"temperature":64,"fan":"AUTO","vane":"AUTO","wideVane":"|"}
lrheatpump {"power":"ON","mode":"HEAT","c_temp":31,"temperature":88,"fan":"AUTO","vane":"AUTO","wideVane":"|"}
lrheatpump/status {"roomTemperature":64,"operating":true}
lrheatpump/timers {"mode":"NONE","onMins":0,"onRemainMins":0,"offMins":0,"offRemainMins":0}
lrheatpump/status {"roomTemperature":64,"operating":false}
lrheatpump/timers {"mode":"NONE","onMins":0,"onRemainMins":0,"offMins":0,"offRemainMins":0}
lrheatpump {"power":"ON","mode":"HEAT","c_temp":17,"temperature":63,"fan":"AUTO","vane":"AUTO","wideVane":"|"}
lrheatpump {"power":"ON","mode":"HEAT","c_temp":31,"temperature":88,"fan":"AUTO","vane":"AUTO","wideVane":"|"}

Anyone else run into this ?

Here is what KUMO CLOUD sends for each mode
FC,42,01,30,10,02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,7B =>INFO
FC,42,01,30,10,03,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,7A =>INFO_TEMP
FC,42,01,30,10,04,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,79 => ???
FC,42,01,30,10,09,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,74 => ???
TP=Type,pw=power,md=mode,fs=fanSpeed,vv=vane,tF=temp
FC,42,01,30,10,- -,TP,00,pw,md,00,fs,vv,00,00,00,00,00,00,tF,00,CHK
FC,41,01,30,10,01,07,00,01,02,00,00,00,00,00,00,00,00,00,A8,00,CB => DRY
FC,41,01,30,10,01,03,00,01,07,00,00,00,00,00,00,00,00,00,80,00,F2 => FAN
FC,41,01,30,10,01,07,00,01,01,00,00,00,00,00,00,00,00,00,A8,00,CC => HEAT
FC,41,01,30,10,01,07,00,01,03,00,00,00,00,00,00,00,00,00,A8,00,CA =>COOL
FC,41,01,30,10,01,05,00,00,00,00,00,00,00,00,00,00,00,00,A8,00,D0 => OFF
FC,41,01,30,10,01,08,00,00,00,00,01,00,00,00,00,00,00,00,80,00,F4 =>FANQuiet
FC,41,01,30,10,01,08,00,00,00,00,02,00,00,00,00,00,00,00,80,00,F3 =>FAN1
FC,41,01,30,10,01,08,00,00,00,00,03,00,00,00,00,00,00,00,80,00,F2 =>FAN2
FC,41,01,30,10,01,08,00,00,00,00,05,00,00,00,00,00,00,00,80,00,F0 =>FAN3
FC,41,01,30,10,01,08,00,00,00,00,06,00,00,00,00,00,00,00,80,00,EF =>FAN4
FC,41,01,30,10,01,08,00,00,00,00,00,00,00,00,00,00,00,00,80,00,F5 =>FANAuto
FC,41,01,30,10,01,10,00,00,00,00,00,00,00,00,00,00,00,00,80,00,ED => VANEAuto
FC,41,01,30,10,01,10,00,00,00,00,00,01,00,00,00,00,00,00,80,00,EC => VANE1
FC,41,01,30,10,01,10,00,00,00,00,00,02,00,00,00,00,00,00,80,00,EB => VANE2
FC,41,01,30,10,01,10,00,00,00,00,00,03,00,00,00,00,00,00,80,00,EB => VANE3
FC,41,01,30,10,01,10,00,00,00,00,00,04,00,00,00,00,00,00,80,00,E9 => VANE4
FC,41,01,30,10,01,10,00,00,00,00,00,05,00,00,00,00,00,00,80,00,E8 => VANE5
FC,41,01,30,10,01,10,00,00,00,00,00,07,00,00,00,00,00,00,80,00,E6 => VANE_Swing

TP=Type,pw=power,md=mode,fs=fanSpeed,vv=vane,tF=temp
FC,42,01,30,10,- -,TP,00,pw,md,00,fs,vv,00,00,00,00,00,00,tF,00,CHK
INFO : FC,42,01,30,10,02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,7B
INFO : FC,42,01,30,10,03,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,7A
???? : FC,42,01,30,10,04,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,79
???? : FC,42,01,30,10,09,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,74

DRY : FC,41,01,30,10,01,07,00,01,02,00,00,00,00,00,00,00,00,00,A8,00,CB DRY ON
FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,BE,00,B2 DRY, FAN_Q,88°
FC,41,01,30,10,01,0C,00,00,00,00,02,00,00,00,00,00,00,00,BE,00,B1 DRY, FAN_1,88°
FC,41,01,30,10,01,14,00,00,00,00,00,00,00,00,00,00,00,00,BE,00,AB DARY,VANEA,88°
FC,41,01,30,10,01,14,00,00,00,00,00,01,00,00,00,00,00,00,BE,00,AA COOL, VANE1,88°

FAN : FC,41,01,30,10,01,03,00,01,07,00,00,00,00,00,00,00,00,00,80,00,F2 FAN ON
FC,41,01,30,10,01,08,00,00,00,00,01,00,00,00,00,00,00,00,80,00,F4 FAN, FAN_Q,NO_temp_setting
FC,41,01,30,10,01,08,00,00,00,00,02,00,00,00,00,00,00,00,80,00,F3 FAN, FAN_1,NO_temp_setting
FC,41,01,30,10,01,10,00,00,00,00,00,00,00,00,00,00,00,00,80,00,ED FAN, VANEA,NO_temp_setting
FC,41,01,30,10,01,10,00,00,00,00,00,01,00,00,00,00,00,00,80,00,EC FAN, VANE1,NO_temp_setting

HEAT : FC,41,01,30,10,01,07,00,01,01,00,00,00,00,00,00,00,00,00,A8,00,CC HEAT ON
: FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,94,00,DC HEAT,FAN_Q,50°
FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,BE,00,B2 HEAT,FAN_Q,88°
FC,41,01,30,10,01,14,00,00,00,00,00,00,00,00,00,00,00,00,94,00,D5 HEAT,VANEA,50°
FC,41,01,30,10,01,14,00,00,00,00,00,01,00,00,00,00,00,00,94,00,D4 HEAT,VANE1,50

COOL : FC,41,01,30,10,01,07,00,01,03,00,00,00,00,00,00,00,00,00,A8,00,CA COOL ON
FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,A0,00,D0 COOL, FAN_Q,61°
FC,41,01,30,10,01,0C,00,00,00,00,02,00,00,00,00,00,00,00,A0,00,CF COOL, FAN 1,61°
FC,41,01,30,10,01,0C,00,00,00,00,01,00,00,00,00,00,00,00,BE,00,B2 COOL, FAN_Q,88°
FC,41,01,30,10,01,0C,00,00,00,00,02,00,00,00,00,00,00,00,BE,00,B1 COOL, FAN_1,88°
FC,41,01,30,10,01,14,00,00,00,00,00,00,00,00,00,00,00,00,BE,00,AB COOL, VANEA,88°
FC,41,01,30,10,01,14,00,00,00,00,00,01,00,00,00,00,00,00,BE,00,AA COOL, VANE1,88°

Looks like temp can always be sent, with any setting. It looks like there is a magic byte that says what the payload could contain. The above seems pretty easy to replicate and I am sure I could recode a branch of the library to do the above...just not tonight LOL

So, from the above, magic bytes are as follows
0x0c FAN speed change and TEMP for modes DRY,COOL,HEAT

If I call sync() in the loop while millis() is less than (PACKET_SENT_INTERVAL_MS * 10) it tries to connect again and again forever.

(millis() - (PACKET_SENT_INTERVAL_MS * 10) > lastRecv))

is not a correct time comparison, it should be done like this

(millis() - lastRecv > (PACKET_SENT_INTERVAL_MS * 10))

other similar time comparison have to be reviewed similarly

https://arduino.stackexchange.com/questions/12587/how-can-i-handle-the-millis-rollover

The documentation on the Mitsubishi AirCon protocol is incomplete. Possible values isn't covered in detail (what does each value mean), no unique name is given for each byte number, the descriptions are too short, and no meaningful examples are provided.

Without complete/meaningful documentation no Software Developer can implement the Mitsubishi AirCon protocol using a programming language (Kotlin via Kotlin Native, Python via MicroPython etc).

I'm very amateur when it comes to circuits but it seems to me you are pulling the ESP serial UP to 5v? I would assume this would blow or slowly blow the 3.3v ESP?

I'm looking to build this circuit but don't want to get into replacing ESP's often as I want to install inside of HP enclosure.

Can confirm this unit is working :)

WideVane setting seems to be ignored by heatpump. Changing via IR remote, HP reports the change. change via esp and it is ignored.
Maybe we nee to look at the IR protocol and see if that works with the custom packet sender
https://github.com/r45635/HVAC-IR-Control/blob/master/Protocol/Mitsubishi_IR_Packet_Data_v1.1-FULL.pdf
Also, I hooked up my kumo cloud again and it doesn't even have wideVane option LOL...I got mine for free, but mitsu sells these for $180 a pop, what a ripoff

I am running the mitsubishi_heatpump_mqtt_esp8266.ino and in the last couple of days the temperature is being reported as 1073741826 (looks like an int variable has not been set?). It's only started in the last few days - might be related to the callback commit?

I switched on debug mode over MQTT and I can see that the info packet (03) is reporting in the 4th byte (where room temp lives) "0a" (hex) which maps to 20 degrees according to ROOM_TEMP_MAP

here is the MQTT output:

heatpump/temperature {"roomTemperature":1073741826}
heatpump/debug/set on
heatpump/debug debug mode enabled
heatpump/debug {"packet":"03 00 00 0a 00 00 a8 00 00 00 00 00 00 00 00 00 "}
heatpump/debug {"packet":"02 00 00 00 08 04 00 07 00 00 0c b6 00 00 00 00 "}
heatpump/debug {"packet":"03 00 00 0a 00 00 a8 00 00 00 00 00 00 00 00 00 "}
heatpump/debug {"packet":"02 00 00 00 08 04 00 07 00 00 0c b6 00 00 00 00 "}
heatpump/debug {"packet":"03 00 00 0a 00 00 a8 00 00 00 00 00 00 00 00 00 "}
heatpump/debug {"packet":"02 00 00 00 08 04 00 07 00 00 0c b6 00 00 00 00 "}
heatpump/temperature {"roomTemperature":1080950825}
heatpump/debug {"packet":"03 00 00 0a 00 00 a8 00 00 00 00 00 00 00 00 00 "}
heatpump/debug {"packet":"02 00 00 00 08 04 00 07 00 00 0c b6 00 00 00 00 "}
heatpump/debug/set off
heatpump/debug debug mode disabled
heatpump/temperature {"roomTemperature":1073741826}
heatpump/temperature {"roomTemperature":1073741826}
heatpump/temperature {"roomTemperature":1073741826}
heatpump/temperature {"roomTemperature":1073741826}

I don't think the fact that it changes to 1080950825 during debug mode is anything to read into, as I am guessing it's reporting a random piece of memory for roomTemperature because it's not set, and that random piece of memory changes when debug mode is switched on.

I haven't had a chance to debug further yet, but wanted to post it here first :)

I have setup an ESP-07 and connected to a Mitsubishi MSZ-AP50VGK. It is correctly responding to changes of function etc but the reported room temperature is always 0.

on the /status topic I get the periodic
{ "roomTemperature": 0, "operating": false }

Is there something I am doing wrong?

Thanks

Tom

HI @SwiCago

I've just finished building dgoodlad/esp8266-mitsubishi-aircon based on your HeatPump library, thanks for so much hard work! I wonder if you've any interest in pulling this project in as an example, or to link to it? The big changes from your README and home assistant example are:

• Uses a TXB0104 logic level shifter rather than a pullup resistor to talk 5V
• Switches modes in software based on whether 5V power is coming from the heatpump or from another source (e.g. FTDI/USB power) for development purposes
• Uses the alternative UART pins (Serial.swap) to keep the ESP's bootup messages off the heatpump's serial lines, which I'd found sometimes caused it to panic and reset
• Integration with Home Assistant via the MQTT HVAC Component instead of a custom python component
• Online/offline availability state in HA via MQTT's "last will" feature
• WiFiManager for configuration

I have a multihead compressor with five heads in my home, and they're working great with this hardware+software now 😄

Espressif has fixed the flaw, but due make sure you are using a version that has the fix in place
esp8266/Arduino#3725

NOTE: this is not a flaw in the heat pump library, but rather the core code of the esp8266 chip. Just thought I'd give everyone a friendly heads up ;)

@kayno @lekobob @schotime , have any of you tried to use MQTT over TLS , so that communication between ESP and Server are secure.
I read it is just a matter of using "WiFiClientSecure" instead of "WiFiClient" and then setting port to 8883 instead of 1883

Upgraded my version of HA to 0.60.1, and all of a sudden the mitsubishi_mqtt platform has stopped working with a completely non-informative error message in the log. Removing the mitsubishi_mqtt from the configuration and putting in a generic_thermostat object works just fine.

`Sun Jan 07 2018 21:27:09 GMT-0500 (EST)

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 231, in async_update_ha_state
attr)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 333, in _attr_setter
value = getattr(self, name)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/climate/init.py", line 736, in supported_features
raise NotImplementedError()
NotImplementedError`

THIS IS NOT A THREAD TO ASK FOR HELP! USE GITTER CHAT FOR HELP

Hi guys, I would like to use this area to list unit types that are know to work with this library.
Exact number(as in tonnage) not necessary, as all units of the same type would work, if confirmed for one.
Please state Region and models that you have personally tested with. If you can provide weblink of unit that would help. I'll start
North America - MSZ-FH (Wall unit)
North America - SEZ-KD (Horizontal Ducted unit)
Mini split on shared compressor
North America - MXZ-8C48NAHZ (8 zone outdoor unit)

Linked this list to readme, until we have a big enough list. Then I'll create a compatability list.
The following webpage may help find your exact unit type
http://meus1.mylinkdrive.com/index.html

THIS IS NOT A THREAD TO ASK FOR HELP! USE GITTER CHAT FOR HELP

@kayno as mention in the closed pull. I have added a method to send custom packets. It will automatically add the starting 0xfc and trailing checksum byte. Don't break your heatpump ;)

Hello,
I'm using this fantastic project to control my mitsubishi units with HomeAssistant and everything works fine, but I have some errors logged by HomeAssistant.

2019-01-22 10:41:11 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved Traceback (most recent call last): File "/usr/lib/python3.6/concurrent/futures/thread.py", line 56, in run result = self.fn(*self.args, **self.kwargs) File "/home/homeassistant/.homeassistant/custom_components/climate/mitsubishi_mqtt.py", line 107, in message_received self.schedule_update_ha_state() File "/opt/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 317, in schedule_update_ha_state self.hass.add_job(self.async_update_ha_state(force_refresh)) AttributeError: 'NoneType' object has no attribute 'add_job'

NOTE: I also changed line 188 of mitsubishi_mqtt.py from self.update_ha_state() to self.schedule_update_ha_state()

How to fix that error?

Did anyone investigate older units that don't have the famous CN105 connector? I was reading that it's alternatively called CN92 on some of the in-ceiling and ducted systems. However the older models (without Inverter) don't have either of these connectors.

I was looking at a PEAD-RP2.5GA ducted unit and it's got a CN90 "Wireless" port meant for IR remote control receivers as well as a connector CN51 called "HA Terminal-A" whose purpose I don't understand. However I've not found a clear output signal, but I wasn't able to check the unit in place while running, just the indoor board on its own, so it might just not have output anything :/

Here's the pins I've been able to identify:

CN90 Wireless
Pin 1: goes to IO pin 20 of the CPU via a 200Ohm resistor, and has a 22k pullup
Pin 2: goes to IO pin 21 of the CPU via a 200Ohm resistor, and has a 22k pullup
Pin 3: GND
Pin 4: not sure
Pin 5: 5V
Pin 6: driven against GND via a NPN transistor (Q71) from IO pin 18 on the CPU
Pin 7: driven against GND via a NPN transistor (Q71) from IO pin 18 on the CPU
Pin 8: not sure
Pin 9: 12-15V unregulated

CN51 HA Terminal-A
Pin 1+3: 12-15V unregulated
Pin 2+4: not sure

Sorry if this is the wrong place I am new to ESP8266 programming and Git.

I modified the Demo to control me heat pump and it worked great as an AP. But when i changed the code to connect to my Wifi network it took down my Wifi. End goal is voice commands through Google home to Home assistant for basic settings.

After calling heatpump.connect(&Serial) the onConnectCallback() gets fired every 2 seconds (approximately). Looks like esp is not able to connect

First of all, thank you very much for your project.

Has somebody tried a NodeMcu(with the ESP8266 and working with 5v)? I wonder if we can use it directly to the CN105, without any tension regulator

thanks

Hi al, kayno.

I'm Albertoo from nicegear.nz. Can you help me?

If i try add more mqtt_publish in hpSeetingsChanges the sketch dont' work (only reads temperature) not send commands to heatpump or mqtt /heatpump.

The code i use is:

void hpSettingsChanged() {
const size_t bufferSize = JSON_OBJECT_SIZE(6);
const size_t bufferSizeDomoticz_power = JSON_OBJECT_SIZE(3);
const size_t bufferSizeDomoticz_mode = JSON_OBJECT_SIZE(3);
const size_t bufferSizeDomoticz_fan = JSON_OBJECT_SIZE(3);
const size_t bufferSizeDomoticz_temperature = JSON_OBJECT_SIZE(3);

DynamicJsonBuffer jsonBuffer(bufferSize);

DynamicJsonBuffer jsonBufferDomoticz_power(bufferSizeDomoticz_power);
DynamicJsonBuffer jsonBufferDomoticz_mode(bufferSizeDomoticz_mode);
DynamicJsonBuffer jsonBufferDomoticz_fan(bufferSizeDomoticz_fan);
DynamicJsonBuffer jsonBufferDomoticz_temperature(bufferSizeDomoticz_temperature);

JsonObject& root = jsonBuffer.createObject();
JsonObject& domoticz_power = jsonBufferDomoticz_power.createObject();
JsonObject& domoticz_mode = jsonBufferDomoticz_mode.createObject();
JsonObject& domoticz_fan = jsonBufferDomoticz_fan.createObject();
JsonObject& domoticz_target_temp = jsonBufferDomoticz_temperature.createObject();


heatpumpSettings currentSettings = hp.getSettings();

root["power"]       = currentSettings.power;
root["mode"]        = currentSettings.mode;
root["temperature"] = currentSettings.temperature;
root["fan"]         = currentSettings.fan;
root["vane"]        = currentSettings.vane;
root["wideVane"]    = currentSettings.wideVane;
char buffer[512];
root.printTo(buffer, sizeof(buffer));
bool retain = true;
mqtt_client.publish(heatpump_topic, buffer, retain);
domoticz_power["command"] = "setuservariable";
domoticz_power["idx"]     = 13;
domoticz_power["value"]   = currentSettings.power;
char buffer_domoticz_power[512];
domoticz_power.printTo(buffer_domoticz_power, sizeof(buffer_domoticz_power));
mqtt_client.publish(domoticz_mqtt, buffer_domoticz_power);
domoticz_mode["command"] = "setuservariable";
domoticz_mode["idx"]     = 12;
domoticz_mode["value"]   = currentSettings.mode;
char buffer_domoticz_mode[512];
domoticz_mode.printTo(buffer_domoticz_mode, sizeof(buffer_domoticz_mode));
mqtt_client.publish(domoticz_mqtt, buffer_domoticz_mode);
domoticz_fan["command"] = "setuservariable";
domoticz_fan["idx"]     = 15;
domoticz_fan["value"]   = currentSettings.fan;
char buffer_domoticz_fan[512];
domoticz_fan.printTo(buffer_domoticz_fan, sizeof(buffer_domoticz_fan));
mqtt_client.publish(domoticz_mqtt, buffer_domoticz_fan);
domoticz_target_temp["command"] = "setuservariable";
domoticz_target_temp["idx"]     = 14;
domoticz_target_temp["value"]   = currentSettings.temperature;
char buffer_domoticz_target_temp[512];
domoticz_target_temp.printTo(buffer_domoticz_target_temp, sizeof(buffer_domoticz_target_temp));
mqtt_client.publish(domoticz_mqtt, buffer_domoticz_target_temp);

}

why cant't publlish mqtt messages ?

Thanks in advance!!!!!!!

A feature, to allow end user to set library into auto update mode.
Auto update should occur witha slight delay to ensure that end user finished setting individual settings. Default should be false, just like any library that has automatic features, such as db auto commit.
We can modify constructor to set auto update on at start, if that makes sense

Hi,
is it possible to "merge"

integrations/OpenHAB/mitsubishi_heatpump_mqtt_esp8266_template/mitsubishi_heatpump_mqtt_esp8266_template.ino
into
examples/mitsubishi_heatpump_mqtt_esp8266/mitsubishi_heatpump_mqtt_esp8266.ino

and

integrations/OpenHAB/mitsubishi_heatpump_mqtt_esp8266_template/mitsubishi_heatpump_mqtt_esp8266.h
into
examples/mitsubishi_heatpump_mqtt_esp8266/mitsubishi_heatpump_mqtt_esp8266.h
?

Files in integrations folder are more updated and the codebase is the same.

I'm trying your example code to control the AC unit over MQTT. It doesn't seem to me that the hpSettingsChanged() callback is called, when for example I change the settings with the remote. Is that supposed to be that way? When should it be called? This is the log of the MQTT traffic on the debug topic

US-IT00103-2:~ lorenzo.decaria$ mosquitto_sub -h raspberrypi.local -t heatpump/debug

{"packetSent":"fc 5a 01 30 02 ca 01 a8 "}
{"packetRecv":"fc 7a 01 30 01 00 54 00 1c 06 ff 3f dc 06 10 40 5f f3 fe 3f 00 00 "}
{"packetSent":"fc 42 01 30 10 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7b "}
{"packetRecv":"fc 62 01 30 10 02 00 00 01 01 1a 05 00 00 00 03 ab 00 00 00 00 8c "}
{"packetSent":"fc 42 01 30 10 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7a "}
{"packetRecv":"fc 62 01 30 10 03 00 00 0a 00 00 a8 00 00 00 00 00 00 00 00 00 a8 "}
{"packetSent":"fc 42 01 30 10 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 79 "}
{"packetRecv":"fc 62 01 30 10 04 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 d9 "}
{"packetSent":"fc 42 01 30 10 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 "}
{"packetRecv":"fc 62 01 30 10 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 "}
{"packetSent":"fc 42 01 30 10 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 77 "}
{"packetRecv":"fc 62 01 30 10 06 00 00 09 01 00 00 00 00 00 00 00 00 00 00 00 4d "}
{"packetSent":"fc 42 01 30 10 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 74 "}
{"packetRecv":"fc 62 01 30 10 09 00 00 00 01 01 00 00 00 00 00 00 00 00 00 00 52 "}
{"packetSent":"fc 42 01 30 10 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7b "}
{"packetRecv":"fc 62 01 30 10 02 00 00 01 08 1a 00 00 00 00 03 ab 00 00 00 00 8a "}
{"packetSent":"fc 42 01 30 10 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7a "}
{"packetRecv":"fc 62 01 30 10 03 00 00 0a 00 00 a8 00 00 00 00 00 00 00 00 00 a8 "}
{"packetSent":"fc 42 01 30 10 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 79 "}
{"packetRecv":"fc 62 01 30 10 04 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 d9 "}
{"packetSent":"fc 42 01 30 10 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 "}
{"packetRecv":"fc 62 01 30 10 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 "}

The sample circuit has two 10K resistors from the ESP pins to 5V. Shouldn't there be matching 20K resistors from the ESP pins to ground to complete the voltage divider for the 5V to 3,3V level shift?

I thought it's a good idea to raise a new issue for improvements or changes to the room temp.

Is there a reason it sends every 60 seconds? I thought the MQTT philosophy is to send when it changes, same way the other settings work.
I already modified and tested the following changes:
-create callback for room temp modified
-separate room temp from the settings struct
-trigger the callback when room temp changed with mqtt retain set to true

What do you guys think??

I am trying to control a MSZ-SF25VE3 indoor unit. I have hooked up an FTDI USB to serial adapter to RX, TX and GND of the CN105 and tried to receive with 2400 8E1 but don't get anything. The 12V, 5V and GND signals are there but there is no serial data.
Are there other serial speeds or parameters used by the ME units? Or does one need to enable the serial functionality somehow first?

@kayno, how do you send a command to one specific client?
I have 6 zones and if I send heatpump/set as per your sketch it turns them all on.
Do we need to change the topic to be "/heatpump/clientid/set" ?

Is anyone seeing this?

I'm getting vane, fan, and mode coming through blank every now and then. Its very strange. When this happens it seems to never update the current settings so it fires the settings changed event every single time.

src\HeatPump.h:136:33: warning: converting to non-pointer type 'byte {aka unsigned char}' from NULL [-Wconversion-null]

  void sync(byte packetType = NULL);

src\HeatPump.cpp:324:48: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]

  packetCallback(packet, length, "packetSent");

src\HeatPump.cpp:387:58: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]

  packetCallback(packet, PACKET_LEN, "packetRecv");

Not awesome at cpp but suggested solutions?

1

void sync(byte packetType = 99);

if(packetType != 99) {
    packet[5] = INFOMODE[packetType];
} else {
    packet[5] = INFOMODE[infoMode ? 1 : 0];
    infoMode = !infoMode;
}

2,3 should be ok by casting?

packetCallback(packet, length, (char*)"packetSent");
packetCallback(packet, PACKET_LEN, (char*)"packetRecv");

Can you reopen #74 please?

I posted an answer after close but I can’t reopen by myself..

Hi there

Sorry if this is the wrong place to ask but on your demo circuit you have VCC, RST and CH_PD all connected together - whats the purpose of these connections?

Jake

What are the Resistors purpose in this diagram?

I have my SVZ heatpump connected to a Nodemcu. This one has an onboard regulator, so I have the 5V from the Mitsubishi unit connected to the 5V of the Nodemcu. I can transmit data and was able to set the desired setting (e.g. cool, low fan) to the unit. However, no data is being transmitted back, neither the temperature.

The RX/TX are ok though, I tested this.

I do use the pullup resistors on RX and TX.

if update() is called and some new wantedSettings are transmitted, the callback is not triggered because currentSettings are assigned to wantedSettings if the lastUpdateSuccessful is true (thus when settings message is received, currentSettings is already equal to receivedSettings, but no callback was triggered).

currentSettings should probably only be updated by receiving a settings message from the HP.

I remove this code in update()

if(lastUpdateSuccessful) {
currentSettings = wantedSettings;
}

if I get around to testing or someone confirms it's a problem in here and not something I did in my fork I'll submit a pull request

Currently when the code starts, currentSettings and wantedSettings is set to:

• POWER: OFF
• MODE: FAN
• TEMP: 22
• FAN: 1
• VANE: 1
• WIDEVANE: SWING

Once connect is done and we are syncing, only currentSettings is updated, not wantedSettings. This means if you call setPowerSetting("ON") and call update() to make it happen, your heatpump is set to ON with the other settings as the defaults, and not what the currentSettings are based on the last time the unit was running (in my case this is usually my "default" setting: AUTO/another temp/SWING/SWING/SWING).

This becomes a problem when the likes of home assistant has consumed the retained status message. You can see this in the messages that occur (annotated to show what's happening:

$ mosquitto_sub -h localhost -p 1883 -v -t 'heatpump/#'
heatpump {"power":"OFF","mode":"AUTO","temperature":27,"fan":"AUTO","vane":"SWING","wideVane":"SWING"} // last known settings of heatpump, matching what it was last set to

// ESP8266 boots up


heatpump/temperature {"roomTemperature":24} // reports temp every 60s
heatpump/temperature {"roomTemperature":24} // reports temp every 60s
heatpump/set {"power": "ON"} // in home assistant, I press the switch to switch it on (leaving all other settings as they are, which currently replicates retained status message above). This sends the power command which calls setPowerSetting() which just changes wantedSettings.power, and then update() is called
heatpump {"power":"ON","mode":"FAN","temperature":22,"fan":"1","vane":"1","wideVane":"SWING"} // heatpump now on, but all the other settings have changed because wantedSettings was still on the defaults for the others, and hadn't been synced

// I then go and set the other settings how i want them
heatpump/set {"temperature": 22}
heatpump {"power":"ON","mode":"FAN","temperature":22,"fan":"1","vane":"1","wideVane":"SWING"}
heatpump/set {"mode": "AUTO"}
heatpump/set {"fan": "AUTO"}
heatpump {"power":"ON","mode":"AUTO","temperature":22,"fan":"AUTO","vane":"1","wideVane":"SWING"}
heatpump/set {"vane": "SWING"}
heatpump/set {"temperature": 25}
heatpump/set {"temperature": 26}

// eventually it's back to my "default" settings
heatpump {"power":"ON","mode":"AUTO","temperature":26,"fan":"AUTO","vane":"SWING","wideVane":"SWING"}
heatpump/set {"power": "OFF"} // and I power down the heatpump
heatpump {"power":"OFF","mode":"AUTO","temperature":26,"fan":"AUTO","vane":"SWING","wideVane":"SWING"} // and get confirmation with a new retained message showing the status
heatpump/temperature {"roomTemperature":24}

//  next time I power it up, it's all good, because wanted settings has been updated with each change above.
heatpump/set {"power": "ON"}
heatpump {"power":"ON","mode":"AUTO","temperature":26,"fan":"AUTO","vane":"SWING","wideVane":"SWING"}

I think wantedSettings should be left as unset and not set by the constructor, and then in getData() when a settings packet comes in we check to see if it's unset (indicating script has just started and this is the first settings packet we have recived), and set it to currentSettings.

When I have some time I will code this up - just wanted to get it logged as an issue while it's on my mind!

I have been doing some experimenting with my heat pump. I found if you send a request packet (0x42) with a 0x09 in byte 5 (0xfc is 0) you get a packet with a few info bytes. Here is what I found so far.

Examples:
fc 62 01 30 10 09 00 00 00 01 01 00 00 00 00 00 00 00 00 00 00 52
fc 62 01 30 10 09 00 00 00 03 02 00 00 00 00 00 00 00 00 00 00 4f
fc 62 01 30 10 09 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 4c
fc 62 01 30 10 09 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 52

Byte 8:
0x04 is preheating
0x08 is standby or waiting, In a multi head system if others are already heating and one wants to cool it goes to this mode.

Byte 9: Heating or cooling stage.
0x01 to 0x04, in heating 0x01 is lowest power 0x05 is highest output

Byte 10:
Only in "Auto" mode is shows what the unit is doing
0x01 is cool
0x02 is heat

In the examples above #1 is Auto mode calling for low cooling
#2 is Auto mode calling for 3rd stage heating
#3 is Waiting (other units in cool while calling for heat)
#4 is Heating mode at stage 2. Looks the same for cooling mode at stage 2

I also purchased a MHK1 thermostat for one of my units to figure out how it works. Because you can set it up to sense temperature at the thermostat, it sends an "external room temp" packet.

It looks like this:
fc,41,01,30,10,07,01,00,ad,00,00,00,00,00,00,00,00,00,00,00,00,c9

Byte 8 is the room temp in the normal hi resolution formula ((n -128)/2)= deg c

the unit responds with:
fc,61,01,30,10,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,5e

For the most part the thermostat send the same commands for power, fan, vane and such. It never uses "Auto" mode, it figures out the temp difference and sets the unit in cool or heat accordingly, and sends a setpoint for each.

Lastly, there is a byte 5 0x04 info packet that can be requested, I think it is a error information packet. For me it always responds with 0x80 in byte 9. Based on this 0x80 is "normal operation" . I have no way to test this, so it is only speculation. My thermostat requests that packet constantly.

I'm loving this library and set up controllers for my four MSZ-GL06NA heatpumps, each running the standard mqtt example (modified only with my config details). It's really awesome!

However, I'm seeing some odd behavior around reporting room temperature if the unit is not actively "operating" to heat or cool the room and I can't figure out whether it is an issue with my heat pumps, the library, or the sketch. Basically, while the unit is heating or cooling to get to the target temperature, it reports the room temperature with relative accuracy. However, once it has gotten to that target temperature (or a few degrees past it), it seems to stop sending accurate temperature readings (essentially ignoring natural temperature changes that would take the room well beyond the target).

Here's a specific example -- last night we had the units set to "HEAT" with a target temp of 20 C / 68 F. It accurately reported the current room temperature when I first set it (18 C / 64.5 F) and while it was operating to heat up to the target. In the morning, though, the room started to heat up on its own from the sun coming in the windows and got well above the target temperature. But no matter how hot it got in the room, the heat pump never reported that it was more than 22.5 C / 72.5 F. When I switched the units to cool, the unit immediately started reporting the accurate room temperature (24.5 C / 76 F). My units all do this and they do it consistently, even with much larger discrepancies in the temperature, where the reported temperature will be off by 8-10 degrees F and then immediately correct themselves when the mode is switched.

Here's a look at the MTQQ messages that are being generated from that specific example:

hp/3 - {“power":"ON","mode":"HEAT","temperature":20,"fan":"AUTO","vane":"AUTO","wideVane":"|"}
… [several hours]
hp/3/status - {“roomTemperature":22.5,"operating":false}
hp/3/status - {“roomTemperature":22.5,"operating":false}
hp/3/status - {“roomTemperature":22.5,"operating":false}
hp/3/status - {“roomTemperature":22.5,"operating":false}
hp/3 - {“power":"ON","mode":"COOL","temperature":20,"fan":"AUTO","vane":"AUTO","wideVane":"|"}
hp/3/status - {“roomTemperature":24.5,"operating":false}
hp/3/status - {“roomTemperature":24.5,"operating":true}
hp/3/status - {“roomTemperature":24.5,"operating":true}
hp/3/status - {“roomTemperature":24.5,"operating":true}

As you can see the reported roomTemperature immediately jumps from 22.5 to 24.5 when the mode is changed from HEAT to COOL.

I've looked through the code for the library and the sketch, but I don't understand it well enough to tell whether the issue is with the heat pump itself reporting the wrong temperature when requested or if there's something about the library that isn't requesting or correctly updating the status under those circumstances.

Has anyone else come across this? Any ideas?

Currently when the heatpump starts up (e.g. after a power outage/disconnection from power supply) the ESP8266 has to wait for some time before connect() will work. We should add some code to detect if the heatpump is connected or not, so that connect can be called. And by "add come code", I don't mean delay(99999) :)

I like the way the Arduino pubsubclient for MQTT does this:

while (!mqtt_client.connected()) {
    // Attempt to connect
    if (mqtt_client.connect(client_id, mqtt_username, mqtt_password)) {
      mqtt_client.subscribe(heatpump_set_topic);
    } else {
      // Wait 5 seconds before retrying
      delay(5000);
    }
  }

The looping until connected is done in the user's sketch, not the library, which i think is the way to go. Allows the user to control how they deal with connecting, and what they want to do if it can't connect. We could allow for something like this:

while(!hp.connected()) {
  delay(2000);
  hp.connect();
}

Or if we could get connect() to detect if connect has worked, return a true/false value for the user to use, like they do in the mqtt example, except for heatpump it would look like:

while (!hp.connected()) {
  // Attempt to connect
  if (!hp.connect()) {
    // Wait 5 seconds before retrying
    delay(5000);
  }
}

So we just need to figure out a) how can we determine at anytime if we are connected to the hp, which will define what connected() returns, and b) how can we tell if connect() has worked or not.

I note from debugging that when I connect() to my heatpump I get back some packets we don't handle:

heatpump/debug {"packetSent":"fc 5a 01 30 02 ca 01 a8 "} // sending CONNECT[8] packet once
heatpump/debug {"packetSent":"fc 5a 01 30 02 ca 01 a8 "} // sending CONNECT[8] packet twice
heatpump/debug {"packetSent":"fc 42 01 30 10 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7b "} // sending a request for settings (sync() called from mqtt example)
heatpump/debug {"packetRecv":"fc 7a 01 30 01 00 54 00 38 ec fe 3f d8 04 10 40 c0 87 fe 3f 00 00 "} // what is this response - 7a??
heatpump/temperature {"roomTemperature":0} // mqtt example script reporting temperature, which hasn't been obtained from heatpump yet. should handle this (not a library issue, but an example issue)
heatpump/debug {"packetRecv":"fc 7a 01 30 01 00 54 00 5c ea fe 3f 10 3d 20 40 60 ea fe 3f 00 00 "} // another 7a packet, different data to last one... what is 7a? was it sent twice because we sent CONNECT[8] twice?
heatpump/debug {"packetRecv":"fc 62 01 30 10 02 00 00 00 08 08 00 00 00 00 0c ae 00 00 00 00 91 "} // finally a response to our request for settings, we now know the settings
heatpump {"power":"OFF","mode":"AUTO","temperature":23,"fan":"AUTO","vane":"AUTO","wideVane":"SWING"} //mqtt example reports settings (callback fired)
heatpump/debug {"packetSent":"fc 42 01 30 10 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7a "} //request room temp
heatpump/debug {"packetRecv":"fc 62 01 30 10 03 00 00 0b 00 00 aa 00 00 00 00 00 00 00 00 00 a5 "} //room temp response - we now know room temp
heatpump/temperature {"roomTemperature":21} //mqtt example reports room temp (callback fired)
heatpump/debug {"packetSent":"fc 42 01 30 10 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7b "} // periodic request settings - now into the normal sync() rhythm 
heatpump/debug {"packetRecv":"fc 62 01 30 10 02 00 00 00 08 08 00 00 00 00 0c ae 00 00 00 00 91 "}// periodic receive settings
heatpump/debug {"packetSent":"fc 42 01 30 10 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7a "}// periodic request room temp
heatpump/debug {"packetRecv":"fc 62 01 30 10 03 00 00 0b 00 00 aa 00 00 00 00 00 00 00 00 00 a5 "}// periodic receive  room temp

Perhaps the 0x7a is a connect() response?

And as for periodically determining if we are connected(), I am not sure how to do this. Perhaps if we don't get a response from a sync() call, we just assume we are disconnected? perhaps if it's 5 missed responses to a sync() request? I need some input from everyone on this one :)

I have run into an odd issue. If I put more than 17 characters into heatpump_topic, it fails to publish and instead dumps the failed to publish warning. I tried tons of combinations until I realized it seems to be limited to any 17 or less characters including any "/" topic separators.

It only happens to the hpsettingschanged publish void. I replaced the json "buffer" variable with "test" and then I could put whatever topic I wanted. The other voids for status and timers are happy with nice and long topics.

I see in #37 that @kayno uses "home/living-area/heatpump" (which I also tried) This is over 17 so I don't understand why mine won't accept it. I'm using the mqtt_esp8266 example code. Only thing changed is the ssid, password, and topics in the .h file.

Using a huzzah.

Hi,

if for whatever reason after a successful update the call to sync(RQST_PKT_SETTINGS) inside update() method fails

if(packetType == RCVD_PKT_UPDATE_SUCCESS) {
// call sync() to get the latest settings from the heatpump, which should now have the updated settings
sync(RQST_PKT_SETTINGS);
...

beiing that still stands wantedSettings != currentSettings any following sync() gets stuck into trying to update again and again...

It should be checked that sync(RQST_PKT_SETTINGS) is successful and take appropriate actions if not!

Cheers

Hold my hand here? :)

I see the links to digikey parts, but I'm not entirely sure how to make these pigtails. Do you need a crimping tool of some sort? Five contacts per housing?

Hi there,

Great work on this one. I just bought a house with 4 x Mitsi heat pumps and I use Home Assistant now so quite fizzed when I discovered your repo! Here's hoping the inverters are the right model. Instead of using a 01 chipset, could you use one of the above boards to negate the use of the 5v reg? Would you still need the 10k pullups on the Tx and Rx lines?

I have the MQTT example and running 95%

I do have an issue with the remoteTemp

When I publish as example - {remoteTemp:24} to the heatpump/set topic the HP is returning 10
I have tried with different temperature settings with the same result.

When I publish{remoteTemp:0} it returns to use the internal temperature sensor.

Anyone have an idea what is wrong?

@kayno
I plan to make an example sketch that will allow OTA updates. I have been reading up on it and will probably tackle that after work. Seems pretty straight forward. It is basically two sketches mixed into one, where one part is the OTA listener and the rest is what ever you want.

Hi All

I have my ESP8266 connected to my MQTT broker, I can see all Packet sent, but when I try the heat pump/set I get : invalid J SON on heat pump_set_topic.

Anyone have the correct syntax of the payload, so I can narrow out the payload as error?

Hello @kayno , @SwiCago, I've discovered a little bug that I do not know is due. If I start the heat pump in ventilation mode from mosquitto and then change the mode to cold from the control or from the thermostat, and then turn off the pump from mosquitto the pump is turned off in ventilation mode and not in cold mode as it should be, it seems Which does not store the changes made in the operating mode (fan, cool, etc ...) from the thermostat or the control when turning off from mosquitto.

Thanks