Ok, so I made some progress with this, which I thought folks might be interested in.
Firstly, the hardware is very simple: an ESP32 module, and a TXB0104 level converter. I wired the level converter up to both ESP32-UART1 and ESP32-UART2, so that I could expose both COM ports on the 832 panel. I used the default pins for UART2, and chose GPIO26/27 for UART1, since the ESP32 can remap its pins fairly arbitrarily.
I also wired up a GPIO to the TXB0104’s enable pin so that I can disable/enable the level converter if desired. This seems not to be a good idea, because the RX pins on the ESP32’s UART then float, and cause garbled input. It might be a good idea to add a weak pulldown on the RX pins …
From a software perspective, I chose ESPHome, with a simple custom component to do the mapping from a TCP port to the UART. I found this (https://gist.github.com/oxan/4a1a36e12ebed13d31d7ed136b104959) which was almost perfect, then added a couple of mods to allow specifying the port in the constructor, so that I can run two separate stream server instances at once. I also added some debug code, so that the characters read/written to the UART’s are reported in ESPHome’s logs, which are subsequently available via USB on UART0, or over the network using esphome logs
, as well as via MQTT (I’m working on a utility to process these messages to assist in reverse engineering the Wintex command stream).
Here is the ESPHome yaml I created:
esphome:
name: alarm
platform: ESP32
board: esp32dev
platformio_options:
upload_speed: 460800
includes:
- stream_server.h
- stream_server.cpp
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
captive_portal:
# Enable logging
logger:
# baud_rate: 0
# Enable Home Assistant API
api:
mqtt:
broker: home.dawes.za.net
discovery: false
log_topic: alarm/logs
ota:
time:
- platform: homeassistant
id: homeassistant_time
text_sensor:
- platform: version
name: Alarm ESPHome Version
- platform: wifi_info
ip_address:
name: Alarm IP
ssid:
name: Alarm SSID
bssid:
name: Alarm BSSID
sensor:
- platform: uptime
name: Alarm uptime
- platform: wifi_signal
name: Alarm WiFi Signal
update_interval: 60s
switch:
- platform: restart
name: Alarm Restart
- platform: gpio
id: level_converter
inverted: false
name: Enable Alarm UARTs
pin: 13
uart:
# - id: uart0
# tx_pin: GPIO1
# rx_pin: GPIO3
# baud_rate: 115200
# data_bits: 8
# parity: none
# stop_bits: 1
- id: uart1
tx_pin: GPIO26
rx_pin: GPIO27
baud_rate: 9600
data_bits: 8
parity: none
stop_bits: 1
- id: uart2
tx_pin: GPIO17
rx_pin: GPIO16
baud_rate: 19200
data_bits: 8
parity: none
stop_bits: 2
custom_component:
- lambda: |-
auto stream_server1 = new StreamServerComponent(id(uart1),10000);
return {stream_server1};
- lambda: |-
auto stream_server2 = new StreamServerComponent(id(uart2),10001);
return {stream_server2};
The panel itself is configured to have a USB-COM on both ports.
At this stage, I can connect Wintex to either TCP 10001 or 10000, and use all of the usual Wintex functionality.
My plan going forward is to write a PC-based program that receives the logs via MQTT, applies known decoding rules to the commands sent and responses received, and displays them for human consumption and further decoding. Ideally, duplicate messages will be reduced to a counter, to reduce the amount of processing/thought required!
Once sufficient understanding of the Wintex protocol has been achieved, the plan is then to migrate that understading into a second ESPHome custom component that will expose intelligent API calls to HA or other MQTT subscribers.