Airco off after MQTT disconnect

[PietNL]

Hi,

This could be related to my setup but I'd like to look into it and see where this comes from. The issue is that my units (2) turn off after they disconnect from the MQTT broker.

I'm hoping someone will be able to reproduce. Steps:

1. Have the aircon unit on
2. Stop the MQTT broker (Running on home assistant in my case)
3. Unit will turn off after about 2 minutes

I've looked into other reported issues but these seem to be related to the MQTT service itself and I think that in this case it could be related MHI-AC-Ctrl itself as the issue occurs whilst still being disconnected from the MQTT service. I'm not a developer myself but have some basic understanding of programming so will try to help out where possible.

My setup: Home Assistant with Mosquitto MHI-AC-Ctrl 2.03 SRK50ZS-W SRK35ZS-w

Any ideas?

[absalom-muc]

Could you provide the log from the serial debug console?

You describe 3 steps

1. Have the aircon unit on
2. Stop the MQTT broker (Running on home assistant in my case)
3. Unit will turn off after about 2 minutes

Do you restart the MQTT broker between step 2 and 3?

[PietNL]

To get the log from the serial console, just hook up the module to a laptop via usb and use the arduino software to capture the log? So the module is then connected to both the unit and the laptop? (Just want to make sure that I do not provide the module with too much power, as in both the airco and laptop powering it)

I did not restart the MQTT broker between step 2 and 3, it was still turned off at the moment the aircon unit also turned off. That's why I suspect there's something in the module itself and not in my Home Assistant/MQTT setup 🙂

[absalom-muc]

There is no problem powering it "doubled". But please keep in mind: :warning: Opening of the indoor unit should be done by a qualified professional because faulty handling may cause leakage of water, electric shock or fire! :warning:

[PietNL]

Please see attached for a serial log. Unfortunately nothing to see here when the unit turns off.. You can see where I stopped the MQTT broker (17:28:59.860) .

The unit turned off around the 17:30:55 time in the log, kept it running for a couple of seconds after that but nothing showed up. serial log.txt

[absalom-muc]

Sorry, spontaneously I have no idea what happened. I have to think about it longer ...

[absalom-muc]

Please insert some debug prints (row 109 in MHI-AC-Ctrl-core.cpp):

void MHI_AC_Ctrl_Core::set_power(boolean power) {
    Serial.print("set_power changed to ");
    Serial.println(power);
    new_Power = 0b10 | power;
}

void MHI_AC_Ctrl_Core::set_mode(ACMode mode) {
    Serial.print("set_mode changed to ");
    Serial.println(mode);
    new_Mode = 0b00100000 | mode;
}

and retest it.

[PietNL]

Thanks! Will try that later. I'm wondering, could it be that the unit expects some kind of ping/keepalive on the SPI side (from the module) that will not be sent as soon as the MQTT client goes into a reconnect loop?

[absalom-muc]

Thanks! Will try that later. I'm wondering, could it be that the unit expects some kind of ping/keepalive on the SPI side (from the module) that will not be sent as soon as the MQTT client goes into a reconnect loop?

That was a great idea @PietNL 👍

After some testing I can confirm the following behaviour when the last command to the AC was send via SPI and not via the IR-RC: If there is a stuck-at 0 or stuck-at 1 on the MISO pin then it takes 120 seconds until the AC goes into an error state (MQTT topic Errorcode=1) and the AC switches off. You can leave the error state by sending a command via IR-RC (also if MISO is still stucked) or by sending a command via SPI (of course MISO stuck has to be released). I assume this is some kind of safety function.

[PietNL]

Haha, happy to help! Thanks for testing and confirming!

So, is there anything that can be coded in the MQTT reconnect loop to prevent this from happening? (or maybe also in the Wi-Fi reconnect stuff? I'm experiencing this issue because my wifi to the unit is pretty unstable at times)

[absalom-muc]

Sorry, but I don't plan to implement a workaround because I would expect a massive impact on the software and from my point of view the effort is not justified.

[PietNL]

I've been thinking about this, would it be an option to restart the module after let's say 5-10 MQTT reconnects or something? If I'm correct this would re-initialize the SPI connection and work around this issue isn't it?

[absalom-muc]

I believe it will not work because the SPI communication is only started after WiFi and MQTT is established. You could try the following, replace row 62 of support.cpp while (!MQTTclient.connected()) { // Loop until we're reconnected by if(!MQTTclient.connected()) { // Loop until we're reconnected It prevents hanging in the MQTT reconnect loop, but I've not tested it and I'm not sure if there are any side effects.

[al400k]

i have the same problems with some of my AC units (i have 4 with MHI-AC-Ctrl). some of them can switch off by itself, nothing strange in MQTT logs. usually the problem with 2 units that have bad wifi coverage. Sometimes switching Off/on AC(and MHI-AC-Ctrl) power helps.

[WorlockM]

I do not really see this as a problem. When for some reason your MQTT server (or even your wifi module) stops working, it feels comforting to me knowing that the AC will turn off by itself. I think that's a nice safety feature because I might not even be home and I can't turn the AC of from where I am if MQTT does not work.

By the way, I never ever experienced that my MQTT server stops working suddently. I might restart it myself because I am updating it, but that doesn't take 2-3 minutes.

[absalom-muc]

closed since there was no update for a long time. Please feel free to re-open in case of follow-up topics.

[buennerbernd]

I have also observed that the AC turns off by itself sometimes.

My setup: SRK35ZS-S 2.6R2 WIFI: a mesh with 3 access points and the same SSID (one is really the closest) MQTT-Broker: FHEM Built-in MQTT2_SERVER

My first countermeasure: set WiFI_SEARCHStrongestAP false Since that change there was not much reason for heating, but I have not observed that the AC turns off anymore.

My proposal: Especially when the AC is powered on, SPI is more important than WIFI or MQTT. The scan for networks can be done async. See: https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/scan-class.html

May be you introduce a further WiFiStatus named NETWORK_SCAN_ONGOING besides WIFI_CONNECT_ONGOING

[absalom-muc]

The switch-off happens only 120 seconds after the last SPI toggling. The WIFI search should not take more than few seconds. Before I spend the effort adapting the software, I would appreciate when we check first the source of the problem. E.g. why is the time-out of 120s not sufficient in your case?

[buennerbernd]

For now I don‘t have logs available from that happenings other than my FHEM logs. If you’re interested, I can post it. I was wondering what could hinder the loop 2 minutes from running. The only thing that was suspicious to me was the network scan.

[absalom-muc]

For now I don‘t have logs available from that happenings other than my FHEM logs. If you’re interested, I can post it.

No, thank you. I believe this effect is specific to your environment and you can do the analysis better than me.

[ihitsov]

I really like your work, but I also have the problem with my aircos randomly turning off. It happens a lot more often with the one that is further away from the router. I think its quite a severe issue since the heating the the house suddenly is turned off and the wife complains :). It would be really nice to have a solution for this.

[Deinagkistrodon]

I also experience this problem. HA is on my RPI3 and it's not fast enough to do a reboot within 120 secs. So, after every reboot my MHI-SRKZS-S turns off. For me it's a small problem in the cooling season but, as the unit is also my only source of heating, it is very inconvenient in winter as my HA reboots / lost connection to mqtt / lost connection to wifi. If this happens when I'm asleep or away it is very cold when I wake up or come home.

[absalom-muc]

Currently I don't intend to change it because it would mean a massive architecture change of MHI-AC-Ctrl software.

You could try the following work arounds:

• see above
• adapt row 397 of MHI-AC-Ctrl.ino as described here
• find out the reason for the lost WiFi / MQTT connection. Maybe it makes more sense to fix the cause than the effect