Add support for tcp forwarded serial ports

[youduda]

This allows users to connect to deCONZ Zigbee radio devices that are forwarded via network e.g. with ser2net or socat by specifying a custom path in the format tcp://host:port.

Tested and working for 2 weeks over a VPN connection. Daily disconnections by the ISP, short-term high latency and other connections issues did not cause any major issues.

If this is accepted, I can add instructions and a working configuration example to the documentation.

[codecov-commenter]

Codecov Report

Merging #176 (76e2b76) into dev (b3aac2e) will decrease coverage by 0.09%.
The diff coverage is 80.00%.

@@            Coverage Diff             @@
##              dev     #176      +/-   ##
==========================================
- Coverage   96.69%   96.60%   -0.10%     
==========================================
  Files           7        7              
  Lines         908      912       +4     
==========================================
+ Hits          878      881       +3     
- Misses         30       31       +1     

Impacted Files	Coverage Δ
zigpy_deconz/uart.py	94.39% <80.00%> (-0.76%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b3aac2e...76e2b76. Read the comment docs.

[puddly]

Is this tcp:// protocol code necessary? PySerial natively supports the socket:// protocol: it's how all of the existing TCP coordinators are currently working and requires no extra code.

It's sort of documented in the ZHA docs (https://www.home-assistant.io/integrations/zha/#zigate-or-sonoff-zbbridge-devices), but only in the ZiGate section.

[youduda]

It is required. This does not use PySerial but pyserial-asyncio and a wrapper is required even for ZiGate. The implementation of ZiGate is quite similar to what I did.

[puddly]

The socket:// protocol works fine for me on HA Core 2021.11.5, with an unmodified zigpy-deconz:

2021-12-20 13:13:36 DEBUG (MainThread) [zigpy_deconz.uart] Connection made
2021-12-20 13:13:36 DEBUG (MainThread) [zigpy_deconz.api] Command Command.device_state (0, 0, 0)
2021-12-20 13:13:36 DEBUG (MainThread) [zigpy_deconz.uart] Send: 0x0702000800000000
2021-12-20 13:13:36 DEBUG (MainThread) [zigpy_deconz.uart] Frame received: 0x0702000800a20000
2021-12-20 13:13:36 DEBUG (MainThread) [zigpy_deconz.api] Device state response: [<DeviceState.128|APSDE_DATA_REQUEST_SLOTS_AVAILABLE|2: 162>, 0, 0]
2021-12-20 13:13:36 DEBUG (MainThread) [zigpy_deconz.api] Network state transition: OFFLINE -> CONNECTED
2021-12-20 13:13:36 DEBUG (MainThread) [zigpy_deconz.uart] Closed serial connection

zigpy-znp supports Ethernet coordinators that also use a TCP-serial proxy and it needs no special code to do this. I'm not sure why the zigpy-zigate has that code either.

I think the pyserial-asyncio code is generic enough to not care about the underlying transport, it just adapts pyserial to work with the asyncio event loop. Its source code does explicitly mention sockets so I think it's not merely working by accident:

class SerialTransport(asyncio.Transport):
    """An asyncio transport model of a serial communication channel.
    A transport class is an abstraction of a communication channel.
    This allows protocol implementations to be developed against the
    transport abstraction without needing to know the details of the
    underlying channel, such as whether it is a pipe, a socket, or
    indeed a serial port.                             ^^^^^^^^
    """

[Adminiuga]

All radios use pyserial-asyncio which is a wrapper around ptserial.
We did not need anything special to support socket URLs for other libs. Not sure why you needed it for Deconz. Did you try with the original version?

[youduda]

Nice, works for me as well. Due to the ZHA documentation I checked the socket:// schema as well before creating this wrapper code, and it didn't work, but now it does. Looks like my setup has been the issue, not the code.

I'd suggest to revert this MR.