Sila Solar V2000M

[andrewww173]

Hi! does my Sila Solar V2000M inverter support this?
I tried using two different RS232 converters on each of them, the result is the same. I checked all the wires with a multitester, everything is fine with the connection. Below is a photo of the wires:

[syssi]

Why did you attach 4 wires? Please remove the black one and compare your setup with this one:

https://github.com/syssi/esphome-pipsolar#schematics

[syssi]

You have to swap the red and white wire!

[andrewww173]

This is the cable included with the inverter in the box. I'm all
I did as you said, but the result does not change, I tried everything, used pins gpio1/gpio3 and gpio5/gpio4, tried to connect through different cables and other max32 modules. The inverter does not send any data

[syssi]

Did you try a loopback test? Connect the orange and orange-white wire and have a look at the debug output of the uart component. Do you see outgoing and incoming traffic?

[andrewww173]

sorry, I didn't understand ) I need to disconnect the brown wire from max3232 or connect orange and orange-white wires directly to wemos?

[syssi]

No. Just connect the orange wire to the orange-white wire (RX to TX). In this case the transmission is routed back to the receiver and you should see outgoing traffic as incoming bytes (too).

[andrewww173]

I connected two wires on the board and nothing happened

[syssi]

Please provide a ESPHome log. I would like to verify your interpretation. :-)

[andrewww173]

please )
For now, I'll try to do the same on another module. I have a couple rs 232 to ttl
logs_wemos-03-solar_logs.txt

[andrewww173]

look, here's a new module, but nothing new in the logs

logs_wemos-03-solar_logs (2).txt

[syssi]

Please enable the debug mode of the uart TTL. You cannot see any incoming raw traffic without this setting.

logger:
  level: DEBUG
  # Don't write log messages to UART0 (GPIO1/GPIO3) if the inverter is connected to GPIO1/GPIO3
  baud_rate: 0

uart:
  id: uart_0
  baud_rate: 2400
  tx_pin: GPIO4
  rx_pin: GPIO5
  debug:
    direction: BOTH
    dummy_receiver: false
    after:
      delimiter: "\r"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

[andrewww173]

logs_wemos-03-solar_logs (3).txt
and log with looped wires
logs_wemos-03-solar_logs (4).txt

[syssi]

Okay. There is no incoming traffic in all logs. In this case the issue is located between the RS232 converter and your ESP. Please connect GPIO4 to GPIO5 as next step. In this case we ignore the RS232 converter and are creating the loopback at the ESP.

[andrewww173]

ok, I attached the log and my yaml
logs_wemos-03-solar_logs (5).txt
wemos-03-solar.txt

[syssi]

Let's use the protocol test for the different loopback scenarios: https://github.com/syssi/esphome-pipsolar/blob/main/tests/esp8266-test-protocols.yaml

Please flash this YAML and provide another log. I guess the log will be more clear here.

[andrewww173]

this log with lopped GPIO4 to GPIO5
logs_wemos-03-solar_logs (6).txt
and this log with connected RS232 and inverter
logs_wemos-03-solar_logs (7).txt

[syssi]

Please unplug the inverter. Connect/bridge the RX/TX pin of the RS232 converter again to create the loopback and provide another log.

[andrewww173]

ok, please.
Now RS232 is connected to wemos, but inverter is unplugged
logs_wemos-03-solar_logs (9).txt

[syssi]

Please unplug the RS232 converter now and connect GPIO4 to GPIO5 + provide another log.

[andrewww173]

here it is )
logs_wemos-03-solar_logs (10).txt

[syssi]

Did you connect GPIO4 & GPIO5 for sure?

[syssi]

I just learned a software serial connection (GPIO4/GPIO5) doesn't supported full duplex and the loopback test doesn't work here. Please change the protocol test to GPIO1/GPIO3 + set the baud rate of the logger to 0:

substitutions:
  name: pipsolar
  tx_pin: GPIO1
  rx_pin: GPIO3

esphome:
  name: ${name}

esp8266:
  board: d1_mini

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

ota:

logger:
  level: DEBUG
  baud_rate: 0

api:
  reboot_timeout: 0s

uart:
  id: uart0
  baud_rate: 2400
  tx_pin: ${tx_pin}
  rx_pin: ${rx_pin}
  debug:
    direction: BOTH
    dummy_receiver: true
    after:
      delimiter: "\r"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

interval:
  - interval: 80s
    then:
      # PI30/PI30MAX/PI30REVO/PI41
      - logger.log:
          level: INFO
          format: "Testing PI30/PI30MAX/PI30REVO/PI41 commands..."
      - logger.log:
          level: INFO
          format: "This is the set of commands supported by the pipsolar component!"
      - uart.write: [0x51, 0x50, 0x49, 0xBE, 0xAC, 0x0D]  # QPI\xbe\xac\r
      - delay: 1s
      - uart.write: [0x51, 0x44, 0x49, 0x71, 0x1B, 0x0D]  # QDIq\x1b\r
      - delay: 1s
      - uart.write: [0x51, 0x46, 0x4C, 0x41, 0x47, 0x98, 0x74, 0x0D]  # QFLAG\x98t\r
      - delay: 1s
      - uart.write: [0x51, 0x4D, 0x4E, 0xBB, 0x64, 0x0D]  # QMN\xbbd\r
      - delay: 1s
      - uart.write: [0x51, 0x4D, 0x4F, 0x44, 0x49, 0xC1, 0x0D]  # QMODI\xc1\r
      - delay: 1s
      - uart.write: [0x51, 0x50, 0x49, 0x47, 0x53, 0xB7, 0xA9, 0x0D]  # QPIGS\xB7\xA9\r
      - delay: 1s
      - uart.write: [0x51, 0x50, 0x49, 0x52, 0x49, 0xF8, 0x54, 0x0D]  # QPIRI\xF8T\r
      - delay: 1s
      - uart.write: [0x51, 0x50, 0x49, 0x57, 0x53, 0xB4, 0xDA, 0x0D]  # QPIWS\xb4\xda\r
      - delay: 1s
      - uart.write: [0x51, 0x54, 0x27, 0xFF, 0x0D]  # QT'\xff\r
      - delay: 1s

      # PI41 split phase
      - logger.log:
          level: INFO
          format: "Testing PI41 split phase / multiple strings commands..."
      - uart.write: [0x51, 0x50, 0x49, 0x47, 0x53, 0x32, 0x68, 0x2D, 0x0D]  # QPIGS2h-\r
      - delay: 1s
      - uart.write: [0x51, 0x50, 0x32, 0x47, 0x53, 0x30, 0x14, 0x05, 0x0D]  # QP2GS0\x14\x05\r
      - delay: 1s
      - uart.write: [0x51, 0x50, 0x32, 0x47, 0x53, 0x31, 0x04, 0x24, 0x0D]  # QP2GS1\x04$\r
      - delay: 1s

      # PI18
      - logger.log:
          level: INFO
          format: "Testing unsupported PI18 commands..."
      - uart.write: [0x5E, 0x50, 0x30, 0x30, 0x35, 0x50, 0x49, 0x71, 0x8B, 0x0D]  # ^P005PIq\x8b\r
      - delay: 1s
      - uart.write: [0x5E, 0x50, 0x30, 0x30, 0x35, 0x47, 0x53, 0x58, 0x14, 0x0D]  # ^P005GSX\x14\r
      - delay: 1s
      - uart.write: [0x5E, 0x50, 0x30, 0x30, 0x36, 0x4D, 0x4F, 0x44, 0xDD, 0xBE, 0x0D]  # ^P006MOD\xdd\xbe\r
      - delay: 1s

      # PI17
      - logger.log:
          level: INFO
          format: "Testing unsupported PI17 commands..."
      - uart.write: [0x5E, 0x50, 0x30, 0x30, 0x33, 0x50, 0x49, 0x0D]  # ^P003PI\r
      - delay: 1s
      - uart.write: [0x5E, 0x50, 0x30, 0x30, 0x34, 0x4D, 0x4F, 0x44, 0x0D]  # ^P004MOD\r
      - delay: 1s
      - uart.write: [0x5E, 0x50, 0x30, 0x30, 0x35, 0x46, 0x4C, 0x41, 0x47, 0x0D]  # ^P005FLAG\r
      - delay: 1s

      # PI16
      - logger.log:
          level: INFO
          format: "Testing unsupported PI16 commands..."
      - uart.write: [0x51, 0x50, 0x49, 0x0D]  # QPI\r
      - delay: 1s
      - uart.write: [0x51, 0x4D, 0x4F, 0x44, 0x0D]  # QMOD\r
      - delay: 1s
      - uart.write: [0x51, 0x50, 0x49, 0x47, 0x53, 0x0D]  # QPIGS\r
      - delay: 1s
      - uart.write: [0x51, 0x50, 0x49, 0x52, 0x49, 0x0D]  # QPIRI\r
      - delay: 1s
      - uart.write: [0x51, 0x4D, 0x4F, 0x44, 0x0D]  # QMOD\r

      - logger.log:
          level: INFO
          format: "Done. Repeating..."

Connect GPIO1 to GPIO3 and try again.

[andrewww173]

in this case, the log is definitely different)))
logs_wemos-03-solar_logs (11).txt

[andrewww173]

after change
logger:
level: DEBUG
baud_rate: 0
logs_wemos-03-solar_run (1).txt

[syssi]

This logs goods:

[11:14:55][D][uart_debug:158]: >>> "QPI\r"
[11:14:55][D][uart_debug:158]: <<< "QPI\r"
[11:14:56][D][uart_debug:158]: >>> "QMOD\r"
[11:14:56][D][uart_debug:158]: <<< "QMOD\r"

If we send ">>> QPI\r" we are receiving the same message at the next line (<<< "QPI\r"). Please attach the RS232 converter to GPIO1/GPIO3 now and connect the RX+TX pins (orange + orange-white) of the RS232. Do you see the local echo again? Please provide the log.

[andrewww173]

if I understood correctly, I connected the converter as usual, but without the brown wire

logs_wemos-03-solar_logs (12).txt

[syssi]

Could you provide a photo of your cables between the ESP and the RS232 converter? The received messages are garbage.

[andrewww173]

[syssi]

Good! Please bridge the RS232-TX/RX lines (orange-white <-> orange) again and provide another log.

[andrewww173]

photo and log)

logs_wemos-03-solar_logs (13).txt

[syssi]

This looks good!

[12:30:17][D][uart_debug:158]: >>> "QMN\xBBd\r"
[12:30:17][D][uart_debug:158]: <<< "QMN\xBBd\r"
[12:30:17][D][uart_debug:158]: >>> "^P005GSX\x14\r"
[12:30:17][D][uart_debug:158]: <<< "^P005GSX\x14\r"
[12:30:18][D][uart_debug:158]: >>> "QMODI\xC1\r"
[12:30:18][D][uart_debug:158]: <<< "QMODI\xC1\r"

The ESP is connected properly to the RS232 converter. You are able to transmit and receive at the logic level of RS232 now. Please remove the bridge and attach the inverter again (don't touch the YAML).

[syssi]

If the inverter doesn't respond immediately please swap the orange and orange-white cable.

[andrewww173]

swapping the orange and orange-white cable does not give results (( the logs are the same, there is no answer
logs_wemos-03-solar_logs (14).txt

[andrewww173]

maybe the uart is not involved in the inverter itself? The watchpower application works on the computer...

[syssi]

Do you use the same port if you use watchpower or are you talking about a USB port?

[andrewww173]

for whatchpower I use usb, and it working correct.
But port rs232 looks like not turned on.

[syssi]

As a last try I would try to use watchpower + rs232 to make sure the RS232 port of the inverter is functional.

[andrewww173]

Ok ) And what I should to do? Watchpower is working now and show correct data:

[andrewww173]

[syssi]

Do you have a computer with a 9p D-SUB serial port? Could you attach your inverter to this port instead of the USB cable?

[andrewww173]

Wow! you puzzled me :)))
But there is a chance, maybe next weekend I will be able to find a couple of such old-school monsters in my garage. I would like to run it again)))
And tell me, have you thought about improving pipsolar and using usb to uart converter instead of rs232, theoretically is this possible?

[syssi]

And tell me, have you thought about improving pipsolar and using usb to uart converter instead of off ttl of uart, theoretically is this possible?

The ESP8266 and ESP32 doesn't provide a USB stack. There are new ESP32 modules with USB host support. So there is a chance in a few years.

[andrewww173]

Cool, I'll follow your news :))

[andrewww173]

HI ! you will laugh, below in the photo is the reason for all the failures

The second one shows that I decided to connect the wires directly to the board.
The logs have changed, but I still can't extract the correct data. I attached two logs with a normal pipsolar code and a test debugcode from the messages above
logs_pipsolar_logs.txt
logs_pipsolar_debug.txt

[syssi]

We should start from scratch and try to identify wiring issues between the ESP, RS232 converter and your communication board. The captured traffic is just garbage probably because of bad grounding.

[andrewww173]

I don't even know where to start, all the wires are now soldered. looks reliable

[liaukouski]

I have same problem with Sila VI 5000MH, nit work with any cable, rs232, esp