As found out in the previous log, the wifi module is an XLW-210D from xlwtech, running on an AX220xx compatible chip from Asix.

Rabbit hole 3 (dead end):

It is possible to get access to the source code of the reference design with the right google queries and some guessing shockingly easy (why do they include the "blabla not for public relase" note only INSIDE the source code and not in the archive file name?)... as this data is not meant to be freely accessible on the web, I won't provide it here and won't provide tips how to find it. There is no "magic" in there, as the regular function of the device is just obvious, and neither the "AppSrv" nor the demoplug source is included.

Back to Rabbit hole 1:

If AppSrv is enabled, the device spits out to 114.215.182.213:8001 every 500ms:

> 11 00 <OWN MAC ADDR>

Obviously, it wants to call home. Lets answer that call by just echoing back:

> 11 00 <OWN MAC ADDR>
< 11 00 <OWN MAC ADDR>
> 11 00 <OWN MAC ADDR>
< 11 00 <OWN MAC ADDR>
...

This does not work, the device does not react. Lets assume the first two bytes are a command, last 6 ones are parameter. As embedded devs usually don't grab numbers from a RNG for enums etc. but use simple patterns... lets try:

> 11 00 <OWN MAC ADDR>
< 12 00 00 00 00 00 00 00
...silence....

Is it dead, jim? No! Exactly 60 seconds later, the device asks for AppSrv, this time with other content:

> 11 01 <OWN MAC ADDR>
< 12 00 00 00 00 00 00 00
> 11 01 <OWN MAC ADDR>
< 12 00 00 00 00 00 00 00
...

It is not happy with 0x12 anymore. Maybe it wants more?

> 11 00 <OWN MAC ADDR>
< 12 00 00 00 00 00 00 00
...60 seconds silence...
> 11 01 <OWN MAC ADDR>
< 12 01 00 00 00 00 00 00
...60 seconds silence...
> 11 02 <OWN MAC ADDR>
< 12 02 00 00 00 00 00 00
...60 seconds silence...
> 11 03 <OWN MAC ADDR>
< 12 03 00 00 00 00 00 00
... and so on.

Yay, AppSrv fake online :D

Another thing found out: If the payload is shorter than 8 bytes, the message is ignored. At least for the \x12 command the last 6 bytes just seem to be there for alignment and without any particular function.

Btw the source of the UDP packets is not checked by the device, as long as I sniff the data with libpcap and issue a simple

printf "\x12\x??\x00\x00\x00\x00\x00\x00" | nc -u 192.168.0.9 8001

the device is happy.

Uart communication does not seem to interfere with "AppSrv" actions in this state.

To this point, it was easy to figure out the protocol, just because there is direct feedback (read: changed or no response) from the device which "asked" for the right answer. Now the connection is there but I don't know what to ask the device for.

As the AppSrv thing is meant to be a remote-control service from smartphone/anywhere (google translator told me), there must be a command that lets us

a) write data to UART

b) read (poll) data from UART (or enable data transmission)

As this is a chip on my desk, I am sure they shipped it with the complete function and did not stop the implementation after handshaking, even if the AppSrv is offline right now...