U+ Connect Module Info / Captures

[mulcmu]

The U+ Connect module (GE Part# PBX23W00Y0) provides cloud based interface to select appliances. Module is in a small plastic case with a single push button and led on front, RJ45 port for connection to appliance, and internal magnets to secure product in rear housing. It comes with a 12-inch Ethernet cable to connect to appliance. FCC ID is ZKJ-WCATC001, report is here.

Connected it to my dryer for initial testing. The Android app to establish the connection is quite buggy, lots of random closes/crashes and not very responsive. Basic status for dryer settings were passed back to the app. It did not seem to support turning dryer on remotely. It had an option and confirmation dialog box to turn dryer off remotely but this function didn't actually work. Pin 7 had the expected19200 serial traffic. Here was sample capture of the traffic.

PCB photos: Top Bottom1: Bottom2:

[puddly]

Thanks for the pictures.

I'm seeing only six instances of the start-of-packet byte E2 in your capture. Did you invert the RX pin when capturing over serial? If you have an FTDI USB-serial adapter, it can be done with their FT prog utility:

[mulcmu]

I was using RealTerm. The invert option was not checked yesterday.

[puddly]

It's not a software tweak, it's something done in firmware or hardware. The serial data sent by the bus can erroneously be interpreted as "normal" serial but it isn't usable data.

[mulcmu]

I managed to get an ESP32 hooked up to log the serial data remotely with custom ESPHome UART. (Don't have to lug laptop to laundry now.) It is configured with the UART inverted in hardware. Only the RX is hooked up currently. Here were a few captures. Looks like e2 and e3 for packet start and end are coming across. capture1.txt capture2.txt captur3e.txt

[puddly]

I've re-written a large portion of the code. Try it out:

$ virtualenv -p 3.9 venv
$ source venv/bin/activate
$ git clone https://github.com/puddly/casserole
$ pip install -e ./casserole
$ cat capture2.txt | python -m casserole.tools.parser
2021-12-22 20:51:27 ubuntu.local __main__[48214] DEBUG RX: <E2 24 0B BE F0 01 20 12 56 3F E3 E1>
2021-12-22 20:51:27 ubuntu.local __main__[48214] INFO Parsed: <GEAFrame(src=0xBE, dst=0x24, payload=<F0 01 20 12>, ack=True>
2021-12-22 20:51:27 ubuntu.local __main__[48214] INFO Parsed payload: <ERDCommand(command=<ERDCommandID.READ: 0xF0>, erds=[0x2012:None])>
2021-12-22 20:51:27 ubuntu.local __main__[48214] DEBUG RX: <E2 BE 0D 24 F0 01 20 12 01 01 AC 66 E3 E1>
2021-12-22 20:51:27 ubuntu.local __main__[48214] INFO Parsed: <GEAFrame(src=0x24, dst=0xBE, payload=<F0 01 20 12 01 01>, ack=True>
2021-12-22 20:51:27 ubuntu.local __main__[48214] INFO Parsed payload: <ERDCommand(command=<ERDCommandID.READ: 0xF0>, erds=[0x2012:<01>])>
2021-12-22 20:51:27 ubuntu.local __main__[48214] DEBUG RX: <E2 24 08 BE F3 1C 31 E3 E1>
2021-12-22 20:51:27 ubuntu.local __main__[48214] INFO Parsed: <GEAFrame(src=0xBE, dst=0x24, payload=<F3>, ack=True>
2021-12-22 20:51:27 ubuntu.local __main__[48214] WARNING Failed to parse ERD: <F3>
...

The packets are also a little unstructured so I think yours is using the GEA1 protocol, like my washer. There's apparently now a GEA2 and GEA3.

The utility decodes bytes read from lines over stdin, so you can feed it any data as long as it looks something like this (must contain uart_debug and have hex bytes after <<<):

uart_debug <<< BF 0B 24 A0 01 60 03 9B 51 E3

[mulcmu]

Looks like my washer is GEA3. Here was a sample capture using two uarts on ESP32 to capture both lines between U+ and the washer. Uarts configured for 230400 baud but not inverted.

wcap1.txt

The casserole parser has been very useful for decoding.
wcap1.out.txt