ginkage / MHI-AC-Ctrl-ESPHome

ESPHome integration for MHI-AC-Ctrl project
MIT License
112 stars 39 forks source link

Upgrade to latest MHI-AC-Ctrl, new fan modes, add set_vanes service #38

Closed arpiecodes closed 2 years ago

arpiecodes commented 2 years ago

Hello! This pull request bumps the bundled MHI-AC-Ctrl to the latest version, as requested in #34. It also makes use of the new fan modes that were recently discovered, fixing #36. Please note that because ESPHome only supports auto, low, medium and high as fan speed values (3), there is a slight jump between medium and high (because the unit supports 4 speeds). Both speeds 2 and 3 count as medium when reporting back to HA.

I've also added a 'set_vanes' API service so you can set the vane position to the static ones supported by the unit (1=most upward position, 4=most downward position, 5=swing, 0=unknown). This is a workaround because the ESPHome Climate class does not support setting vane positions, only disabling/enabling swing mode. Swing mode actually sets the vane setting to 5 (swing), and choosing swing mode off will set it to 0 (unknown). This solution should solve #25.

To upgrade, simply copy all new versions of the files included in the pull to your esphome dir in HA.

Please let me know if there are any issues with the new code, I'll try to fix them asap.

ginkage commented 2 years ago

Thank you so much!

ervee commented 2 years ago

Hi Jorrit, thank you VERY much for your help! Here are my results so far:

I pulled the updated two .h files and the .cpp file from your repo. Ran "Clean Build Files" in ESPHome (2022.8.0) in HA (2022.9.7). Updated my yaml to include the "- service: set_vanes" part and the extra vanes sensor. Installed the new version via ESPHome OTA to one of my units.

During build I noticed this error:

...
Compiling /data/esphvac1/.pioenvs/esphvac1/src/main.cpp.o
Generating LD script /data/esphvac1/.pioenvs/esphvac1/ld/local.eagle.app.v6.common.ld
Compiling /data/esphvac1/.pioenvs/esphvac1/lib09e/ESPAsyncTCP-esphome/AsyncPrinter.cpp.o
In file included from src/main.cpp:55:
src/mhi_ac_ctrl.h: In member function 'virtual void MhiAcCtrl::cbiStatusFunction(ACStatus, int)':
src/mhi_ac_ctrl.h:102:16: warning: enumeration value 'opdata_0x94' not handled in switch [-Wswitch]
  102 |         switch (status) {
      |                ^
src/mhi_ac_ctrl.h:102:16: warning: enumeration value 'opdata_unknown' not handled in switch [-Wswitch]
Compiling /data/esphvac1/.pioenvs/esphvac1/lib09e/ESPAsyncTCP-esphome/ESPAsyncTCP.cpp.o
Compiling /data/esphvac1/.pioenvs/esphvac1/lib09e/ESPAsyncTCP-esphome/ESPAsyncTCPbuffer.cpp.o
...

Did you also see this error and does it make something go bad?

2.

Now I just put my AC on to heat and the fan modes seem to work. Auto seems to be working Low sets the fan to 3 Medium set the fan to 4 And High set the fan to 8

In Fan only mode I'm not sure what auto fan speed should do :) But low/med/high sets 2/3/5

I have not tested other modes yet.

3.

The vanes control in the the HA thermostat card now does nothing anymore? How am I supposed to use the new vane control? I assume I need to make a separate control on my dashboard or something. I'm sorry to ask but I could not yet figure it out.

Edit: For number 3, the vane control, I created a standard Button on my dashboard. With this I can use "call-service" to set the vane mode to 5 (swing) on tap, to 4 (down) on long tap and to 1 (up) on double tap. It's not pretty but it works and most of the time I'll control the vanes with an automation anyhow.

arpiecodes commented 2 years ago

Hello ervee,

  1. The 'unknown opdata' which got included in the latest MHI-AC-Ctrl lib is currently not handled/integrated, so you can safely ignore that warning.
  2. Looks like it works properly then. Auto mode will let the unit decide which fan speed it should use optimal for reaching your setpoint. Typically there's some delay here before the unit will actually change the speed.
  3. I guess it did not really work before, only for setting swing mode. Making it swing is actually still possible the way it used to be. However, it is indeed not possible to select vane position with ESPHome. We cannot change that sadly. To use the new vanes control you will have to indeed add a separate entity. You could for example create an input_select helper (https://www.home-assistant.io/integrations/input_select/) to choose the position from a list on the UX and build two automations (one to set the input based on the received sensor state, one to apply the new selection to the unit).
JunghaJungha commented 2 years ago

Thank you for putting effort into this. I use a d1mini and still have this loop eror:

.... [18:38:33][C][version.text_sensor:021]: Version Text Sensor 'MHI-AC-Ctrl ESPHome Version'

[18:38:33][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:33][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4

[18:38:33][C][mdns:101]: Hostname: lr_mhi_ac_ctrl [18:38:33][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:33][C][ota:089]: Over-The-Air Updates: [18:38:34][C][ota:090]: Address: lr_mhi_ac_ctrl.local:8266 [18:38:34][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:34][C][api:138]: API Server: [18:38:34][C][api:139]: Address: lr_mhi_ac_ctrl.local:6053 [18:38:34][C][api:143]: Using noise encryption: NO [18:38:34][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:34][C][wifi_signal.sensor:009]: WiFi Signal 'MHI-AC-Ctrl WiFi Signal' [18:38:34][C][wifi_signal.sensor:009]: Device Class: 'signal_strength' [18:38:34][C][wifi_signal.sensor:009]: State Class: 'measurement' [18:38:34][C][wifi_signal.sensor:009]: Unit of Measurement: 'dBm' [18:38:34][C][wifi_signal.sensor:009]: Accuracy Decimals: 0 [18:38:34][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:34][C][wifi_info:009]: WifiInfo IPAddress 'MHI-AC-Ctrl IP' [18:38:34][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:34][C][wifi_info:011]: WifiInfo SSID 'MHI-AC-Ctrl SSID' [18:38:34][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:34][C][wifi_info:012]: WifiInfo BSSID 'MHI-AC-Ctrl BSSID' [18:38:34][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:34][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:34][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:34][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:35][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:35][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4 [18:38:35][W][mhi_ac_ctrl:079]: mhi_ac_ctrl_core.loop error: -4

arpiecodes commented 2 years ago

@Koendejongh sorry, I do not know why this is happening in your case. Best guess its some issue with your SPI connection.

Do you have the following lines in your yaml?

  platformio_options:
    # Run CPU at 160Mhz to fix mhi_ac_ctrl_core.loop error: -2
    board_build.f_cpu: 160000000L

They are important to keep up with the SPI signal. You are getting -4 but I am almost certain your error has something to do with your SPI communication failing one way or the other. You could also simply have a bad (batch of) ESP's.

JunghaJungha commented 2 years ago

Hi Synegic,

I agree with you it might be something with the SPI communication. The lines you mentioned are in my yaml.

So I tested some d1mini's (Wemos from Ali)I still had but all give this loop error -4. Then I bought 2 different d1mini boards (Wemos V4 and RobotDyn). They all give this loop error -4.

I tested most of them without attached to the hardware board (https://github.com/absalom-muc/MHI-AC-Ctrl/blob/master/Hardware.md), does that make any difference?

Could you check if you get errors if you upload the firmware to a standalone d1mini? If you do, it might be related to my hardware board.

Thanks,

JunghaJungha commented 2 years ago

Hi, were you able to check?

Thanks.

arpiecodes commented 2 years ago

Hi @Koendejongh, currently do not have any spare esp's laying around. But I'm also not sure what you're trying to do. It's quote logical for the ESP to return a loop error if it's unable to actually communicate through SPI. So if you run the board without being connected to the AC correctly, it will probably always return errors.

Also, beware that power instabilities/filtering could be a real issue. AFAIK the MHI-AC-Ctrl hardware also contains some capacitors to flatten out dirty power. Might be an issue, might not be an issue. But I can only share my experience with the actual hardware module.

Can you check if you have the same errors with the original firmware? If so, please post an issue on the original libraries Git. We cannot help you here with core library issues (as this seems to be case). https://github.com/absalom-muc/MHI-AC-Ctrl

JunghaJungha commented 2 years ago

Hi all,

I fully reassembled the hardware and now it works. No more loop errors!