Open andrewww173 opened 2 years ago
Why did you attach 4 wires? Please remove the black one and compare your setup with this one:
You have to swap the red and white wire!
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
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?
sorry, I didn't understand ) I need to disconnect the brown wire from max3232 or connect orange and orange-white wires directly to wemos?
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).
I connected two wires on the board and nothing happened
Please provide a ESPHome log. I would like to verify your interpretation. :-)
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
look, here's a new module, but nothing new in the logs
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);
logs_wemos-03-solar_logs (3).txt and log with looped wires logs_wemos-03-solar_logs (4).txt
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.
ok, I attached the log and my yaml logs_wemos-03-solar_logs (5).txt wemos-03-solar.txt
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.
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
Please unplug the inverter. Connect/bridge the RX/TX pin of the RS232 converter again to create the loopback and provide another log.
ok, please. Now RS232 is connected to wemos, but inverter is unplugged logs_wemos-03-solar_logs (9).txt
Please unplug the RS232 converter now and connect GPIO4 to GPIO5 + provide another log.
here it is ) logs_wemos-03-solar_logs (10).txt
Did you connect GPIO4 & GPIO5 for sure?
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.
in this case, the log is definitely different))) logs_wemos-03-solar_logs (11).txt
after change logger: level: DEBUG baud_rate: 0 logs_wemos-03-solar_run (1).txt
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.
if I understood correctly, I connected the converter as usual, but without the brown wire
Could you provide a photo of your cables between the ESP and the RS232 converter? The received messages are garbage.
Good! Please bridge the RS232-TX/RX lines (orange-white <-> orange) again and provide another log.
photo and log) logs_wemos-03-solar_logs (13).txt
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).
If the inverter doesn't respond immediately please swap the orange and orange-white cable.
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
maybe the uart is not involved in the inverter itself? The watchpower application works on the computer...
Do you use the same port if you use watchpower or are you talking about a USB port?
for whatchpower I use usb, and it working correct.
But port rs232 looks like not turned on.
As a last try I would try to use watchpower + rs232 to make sure the RS232 port of the inverter is functional.
Ok ) And what I should to do? Watchpower is working now and show correct data:
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?
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?
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.
Cool, I'll follow your news :))
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
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.
I don't even know where to start, all the wires are now soldered. looks reliable
I have same problem with Sila VI 5000MH, nit work with any cable, rs232, esp
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: