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) 
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… 
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. 
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. 
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.
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 
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!
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.
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
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!
ive tried searching, I can’t find how to disable auto discovery. Are you referring to this and I exclude my ESPHome? Same for mDNS, not sure.
I use ubiquiti for my home networking and have assigned the dongle a fixed IP of 192.168.1.34
Interestingly the dongle is working 100% correct if I use the code from the first post (the one for Jan 2021), the code from the dongle seller if I compare there isn’t much difference so im now really confused why that works ok but missing some of the integration. Could it be the board setting being called ESP01_1m even though mine is esp12e?
Yes I can ping the dongle from my Mac, so its receiving internet.
I think im going to format my SD card and start again, something isn’t working correctly and my config may be the reason
Yeah, I think Paddy is overcomplicating things a bit;
I think he ment AutoConfigure within the Midea component.
But you mentioned the web interface works correct, so I don’t think that is relevant…leave the esphome yaml as is…
However, you should remove it from ESPHome Addon, and then re-add and flash it from there (using the secure yaml)
This will ensure your ESPHome binary is compatible with your EspHome addon
PS: If this is the only ESPHome device you have, you could even remove ESPHome completely from HA, restart HA, and then add it again…
Who? Me? 
Yeah, that could very well be!
What I meant above was to disable api and mDNS in the config file. I’d call it “eliminating interference”. But if it works, it’s fine. 
So what is the actual status, so that we can go from there.
api password was never enabled(as far as i know), but ha throws an error regarding the api…
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)
That’s why I wouldn’t set it up for the first run. 
Leaving api out completely should resolve this error - no api, no error. 
So what’s the actual status? What firmware is running on the dongle and where are errors left?
Hi Starkiller 99
I have an Midea MKG serie fan coil.
So i can connent an MAX485 module to the display unit (tx rx gnd 5v connection)
And use the modbus protocol for this unit?
Or am i missing something?
Best Regards,
Lieven
How do I determine firmware for the dongle? or are you referring to the config?
Config wise, this is what ive got running but there is no log output, all commands work however.
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
manual_ip:
static_ip: 192.168.1.34
gateway: 192.168.1.1
subnet: 255.255.255.0
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
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.
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
ESPHome also detects it but doesn’t show it as online, I can click visit and it does take me to the dongle.
I’ve uninstalled and started fresh using a new image, still the same.
Im convinced its something in the config.yaml that’s wrong, not sure what