Jumping in on the single-subscription behavior @joshua.longenecker mentioned above — I’ve got a fully characterized case and I’m hoping someone has found a way past it.
Setup: GE PVD28BYNFS (4-door French door fridge, board dated 2021), running @mguaylam’s esphome-gea component on an ESP32-C3 tapped on the RJ45 service port. It’s GEA2 and my adapter at 0xE4, the WiFi module at 0xBF, main board at 0x00.
I’ve confirmed on the bus:
- With the WiFi module plugged in, my adapter gets zero link-ACKs from the MC. Every F2 subscribe / F0 read / F1 write exhausts retries and drops. It’s not collision or timing: a single lone read into an otherwise-silent bus (passive-only, no re-subscribe flood) still gets no ACK.
- Pull the module, and the adapter immediately works fully. It reads compartment temps (0x1004), writes setpoints, the whole ERD set.
- So the module is holding the one subscription slot and the MC won’t service a second external client at all is what I’m thinking.
My adapter (0xE4) queues a read of 0x1004 (compartment temps):
[23:50:08.615][D][gea:965]: Queued read ERD 0x1004
[23:50:09.743][W][gea:915]: Request cmd=0xF0 id=0x08 exhausted retries, dropping
…no link-ACK ever came back. Same result every retry cycle:
[23:50:28.574][D][gea:965]: Queued read ERD 0x1004
[23:50:29.651][W][gea:915]: Request cmd=0xF0 id=0x09 exhausted retries, dropping
[23:50:48.576][D][gea:965]: Queued read ERD 0x1004
[23:50:49.677][W][gea:915]: Request cmd=0xF0 id=0x0A exhausted retries, dropping
Meanwhile the WiFi module (0xBF) is the ONLY external node the MC talks to.
It re-registers its subscription every ~5s and gets answered every time:
[23:50:09.742] SNIFF dest=0x00 src=0xBF : 00 08 BF F3 D2 BF # module → MC: F3 subscribe
[23:50:11.585] SNIFF dest=0xBF src=0x00 : BF 51 00 F3 18 00 07 … # MC → module: 24-ERD sub list
[23:49:55.449] SNIFF dest=0x00 src=0xBF : 00 0B BF F0 01 D0 07 02 0B # module → MC: read 0xD007
[23:49:55.488] SNIFF dest=0xBF src=0x00 : BF 10 00 F0 01 D0 07 04 .. # MC → module: answered
Passive snoop works great alongside the module. I get everything the module itself polls (doors, door-in-door, energy, filter, ambient) read-only. The catch: the module never fetches 0x1004, so compartment temps are simply never on the bus for me to snoop. That’s the one value I actually want, and it’s unreachable as long as the module owns the session.
My question: has anyone gotten both running simultaneously on one of these single-subscription appliances? The WiFi module (for the SmartHQ app) and a second client for HA read/write? Any appliance-side angle, a different address/role the MC will grant a second session to, a service-tool handshake, something in the GEA2 layer, or is it fundamentally one-client-or-the-other on this vintage?