Cassette model with 4 independent vanes

[nagyrobi]

Dear @Sammy1Am @KazWolfe Thank you very much for this component and especially that you are willing to include it in the main ESPHome core. My setup is made of SLZ-M35FA indoor cassette unit, a PAR-41MAA wired remote control wall panel and a SUZ-M35VA outdoor unit. The wired controller is attached to a separate 2-wired connector, thus my CN105 remained free for ESPHome :-) I attached an ESP32C3 through a level shifter and it started working instantly.

[17:16:15][C][mitsubishi_itp:103]: Discovered Capabilities: Identify Base Capabilities Response: [FC.7B.01.30.10]C9.03.00.20.00.0A.07.E5.E4.25.A6.BC.94.B8.A6.B8 4D
 HeatDisabled:No SupportsVane:Yes SupportsVaneSwing:Yes DryDisabled:No FanDisabled:No ExtTempRange:Yes AutoFanDisabled:No InstallerSettings:Yes TestMode:Yes DryTemp:Yes StatusDisplay:Yes
 CoolDrySetpoint:19.000000/30.000000 HeatSetpoint:10.000000/28.000000 AutoSetpoint:19.000000/28.000000 FanSpeeds:3

I prefer to use your component as external from source: github://muart-group/esphome@dev due to the need for an external temperature source because this is a very unusual space, made of two smaller rooms interconnected, where the outer room has higher temperature losses/gains than the inner one. I had to put the unit into the outer room due to technical reasons, but I need to measure the temperature in the inner area for it to be optimal. Also the placement of the sensor is critical, a wired sensor is simply not feasible. The PAR-41MAA wired remote control has a temp sensor on its own, and the AC unit uses that by defaullt when set to Internal.

For temperature measurement, I use Xiaomi LYWSD03MMC, which is proven to be very accurate. Using pvvx_mithermometer component in ESPHome, I catch its BLE advertisments directly on the ESP32C3 which is connected to the AC unit - this makes an ideal setup:

sensor:
  - platform: pvvx_mithermometer
    mac_address: "AA:BB:CC:DD:EE:FF"
    temperature:
      id: temp_outer_room
      internal: false
      name: Temp of outer part of the room
      force_update: true
      filters:
        - filter_out: nan
        - exponential_moving_average:
            alpha: 0.1
            send_every: 3
        - delta: 0.03
        - timeout: 3600s #if data wouldn't come, fall back to Internal
        - heartbeat: 10s
    humidity:
      id: hum_outer_room
      internal: false
      name: Hum of outer part of the room
      filters:
        - throttle: 60s

  - platform: pvvx_mithermometer
    mac_address: "FF:EE:DD:CC:AA:BB"
    temperature:
      id: temp_inner_room
      internal: false
      name: Temp of inner part of the room
      force_update: true
      filters:
        - filter_out: nan
        - exponential_moving_average:
            alpha: 0.1
            send_every: 3
        - delta: 0.03
        - timeout: 3600s #if data wouldn't come, fall back to Internal
        - heartbeat: 10s
    humidity:
      id: hum_inner_room
      internal: false
      name: Hum of inner part of the room
      filters:
        - throttle: 60s

Since the sensors push advertisments at every 2.5 seconds, and their values are a bit noisy, I use the filters above to clean the curves. This way I can choose which sensor to work against to, and this is very good. It worked out of the box.

Now a few words about the unit itself. One of the most important features in this setup is that the unit has 4 vanes, each can be set to its own angle (manual, page 10):

Now some actual feedback about the mitsubishi_itp component in this context:

• the climate entity works as expected (added a positive comment in the base PR). Changes in HA are instantly reflected on the wall panel.
• as described, the temperature_source select works perfectly with the sensors above. This is reflected in the wall panel's display too; after changing the source in HA, it shows the selected value on the panel after a few seconds. It also reflects back into HA. Perfect!
• vane_position select has no effect (I've set the vanes manually from the wall panel; vane_position does change the icon on the panel though, but vanes don't move - maybe because I've set them separately?).
• horizontal_vane_position resets to Auto no matter what I select, but I guess this is irrelevant for this unit
• outdoor_temperature works (proper outdoor value shown)
• compressor_frequency shows always 0 Hz
• thermostat_humidity and thermostat_temperature show unknown (I guess because PAR-41MAA is not an enhanced_mhk, it only has a temperature sensor and no humidity sensor; there's no way to see anymore this value if the temperature_source is set to something else)
• binary sensors apparently work, though I get OFF for isee_status, which is not clear to me, my unit doesn't have i-see, so I guess it should probably be unknown (guess I should remove it from config). preheat works. Time will tell if defrost, filter_status, standby work for real or not...
• text sensors also look operational, getting proper values for actual_fan and seeing No Error Reported for error_code

Some suggestions:

• for cassette units we could have something similar to horizontal_vane_position but simply vane_1_angle, vane_2_angle, vane_3_angle, vane_4_angle to be consistent with the wall panel interface.
• the temperature_source select's "Internal" value should have an optionally configurable string in the yaml for localization (or more correct naming, in this case even in English it would probably be more correct "Wall panel" instead)
• the wall panel has a screen showing energy consumption of the unit over time, in kWh. I assume there's a counter which would be nice to have as an energy sensor in HA. We could show it as individual energy consumer in the Energy Dashboard.

A question:

• how's the temperature_source select state restored at boot? If I simply reboot the node (with the restart button), it's apparently restored. If OTA the node due to any config change (unrelated to this), the temperature_source select falls back to "Internal", it's not restored.

Let me know if any logs from ESPHome are needed to increase compatibility with cassette units.

[Sammy1Am]

Sorry for the delay in replying, and thank you so much for the detailed information! It's really helpful to know how things are working in other environments since I can only test with what I have at home. I have a sort of similar setup where the built-in sensors are in poor locations for keeping the actual occupied space at a good temperature.

I'll start with the less complicated answers:

how's the temperature_source select state restored at boot?

I'm using the ESPPreferenceObject for the preferences, but with a hash based on the compilation time of the firmware. This means that whenever a new firmware is uploaded, the preferences are reset. The goal is to make sure that code changes that could potentially effect how preference values are stored/read/used get a fresh start. Ideally we could probably replace that with a preferences-version-number so that they're only reset to defaults if we actually change the preferences, but it would require human intervention for each change (so we didn't when changes were frequent, but honestly it might be fine now that things have settled a little).

the wall panel has a screen showing energy consumption of the unit over time, in kWh.

Unfortunately, the wall panel connects using a different connector and therefore (for some reason) an entirely different protocol. We're not really aware of much work that's gone into decoding / utilizing that one, but it sounds like it has some neat stuff.

vane_position select has no effect (I've set the vanes manually from the wall panel; vane_position does change the icon on the panel though, but vanes don't move - maybe because I've set them separately?). ... for cassette units we could have something similar to horizontal_vane_position but simply vane_1_angle, vane_2_angle, vane_3_angle, vane_4_angle to be consistent with the wall panel interface.

I would love to see the log output from your cassette unit (especially the GetSettings Response) when you change the various vane angles using the wall unit. So far we haven't been successful in figuring out where to control those vanes from (or if it's even possible). The fact that vane_position changes the wall panel seems to suggest there might be some kind of overlap, but it's also possible that this control ability is exclusive to the 2-wire controllers.

[nagyrobi]

This means that whenever a new firmware is uploaded, the preferences are reset.

I experiment with settings a lot, and try to keep ESPHome up to date so having to go and manually restore the temperature_source select state is very annoying. Sometimes I forget that, and even if I don't, I can't be fast enough to immediately make the manual change, the unit gets the wrong values and climate history graphs look nasty with unexplanable jumps on the target temperature line.

The goal is to make sure that code changes that could potentially effect how preference values are stored/read/used get a fresh start.

One way to handle this would be to add an initial_option setting (similar to template select), to set the option to on setup if not restored from preferences. I would never want to use Internal, unless ESPHome node would completely fail (but that's handled by the unit anyway)...

[Sammy1Am]

One way to handle this would be to add an initial_option.

That might be a safer bet actually, I'll add that next time I'm in the code. I've got an automation in Home Assistant that triggers on a change to Internal and immediately sets it back to whatever I wanted it to be. Not quite as graceful :P

[nagyrobi]

Please let me know when to test

[nagyrobi]

My finding related to the vanes is that the possibility to set the 4 vanes independently is actually an override (which can also be set from the IR remote btw.) You need to turn off the unit, and then in the appropriate menu it switches into an air blow mode where you can literally adjust the overridden positions of the vanes by sensing the air. You can set these overrides independently, which means that any other setting (Auto, 1-5, Swing) will be ignored for the overridden vane. Exiting the menu saves this setting, and then you can turn the unit back on.

So the principle is, that you have the usual Auto, 1-5, Swing vane options in parallel for all four, but you can override independently each with a fixed position or even close one of them completely. The ones not overridden with manual positioning will follow the usual Auto, 1-5, Swing vane options, the ones overridden will stay always sit in the overridden position while the unit is on. All of them will close regardless of this when turning off the unit.

Apparently there's no way (at least from the wall panel) to change the position of the manually set vanes during operation. Thus I assume this is not something that could be set through CN105 connector.

[nagyrobi]

While trying to mitiagate the temperature source select resetting to Internal, I thought that maybe I could use ESPHome's on_boot for that. I discovered that select is not compatible with ESPHome's native select.set action.

select:
  - platform: mitsubishi_itp
    temperature_source:
      name: Klíma Iroda hőmérséklet forrása
      id: tempsource
      sources:
        - temp_irodakulso
        - temp_irodabelso
        - temp_irodaatlag

This fails:

    ...:
      - select.set:
          id: tempsource
          option: 'temp_irodabelso'

with:

[16:54:19][D][select:062]: 'Klíma Iroda hőmérséklet forrása' - Setting
[16:54:19][W][select:111]: 'Klíma Iroda hőmérséklet forrása' - Option temp_irodabelso is not a valid option

However this works:

    ...:
      - select.set_index:
          id: tempsource
          index: 2

The index is 0-based, and apparently Internal is at index 0.

[Sammy1Am]

Does temp_irodabelso have a name or friendly_name? I believe when calling select.set you may have to use whatever is displayed in the UI rather than the component id.

Otherwise, that's a very clever way to handle that.

[nagyrobi]

Otherwise, that's a very clever way to handle that.

You need priority: 250 on boot, with the default 600 it won't work. I still consider it a mitigation, because it may very well still pass through an internal value during the time passed between setting up the component (defaulted to Internal) and the moment on_boot stuff will be autoexecuted. Would be much cleaner with initial_option as the component will be set up right away as intended.

temp_irodabelso is set to be internal to ESPHome, it's not passed to HA, but it does have a name, as that's being displayed in the select.

you may have to use whatever is displayed in the UI rather than the component id.

It's fine with me to use set_index instead - I thought I'd just mention my observation and hope devs won't make a problem out of this when time will come to submit it in a PR.

[nagyrobi]

• Time will tell if defrost, filter_status, standby work for real or not...

Confirming that defrost works.

[Sammy1Am]

Just wanted to say thank you for the idea to put the temperature select in the on_boot section. It works great. I managed to get it by value by using the display string instead of the id (because that's how ESPHome does it internally, surprisingly):

on_boot:
    priority: 260
    then:
      - select.set:
          id: temp_source_select
          option: "Thermostat"

The ESP controlling one of my wall units crashes constantly (even though the other two have never crashed). I've replaced the ESP twice, but it keep crashing, so I'm suspicious it's actually something to do with the unit or the MHK2 that it's connected to (I had the MHK2 disconnected for a while and it seemed more stable then). This will help a lot since it seems to have some trouble reverting to the internal sensor when it crashes. I don't know why it does that, but I can't figure out why it's crashing either.

Not sure when I'll have time to mess with the code again and see about a more sane approach to resetting the preferences though, but I'll keep this issue open so I don't forget about it.

[nagyrobi]

No crashes here. Which ESP mcu are you using?

I even combined mine with a mmWave sensor for presence detection. If there is no person in the room for more than 15 minutes, adjudst the target temp to less energy consumption.

[Sammy1Am]

Well I started with an ESP8266, and figured maybe that was the problem. So I switched to a ESP32-CAM (because it's what I had laying around), but that had some sort of janky wiring, so figured maybe that was the cause. But now I've got it on a custom PCB (shameless link), and it's still crashing.

Like I said, I think the only time it worked for a while was when I had the thermostat unplugged. Weirdly though, the upstairs controller is also plugged into an MHK2 and has never had any issues. So it's not even that it's plugged into a thermostat, it's that thermostat in particular maybe.

The WiFi signal is also touchy down there, but I increased the restart timeout to like 40min and it doesn't seem like that was it either (but could be a contributing factor maybe?)

[nagyrobi]

How about exchanging only the MHK2's with each other?