Serial wireless bridge (not full spec RS232)

I didn’t want to high jack your thread so I didn’t give much information about my APC setup. But as you’ve asked. The APC serial connection is RS232. It only uses TX, RX and ground. I’m using a MAX3232 RS232 to TTL ic to connect the RX and TX to the ESP.

I find Esphome much easier to use than Tasmota, but that’s obviously personal preference and familiarity. I’ve had a quick look at the Serial to TCP Bridge - Tasmota and I would have thought that using a MAX3232 ic would be a more reliable way of connecting as it gives the correct voltage conversions.

EDIT
Disregard my comment about using a MAX3232. I’ve re-read the link and realised that it’s not a voltage level problem but a problem with the limitations of using that GPIO.
Have you considered using an ESP32 instead of an ESP8286? It has more UART’s available so doesn’t have the same GPIO limitations.

The APC serial connection is RS232. The owners manual shows the connections and protocol 2400, 8, N 1. It only uses TX, RX and ground. If I connect a USB to RS232 cable to the UPS it appears correctly with all the correct values in the Home Assistant AP Integration and in the apcupsd program, so I know that the serial port is working.

The issue appears to be that the serial data is being corrupted in some way by the Stream Server. Viewing the output of the apcupsd program it shows that some of the values reported are correct but some are completely wrong, ie Supply Voltage is 800 volts and the wrong model of UPS. But they are also not consistent and often no values at all are shown.

I finally got my proof-of-concept working! :slight_smile:

The idea of having a pullup and pulldown resistors followed by a diode was a red herring. But using GPIO13 for RX and GPIO15 for TX worked. (using GPIO01 and GPIO3, the defaults, may have boot messages sent.

My hardware is

GND and 3V3 are provided by the USB/Serial device and connected with the jumper wire (Magic Smoke alert! BE SURE TO US THE 3V3 and not 5V!)

On the ESP-12F’s
connect the resistor between GPIO15 and GND
connect a wire from EN to 3V3

RX of the USB/Serial connects to GPIO15
TX of the USB/Serial connects to GPIO13

The Tasmota binary is ZBBridge. This can be selected when using the Tasmota Web Installer. A development test frame is nice to have to download the binary.

It is possible to use the USB/Serial device to install Tasmota.

  1. wire the ESP-12F as above with the following changes
  2. connect GPIO01 to RX of the USB/Serial device
  3. connect GPIO03 to TX of the USB/Serial device
  4. connect GPIO0 to GND
  5. Plug the USB/Serial device into a USB port.
  6. Run the installer
  7. When complete, disconnect the USB/Serial from the computer
  8. Disconnect GPIO0 from GND
  9. reconnect the USB/Serial
  10. restart the web installer
  11. At this point the installer will give you the option to set the SSID/password of your WiFi in the ESP12F during installation.
  12. Move Rx and Tx back to 13 and 15

The module configuration is set from the ESP-12F web page (you will know the IP address of the device in the address bar of the web page)
Set GPIO13 to TCP Rx and GPIO15 to TCP Tx

On the console page of one of the ESP-12F’s execute the command:
TCPStart 8888 [ip address of other ESP-12F]
On the console page of the other ESP-12F, execute the command:
TCPConnect 8888,[ip address of the first ESP-12F] (The comma ‘,’ is required!)

The bridge should be operational. I tested using two instances of PuTTY, COM port of ESP-12F, BAUD rate 115200. (BAUD rate is default and can be changed. Bits are hard coded to be 8N1)

The first ESP-12F is configured as a TCP server. This can easily be made to happen at boot time.

The second is a bit tricky because the first ESP-12F (TCP server) has to be up and running before the second can connect to it.

As a bit of flourish, I set GPIO02 to Relay 1. GPIO02 is connected to the onboard LED. If the ESP-12F is running, I can turn ON/off the LED from the device’s web page.

The next steps are

  1. get bridge running automatically at boot.
  2. Connect an Arduino Nano configured as a MySensors Gateway connected to one side of the bridge (ESP-12F powered by the Arduino) and the other side connected to a USB/Serial which will look like a MySensors Gateway to Home Assistant.
  3. Further? create virtual TCP client in the HA computer that appears to be a serial port to HA. This would be the “other” end of the bridge.

to get the connection to occur on boot,
Device A will have this rule:
Rule1 ON System#Boot DO TCPStart 8888 192.168.1.199 ENDON
and enabled with
Rule1 on
Device B will have this rule:
Rule1 ON System#Boot DO Ping 192.168.1.198 ENDON ON Ping#192.168.1.198#success<1 DO Backlog Delay 100; power toggle; Ping 192.168.1.198 ENDON ON Ping#192.168.1.198#success>0 DO Backlog TCPConnect 8888,192.168.1.198; Power 1 ENDON
and enabled with
Rule1 on

This is three triggers:

  1. send out a ping on boot
  2. If there is no response to the ping, wait 10 seconds, blink the onboard LED, ping again
  3. if there is a response to the ping, which means Device A is up and the TCP server is probably running, connect to the TCP server and turn on the onboard LED.

In my “Next step 3” I think this already exists as part of the MySensors Integration as the “Ethernet gateway”.

I have successfully reach my goal with two ESP32 (DEV KIT) as a wireless cable. All the above was theory (to me) until now when I put all of the hardware together and tested it.

@IanQ, this should work for you. You’ll just use a different BAUD rate.

My set up is an Aduino Nano running a MySensors Serial Gateway to Home Assistant. Normally, the Nano is plugged into a USB port of the computer which is running HA. My set up is: Nano-(ttl serial)->ESP32-(WiFi)->ESP32-(ttl serial)->Serial-to-USB–>computer–>HA with MySensors Integration.

Thanks for all your help anc comments

Glad to hear that you got it working. Not sure that I was much help?
I was going to try your method using ESP-12F modules but only have one spare one at the moment. I’ve ordered another one and will try it when it arrives.
I gave the ESP32 ETH01 another try on my UPS after updating Esphome to 2026-1-0 and flashing the updated oxan Esp code. The later code was meant to reduce latency so I hoped it had helped. After rebooting the ESP and UPS a couple of times it all worked and all the correct values were shown in the APC integration. I had it running for over 30 minutes and even after rebooting the UPS and ESP32 individually and together it kept working.
But when I tried it the next day it didn’t work, giving random and completely inaccurate values, and nothing I did made it work again. I noticed that the receive led on the ESP32 board was on all the time, even if the MAX3232 was disconnected from the UPS. This had happened before but rebooting everything cleared it, but now it doesn’t. So it looks like the MAX3232 is faulty and hopefully that may have been why it was only working occasionally. I’ve ordered another MAX3232 and hopefully that will get it working reliably.

If I can get the ESP32 ETH01 to work reliably that would be my preferred option as it only uses one ESP device, so it’s more energy efficient, and a wired connection should be more reliable than a wireless one. But as your method is confirmed as working I’ll give it a try as it will give me an alternative if needed.

I notice you are now using ESP32 boards instead of ESP-12F. Was that because the ESP-12F boards wouldn’t work?
Are you using the same Tasmota ZBBridge firmware with the ESP32 boards.

As a generic comment, the discussion at The best gets better - Home Assistant Connect ZBT-2 - #188 by Hedda may trigger some more ideas.