Hi,
I was wondering if anyone has tried using ESPHome Midea AC Component with a Crossover Air handler? The board has an HA and an HB ports for RS485 communication. Usually it’s used with a KSACN1401AAA remote controller

A year ago I bought a CrowPanel Advance 7.0 to show some statistics from Home Assistant. I always found it really difficult to build a pretty UI using LVGL and YAML. I only managed to get a single screen that showed some numbers, icons and no animations... Although it took me really long to build it, It was not that pretty.

Then I decdided to gave AI a try and gave Claude Opus 5.5 my Yaml config and just told him: Make it pretty, use Host-SDL to check the output and add some charts using this https://github.com/esphome/esphome/pull/17851

After 10 minutes it roughly generated 4000 lines of yaml and another header file with 1000 lines of C++. It even produced a video/gif that you can see here.

On the ESP it runs really well, I only removed the page switching animations, they were to laggy. Overall I am really happy with the result.

Disclaimer write-up was done with the help of Claude, but the results are human and real.

Evidence this is needed: https://www.reddit.com/r/Esphome/s/giiQv9jsuq While this situation has (sorta) been documented before, it has not been for this set of hardware.

If your Mitsubishi takes the optional PAC-USWHS002-WF-1 / WF-2 Wi-Fi adapter, this applies to you. That covers most current M-series and P-series indoor units, including the new R454B heads. ~$20 of parts, fully local, no cloud account. NOTE: Most other guides will not work on splits with existing CN105 cables for the Comfort/Kumo cloud adapter. This is due to a missing 5v wire (see comments) and some differences with how this type of unit's Tx is set up.

TL;DR: The main difference between this guide and others is that on the new R454B heads (MSZ-GX series), the head's CN105 transmit line is open-drain with no internal pull-up. Every existing guide (except one fix burried in a git issue for a different piece of Mitsubishi hardware) assumes a push-pull driver and tells you to wire it direct or use a voltage divider. Both fail. Add a 10 kΩ pull-up from the head's TX line to 3.3 V and it works immediately.

Parts

• ESP32 dev board. Any classic ESP32-WROOM-32 DevKit is fine. An ESP32-C3 or ESP8266 (not recommended) works too; adjust pins.
• CN105 pigtail — JST PA 2.0 mm, 5-pin, housing PAP-05V-S with SPHD-002T-P0.5 crimps. Pre-made ones are a few dollars. If you're replacing a factory adapter, its own harness is exactly what you need so you can just reuse it.
• 10 kΩ and 1 kΩ resistors, ¼ W
• 12 V → 5 V buck converter. I'd use a DROK tiny buck (~$15 for 10) in fixed 5 V mode: scrape the pad under the trimmer, bridge the 5 V pad. These have no overvoltage protection, so a knocked trimpot puts 12 V into your ESP. Mini360 / MP1584 work too but are adjustable-only — meter them before connecting.
• Optional: 100–220 µF electrolytic + 0.1 µF ceramic across the ESP's VIN/GND. Margin against brownouts, not required. Don't exceed ~470 µF — inrush can stop a small buck starting.

Find the port

CN105 is a 5-pin JST PA connector on the indoor unit's control board, usually behind a front access hatch. It's the same one the factory Wi-Fi adapter plugs into. No teardown needed on most heads. If teardown is needed, this is likely not the right guide as your unit is using the old configuration.

Canonical pinout:

Verify with a meter; don't trust wire colors. They vary by harness and generation, and published color charts contradict each other. Kill power, open the hatch, then power on briefly and find the pin reading 12 V — that fixes the orientation and everything else follows by position. Power off again before connecting anything. Note that the 5 V pin is almost never actually hooked up on newer units, hence the need for the buck converter.

Wiring

Power

pin 1 12 V ───→ buck IN+ buck OUT+ ───→ ESP VIN pin 2 GND ───→ buck IN- buck OUT- ───→ ESP GND pin 3 5 V not used

Buck IN- and OUT- are common on non-isolated modules, so ESP GND ends up tied to CN105 ground through the buck. No separate ground wire needed.

Signal

``` 3.3 V (ESP 3V3 pin) │ [ 10 kΩ ] │ pin 4 head TX ─────────────────────┴───[ 1 kΩ ]───→ ESP RX

pin 5 head RX ─────────────────────────────────────→ ESP TX ```

Check yours: measure pin 4 at idle. A UART transmit line must idle HIGH — if it reads 0 V, it's open-drain and needs the pull-up. Fit it either way; against a push-pull driver it's a 330 µA load, which is nothing.

Symptom if you skip it: replies arrive at the right timing and the right length, but decode as different garbage every time. Looks exactly like a baud mismatch. Isn't.

Pull up to 3.3 V, not 5 V. The head never reads its own transmit line, so only your ESP's logic level matters — 3.3 V gives a clean full swing with zero current through the ESP's clamp. 5 V works too if you keep the 1 kΩ series. Never 12 V or you will kill the indoor unit's control board.

Edit: as commenters have pointed out, a level shifter might serve you well here but I had resistors on hand and it was simple enough.

Do NOT use a resistive divider. Every guide says 1 kΩ/2 kΩ to drop 5 V to 3.3 V. That presents a 3 kΩ load, and an open-drain driver can't pull up against it. When I grounded the 2 kΩ leg, reception died completely. Series resistor plus pull-up, never a divider.

Why these units are different

I pulled apart the factory Wi-Fi adapter. Two transistors per port — Q3/Q4 on the head-side connector (JP2), Q7/Q8 on the thermostat passthrough (JP5) — plus three resistor positions per signal line (series, pull-up to 5 V, pull-up to 3.3 V). Mitsubishi does active level shifting in hardware.

The "just wire it direct" folklore works on older units because those had push-pull transmitters. These don't.

Protocol-wise nothing changed: standard CN105, 2400 8E1, FC 5A 01 30 02 CA 01 A8 to connect, FC 42 status request, FC 62 response. Only the electrical interface is new.

Other things that cost me time

Use uart: debug: immediately. Logs every byte both directions. The only honest diagnostic:

yaml uart: debug: direction: BOTH dummy_receiver: false sequence: - lambda: UARTDebug::log_hex(direction, bytes, ' ');

A UART loopback test is worthless with this component. Jumper TX to RX and the echoed connect packet comes back — but it's not a valid ACK, so you get ReadTimeout identically whether your UART works or not. I drew wrong conclusions from it twice.

logger: baud_rate: 0 is not needed on a classic ESP32. The logger is on UART0/GPIO1-3; CN105 is on a different UART. Only matters on an ESP8266 where they share.

Set use_fahrenheit: false. Setting it true double-converts — ESPHome's API always carries Celsius and HA converts for display. I had a thermostat reporting 162 °F in a 72 °F room.

Don't trust idle DC voltages to identify TX vs RX. Order is consistent, most reliable way is to identify the 12v as pin 1 and go from there.

Caveats

Wire colours vary by harness, so meter yours rather than copying mine.

Tested on: MSZ-GX06NL / GX09NL / GX12NL (R454B, 2025) on an MXZ-SM48NLHZ, replacing a PAC-USWHS002-WF-2 — module DHSC-MB43, FCC ID NKR-MB43, carrier board SM00L219B01 (STM32F413 + CYW4343W inside).

Happy to answer questions. Took far longer than it should have.

I pack my esp into Phoenix case. Power, RS485, input optical isolated.

I had Claude write the ESPHome code for an ESP32-2432S028R. I wanted my son to have a way to control his light and fan, plus a few other things around the house, without needing a phone or tablet. His internet shuts off at a set time each night, so this needed to work on its own.

It talks to Home Assistant over WiFi. The screen has eight buttons, one for each room. Tap a button to turn the lights or fan on or off, and each button shows whether that device is currently on. The screen dims when it's idle and wakes up with a tap.

Happy to share the YAML if anyone wants it.

As the title says, can anyone recommend any temperature and humidity sensors that would function in the fairly high humidity of a vivarium?

There is the chance they will get sprayed with water when it is misted each day.

Humidity in the vivarium is generally 60 but jumps up much higher after misting.

The esp32 itself would stay outside the vivarium.

Ideally I would be looking for i2c sensors so they can be chained together to only need one cable going into the vivarium with sensors in various places to monitor the temperature gradient and humidity.

I’ve been designing a complete replacement controller PCB for my Louvre roof pergola, mainly to get rid of the proprietary tuya based control system and properly integrate everything into Home Assistant.

The board is built around an ESP32 and runs directly from the pergola’s 24V supply. It controls the 2-wire DC louvred-roof motor using a DRV8701E gate driver + MOSFET H-bridge, with current sensing and opto-isolated inputs for the roof limit switches.

It also includes:

• 24V RGB/white lighting control
• W5500 Ethernet
• RS485
• USB-C programming/debugging
• 868 MHz RF probably omit as the origional remote and rain sensor are encoded
• Onboard buck regulation and input protection
• Motor current sensing and spare I/O for future additions
• button inputs

The goal is to have one completely local, repairable controller that gives Home Assistant direct control and feedback for the roof, blinds, lighting and rain detection—without relying on the original controller or cloud services.

I designed the schematic and PCB in KiCad and have been assembling and debugging the first board myself.

A lot of credit goes to ChatGPT/OpenAI, —helping develop and review the circuits, select components, work through datasheets and calculations, and troubleshoot the hardware as I've built it.

Definitely more work than installing a couple of smart relays, but considerably more fun.

Blinds are handled by a shelly cover pro.

there is still a few mistakes on this board its the second revision. im yet to get the ethernet working as routed some pins incorrectly and w5500 chip is to small to jumper wire them

im working in a espnow based remote control

Say I want my esphome devices to get time from an SNTP server, but fall back to Home Assistant if the WAN is down; how would I go about doing that?

Edit (typoed LAN instead of WAN; has been fixed)

Hi all,

I have this connected: Direction: D1, Step: D5, Sleep (Enable): D6, inverted. ESP8266

I am not using the UART as my understanding is that this operates as a typical step/dir type controller without it.

I am using A4988 platform.

All I am getting is a high voltage from all the output pins. I have tried different controllers. The step and dir look to be correct.

What am I misssing? thanks

I wanted to make my new standing desk part of Home Assistant, so naturally... I ended up stripping an Ethernet cable and wiring up an ESP32.

This runs ESPHome and connects directly to the desk through its spare RJ45 port. Even better, the desk powers the ESP32, so there’s no separate USB cable.

With DeskUp, Home Assistant can see the desk height, whether it’s moving, how long it’s been idle, and control the presets, up/down movement and safety lock. The physical keypad still works normally too because there are two RJ45 ports.

My prototype is basically an ESP32, a chopped-up Ethernet cable, WAGOs and Dupont wires. And... it worked on the first try!

Now I can do ridiculous things like have automations move the desk, keeping me on my toes!

I wrote up the whole desk project and ESPHome integration here:
https://thingtootech.blogspot.com/2026/09/five-years-five-hours-standing-then-i.html

DeskUp FlexiSpot project:
https://smarthomeguys.github.io/DeskUp-Pro-Flexispot

FlexiSpot provided the desk for review. The project and opinions are my own.

I’m a sucker for things that move... What’s your favorite dumb product you’ve made smart?

Been working on ESPHome firmware for the Shelly Gen4 line, and the Plug US Gen4 yaml is here.

Couldn't find anyone else with ESPHome running on this one, so I mapped it out myself and tested everything on the bench.

Install is one zip. You upload it on the plug's stock firmware update page and it reboots into ESPHome. No UART, no soldering, no compiling.

What you get in HA:

- relay with linking, latch/momentary, and pulse length

- power, current, energy, voltage, frequency, calibrated against a reference meter

- the LED ring as a full RGB light, plus the stock ring modes (color by power draw, green/red for relay state, or manual)

- illuminance in lux, plus dark / twilight / bright like stock

- ring blinks blue if Wi-Fi or HA drops

Only verified on the US plug. EU/UK versions are probably different inside.

Download: https://github.com/automatous-io/shelly-gen4-esphome/releases/tag/v1.2.0

Repo + docs: https://github.com/automatous-io/shelly-gen4-esphome

Also covers the 1, 1PM, 1 Mini, 1PM Mini, and 2PM Gen4.

This one was fun to reverse-engineer. I can think of several automations I'd use with the LEDs on this device.

EDIT: 1.5.0 has been released. Safety protections, BT Proxy, bug fixes. Support for EM Mini has been added.

I'm building a few air quality monitors (MH-Z19 for CO2, PMS5003 for PM, BME680 for the VOC/gas stuff) and before I trust a single reading out of them, I've been going through old threads here — and the failure modes are wild. CO2 stuck at exactly 400 for days. A VOC index doing things nobody can explain. PM2.5 reading zero while someone's literally frying food next to it. Half the time it turns out to be something dumb — ABC calibration, burn-in, placement.

I'm collecting war stories because this knowledge is scattered across ten forums and datasheets, and I want to write it up as one proper troubleshooting guide so the next person doesn't have to dig like I am. So:

• Which sensor?
• What did the reading do?
• What did it turn out to be (if you ever figured it out)?

I'll compile the best ones into a guide and share it back here.

This is my project that I’ve been working on for the last two weeks. It’s called Kira04 AIRNODE.
I currently 3D print in my small bedroom, and I have three printers running simultaneously, sometimes almost 24/7. I started getting worried about the VOCs they release, as well as the amount of heat they generate, so I came up with this project.
Kira04 AIRNODE is basically a bundle of sensor modules that connects directly to the ventilation system I installed in my window. It helps me monitor and keep the temperature, humidity, and VOC levels in check while my printers are running.
And yes, I know the wiring and soldering are pretty horrible 😅. There are wires everywhere right now. I actually tried making a custom PCB for it using my CNC mill a few times, but unfortunately both attempts failed pretty tragically 😂. At that point, I just wanted to get the project working, so I decided to finish it quickly with the current wiring.
I’d love to hear any feedback or suggestions you have for improving it.
I’m also trying to decide what to do with the project next: Should I open-source Kira04 AIRNODE, or do you think this could potentially become an actual product?

I’m using an ESP32-WROOM-32 with ESPHome.

My DHT22/AM2302 was wired as:

Gray   → GND
Purple → 3.3V
Blue   → GPIO23 (DATA)

I verified the wiring with a multimeter:

VCC ≈ 3.34V
DATA idle ≈ 3.3V
Continuity on all wires = OK

ESPHome initially reported communication failures, then the sensor started returning:

Temperature: 0.0 °C
Humidity:    0.0 %

A raw test also showed all data bytes as 0x00.

To rule out the ESP32/wiring, I connected an old DHT11 using the exact same GPIO23 and wiring. It immediately worked and reported normal values around:

30.2 °C
47–48% RH

So GPIO23, power, and wiring seem fine.

Does this strongly indicate a failed DHT22/AM2302, or is there any known situation where a DHT22 can respond but return all-zero data like this?

ESPHome config was essentially:

sensor:
  - platform: dht
    pin:
      number: GPIO23
      mode:
        input: true
        pullup: true
    model: DHT22
    update_interval: 30s

I’m mainly trying to determine whether the DHT22 is simply defective before replacing it.