Midea branded AC’s with ESPhome (no cloud)

@metaljay
I’m not up to my game today, sorry. :slight_smile: What I totally oversaw was, where did you install ESPHome? On your Home Assistant server I guess, right?

So you have the following setup (please fill in):

  • You have a _______ to run Home Assistant (a RaspberryPi, a XY)
  • You run Home Assistant OS on that computer? _____ (yes/no)
  • Here you installed ESPHome as an AddOn? _____ (yes/no)

What does the web server show, is it possible to get some more info here? Maybe you could make some screenshots of the page(s). I’m quite sure, the web server should be able to offer some possibilities to upload a new firmware. If so, we can built a “new” firmware in ESPHome (in your AddOn) and flash it over the now used firmware via the webserver.

Anyway, I think, we don’t need the Mac here, just to get to a web page, but nothing more. :slight_smile:

I guess the issue is that he doesn’t have an entry for his dongle in esphome, so he doesn’t have a yaml config either…


and since the design is unknown, it would be guessing for gpio pin layout, board type as well as platform…
But it looks like esp-12e

and i guess gpio 1 + 3.
(as gpio 4 + 5 are for auxiliary sensors)

Ofc another thing worth trying is to swap orange and brown wires… ut it wouldn’t surprise me either if it is just a bad connection :wink:

Not yet. :wink: :smiley:

If the web server is running on the dongle, we should be able to get the data we need from it. And this data we use to setup the dongle as a new device in ESPHome. Could work, I guess… :rofl:

@paddy0174 His screenshot on Telegram doesn’t show much data…

That’s really not much to go on… :frowning:

So, it will be a guessing game! :rorl: :rofl: What else could we do on such a nice Friday evening? :wink:

I managed to speak to the seller and they gave me the config.yaml

substitutions:
  node_name: midea-ac
  node_id: midea_ac
  friendly_node_name: "Midea AC"

esphome:
  name: ${node_name}
  comment: ${friendly_node_name}
  platform: ESP8266
  board: esp12e
  name_add_mac_suffix: true
  project:
    name: "lizardsystems.midea_mini_dongle"
    version: "1.4.0"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: "AC-wifi"
    password: "slwf01pro"

captive_portal:

dashboard_import:
  package_import_url: github://lizardsystems/midea-mini-dongle/edit/main/midea_ac.yaml

logger:
  baud_rate: 0
#  level: ERROR
  esp8266_store_log_strings_in_flash: false

ota:

web_server:
  port: 80
  css_url: ""
  js_url: "www.js"
  local: true
  version: 2
  

api:

uart:
  tx_pin: 1
  rx_pin: 3
  baud_rate: 9600
  
climate:
  - platform: midea
    name: ${friendly_node_name} Climate         # Use a unique name.
    id: ${node_id}_climate
    period: 1s                  # Optional
    timeout: 2s                 # Optional
    num_attempts: 3             # Optional
    autoconf: true              # Autoconfigure most options.
    beeper: true                # Beep on commands.
    visual:                     # Optional. Example of visual settings override.
      min_temperature: 17 ∞C    # min: 17
      max_temperature: 30 ∞C    # max: 30
      temperature_step: 0.5 ∞C  # min: 0.5
    supported_modes:            # All capabilities in this section detected by autoconf.
      - FAN_ONLY                # This capability is always used.
      - HEAT_COOL
      - COOL
      - HEAT
      - DRY
    custom_fan_modes:
      - SILENT
      - TURBO
    supported_presets:          # All capabilities in this section detected by autoconf.
      - ECO
      - BOOST
      - SLEEP                   # This capability is always used.
    custom_presets:             # All capabilities in this section detected by autoconf.
      - FREEZE_PROTECTION
    supported_swing_modes:
      - VERTICAL                # This capability is always used.
      - HORIZONTAL
      - BOTH
    power_usage:                # Optional. Outdoor temperature sensor (may display incorrect values after long inactivity).
      name: "${friendly_node_name} Power Usage" 
      id: ${node_id}_power_usage
    outdoor_temperature:        # Optional. Power usage sensor (only for devices that support this feature).
      name: "${friendly_node_name} Outdoor Temperature"
      id: ${node_id}_outdoor_temperature
    humidity_setpoint:          # Optional. Indoor humidity sensor (only for devices that support this feature).
      name: "${friendly_node_name} Humidity"
  
switch:
  - platform: template
    name: ${friendly_node_name} Beeper
    icon: mdi:volume-source
    restore_state: true
    optimistic: true
    turn_on_action:
      midea_ac.beeper_on:
    turn_off_action:
      midea_ac.beeper_off:
      
binary_sensor:
  - platform: status
    name: ${friendly_node_name} Connection Status
    id: ${node_id}_connection_status

text_sensor:
  - platform: template
    name: Uptime Human Readable
    id: uptime_human
    icon: mdi:clock-start

  - platform: version
    name: ${friendly_node_name} ESPHome Version
    id: ${node_id}_esphome_version    

  - platform: wifi_info
    ip_address:
      name: ${friendly_node_name} IP Address
      id: ${node_id}_ip_address
      icon: mdi:ip-network

sensor:
  - platform: uptime
    name: Uptime Sensor
    id: uptime_sensor
    update_interval: 60s
    on_raw_value:
      then:
        - text_sensor.template.publish:
            id: uptime_human
            state: !lambda |-
              int seconds = round(id(uptime_sensor).raw_state);
              int days = seconds / (24 * 3600);
              seconds = seconds % (24 * 3600);
              int hours = seconds / 3600;
              seconds = seconds % 3600;
              int minutes = seconds /  60;
              seconds = seconds % 60;
              return (
                (days ? to_string(days) + "d " : "") +
                (hours ? to_string(hours) + "h " : "") +
                (minutes ? to_string(minutes) + "m " : "") +
                (to_string(seconds) + "s")
              ).c_str();
  - platform: wifi_signal
    name: ${friendly_node_name} WiFi Signal
    id: ${node_id}_wifi_signal
    update_interval: 60s

button:
  - platform: restart
    name: ${friendly_node_name} Restart
    id: ${node_id}_restart
    icon: "mdi:restart"
  - platform: shutdown
    name: ${friendly_node_name} Shutdown
    id: ${node_id}_shutdown
  - platform: safe_mode
    name: ${friendly_node_name} Restart (Safe Mode)"
    id: ${node_id}_safe_mode

Im guessing I need to switch 1 and 3 around at UART and then try flash it?

So I made the changes to

uart:
  tx_pin: 1
  rx_pin: 3

downloaded the firmware, flashed it OTA and now can see way more data in the web viewer. ESPhome for some reason cannot adopt the dongle though

What does tx/rx say in log?

as long as either tx or rx is missing, it won’t work

im getting this now:

14:05:31	[D]	[ApplianceBase:139]	
Response timeout...
14:05:31	[D]	[ApplianceBase:154]	
Destroying the request...
14:05:31	[D]	[AirConditioner:178]	
Enqueuing a GET_STATUS(0x41) request...
14:05:31	[D]	[ApplianceBase:173]	
Enqueuing the request...
14:05:31	[D]	[ApplianceBase:075]	
Getting and sending a request from the queue...
14:05:31	[D]	[ApplianceBase:162]	
TX: AA 21 AC 8D 00 00 00 00 00 03 41 81 00 FF 03 FF 00 02 00 00 00 00 00 00 00 00 00 00 00 00 03 18 68 5B 
14:05:33	[D]	[ApplianceBase:139]	
Response timeout...
14:05:33	[D]	[ApplianceBase:146]	
Sending request again. Attempts left: 2...

still no RX…

Can you explain more what you mean? The log just outputs what I posted above, the yaml I’ve switched around like you said

i meant, the unit does not answer back (the esp sends (tx), but the ac doesn’t respond (rx)

I’de suggest to change gpio’s back to as they where, and check to usb2header connection for bad contact.
Ofc. it could also be that the esp12 simply is malfunctioning….
i noticed gpio4 and 5 are available on the pins on the back, you could try it with that ones by connecting it to brown and orange wires (or swapped) :thinking:

In my opinion, this is going the wrong way. I’d prefer a more basic approach, where we set up the dongle in ESPHome and flash it with a “ESPHome” firmware from your server.

But to give a good advise, I’d really need to know how your setup is. That ESPHome can’t detect your own firmware isn’t a good sign, and makes me guess, something else might be wrong… :wink:

i think that is what he did, as he received the config from the maker, and recompiled , i assumed on his own server…

This doesn’t sound to me, as it would be working with ESPHome(HA). The firmware is created, downloaded to a PC/Mac and uploaded via integrated web server. ESPHome should at least get the device, maybe with errors, but it should still get it.

That’s why I was asking last night for the setup. :slight_smile: And how, in general, is worked with the system. For me, it sounds like the “usual” approach from people asking for support - we click, we do that, we adjust there. In my experience there is a point where useful things get buggy, when people “try for their own”. In Germany we call that “blind actionism”. It’s not important what we do, as long as it looks like we are doing something. :rofl: :rofl: :rofl:

That being said, I’m a fan of starting with the basics. ESPHome must be running without errors, next step, the dongle must be recognizable, and then I’d start with a minimal setup, like OTA and wifi and work my way upwards. For now, we can’t rule out any general problems with ESPHome and the connections there in. Might very well be, that everything is all right and woking as it should, but I personally like to check that before I go deeper. But that’s me, maybe all these years in IT support have made me more suspicious than I’d need to be. :slight_smile: :rofl:

I agree, but it appears esphome was already working according the screenshot made in telegram…


so as far as i can see the whole (and only) issue is no RX….

OK, I see, you’re getting the head start on Telegram :rofl: :rofl: :rofl:

Apologies, ill try make this clearer as appreciate you guys don’t know the full story.

I am running ESPHome on home assistant on a raspberry pi, ESPHome correctly identifies the dongle like so:

I then create an instance for the dongle and attempt to ‘flash’ it using the default config

substitutions:
  name: midea-ac-4b6861
packages:
  lizardsystems.midea_mini_dongle: github://lizardsystems/midea-mini-dongle/edit/main/midea_ac.yaml
esphome:
  name: ${name}
  name_add_mac_suffix: false


wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

I am greeted with this error:

INFO Reading configuration /config/esphome/midea-ac-4b6861.yaml...
Failed config

packages: [source /config/esphome/midea-ac-4b6861.yaml:4]
  
  edit/main/midea_ac.yaml does not exist in repository.
  lizardsystems.midea_mini_dongle: github://lizardsystems/midea-mini-dongle/edit/main/midea_ac.yaml

So I edit the config and copy and paste the setup from here and leave all values as in the link.
I then get this error:

Which suggests I need to assign static IP. (192.168.1.34)
Back to the config and I add my fixed IP, then ‘refresh’ the config which completes, but im just left with output and it never finishes…
If I change the TX and RX around (1 and 3) I still get the same…

There is this within the log though:

INFO Starting log output from 192.168.1.34 using esphome API
WARNING Can't connect to ESPHome API for 192.168.1.34: Timeout while connecting to ('192.168.1.34', 6053)

If I connect to the dongle via the web, I can see it IS able to view the state correctly as its reading the temperate but nothing within ESPHome

Hmm…

No, it suggest there is something wrong with multicast dns on you netmask, but nothing wrong with using a static IP.
(But even better would be to use a IP reservation on you DHCP server, which probably runs on your router)

I am a bit confused here, which output and what never finishes exactly?

I assume the screenshot from web is with original gpio assignment?
That actually looks very good, and gpio’s are both correct.
This is how the log in esphome should look like too…

So maybe it is as Paddy suspected, something is wrong with esphome setup.
This could also be related:

INFO Starting log output from 192.168.1.34 using esphome API
WARNING Can't connect to ESPHome API for 192.168.1.34: Timeout while connecting to ('192.168.1.34', 6053)

Maybe better to start from scratch (sort of)

  • secure the yaml you have now (the one from working web interface), this config should work for you
  • delete the midea integration from esphome (goto devices and services / esphome / midea-ac, hit the three dots and delete)
  • if this is the first (and only) esphome device, maybe even delete and and reinstall the esphome addon
  • add a new device to esphome addon with the secured yaml
    OTA probably doesn’t work so choose Manual download Install it yourself using ESPHome Web or other tools; this will compile the bin and you will be able to download it,
  • Using the web interface on 192.168.1.34, select the new bin files to update the dongle

^^ What @aceindy said! :slight_smile:

I’d do it a little different, as my suspicions is, the IP is already in use by the original dongle firmware. So if you now try to connect, it won’t work, as the new firmware can’t get through. :slight_smile:

But that’s just a guess.

In addition what @aceindy said, take note of these:

  • Disable the auto discover for ESPHome, no need right now, if you want it, you can enable it after everything is running
  • Note the IP of the dongle with this firmware. If you can set the IP to static, do it.
  • Use fixed IP settings in ESPHome for this device.
  • Disable mDNS in the settings for this device
  • Setup a new firmware, where you just work with the minimum necessary for the AC to run. Most things are auto-discovered in the device, and for now, we only need it to run with the basics, the rest comes later.
  • If you’re not sure, ask before you do it :wink:

And if you have to report errors, we need to know some basics from exactly that time. So please include the following infos:

  • what version is running on the dongle? Still the original or one of a newly created.
  • which IP is assigned in the router and is it correct
  • can you ping the device from your Mac?

We’ll see, but I think we’re very close to bring this to a good end! :slight_smile: