GEA2 field reports — share your setup and reliability experience

[mguaylam]

GEA2 field reports

This component is new and protocol: gea2 has not yet been validated against a real appliance over an extended period of time. The implementation is complete and passes the test suite, but we have no field data on how it behaves on a live multi-node GEA2 bus. Before deciding what to harden next — for example, byte-level collision detection on the half-duplex bus, see docs/protocol.md#collision-handling-gea2 — we need real-world reports.

The current implementation does not match GE’s reference firmware (tiny-gea-api) on collision handling: we filter our own self-echo by dest address and rely on retries to recover from collisions, instead of detecting them at the byte level. That may be perfectly fine in practice — or it may cause sluggish writes and dropped requests on busy buses. We don’t know yet.

If you’ve wired this up and started using protocol: gea2, please share what you’re seeing here — including "everything works" reports, which are just as useful as bug reports.

What we’d like to know

1. Appliance — model number, year, type (washer / dryer / fridge / …).
2. Adapter — FirstBuild, mulcmu PCB, custom?
3. How long has it been running? Hours, days, weeks?
4. get_dropped_requests() value after a representative period of uptime. Expose it via a template_sensor or check the logs at INFO.
5. Subjective feel — do writes from Home Assistant feel responsive? Does state get stuck or lag?
6. Logs — any recurring WARN / ERROR lines from the gea component? (timeouts, parse errors, dropped requests)
7. Configuration — your gea: block (especially poll_interval) and roughly how many ERDs you have declared.
8. Other active modules on the appliance bus that you’re aware of (control panel, ice maker, dispenser, …).

How to gather the diagnostics

sensor:
  - platform: template
    name: "GEA dropped requests"
    lambda: |-
      return id(gea_hub).get_dropped_requests();
    update_interval: 60s

Or just grep your ESPHome logs for dropped and WARN lines.

What happens next

Reports here will inform whether we:

• Document the current behaviour as sufficient and close the topic, or
• Implement byte-level collision detection (described in docs/protocol.md#collision-handling-gea2) with a real-world scenario to validate against.

Either way, no decision is being made in a vacuum — your reports drive this. Thanks!

[mulcmu]

Clothes dryer model GTD72EBPN0DG
dryer.yaml

Been running almost 2 weeks, no issues. Slower than GEA3 response but that is expected.

MCU polls 0xBF for wifi adapter / Uconnect+ module. Ignored packet lines in logs.
Sent packets are looped back for gea2 so each tx packet to MCU generates a ignored packet message as well.

Had a few CRC errors, but nothing problematic.

[mguaylam]

Nice! The loopback is to be expected for GEA2 indeed. Your dryer don’t support GEA3?
I’m also so happy that it works with your adapter. I did not had the time to play with it yet, I’m very busy for the next week, can’t wait to try it.

I see you don’t have any writes, had you had the chance to try it out?

[mulcmu]

I haven't tried any write commands for any of my appliances yet. Got both washer and dryer at same time but one was gea2 and one gea3. Neither had built-in wifi.

My point with the loopback was flooding the logs with noise, #5

[mekaneck]

I finally got this working. I have a number of appliances I'll be using, this is just the first.
1. Appliance — Washing machine GTW750CPL1DG
2. Adapter — mulcmu PCB
3. How long has it been running? Only a few hours
4. get_dropped_requests() value Not reviewed yet
5. Subjective feel — Writes seem fast enough. Reads are a bit delayed. Neither will be an issue.
6. Logs — No issues yet
7. Configuration —

gea:
  id: gea_hub
  uart_id: uart_gea
  protocol: gea2
  dest_address: 0x23
  poll_interval: 1s

I'll note that I have no idea how a normal user would determine the correct destination address. I am fortunate to have an "official" homeassistant adapter which can run the gea2 fork, and that code will determine the correct destination address. So I did that first, then updated my yaml config with the correct address, and flashed it on my mulcmu adapter.

[mguaylam]

Thanks I’ll look at how we can improve on auto-detection for GEA2. It’s quite elegant what he did. I wonder where he got 0x0008 from. I also wonder if we could lower the poll interval below 1 second without having too much CRC errors to make GEA2 faster. Will need people willing to test that.

[mulcmu]

I had a few old captures of Uconnect+ connected to dryer. There was an 0xF3 command that looked to be a list erds and maybe and 0xF4 that was subscription like.

                                   
								   gea2 subscibe list all???
								   E2 FF 08 BE F3 AA 2D E3 
								   
								   gea2 subscribe list reply???
								   E2 BE 33 24 F3 0E 00 37 00 20 00 00 20 01 00 20 02 00 20 0A 00 20 10 00 20 1D 00 20 38 00 20 39 00 20 4D 00 20 50 00 20 51 00 20 52 00 20 53 00 D5 4F E3 E1 

[mekaneck]

I wonder where he got 0x0008 from.

0x0008 is the appliance type, which only the main board should respond to. So the adapter uses the broadcast destination address of 0xFF and asks for ERD 0x0008 and only one board on the bus should reply. So then that source address is consumed and used as the destination address for all subsequent ERD requests.

[mekaneck]

One thing I've noticed is that for both my washer and dryer, the wifi module address is 0xBF. So in order to get the wifi connection status (ERD 0x6003) it needs to be requested from that address rather than the main board address. I was able to modify the gea2 code for the official adapter to do that, but haven't looked to see what changes would be necessary to add that erd to this ESPHome component.

[mekaneck]

I am attempting to get this code working on a dryer, and am not having any success.

1. Appliance — Clothes Dryer GTD75GCPL0DG
2. Adapter — mulcmu PCB
3. How long has it been running? Only intermittently
4. get_dropped_requests() value N/A
5. Subjective feel — N/A
6. Logs — very verbose logs attached
7. Configuration —

# 2. Set up the UART (pin numbers depend on your board)
uart:
  id: uart_gea
  tx_pin:
    number: GPIO5
    inverted: true
  rx_pin:
    number: GPIO10
    inverted: true
  baud_rate: 19200

# 3. Define the GEA hub
gea:
  id: gea_hub
  uart_id: uart_gea
  protocol: gea2
  dest_address: 0x2B
  src_address: 0xE4
  poll_interval: 5s
  gea2_discovery: false
  erd_lookup: false

Using the official adapter and the gea2 forked code, I am able to confirm the main board address (0x2B) and able to read 18 valid ERDs. The official adapter uses a hardcoded 0xE4 as the source (adapter's own) address, so that is what I've used as well.

I suspect I'm having issues with collisions but unsure how to further debug. Attached are the very verbose logs.

esphome_dryer_logs_very_verbose.txt

I have tried this physical board on both the washer and the dryer, and confirmed that it works on the washer (with the appropriate yaml), so there isn't anything wrong with the manufacturing of the board itself.

I have tried some debugging with forking the esphome code and leveraging AI, but it is taking me down rabbit holes that doesn't seem fruitful. It was convinced the baud rate should be 9600 and also convinced the bus was very noisy. I went back to the official adapter and code and confirmed that it was working on 19200 and also modified the gea2 code to post to the serial output when messages appeared on the bus that had a destination of something other than the adapter. My washer never has other messages, but my dryer does occasionally have one message from the main board (0x2B) to the wifi module (0xBF), and then the associated reply immediately after, but that is the only other traffic and only seems to happen every ~10 seconds or so.

[Zagrophyte]

What we’d like to know

1. Appliance — GDF640HSM0SS Dishwasher
2. Adapter — mulcmu PCB-A (JLCPCB)
3. Just installed
4. get_dropped_requests() value - see screenshot
5. Unknown since no bus connect
6. LED toggles seem to lag
7. Nothing but dropped requests - did ignore a wifi board 0xBF poll though
8. Configuration — see screenshots
9. Should just be control board and UI Board.

[mguaylam]

Good idea indeed since it will last the time of the time out, should speed up considerably.

[Zagrophyte]

I was able to find a shorter cable and this helped. Currently testing #10

[Zagrophyte]

I was able to get all the newly discovered ERDs reading in my YAML, I'm up to 48 now!

With 100ms polling interval I am still getting responsiveness of ~4-5 seconds (as measured by door open/close and a few other statuses) while polling all 48 ERDs.

Some are very interesting! One seems to update every minute with a timestamp, and another seems to have raw analog voltages:

[mguaylam]

Nice!! Yeah I have a lot of questions seeing those screenshots. I definitively do not have those interesting ERDs on my GEA3 dishwasher.

As for the poling interval, I don't know... it's true that polling just 40 ish ERDs takes quite a bit of time. I might look into dynamic polling where you could poll some ERDs fast and other not, freeing time for the ones you care.

I honestly don't know how fast we can go with this bus. Let me know anything you find. 🙂

[Zagrophyte]

I like that idea, I was thinking the same about "interval groups" or tiers, some are more suitable for realtime, while some are more background information over longer time.

Will be fun to see how far it can be pushed over time!

[burkemw3]

Myself and one other have gotten Bradford White AeroTherm RE2H50S10-1NCTT-CON heat pump hot water heaters working with GEA2. Some more info at https://community.home-assistant.io/t/water-heater-bradford-white/588528/25 and the immediately following post from me.

My first GEA2 scan didn't yield anything. I didn't have src or dst address set. I set them both (and jumped through NVS reset hoops), then got the ERD list from my post. Not sure if it was bad luck, or something else.

I used first build adapter, mannkind appears to have used mulcmu build

[mguaylam]

Thanks for reporting back.

I taught I fixed auto discovery of the destination with #7

I'll try to check what went wrong. What did you end up putting as settings? Did you have any info on the log when it try to auto discover the board address?

[burkemw3]

Pretty sure my initial config was

uart:
  id: uart_gea
  tx_pin: GPIO9
  rx_pin: GPIO10
  baud_rate: 19200

gea:
  id: gea_hub
  uart_id: uart_gea
  protocol: gea2
  gea2_discovery: true
  erd_lookup: true

It did output a log message about finding the dest address. I can't actually remember if it was the same as I'm using (0x60) or something else like 0xC0 from the erd discovery docs.

Working config is from linked post, but here's the direct link: https://pastebin.com/rMDuX31g

[jcastro14]

I posted this as an "issue" at first, then tried to delete it. Here's my summary of my exploration of my Dishwasher and Fridge:

esphome-gea Investigation Summary — Fridge + Dishwasher

Two GE Cafe appliances integrated via the FirstBuild GEA adapter
(mguaylam/esphome-gea), both over GEA2. This covers what was found on
each appliance, and — more importantly for upstream — three real bugs
found in the component itself, plus several tooling fixes to
tools/erd_scanner.py.

---

1. Refrigerator — GE Cafe CYE22TSHGSS

• Protocol: GEA2, 19200 baud, half-duplex
• Wiring: Seeed XIAO ESP32-C3, TX=GPIO9, RX=GPIO10
• Addressing: src_address: 0xBB, dest_address: 0x00 (single node,
  found via GEA2 auto-discovery on boot)

ERD coverage

Full 0x0000–0xFFFF brute-forced across four passes
(0x0000-0x0FFF, 0x1000-0x2FFF, 0x3000-0x7FFF, 0x8000-0xFFFF).
38 unique responsive ERDs total, all falling in the 0x0000-0x0FFF
and 0x1000-0x1105 ranges; nothing anywhere else in the address space.

Confirmed via GEA2 on-device discovery + brute force:
0x0001, 0x0002, 0x0003*, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008, 0x0009, 0x000A, 0x1000*, 0x1001*, 0x1002*, 0x1003*, 0x1004, 0x1005, 0x1006, 0x1007, 0x1008*, 0x1009, 0x100A, 0x100B, 0x100C, 0x100D, 0x100E, 0x100F, 0x1010, 0x1011*, 0x1012, 0x1013, 0x1014*, 0x1016, 0x1100, 0x1101, 0x1102, 0x1103, 0x1104, 0x1105

(* = not in the public GE ERD spec nor the community fork's known-ERD
list — found only via true brute force, invisible to the curated-table
gea2_discovery sweep.)

Notable entities built from these: refrigerator/freezer temps and
setpoints, door alarms, ice maker status, water filter status, dispenser
counters (cold water / crushed / cubed ice), door-open time/count,
diagnostic cycle history (0x1100-0x1105), and hot water dispenser status

• writable desired-temperature control (0x1010/0x1011/0x1018).

Door pocket light — investigated, concluded hardwired

Exhaustively tested: the documented 0x3108 ("Door Pocket Light State")
ERD from GE's public spec does not exist on this bus at all — confirmed
absent across the full address-space brute force. Every other
plausible/undocumented candidate (0x1000, 0x1002, 0x1003, 0x1008,
0x1011, 0x1014, 0x0003) was tested directly against the physical
switch (on/off/on, watching for a matching flip) — none correlated.
Conclusion: the dispenser light is hardwired directly to its physical
switch, with zero GEA bus visibility.

---

2. Dishwasher — GE Cafe CDT725SSF6SS

• Protocol: GEA2, 19200 baud, half-duplex (a GEA3 attempt at 230400
  baud on GPIO21/GPIO20 first was completely silent — 0 bytes ever
  received — before switching to GEA2 and getting real traffic)
• Wiring: same board type, TX=GPIO9, RX=GPIO10
• Addressing: src_address: 0xBB, dest_address: 0x45

Two-node bus topology

GEA2 address-discovery probe found two nodes: 0x41 and 0x45.

• 0x41 never answers any directed read (confirmed via direct
  brute-force testing — zero bytes on the wire for any request). It does,
  however, broadcast a fixed, identical 6-byte message three times at
  power-up, then goes silent for the rest of its life:
  dest=0xFF (broadcast) src=0x41 cmd=0x01, payload
  FF084101668F. Best guess: a boot presence-announcement from a
  secondary board (UI/display?), not a general-purpose ERD server.
• 0x45 answers every request, including for unsupported ERDs (see
  bug GEA2 field reports — share your setup and reliability experience #3 below) — this is the node used for all real ERD work.

ERD coverage

Full 0x0000–0xFFFF brute-forced against 0x45 in one continuous
36h28m run (after the fixes below made scanning practical). 14 unique
responsive ERDs, all in 0x3000-0x301B plus one isolated outlier.

ERD	Size	Status	Notes
0x3004	4B	static	undocumented
0x3005	1B	static	undocumented
0x3006	2B	Door Count (public spec)	u16, decoded: 5,362
0x3008	2B	Error (public spec)	error ID + active flag
0x3009	6B	Cycle Counts (public spec)	started/completed/power-on-reset u16 each; decoded 0/0/93
0x300C	2B	static	undocumented, 0001
0x300D	8B	live only during active cycle, all-zero idle	undocumented — see decode below
0x300F	12B	live, slow continuous drift (confirmed over both ~1 day and ~7h idle windows)	undocumented, unit unconfirmed
0x3016	2B	static	undocumented
0x3017	1B	live only during active cycle (0 idle, 50-100 active)	undocumented — turbidity/soil sensor hypothesis
0x3019	1B	static	undocumented
0x301A	2B	static	undocumented
0x301B	41B	static per-sample, structurally looks like a repeating event log (near-sequential 4-byte values incrementing by exactly 3)	undocumented
0xD005	11B	static, all-zero	undocumented, isolated address far outside the main cluster

0x300D decoded field hypotheses (from a live wash-cycle capture,
unconfirmed — pending comparison against the dishwasher's own
display):

• byte 0: constant 4 (record type?)
• byte 1: fluctuates 145–172, no clear trend → possible water temp (°F)
• bytes 2–3 (u16): steadily decreasing (494→483 over ~5 min) → possible
  time remaining
• bytes 4–5 (u16): fluctuates narrowly (1780–1787) → unidentified
  secondary sensor
• bytes 6–7 (u16): steadily increasing (2397→2407) → possible elapsed
  cycle time

---

3. Critical bugs found in the gea component

All three below were found while chasing why the dishwasher connection to
0x45 kept permanently freezing with no error logged. All are in
components/gea/gea.cpp / gea.h.

Bug 1 — GEA2 bus-idle gate can permanently starve the request queue

The next queued request is only promoted/transmitted once
gea2_bus_clear_() sees GEA2_TX_IDLE_MS (10ms) of silence. On a node
that replies to every transmission (including retries) with enough
traffic, a genuine 10ms gap can stop recurring entirely. Once that
happens, the queue is stuck forever — no error, no warning, just total
silence from then on.

Fix applied: added GEA2_MAX_QUEUE_BLOCK_MS (2000ms) — if the queue
has been blocked that long, force-transmit anyway. Worst case is one
collision, recoverable via the normal retry path; the alternative was a
permanent silent hang.

Bug 2 — "frame stuck" recovery was documented but never implemented

gea.h had a comment and a GEA2_FRAME_STUCK_TIMEOUT_MS constant
describing recovery for a frame that starts (STX seen) but never reaches
ETX — but no code path ever checked it, and the paired timestamp
(rx_frame_progress_ms_) was never assigned anywhere. Any incomplete
incoming frame would wedge rx_state_ outside IDLE forever, with the
receiver never recognizing a new frame again.

Fix applied: actually wired up rx_frame_progress_ms_ in
process_rx_byte_() and added the missing timeout check in loop(),
mirroring the existing echo-timeout pattern. Settled at 500ms after
testing — a much longer window (3000ms) was tried first on a hypothesis
that a slow real response was being cut off prematurely, but direct
evidence disproved that (buffered byte counts stayed just as small even
at 12x the timeout), so it was brought back down.

Bug 3 — short NAK-style replies are silently dropped, wasting all 10 retries every time

The GEA2 read-response parser requires pkt.size() >= 10 to recognize
any response shape at all. On the dishwasher, 0x45 replies to
unsupported-ERD reads with a fixed, correctly-addressed, CRC-valid but
much shorter (~7 byte) reply — e.g. BB0945F000918A (dest=us, len,
src=node, cmd=0xF0, status byte, CRC). This never passes the
minimum-size check, so it's silently ignored and finish_pending_() is
never called — meaning the component blindly burns through all
REQUEST_MAX_RETRIES (10) retries and 6+ seconds (sometimes far more
under bus contention) for an ERD that was actually answered immediately.

Fix applied: if a short reply arrives from the exact node we're
waiting on (src == pending_.dest) using the same opcode while a GEA2
read request is active, treat it as a definitive NAK and call
finish_pending_() immediately instead of retrying. Cut typical
per-unsupported-ERD resolution time from 6–10+ seconds down to under 1
second, which is what finally made a full 65,536-address brute-force scan
of this appliance practical.

Side note, unresolved: this same board sends its short reply twice
per exchange, and the second copy consistently arrives truncated. This
was originally assumed to be our own retransmission colliding with it —
directly disproven, since it still happens even with retries eliminated
entirely by bug #3's fix. Root cause unknown; confirmed harmless (the
first copy is always complete and is what we now act on).

---

4. tools/erd_scanner.py fixes

• aioesphomeapi version incompatibility: execute_service() is
  synchronous in 34.2.1 (the version pinned by ESPHome 2025.7.x) but a
  coroutine in newer releases. Fixed with an inspect.isawaitable() check
  instead of assuming either shape.
• Reconnect resilience: added automatic reconnect-with-backoff for
  both the initial connection and mid-scan interruptions (previously any
  drop crashed the whole scan).
• Checkpoint/resume: added --checkpoint, --resume, and
  --checkpoint-every so multi-hour/multi-day brute-force runs survive
  interruption without losing progress.
• Silent range-scan fallback bug: --range without an explicit new
  --brute-force flag would silently fall back to scanning only the
  curated known-ERD table intersected with that range — not every address
  in it — completely defeating the purpose of a wide brute-force scan
  with no indication anything was wrong.
• Removed a self-inflicted deadlock: a "wait for bus connected before
  resuming" check (added to fix a real race condition after device
  reboots) turned into a permanent deadlock once all polled entities were
  removed from the device config — GEA2 has no spontaneous traffic, so
  "bus connected" can only ever become true as a result of the very read
  the scanner was refusing to send first. Removed the blocking wait
  entirely.

---

5. Other notes for whoever picks this up

• gea2_discovery: true only sweeps a curated ~2,445-address table
  (union of GE's public ERD spec + the community fork's known-ERD list),
  not the full 65,536-address space. This is easy to assume covers
  everything; it doesn't. True brute force (erd_scanner.py --brute-force) is the only way to find undocumented, appliance-specific
  ERDs, and is how most of the fridge's and all of the dishwasher's
  "unknown" ERDs above were found.
• The 0x300D and 0x3017 decodes on the dishwasher are working
  hypotheses from correlating behavior with wash-cycle timing, not
  confirmed against documentation — flagged clearly in the code comments
  as such, pending a direct comparison against the appliance's own display
  during a cycle.