Sometimes, values do not update or revert after seconds

[Sprinterfreak]

My setup:

• Home Assistant
• esp32dev boards without pullups and without level-shifter on Serial0
• Software + #189
• 3x MSZ-AP20VGK

Despite the fact, that the unit get the POST text messages thrown at it and sometimes going nuts on ESP boot the thing works in general on my MSZ-AP20VGK.

There is of course a slight instability. When I change some attributes via HA, like fan or temp or vanes, the unit won't react and the old setting appears again in HA after a few seconds. Sometimes I have to "fight" the settings in a few times until it stays. This is particularly annoying with automations and scenes. HA sends it correctly via MQTT.

Does anyone observe this behavior too?

[gysmo38]

Yes I am aware of this. In fact, sometimes the command take time to be send to the unit and unit take time to send answer. For HA side, the code send MQTT packet directly after a command receive to look reactive. Sometimes, the unit send a packet with old values. I will try to find a solution, maybe ignore message from unit during a laps of time after receive a command.

[logon84]

I found this project because I was looking for a tasmota alternative for the mitsubishi heatpump because this behaviour happens there too. The thing is, some years ago, I was using the swicago project, just the mqtt example that can be found there and this problem wasn't present. Looking forward for a fix.

[Sprinterfreak]

Today one got stuck again. It happened after home assistant activated a scene, and sent:

mitsubishi2mqtt/HVACSchlZ/power/set ON
mitsubishi2mqtt/HVACSchlZ/mode/set heat
mitsubishi2mqtt/HVACSchlZ/temp/set 19.0
mitsubishi2mqtt/HVACSchlZ/vane/set 5
mitsubishi2mqtt/HVACSchlZ/fan/set AUTO

The ESP responded with

mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability online
mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability online
...

each online and offline message was a few seconds up to minutes appart. I then tried sending mitsubishi2mqtt/HVACSchlZ/system/set reboot or /debug/packets/set on quickly after an LWT online message. It didn't seem to react to it. The device was pnigable but with huge spikes in latency. The webpage didn't respond at all.

Then I sent the device a Wifi deauth which resulted in it to eventually opening it's own wifi. I connected to it and just hit reboot. It then connected back to my wifi and did exactly the same. Occasionally publish LWT online/offline.

Then I activated the home assistant scene again.

mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability online
mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/availability online
mitsubishi2mqtt/HVACSchlZ/power/set ON
mitsubishi2mqtt/HVACSchlZ/mode/set heat
mitsubishi2mqtt/HVACSchlZ/temp/set 19.0
mitsubishi2mqtt/HVACSchlZ/vane/set 5
mitsubishi2mqtt/HVACSchlZ/fan/set AUTO
mitsubishi2mqtt/HVACSchlZ/availability offline
mitsubishi2mqtt/HVACSchlZ/system/set reboot
mitsubishi2mqtt/HVACSchlZ/availability online
mitsubishi2mqtt/HVACSchlZ/power/set ON
mitsubishi2mqtt/HVACSchlZ/mode/set heat
mitsubishi2mqtt/HVACSchlZ/temp/set 19.0
mitsubishi2mqtt/HVACSchlZ/vane/set 5
mitsubishi2mqtt/HVACSchlZ/fan/set AUTO
mitsubishi2mqtt/HVACSchlZ/debug/packets {"roomTemperature":0,"temperature":0,"fan":null,"vane":null,"wideVane":null,"mode":"heat","action":"heating","compressorFrequency":0}
mitsubishi2mqtt/HVACSchlZ/state {"roomTemperature":0,"temperature":0,"fan":null,"vane":null,"wideVane":null,"mode":"heat","action":"heating","compressorFrequency":0}
mitsubishi2mqtt/HVACSchlZ/debug/packets {"roomTemperature":0,"temperature":19,"fan":null,"vane":null,"wideVane":null,"mode":"heat","action":"heating","compressorFrequency":0}
mitsubishi2mqtt/HVACSchlZ/state {"roomTemperature":0,"temperature":19,"fan":null,"vane":null,"wideVane":null,"mode":"heat","action":"heating","compressorFrequency":0}
mitsubishi2mqtt/HVACSchlZ/debug/packets {"roomTemperature":0,"temperature":19,"fan":null,"vane":"5","wideVane":null,"mode":"heat","action":"heating","compressorFrequency":0}
mitsubishi2mqtt/HVACSchlZ/state {"roomTemperature":0,"temperature":19,"fan":null,"vane":"5","wideVane":null,"mode":"heat","action":"heating","compressorFrequency":0}
mitsubishi2mqtt/HVACSchlZ/debug/packets {"roomTemperature":0,"temperature":19,"fan":"AUTO","vane":"5","wideVane":null,"mode":"heat","action":"heating","compressorFrequency":0}
mitsubishi2mqtt/HVACSchlZ/state {"roomTemperature":0,"temperature":19,"fan":"AUTO","vane":"5","wideVane":null,"mode":"heat","action":"heating","compressorFrequency":0}
mitsubishi2mqtt/HVACSchlZ/settings {"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat"}
mitsubishi2mqtt/HVACSchlZ/power/set ON
mitsubishi2mqtt/HVACSchlZ/mode/set heat
mitsubishi2mqtt/HVACSchlZ/temp/set 19.0
mitsubishi2mqtt/HVACSchlZ/vane/set 5
mitsubishi2mqtt/HVACSchlZ/fan/set AUTO
mitsubishi2mqtt/HVACSchlZ/debug/packets {"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat","action":"heating"}
mitsubishi2mqtt/HVACSchlZ/state {"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat","action":"heating"}
mitsubishi2mqtt/HVACSchlZ/debug/packets {"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat","action":"heating"}
mitsubishi2mqtt/HVACSchlZ/state {"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat","action":"heating"}
mitsubishi2mqtt/HVACSchlZ/debug/packets {"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat","action":"heating"}
mitsubishi2mqtt/HVACSchlZ/state {"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat","action":"heating"}
mitsubishi2mqtt/HVACSchlZ/debug/packets {"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat","action":"heating"}
mitsubishi2mqtt/HVACSchlZ/state {"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat","action":"heating"}
mitsubishi2mqtt/HVACSchlZ/state {"roomTemperature":20,"temperature":19,"fan":"AUTO","vane":"5","wideVane":"|","mode":"heat","action":"idle","compressorFrequency":0}

Voila, it came back. Interestingly some values in the /state topic where null, which I think should not happen? Also if one mitsubishi2mqtt device gets stuck, the entire shared HVAC system (1 outdoor unit, 4 indoor units) stop working.

Could it be that mitsubishi2mqtt floods the HVAC bus with malformed packets in that case?

[berdi340]

Hello, I have the same problem with jeedom and mqtt, randomly the commands are sent to esp (log) but not to the unit.

[danielgoepp]

I experience this too, as clearly the author does too as he stated above he is aware. I'm going to try to run some debug to provide specific examples of conditions that reproduce, but I have not yet. Interestingly, the order of operations seemed to affect this, also the delay. If I put set temp first, 10s delay, then set fan mode second, 10s delay and then HVAC to cool...it works. However if I put set HVAC mode first, things were not so good. This is a curious one. If I can be of any assistance in testing, lemme know, I have units that are non-critical that I can break all day long.

[danielgoepp]

I'm curious if anyone has further thoughts or work arounds on this? For my time based automations I have just put in longer delays between commands (I started at 10 seconds, but even this was not reliable enough, so I have them at 30 seconds now). However there are times when I want to have a action from a user (wife) and do three things...she is not a fan of waiting a minute and a half just to set the mode of a unit. Sounds like this is actually a problem with the unit itself and what it reports back? I'm just wondering what other folks are doing / experiencing here? Thanks!

[danielgoepp]

For what it is worth, I think I discovered that even my putting in delays work around is not really doing what I need either. I have an automation that only does one thing, and that is turn off. It ran last night, and immediately was reverted, with no other changes being made right before it:

2023-03-17T02:01:39-04:00 mode="cool" action="idle" compressorFrequency="0" roomTemperature="68" temperature="68" fan="2" vane="1" wideVane="|" 
2023-03-17T02:02:09-04:00 mode="cool" action="idle" compressorFrequency="0" roomTemperature="68" temperature="68" fan="2" vane="1" wideVane="|" 
2023-03-17T02:02:39-04:00 vane="1" wideVane="|" mode="cool" action="idle" compressorFrequency="0" roomTemperature="67" temperature="68" fan="2" 
2023-03-17T02:03:09-04:00 compressorFrequency="0" roomTemperature="67" temperature="68" fan="2" vane="1" wideVane="|" mode="cool" action="idle" 
2023-03-17T02:03:39-04:00 vane="1" wideVane="|" mode="cool" action="idle" compressorFrequency="0" roomTemperature="67" temperature="68" fan="2" 
2023-03-17T02:04:09-04:00 fan="2" vane="1" wideVane="|" mode="cool" action="idle" compressorFrequency="0" roomTemperature="67" temperature="68" 
2023-03-17T02:04:39-04:00 roomTemperature="67" temperature="68" fan="2" vane="1" wideVane="|" mode="cool" action="idle" compressorFrequency="0" 
2023-03-17T02:05:06-04:00 mode="off" action="off" compressorFrequency="0" roomTemperature="67" temperature="68" fan="2" vane="1" wideVane="|" 
2023-03-17T02:05:06-04:00 value="off" 
2023-03-17T02:05:25-04:00 wideVane="|" mode="off" action="off" compressorFrequency="0" roomTemperature="67" temperature="71" fan="2" vane="1" 
2023-03-17T02:05:55-04:00 vane="1" wideVane="|" mode="cool" action="idle" compressorFrequency="0" roomTemperature="67" temperature="71" fan="2" 
2023-03-17T02:06:26-04:00 vane="1" wideVane="|" mode="cool" action="idle" compressorFrequency="0" roomTemperature="67" temperature="71" fan="2" 
2023-03-17T02:06:56-04:00 wideVane="|" mode="off" action="off" compressorFrequency="0" roomTemperature="67" temperature="71" fan="QUIET" vane="1" 
2023-03-17T02:07:26-04:00 wideVane="|" mode="off" action="off" compressorFrequency="0" roomTemperature="67" temperature="71" fan="QUIET" vane="1" 
2023-03-17T02:07:56-04:00 vane="1" wideVane="|" mode="off" action="off" compressorFrequency="0" roomTemperature="67" temperature="71" fan="QUIET" 
2023-03-17T02:08:26-04:00 wideVane="|" mode="off" action="off" compressorFrequency="0" roomTemperature="67" temperature="71" fan="QUIET" vane="1" 
2023-03-17T02:08:56-04:00 fan="QUIET" vane="1" wideVane="|" mode="off" action="off" compressorFrequency="0" roomTemperature="67" temperature="71" 
2023-03-17T02:09:26-04:00 roomTemperature="67" temperature="71" fan="QUIET" vane="1" wideVane="|" mode="off" action="off" compressorFrequency="0" 
2023-03-17T02:09:56-04:00 vane="1" wideVane="|" mode="off" action="off" compressorFrequency="0" roomTemperature="67" temperature="71" fan="QUIET" 
2023-03-17T02:10:26-04:00 roomTemperature="67" temperature="71" fan="QUIET" vane="1" wideVane="|" mode="off" action="off" compressorFrequency="0" 

[prashker]

Seems this is a common problem, just adding my experience to it. I found configuring using the thermostat control itself to be too annoying, so I setup my schedule via HA - the MQTT set is being called, but as others have said, seems to either never set or quickly reverts.

At least on HA side I'm considering adding a retry-mechanism, or more specifically (as the explanations above seem to imply command works, but reverts) a repeat-reapply.

[danielgoepp]

@prashker I ended up creating a node-red flow to do just that. I'd be happy to share if you are interested. I hope someday to dig into the actual code to see if we can find the problem and fix it. But for now, this at least keeps my wife happy ;) This flow basically records every requested state, and then on every update of current state compares the two, and if they are different, sents the set again. It sometimes takes a few retries.

[prashker]

@danielgoepp Feel free to send what you can, I'm stuck between fixing it properly or - like you - doing whatever to make the wife happy!

From the perspective of fixing this properly, would need to properly debug and replicate so that testing a fix was easier to do - I will see what info I can scrape from debug info.

From the perspective of just getting something working, I'm tempted to just to a repeat 5 times: sleep 15 seconds, resend command and be done with this!

[danielgoepp]

It's not pretty, but you are welcome to use it : https://hastebin.com/share/gicakuhale.swift Yes, I know I could have done this more efficiently with functions, but I liked the visuals of seeing all the current requested states. Also, of course you would need to be running node-red for this to work. Let me know how things going, I'm very curious on this one.

[Sprinterfreak]

I do it in HASS automations like this

- id: '1669209521130'
  alias: Klima
  description: Post new values to HVAC 3 times
  action:
  - service: scene.create
    data:
      scene_id: climate_tmp
      entities:
        climate.hvac:
          state: heat
          temperature: 20
          fan_mode: AUTO
          swing_mode: 5
  - repeat:
      count: '3'
      sequence:
      - service: scene.turn_on
        target:
          entity_id: scene.climate_tmp
        metadata: {}
      - delay:
          hours: 0
          minutes: 0
          seconds: 30
          milliseconds: 0
  mode: single

This has a pretty good chance, that the HVAC eats the settings. Otherwise they tend to get stuck offline #211. It does not cover manual changes of course.

[logon84]

Just an idea. On Swicago's HeatPump.cpp file, I see a check for RCVD_PKT_UPDATE_SUCCESS. From what I understand, if the heatpump took the settings correctly, it send this RCVD_PKT_UPDATE_SUCCESS packet. But I don't see any reference to RCVD_PKT_UPDATE_SUCCESS in this code....could this be the issue?

[prashker]

SwiCago's codebase seems to work in this manner - when you set something, it "queues" it by making it the "wanted settings" and either explicitly by end user, you call update() or automatically via enableAutoUpdate() (which Mitsubishi2MQTT leverages) - which ultimately:

• Sends the packet with all the new settings to HVAC (and checks for RCVD_PKT_UPDATE_SUCCESS)

I'm just trying to see the core "loop" and how it works in autoUpdate and externalUpdates scenarios....need to dig deeper - but don't believe a lack of handling that packet is the issue. Seems like a read/write loop and during read if auto update is enabled, it tries to set the wantedSettings.

My interpretation of the above is Mitsubishi2MQTT is not responsible at all for any potential rollback of settings, as it basically offloads everything to the library.

There's maybe an argument here to have Mitsubishi2MQTT re-submit its request a few times - might be a hack, but maybe making it configurable for end user until upstream can potentially sort out this issue.

Regarding the "perception of a revert" - I believe https://github.com/gysmo38/mitsubishi2MQTT/blob/master/src/mitsubishi2mqtt/mitsubishi2mqtt.ino#L1365 is responsible. We're updating the local state before the unit actually confirms the state changes, and when the next original state from HVAC comes back, it reverts what Mitsubishi2MQTT sees.

So I definitely believe this is upstream, but I may try and "fix" this here.

[logon84]

I analyzed the tasmota code about this issue sometime ago. What I saw is not a rollback of settings itself, but an ignored settings frame by the heatpump. Then, after this frame was ignored, the code looked again for settings, so what the user sees after, let's say, trying to turn on the heatpump is OFF->SET ON-> ON->OFF. But in fact the device was OFF all the time because due to some reason, the setting on was never received.

Edit: so my idea was that maybe we can try to send settings in a while + delay loop until we get the RCVD_PKT_UPDATE_SUCCESS

[prashker]

Agreed with above assessment, I think this is an issue with the upstream "externalUpdates" handling. It doesn't confirm if wanted settings were actually applied before assuming the settings coming from the thermostat is correct.

It's possible we can recompile Mitsubishi2MQTT without hp.enableExternalUpdate(); and observe behavior. You'd lose out on external updates, but would prevent this code upstream from clobbering the requested automated change.

              if(firstRun || (autoUpdate && externalUpdate)) {
                wantedSettings = currentSettings;
                firstRun = false;
              }

But I am of firm belief that this is upstream problem.

[danepowell]

Just to be clear, disabling updates would be a great way to test this but please don't release it as a fix or workaround. I still use IR remotes in addition to MQTT to manage mini splits.

[prashker]

Agreed it's not a generalized solution. I will recompile my local instance without external updates and test as much as I can there.

What we really need, is a way to reproduce the issue, such that we can raise a proper issue with SwiCago library.

[GhyslainBruno]

Hi all,

I'm using this lib with a PEAD-SM50JA and it works pretty well, even if I'm experiencing the issue you are all mentioning.

Just to mention (I don't know if that'll be useful or not), it seems there is a "state" displayed as "waiting heating" on the remote display provided with my HeatPump, and when the HP is in that state, no setting can be set using this lib.

As a workaround I'm retrying to set the setting using a custom NodeJS script (until both states are equals), which works really well, but it's only a workaround.

In any case, I hope this comment can be useful to some C++ master 😄

[prashker]

I recompiled Mitsubishi2MQTT without hp.enableExternalUpdate() and seems to be fairly reliable experience if controlled solely via automation. Obviously you lose out on external updates which is probably unacceptable for most scenarios.

Since maintaining external updates is desirable, I've attempted to a fix upstream. For more info see: https://github.com/SwiCago/HeatPump/issues/192#issuecomment-1512040314

I've been generating new binaries and flashing them via WebUI by following steps here: https://github.com/gysmo38/mitsubishi2MQTT/discussions/210 - maybe this is elementary but forgive me I am very new to Arduino.

[danielgoepp]

Thanks @prashker. I'm going to compile and upload now to one controller first. I'm going to use the bedroom since that is the one that if it breaks things, the wife will immediately get mad. Unfortunately, it's also the one that gets updated the most, so I'll see the fix / problems soon. Eh...life.

[prashker]

Just an update after having Mitsubishi2MQTT+HeatPump (with my grace period fix attempt). I haven't had any "did my setting apply" anxiety - been consistently working 👍

[notentirelysure85]

Just an update after having Mitsubishi2MQTT+HeatPump (with my grace period fix attempt). I haven't had any "did my setting apply" anxiety - been consistently working 👍

I've been running your fix for the last two weeks also. I have three MSZ-AP heatpumps and all three of them are working well without a single instance of the settings reverting. Great work!

[skooj]

Just an update after having Mitsubishi2MQTT+HeatPump (with my grace period fix attempt). I haven't had any "did my setting apply" anxiety - been consistently working 👍

I have also been using your update for about a week as well and the repeat-until fail-safes that I have used in my automations have not had to loop!

One thing that I have noticed while watching with MQTT Explorer, however, while setting temp is adopted almost immediately, the remote_temp command takes some time to adopt.

I may dig in to this in the next couple of weeks to see if it is an m2mqtt issue, or a heat pump library issue, but I am not sure when I will have time to look into it. Overall, it seems to be working fine, but I'm concerned that one command may drop the remote_temp like we had been seeing with everything else.

[prashker]

@skooj Thanks for the feedback, I also submitted a PR upstream as it seems stable enough for everyone that has been using it so far.

Regarding remote_temp still having a chance to "fail" - this makes sense, the only method I didn't touch was "setRemoteTemperature" as the logic to apply that to the HeatPump seems to be different than all the others (the other functions queue up as "wanted settings" that eventually get published via update() and by extension autoupdate) and setRemoteTemperature seems to generate its own packet and submits that when it can (and does not retry via autoupdate).

I can't immediately think of an obvious solution for this one - or more specifically it will be more convoluted to implement a fix, and I don't use remote temperature myself - will try and put some thought into it.

[skooj]

@prashker, That makes a lot of sense, and also makes me feel a bit more confident that it may not fail, considering it was being handled completely separate from everything else with the update(). I will attempt to monitor it over the next while and report back if I notice any issues.

So far, with quick succession of manual topic pushes, along with setting the temp in HA in quick succession of each other, both are being honored in the end, albeit just a bit slower on the remote_temp side of things. All that to say, it may be a non-issue.

The only reason I even noticed it is because the HA automation I had been using to to push the remote_temp vanished at some point (I likely deleted it accidentally while clearing out old stuff).

Thanks for taking this up and figuring it out!

[prashker]

The good news is for those coming "fresh" into this issue - if you compile HeatPump library from source when compiling mitsubishi2mqtt, you should now have my changes implemented mainline as the owner approved my pull request. See: https://github.com/SwiCago/HeatPump/pull/199

Though I do think there is a more "graceful" solution for someone more keen on source code diving, and there's still the problem above mentioned with setRemoteTemperature being untouched (aka still prone to "dropped" packets) - we are much better off than where we were when this issue was initially created.

If @gysmo38 wants to produce new flashable binaries to release with latest HeatPump library, then it saves steps for those who want to upgrade from an existing mitsubishi2MQTT instance (awesome stuff that this library allows flashing via WebUI!)

[dzungpv]

With my new update, the problem finally complete fix: you can see here: https://github.com/SwiCago/HeatPump/pull/210 and here: https://github.com/dzungpv/mitsubishi2MQTT/commit/f033d4e6b71e9cf0926b4e6ccdd50749cea40e8f