Outdoor temp/temperature step/standby power

[steeks81]

Hi,
Just wondering if it is possbile to get outdoor temperature?
I've got a couple of the new MHI unit's with in-built wifi/and reports outdoor temp correctly.
i.e. https://github.com/jeatheak/Mitsubishi-WF-RAC-Integration

Have built this hardware for slightly older unit with no wifi and trying to do same.
Poking around here https://github.com/absalom-muc/MHI-AC-Trace/blob/main/SPI.md
it mentions
21 "OUTDOOR" [°C]
Outdoor temperature [°C]=DB11

So might be possbile? I did attempt to give it a go but could not seem to get working.

Other suggestiongs, can we please get the temperature step to be configurable? My unit has 0.5 degree resolution on the remote (and the WF-RAC units all have 0.5 step), so could you expose the temperature_step_ variable? It seemed to work fine when I manually changed the code, but would be better if could set via configuration.

Lastly, for standby power, looks like it just always returns "5w" when off. This isn't always desirable when tracking energy usage. Perhaps could again configure via a parameter "Energy usage include standby" for e.g. ?

Overall, great work on this project!

[hberntsen]

Hi steeks81! Thanks for the compliment :).

I've pushed some code, including a new example.yaml that shows how to read the outdoor temperature. I was delaying pushing it because I want to be sure it is stable, it's been running fine for a few days now so I guess it is good enough already. The new set of operation data sensors are timing out a bit more often than I'd like but not too often to really be a problem. I don't own official hardware to tap communications from, so I'm doing some guesswork based on absalom-muc's repo and my own experiments. Like, when I implemented absalom-muc's double frame approach I couldn't get the operation data to work well but I have much better results with a quad-frame cycle.

About the temperature step, I'll change that to 0.5 and test adding

climate:
  - platform: ...
    visual:
      temperature_step:
        target_temperature: 1.0

to the example. I'll first test that at home before pushing it :).

The power usage you're seeing is an integration of the current values provided by the AC and multiplied with a voltage of 230V by default. I'm doing some side-by-side comparison of a Shelly Plug S with Tasmota that I calibrated by hand using a calibrated multimeter. In general, the integrated energy values are too low. It depends on how much the AC is running and how strong it is blasting heat:

In the graph you can see the yellow line for the Shelly, the blue line for power and energy based on the current(amps) value the AC provides and in red the recently added kWh sensor from the AC itself. I've just added a utility meter for the internal kWh meter of the AC so it resets daily so I can compare it better in the coming weeks.

This is over the past month, but do note that the blue AC lines are incorrect on some days because I was working on the code and it was not counting at all or was counting a frozen value. Though the general vibe is that the measurement can be off by a factor of about 1.6 at worst.

So, w.r.t. the 5W baseline: depending on how good the internal kWh sensor is, I'll remove my custom integrated sensor for the energy and power. I'll wait for that decision before I add a convenient option to change the standby value. For now, you can change it here: https://github.com/hberntsen/mhi-ac-ctrl-esp32-c3/blob/7998751717e2b8b52dbf09655498736f0f999ea4/esphome/components/MhiAcCtrl/MHI-AC-Ctrl-core.h#L180-L182

[steeks81]

Hi Harm, Thanks for your quick reply and updates! I’ve pulled the code and pretty much added in all the extra data as per new example, and outdoor temp seems to be good! Wow also a lot of extra data!! If you need help with tests on actual hardware then happy to help. Here is a sample, looks like mostly correct, not sure about some of the more in-depth readings:  However, I am able to get what I’m looking for:  Regarding the power, I was doing a similar thing, using Utility Meter to capture the daily, overall total and cycle totals as per my other MHI (the cycle one simply resets on power on, was pretty much the only one that came with the other integration) What I noticed was the cycle/daily/total meters increasing while the unit was off. I understand that technically that is probably correct, but just wasn’t wanted in my case. I did spot that location in the code to change, but rather than code change, I’m just getting around with a lambda (and similar on the energy one) e.g. power: id: ${device_id}_power name: ${device_name} Power accuracy_decimals: 2 unit_of_measurement: 'W' filters: # only send usage when actually on, value in Watts - lambda: |- if (id(${device_id}).mode != CLIMATE_MODE_OFF){ return x; } else { return 0.0; } Lastly the visual step seems to work a treat!  Esphome was prompting me for a current_temperature step value also, not sure that one is working however (could be something wrong here?) climate: - platform: MhiAcCtrl mhi_ac_ctrl_id: ${mhi_device_id} id: ${device_id} name: "${device_name}" visual: temperature_step: current_temperature: 0.5 target_temperature: 0.5 Thanks again 😊

[steeks81]

After having run this a little longer, looks like getting timeouts on the new op data.

`[11:50:52][D][sensor:093]: 'MHI AC Office Indoor': Sending state 27.50000 °C with 1 decimals of accuracy
[11:50:52][D][climate:396]: 'MHI AC Office' - Sending state:
[11:50:52][D][climate:399]: Mode: OFF
[11:50:52][D][climate:401]: Action: OFF
[11:50:52][D][climate:404]: Fan Mode: LOW
[11:50:52][D][climate:419]: Current Temperature: 27.50°C
[11:50:52][D][climate:425]: Target Temperature: 24.00°C
[11:50:52][D][main:480]: State updated, energy state 0.15397, power 0.00000
[11:51:00][D][esp-idf:000][mhi_task]: W (52085862) MHI-AC-CTRL-Operation-Data: Timeout when requesting Operation Data CompressorProtectionStateNumber

[11:51:00][D][sensor:093]: 'MHI AC Office operation data timeouts': Sending state 1337.00000 with 0 decimals of accuracy
[11:51:02][D][sensor:093]: 'MHI AC Office Indoor': Sending state 27.50000 °C with 1 decimals of accuracy
[11:51:12][D][sensor:093]: 'MHI AC Office Indoor': Sending state 27.50000 °C with 1 decimals of accuracy
[11:51:20][D][esp-idf:000][mhi_task]: W (52105862) MHI-AC-CTRL-Operation-Data: Timeout when requesting Operation Data ReturnAirTemperature

[11:51:20][D][sensor:093]: 'MHI AC Office operation data timeouts': Sending state 1338.00000 with 0 decimals of accuracy
[11:51:22][D][sensor:093]: 'MHI AC Office Indoor': Sending state 27.50000 °C with 1 decimals of accuracy
[11:51:27][D][text_sensor:064]: 'MHI AC Office Uptime': Sending state '14h 28m 33s'
[11:51:27][D][sensor:093]: 'MHI AC Office Uptime': Sending state 52113.32812 s with 0 decimals of accuracy
[11:51:32][D][sensor:093]: 'MHI AC Office Indoor': Sending state 27.50000 °C with 1 decimals of accuracy
[11:51:40][D][esp-idf:000][mhi_task]: W (52125862) MHI-AC-CTRL-Operation-Data: Timeout when requesting Operation Data IndoorUBendTemperature

[11:51:40][D][sensor:093]: 'MHI AC Office operation data timeouts': Sending state 1339.00000 with 0 decimals of accuracy
[11:51:42][D][sensor:093]: 'MHI AC Office Indoor': Sending state 27.50000 °C with 1 decimals of accuracy
[11:51:52][D][sensor:093]: 'MHI AC Office Indoor': Sending state 27.50000 °C with 1 decimals of accuracy
[11:52:00][D][esp-idf:000][mhi_task]: W (52145863) MHI-AC-CTRL-Operation-Data: Timeout when requesting Operation Data IndoorCapillaryTemperature

[11:52:00][D][sensor:093]: 'MHI AC Office operation data timeouts': Sending state 1340.00000 with 0 decimals of accuracy
[11:52:02][D][sensor:093]: 'MHI AC Office Indoor': Sending state 27.50000 °C with 1 decimals of accuracy`

After rebooting the esp (and not toucing anything to do with the AC itself), it seems to have come back ok.

Can work around with a daily reboot for now hopefully

[hberntsen]

Glad to hear the .5 degree setpoint works! I've updated the documentation.

I have also seen it constantly timeout on everything. But it is hard to debug since a re-upload of the code usually fixes it. Then, it works fine for quite some time. I have a few things I still want to try.

For now, you could try removing sensors from your yaml that you don't use as that will also not request these values from the AC.

[steeks81]

I can confirm that the current temp .5 degree resolution also works, just the format was not showing decimals when not needed :)

For the timeout issues, yeah pretty much first thing I tried was to remove all sensors that I didn't need in the hopes it would help, still doesn't seem to help.

Totally get it is hard to debug, as you say an upload/reset fixes it!.

For now I've setup an automation in HA that basically does
If MHI.uptime > 10mins && MHI.operational data timeouts > 199
then reset ESP32.

Could probably test for NAN values before rebooting, but the above seems to do ok for now.

I wonder if you could perhaps "reset" something in the code when timeouts reach a certain threshold (rather than a full esp reboot)?

Here is an example pattern of the timeouts (the first part I was rebooting @100, then changed to 200). interestingly It has a sharp increase in errors between around 20-50 to around 150/time of reboot

[hberntsen]

I've setup the logic analyser today and found a problem.

Sometimes, the frames were not correctly sent because of a timing issue in the code where we queue a SPI transaction and the send buffer was modified after doing that. Then, the AC would receive a part of an old frame and a part of a new frame. The documentation of the ESP32-C3 also says we should not modify the buffer after queueing the transaction.

I've pushed new code and I'm testing it now, seems fine so far. I hope this eliminates the need for the reset

[steeks81]

Been monitoring this for some time now, seems like the operation error rate spikes sharply every few hours, and that is when the sensors like outdoor temp become unavailable.
I set up a Derivative sensor for op error rate/min, and the spikes do line up with when HA starts showing as unavailable.
I'm rebooting the esp when the rate/min goes above 3:

Any other suggestions to cope with this better than a reboot every few hours?
EDIT, just to note, even when Outdoor temp goes Unavailable, it is still working for actual control and strangely Indoor temps still report in without issue.

[hberntsen]

Hm, I don't see these spikes on mine. This is the absolute number of operation data timeouts of last week on mine:

The top line is an AC with just a few operation data sensors, but maybe includes more problematic ones that are thus requested more often?

Are the spikes correlated with frame errors? Just for reference, this is what I have now (colors don't match the previous graph unfortunately):

The indoor temperature sensor is not part of the operation data, it is always sent, even when active mode is off.

I see some ways forward:

• Accepting some amount of timeouts before showing unknown as value
• Rewriting the algorithm that requests the operation data. But what is the correct algorithm? I get the impression that somehow my units handle the current one different than yours.

You could try toggling active mode off and on (with some time in between). I don't like that as a solution but it might be better than rebooting.

[steeks81]

There does seem to be some correlation between the frame errors and operational errors, here is graph with all

Not sure if the state of the AC itself would be related? This unit is primarily off 95% of the time.
I will try toggle active on/off instead of reboot and see what happens (I set active mode on at boot if that means anything).

EDIT. tried toggling the active on/off when gets in this state, it only had the effect of pausing the issues until was activated again. Also had the unpleasant side effect of turning the AC off when active mode toggled off.

I had about 5 of the op data sensors before, now only have outdoor temp and data timeout counter.
So far, error rate still seems to be around the same, but haven't been running it too long.
Interestingly even though I no longer request the "Current", I still see:
W (8726034) MHI-AC-CTRL-Operation-Data: Timeout when requesting Operation Data Current

I would expect to only be seeing these now:
W (8859835) MHI-AC-CTRL-Operation-Data: Timeout when requesting Operation Data OutdoorAirTemperature

[steeks81]

Looks like taking out those other couple of sensors has sorted out the "spiking" issue. Been up for couple of days now, and error rates look more like your examples with just outdoor temp included.
Not sure which was causing the issue, but the ones I took out were:
current:
energy_used:
set_temperature:
return_air_temperature:
indoor_fan_speed:

[hberntsen]

There does seem to be some correlation between the frame errors and operational errors, here is graph with all

There seems to be some correlation between the frame errors and the operation data errors in your screenshot. The communication runs at 20 frames/second. Missing a single frame could be enough to miss operation data. In your case the rate of operation data errors is significantly higher than the rate of frame errors. So it is not purely the frame errors causing this, I guess? I also have no clue why it would need a reset to resume normally. I don't have to do resets on mine.

Could the operation data errors maybe generate a snowball effect? For every error:

• A message is printed in the log
• The number of errors sensor is incremented, triggering a sensor update that has to be transmitted over WiFi

Both cost CPU time and might take time away that should have been spent on communicating with the AC. These are logged as: https://github.com/hberntsen/mhi-ac-ctrl-esp32-c3/blob/6bf514b1e4ab0c5d59abed4de115a5ab2f1c2371/esphome/components/MhiAcCtrl/MHI-AC-Ctrl-core.cpp#L475 . Though when testing I faced no issues logging a line every frame.

If you get errors like: https://github.com/hberntsen/mhi-ac-ctrl-esp32-c3/blob/6bf514b1e4ab0c5d59abed4de115a5ab2f1c2371/esphome/components/MhiAcCtrl/MHI-AC-Ctrl-core.cpp#L410 . That would suggest signal integrity issues to me as these frame errors are probably caused by checksum errors/frame length.

Not sure if the state of the AC itself would be related? This unit is primarily off 95% of the time.

I don't think so. I also have one like that and another that's on during the day and off at night.

EDIT. tried toggling the active on/off when gets in this state, it only had the effect of pausing the issues until was activated again. Also had the unpleasant side effect of turning the AC off when active mode toggled off.

The effect of disabling active mode is that there is nothing sent to the AC unit any more. When that happens for too long the AC unit decides to power off, that's normal behaviour of the AC. I still can't explain why a reset solves the communication issue and this doesn't.

Interestingly even though I no longer request the "Current", I still see:

There are 3 sensors that are based on the current operation data: https://github.com/hberntsen/mhi-ac-ctrl-esp32-c3/blob/6bf514b1e4ab0c5d59abed4de115a5ab2f1c2371/esphome/components/MhiAcCtrl/mhi_ac_ctrl.h#L247 . So you probably have one of them still included.

Not sure which was causing the issue, but the ones I took out were:

The sensors in your list are immediately answered by the AC when they are requested ( see my measurements 883a561). Somehow they are easier for the AC to answer while others need more time before we get an answer. Though that does not seem to matter for the timeouts, they all seem to do it?

[steeks81]

I have certainly see this a fair bit in the logs:
ESP_LOGW(TAG, "error %i . trans len: %i", err, spi_slave_trans.trans_len);

As well as the "missed 20 frames" kind of errors.
e.g.

However the real issue seems to be when it was spiking. Now that those other sensors have been removed, while the errors still happen (including the above examples), I've not yet seen it actually cause an issue requiring a reboot.

Here we can see the difference:

And associated errors:

The last "reset" here wasn't actually the ESP but a HA update, so probably would have keep going on just fine (like your examples).

So for my use case, I guess it is resolved, I don't really need those other sensors, just not exactly sure which one(s??) were causing the spike.
I think I missed some in the list of removed, had a better look:
current:
energy_used:
set_temperature:
return_air_temperature:
indoor_fan_speed:
indoor_total_run_hours:
outdoor_fan_speed:

Just looking at comments in your code example, maybe this one??

&this->outdoor_fan_speed_, // 16 times no match on single, 26 on split

There are 3 sensors that are based on the current operation data:

Ah ok that makes sense.

I'll keep running it for longer as is, but so far looking good!

[hberntsen]

I'm glad to see that you found something that works for you! The number of frame errors is not normal though. The trans length of 265 i.e. indicates we somehow received 1 bit more than expected (normally, 33 * 8). Though that could be an error in the code, I see that very rarely on my end. The 20 frames thereafter is from a one second sleep in the code which I just removed. Things might work fine, but if you notice instability (mainly: you try to control the AC and it does not respond) this would be something to have fixed.

I don't know why the outdoor fan speed would be a problem in particular; it works fine over here and glancing at the timeouts I get in the log, it does not stand out.

I've reworked the code a bit to include a new layer that hides the occasional timeout of an operation data: only values that could not be requested within the past minute now time out (visible timeouts). I've let that run over night here and the counter is still at 0 :).

[steeks81]

Nice one!
Been running the new code for about 16hrs, much lower errors, even after I added back in all the "problem" ones that were causing me issues before.
So far in 16hrs, ~60 frame errors, 450 op data timeouts, 0 visible op data timeouts.
Presumably be even less when take out the sensors I don't need :)

In terms of AC not responding when do things, the only thing I've noticed is that sometimes the Vanes change in HA to Left/Right = "Swing", Up down = "See IR remote". The AC is set to Left and Centre/Down, and confirm when change it back in HA to Left, Centre/Down, it doesn't move the AC (as expected). Not sure exactly what/when is triggering the reset in HA, maybe just a visual thing? Could it be uploading the ESP code?. Not a big deal, but a little annoying :)

[hberntsen]

Good to hear it works well for you!

The "See IR Remote" thing is there because after the remote set it, we don't know how to read the position any more. I copied that behaviour from: https://github.com/absalom-muc/MHI-AC-Ctrl/blob/0e8f545305fd601e15d79f29f7a7fd3658d5f5e7/src/MHI-AC-Ctrl-core.cpp#L311-L322 , to https://github.com/hberntsen/mhi-ac-ctrl-esp32-c3/blob/789af707bf8aed17e216363ef6c17d55ede428b1/esphome/components/MhiAcCtrl/MHI-AC-Ctrl-core.cpp#L243-L265