AUTO aka HEAT_COOL Disappeared and When Forced Back Doesnt Work in HA

[disruptivepatternmaterial]

Somewhere along the line the AUTO/HEAT_COOL on all five of my units disappeared in the options both in the web ui of the device and in HA.

I added in

supports:
  mode: ['HEAT_COOL', 'COOL', 'HEAT', 'DRY', 'FAN_ONLY']

And it reappears but in HA only one temp setting is available.

HA: 2023.12.1 ESPHOME: 2023.12.9 Device Code: latest

Any idea what might be happening? What logs can I give you from the device? Just restart it and grab it for a while? Let me know and I'll do it ASAP.

[echavet]

Hello, It is intentional: I find that the heat_cool mode is not a very ethical mode from a strictly economic standpoint. I do not wish, and it seems to be the common case for most users, for my unit to start air conditioning (cooling) my living room in the middle of a winter afternoon, just because the sun shining through my south-facing bay window has exceeded the 19°C heating setting of my heat pump by 2°C. So, in my opinion, the HEAT_COOL function is a marginal need and requires to be specifically activated. This helps to prevent a mishandling. Particularly with Home Assistant on mobile phones where the touch screen can easily lead us to activate a function accidentally.

Le mer. 14 févr. 2024 à 22:56, disruptive pattern material < @.***> a écrit :

Somewhere along the line the AUTO/HEAT_COOL on all five of my units disappeared in the options both in the web ui of the device and in HA.

I added in

supports: mode: ['HEAT_COOL', 'COOL', 'HEAT', 'DRY', 'FAN_ONLY']

And it reappears but in HA only one temp setting is available.

HA: 2023.12.1 ESPHOME: 2023.12.9 Device Code: latest

Any idea what might be happening? What logs can I give you from the device? Just restart it and grab it for a while? Let me know and I'll do it ASAP.

— Reply to this email directly, view it on GitHub https://github.com/echavet/MitsubishiCN105ESPHome/issues/25, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYTHBB5WBZRO7NZG7NSDHTYTUXI7AVCNFSM6AAAAABDJFXEQOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGEZTKMRWG4YTCMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Eric

[disruptivepatternmaterial]

I think this makes sense if you have a smaller home. With a total of 9 units, it is a common case for them not to need to be on the same mode - the high south facing greenhouse is not the same as the basement/in ground office. So I set them on auto to keep the entire house within a range of 10F. This also is a safety feature for when we are in transitional seasons here and I am away for long periods of time for work. It is not good for the house to be below 60F nor above 80F (for art and natural wood items for example) so I use auto to not able to worry about checking on it. People might think oh you can write an automation that checks the outside, etc... which yes I can. Here in the PNW the weather commonly swings 30-40 degrees F in the same day. I guess I can fork and work on it... but thanks for the info!

[phidauex]

Maybe a feature you can enable in the YAML? Documentation could show that it isn't recommended for most users, but can be enabled if you have a specific use case.

[echavet]

Thank you for all this valuable information. It's interesting to know all user's use cases. Does it bother you to have to specify the heat-cool mode in the yaml file? Or does it still meet your need?

[disruptivepatternmaterial]

So I spent some time in a fork of your code last night and I learned a couple things, maybe everyone knows, but...

the inbuilt AUTO mode in the split unit is:

In this mode, the unit will run on HEAT or COOL depending on the room and set temperatures. Simply set the desired temperature and the inverter compressor will speed up and slow down to maintain temperature. Once the temperature is reached, the outdoor unit will slow down and eventually stop.

The indoor fan will effectively stop when the indoor unit cools down to avoid a draught. When the temperature in the room falls during winter, heating will resume.

If the room temperature is 2ºC above the set temperature in winter, the unit will automatically switch to COOL to maintain temperature.

During summer, the unit running on AUTO mode will automatically switch to cooling to maintain temperature.

Data of 0x10 in the decoder (this is what it is called in your code) tells me if the unit it in auto, what it is doing. I THINK 0x01 is cool and 0x02 is heat going by the temp of the air coming out.

I understand now why you were not a "fan" of auto...it is kind of narrow.

So I started to wonder, what if I implement a config variable of delta, say 5F degrees, then I just do some math in your settings loop and pick the direction (heat/cool) in the code. This seems to work, but I'm not sure it just kind of bugs me for some reason.

But what the KUMO adapter did (I removed a pile of these pieces of junk) is not this AUTO. It was setting a range with AUTO, which is interesting. So I would set it to AUTO and say 55F to 80F when traveling, just in case to handle the large swings we have in the spring/fall. But this cannot be the same as the AUTO in the unit. The KUMO adapter must have been doing some math like I thought above.

So I can get AUTO in the UI, set it with you code (well some changes I made in my fork) and it works, but again it is really narrow.

What I cannot figure out is how can I made the HA UI do the hi/lo settings like it did for Kumo. This is the ideal setup for me, again set low at 55 and high at 80 - I need this UI part to send in the temps to the math I mentioned above.

I hope this makes sense :)

So in theory there are 2 things I guess to implement here: 1 - the inbuilt AUTO with 1 temp point at the center +/- 2C and 2 - HEAT_COOL with a lo/hi and letting the ESP do some math and maybe 3 - case 0x09 (level of heat / cold ) and 0x10 (auto mode is cool or heat)

Maybe this helps us a bit?!

[disruptivepatternmaterial]

So, I THINK

In here

   case climate::CLIMATE_MODE_AUTO:
        //this->setActionIfOperatingAndCompressorIsActiveTo(
        this->setActionIfOperatingTo(
            (this->current_temperature > this->target_temperature  ?
                climate::CLIMATE_ACTION_COOLING :
                climate::CLIMATE_ACTION_HEATING));
        break;

for the inbuilt AUTO (+/- 2C mode) need to see what case 0x10 is to know if the device is heating or cooling...

[disruptivepatternmaterial]

OK I modified as follows

            ESP_LOGD("Decoder", "sending a request for settings packet (0x02)");
            this->buildAndSendRequestPacket(RQST_PKT_SETTINGS);
            this->set_timeout("2ndPacket", interval_max, [this, interval_max]()
                {
                ESP_LOGD("Decoder", "sending a request room temp packet (0x03)");
                this->buildAndSendRequestPacket(RQST_PKT_ROOM_TEMP);
                this->set_timeout("3rdPacket", interval_max, [this, interval_max]()
                    {
                    ESP_LOGD("Decoder", "sending a request status paquet (0x06)");
                    this->buildAndSendRequestPacket(RQST_PKT_STATUS);
                    this->set_timeout("4thPacket", interval_max, [this, interval_max]()
                        {
                        ESP_LOGD("Decoder", "sending an additional info (0x09)");
                        this->buildAndSendRequestPacket(RQST_PKT_STANDBY);
                        }); 
                    });
                });

This adds sending RQST_PKT_STANDBY, which I can get the case 0x09: in your decoder, which I get get the output like this

[15:37:21][D][Decoder:286]: sending an additional info (0x09)
[15:37:21][D][WRITE:142]: FC 42 01 30 10 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 74 
[15:37:21][D][READ:142]: FC 62 01 30 10 09 00 00 00 03 02 00 00 00 00 00 00 00 00 00 00 4F 
[15:37:21][D][Decoder:173]: [Stage is 3]
[15:37:21][D][Decoder:189]: [Byte 8 is unknown]
[15:37:21][D][Decoder:195]: [AUTO Heat]

I got this with the messy (your way is better, but I just trying to get it to work here)

    if (data[4] == 0x01) {
            ESP_LOGD("Decoder", "[Stage is 1]");
    } else if (data[4] == 0x02) {
            ESP_LOGD("Decoder", "[Stage is 2]");
    } else if (data[4] == 0x03) {
            ESP_LOGD("Decoder", "[Stage is 3]");
    } else if (data[4] == 0x04) {
            ESP_LOGD("Decoder", "[Stage is 4]");
    } else if (data[4] == 0x05) {
            ESP_LOGD("Decoder", "[Stage is 5]");
    } else {
            ESP_LOGD("Decoder", "[Byte 9 is unknown]");
    }
    //byte 8 02 - submode?
    if (data[3] == 0x04) {
            ESP_LOGD("Decoder", "[Preheating]");
    } else if (data[3] == 0x08) {
            ESP_LOGD("Decoder", "[Standby]");
    } else if (data[3] == 0x02) {
            ESP_LOGD("Decoder", "[Defrost]");
        } else if (data[3] == 0x00) {
            ESP_LOGD("Decoder", "[Normal]");
    } else {
            ESP_LOGD("Decoder", "[Byte 8 is unknown]");
    }
    // byte 10 what mode are we in with AUTO
    if (data[5] == 0x01) {
            ESP_LOGD("Decoder", "[AUTO Cool]");
    } else if (data[5] == 0x02) {
            ESP_LOGD("Decoder", "[AUTO Heat]");
    } else {
            ESP_LOGD("Decoder", "[Byte 10 is unknown]");
    }

So why is this useful? Well defrost is good to know for keeping an eye on it. The power is just interesting. The HEAT/COOL in AUTO can be used to properly set the ACTION.

I think I will tinker with implementing a real HEAT_COOL setting next - it will require switching the device from HEAT <> COOL based on a spread, which could be set in config, but I think this should be easy.

My fork is a mess :) but if you want a PR for any of this or whatever let me know.

[disruptivepatternmaterial]

kumo.json

Here is a dump from one of the kumo adapters before I removed them with prejudice, it also gives you a sense of the data possible, in case that helps.

[disruptivepatternmaterial]

21:54:57][D][Decoder:286]: sending an additional info (0x09)
[21:54:57][D][WRITE:142]: FC 42 01 30 10 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 74 
[21:54:58][D][text_sensor:064]: 'Floor': Sending state '1stfloor'
[21:54:58][D][READ:142]: FC 62 01 30 10 09 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 53 
[21:54:58][D][Decoder:148]: [0x09 is sub modes]
[21:54:58][D][Decoder:155]: [Stage : STAGE 1]
[21:54:58][D][Decoder:156]: [Sub Mode  : NORMAL]
[21:54:58][D][Decoder:157]: [Auto Mode Sub Mode  : AUTO_OFF]
[21:54:58][D][text_sensor:064]: 'Stage Sensor': Sending state 'STAGE 1'
[21:54:58][D][text_sensor:064]: 'Sub Mode Sensor': Sending state 'NORMAL'
[21:54:58][D][Decoder:274]: sending a request for settings packet (0x02)

I moved it to be the same way you have in you code

void CN105Climate::getPowerFromResponsePacket() {
    ESP_LOGD("Decoder", "[0x09 is sub modes]");

    heatpumpSettings receivedSettings{};
    receivedSettings.stage = lookupByteMapValue(STAGE_MAP, STAGE, 5, data[4], "current stage for delivery");
    receivedSettings.sub_mode = lookupByteMapValue(SUB_MODE_MAP, SUB_MODE, 4, data[3], "submode");
    receivedSettings.auto_sub_mode = lookupByteMapValue(AUTO_SUB_MODE_MAP, AUTO_SUB_MODE, 4, data[5], "auto mode sub mode");

    ESP_LOGD("Decoder", "[Stage : %s]", receivedSettings.stage);
    ESP_LOGD("Decoder", "[Sub Mode  : %s]", receivedSettings.sub_mode);
    ESP_LOGD("Decoder", "[Auto Mode Sub Mode  : %s]", receivedSettings.auto_sub_mode);

    //this->heatpumpUpdate(receivedSettings);
    if (this->Stage_sensor_ != nullptr) {
        this->Stage_sensor_->publish_state(receivedSettings.stage);
    }
    if (this->Sub_mode_sensor_ != nullptr) {
        this->Sub_mode_sensor_->publish_state(receivedSettings.sub_mode);
    }
    if (this->Auto_sub_mode_sensor_ != nullptr) {
        this->Auto_sub_mode_sensor_->publish_state(receivedSettings.auto_sub_mode);
    }
}

And added the right maps and such to the globals...

What I have not been able to figure out is how to use the Auto Mode Sub Mode in the ACTION section to more accurately report the action back to HA.

I have watched it go into preheat, defrost, etc... so maybe you can use this to beef up your code!

[disruptivepatternmaterial]

In more observation that what I thought was the fan stage (for the outside unit) is the fan for the head unit. So this would be used to confirm that the fan is doing what was asked, and better yet - if the fan is in AUTO, you know what fan it is really running at.

[echavet]

Thanks for your messages and your research. I must say I hadn't noticed you were writing that manually setting auto mode wasn't working! I thought you were just saying you were surprised the auto mode had disappeared from the default configuration. So I will check that in detail.

[disruptivepatternmaterial]

So I am closing this for archive sake :) maybe at some point wiki or something else should be used to keep track of the notes and setting we figure out...

[echavet]

https://github.com/echavet/MitsubishiCN105ESPHome/pull/35