Open derekyle opened 1 year ago
As an update, I discovered that I was supposed to have the 3.3 volt pin connected from the esp8266 to the TTL side of the RS232 converter. So now, I am getting all CRC OK messages every second or so. However, now, instead of seeing 0 on everything, all of my sensors are showing as "unknown" in home assistant. And I don't see any of the debug messages like above that say "sending state...". It's just all CRC OK messages.
[20:34:54][D][pipsolar:836]: Sending polling command : QPIGS with length 5
[20:34:54][D][pipsolar:772]: checking crc on incoming message
[20:34:54][D][pipsolar:775]: CRC OK
[20:34:55][D][pipsolar:836]: Sending polling command : QPIRI with length 5
[20:34:55][D][pipsolar:772]: checking crc on incoming message
[20:34:55][D][pipsolar:775]: CRC OK
[20:34:56][D][pipsolar:836]: Sending polling command : QPIWS with length 5
[20:34:56][D][pipsolar:772]: checking crc on incoming message
[20:34:56][D][pipsolar:775]: CRC OK
[20:34:57][D][pipsolar:836]: Sending polling command : QMOD with length 4
[20:34:57][D][pipsolar:772]: checking crc on incoming message
[20:34:57][D][pipsolar:775]: CRC OK
[20:34:58][D][pipsolar:836]: Sending polling command : QPIGS with length 5
[20:34:58][D][pipsolar:772]: checking crc on incoming message
[20:34:58][D][pipsolar:775]: CRC OK
[20:34:59][D][pipsolar:836]: Sending polling command : QPIRI with length 5
[20:34:59][D][pipsolar:772]: checking crc on incoming message
[20:34:59][D][pipsolar:775]: CRC OK
[20:35:00][D][pipsolar:836]: Sending polling command : QPIWS with length 5
[20:35:00][D][pipsolar:772]: checking crc on incoming message
[20:35:00][D][pipsolar:775]: CRC OK
[20:35:01][D][pipsolar:836]: Sending polling command : QMOD with length 4
[20:35:01][D][pipsolar:772]: checking crc on incoming message
[20:35:01][D][pipsolar:775]: CRC OK
[20:35:02][D][pipsolar:836]: Sending polling command : QPIGS with length 5
[20:35:02][D][pipsolar:772]: checking crc on incoming message
[20:35:02][D][pipsolar:775]: CRC OK
[20:35:03][D][pipsolar:836]: Sending polling command : QPIRI with length 5
[20:35:03][D][pipsolar:772]: checking crc on incoming message
[20:35:03][D][pipsolar:775]: CRC OK
[20:35:04][D][pipsolar:836]: Sending polling command : QPIWS with length 5
[20:35:04][D][pipsolar:772]: checking crc on incoming message
[20:35:04][D][pipsolar:775]: CRC OK
[20:35:05][D][pipsolar:836]: Sending polling command : QMOD with length 4
[20:35:05][D][pipsolar:772]: checking crc on incoming message
[20:35:05][D][pipsolar:775]: CRC OK
[20:35:06][D][pipsolar:836]: Sending polling command : QPIGS with length 5
[20:35:06][D][pipsolar:772]: checking crc on incoming message
[20:35:06][D][pipsolar:775]: CRC OK
[20:35:07][D][pipsolar:836]: Sending polling command : QPIRI with length 5
[20:35:07][D][pipsolar:772]: checking crc on incoming message
[20:35:07][D][pipsolar:775]: CRC OK
[20:35:08][D][pipsolar:836]: Sending polling command : QPIWS with length 5
[20:35:08][D][pipsolar:772]: checking crc on incoming message
[20:35:08][D][pipsolar:775]: CRC OK
[20:35:09][D][pipsolar:836]: Sending polling command : QMOD with length 4
[20:35:09][D][pipsolar:772]: checking crc on incoming message
[20:35:09][D][pipsolar:775]: CRC OK
[20:35:10][D][pipsolar:836]: Sending polling command : QPIGS with length 5
[20:35:10][D][pipsolar:772]: checking crc on incoming message
[20:35:10][D][pipsolar:775]: CRC OK
[20:35:11][D][pipsolar:836]: Sending polling command : QPIRI with length 5
[20:35:11][D][pipsolar:772]: checking crc on incoming message
[20:35:11][D][pipsolar:775]: CRC OK
[20:35:12][D][pipsolar:836]: Sending polling command : QPIWS with length 5
[20:35:12][D][pipsolar:772]: checking crc on incoming message
[20:35:12][D][pipsolar:775]: CRC OK
[20:35:13][D][pipsolar:836]: Sending polling command : QMOD with length 4
[20:35:13][D][pipsolar:772]: checking crc on incoming message
[20:35:13][D][pipsolar:775]: CRC OK
[20:35:14][D][pipsolar:836]: Sending polling command : QPIGS with length 5
[20:35:14][D][pipsolar:772]: checking crc on incoming message
[20:35:14][D][pipsolar:775]: CRC OK
[20:35:15][D][pipsolar:836]: Sending polling command : QPIRI with length 5
[20:35:15][D][pipsolar:772]: checking crc on incoming message
[20:35:15][D][pipsolar:775]: CRC OK
[20:35:16][D][pipsolar:836]: Sending polling command : QPIWS with length 5
[20:35:16][D][pipsolar:772]: checking crc on incoming message
[20:35:16][D][pipsolar:775]: CRC OK
Could you provide your config yaml and enable the debug output of the uart
component?
uart:
id: uart0
baud_rate: 2400
tx_pin: ...
rx_pin: ...
debug:
direction: BOTH
I've an idea what's happening: I are receiving an echo of your transmitted message. If you enable the debug output of the uart
message you will see the same sequence of bytes going out and coming in. I assume your wiring isn't correct.
Here are the logs with UART debug turned on.
[09:49:28][D][pipsolar:836]: Sending polling command : QPIGS with length 5
[09:49:28][D][uart_debug:114]: >>> 51:50:49:47:53:B7:A9:0D
[09:49:28][D][pipsolar:772]: checking crc on incoming message
[09:49:28][D][pipsolar:775]: CRC OK
[09:49:28][D][uart_debug:114]: <<< 28:4E:41:4B:73:73:0D
[09:49:29][VV][scheduler:195]: Running interval 'update' with interval=1000 last_execution=149623 (now=150623)
[09:49:29][D][pipsolar:836]: Sending polling command : QPIRI with length 5
[09:49:29][D][uart_debug:114]: >>> 51:50:49:52:49:F8:54:0D
[09:49:29][D][pipsolar:772]: checking crc on incoming message
[09:49:29][D][pipsolar:775]: CRC OK
[09:49:29][D][uart_debug:114]: <<< 28:4E:41:4B:73:73:0D
[09:49:30][VV][scheduler:195]: Running interval 'update' with interval=1000 last_execution=150623 (now=151630)
[09:49:30][D][pipsolar:836]: Sending polling command : QPIWS with length 5
[09:49:30][D][uart_debug:114]: >>> 51:50:49:57:53:B4:DA:0D
[09:49:30][D][pipsolar:772]: checking crc on incoming message
[09:49:30][D][pipsolar:775]: CRC OK
[09:49:30][D][uart_debug:114]: <<< 28:4E:41:4B:73:73:0D
[09:49:31][VV][scheduler:195]: Running interval 'update' with interval=1000 last_execution=151623 (now=152626)
[09:49:31][D][pipsolar:836]: Sending polling command : QMOD with length 4
[09:49:31][D][uart_debug:114]: >>> 51:4D:4F:44:49:C1:0D
[09:49:31][D][pipsolar:772]: checking crc on incoming message
[09:49:31][D][pipsolar:775]: CRC OK
[09:49:31][D][uart_debug:114]: <<< 28:4E:41:4B:73:73:0D
[09:49:32][VV][scheduler:195]: Running interval 'update' with interval=1000 last_execution=152623 (now=153625)
[09:49:32][D][pipsolar:836]: Sending polling command : QPIGS with length 5
[09:49:32][D][uart_debug:114]: >>> 51:50:49:47:53:B7:A9:0D
[09:49:32][D][pipsolar:772]: checking crc on incoming message
[09:49:32][D][pipsolar:775]: CRC OK
[09:49:32][D][uart_debug:114]: <<< 28:4E:41:4B:73:73:0D
[09:49:33][VV][scheduler:195]: Running interval 'update' with interval=1000 last_execution=153623 (now=154623)
[09:49:33][D][pipsolar:836]: Sending polling command : QPIRI with length 5
[09:49:33][D][uart_debug:114]: >>> 51:50:49:52:49:F8:54:0D
And here is my config yaml:
esphome:
name: hybrid-inverter
esp8266:
board: d1_mini
substitutions:
inverter_name: Inverter
# Enable logging
logger:
baud_rate: 0
level: VERY_VERBOSE
logs:
uart: VERY_VERBOSE
uart.arduino_esp8266: VERY_VERBOSE
# Make some components less verbose
api.service: WARN
ota: WARN
hardware_uart: uart1
# Enable Home Assistant API
api:
ota:
password: "pass"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Hybrid-Inverter Fallback Hotspot"
password: "pass"
captive_portal:
uart:
- id: uart_bus
tx_pin: TX
rx_pin: RX
# most devices use 2400 as baud_rate
baud_rate: 2400
debug:
direction: BOTH
pipsolar:
- uart_id: uart_bus
id: inverter0
text_sensor:
- platform: pipsolar
pipsolar_id: inverter0
device_mode:
id: inverter0_device_mode
name: inverter0_device_mode
last_qpigs:
id: inverter0_last_qpigs
name: inverter0_last_qpigs
last_qpiri:
id: inverter0_last_qpiri
sensor:
- platform: pipsolar
pipsolar_id: inverter0
grid_voltage:
name: "${inverter_name} Grid Voltage"
grid_frequency:
name: "${inverter_name} Grid Frequency"
ac_output_voltage:
name: "${inverter_name} AC Output Voltage"
ac_output_frequency:
name: "${inverter_name} AC Output Frequency"
ac_output_apparent_power:
name: "${inverter_name} AC Output Apparent Power"
ac_output_active_power:
name: "${inverter_name} AC Output Active Power"
output_load_percent:
name: "${inverter_name} Output Load Percent"
bus_voltage:
name: "${inverter_name} Bus Voltage"
battery_voltage:
name: "${inverter_name} Battery Voltage"
battery_charging_current:
name: "${inverter_name} Battery Charging Current"
battery_capacity_percent:
name: "${inverter_name} Battery Capacity Percent"
battery_bulk_voltage:
name: "${inverter_name} Battery Bulk Voltage"
battery_float_voltage:
name: "${inverter_name} Battery Float Voltage"
battery_redischarge_voltage:
name: "${inverter_name} Battery Re-discharge Voltage"
battery_recharge_voltage:
name: "${inverter_name} Battery Recharge Voltage"
inverter_heat_sink_temperature:
name: "${inverter_name} Inverter Heat Sink Temperature"
pv_input_current_for_battery:
name: "${inverter_name} PV Input Current for Battery"
pv_input_voltage:
name: "${inverter_name} PV Input Voltage"
pv_charging_power:
name: "${inverter_name} PV Charging Power"
battery_voltage_scc:
name: "${inverter_name} Battery Voltage SCC"
battery_discharge_current:
name: "${inverter_name} Battery Discharge Current"
output_source_priority:
name: "${inverter_name} Output Source Priority"
charger_source_priority:
name: "${inverter_name} Charger Source Priority"
output_mode:
name: "${inverter_name} Output Mode"
binary_sensor:
- platform: pipsolar
pipsolar_id: inverter0
add_sbu_priority_version:
name: "${inverter_name} Add SBU Priority Version"
configuration_status:
name: "${inverter_name} configuration_status"
load_status:
name: "${inverter_name} Load Status"
battery_voltage_to_steady_while_charging:
name: "${inverter_name} Battery Voltage to Steady While Charging"
charging_status:
name: "${inverter_name} Charging Status"
scc_charging_status:
name: "${inverter_name} SCC charging status"
ac_charging_status:
name: "${inverter_name} AC charging status"
charging_to_floating_mode:
name: "${inverter_name} Charging to floating mode"
switch_on:
name: "${inverter_name} Switch On"
fault_inverter_fault:
name: "${inverter_name} Fault"
fault_inverter_voltage_too_low:
name: "${inverter_name} Fault Voltage Too Low"
warning_fan_lock:
name: "${inverter_name} Fault Fan Lock"
warning_battery_low_alarm:
name: "${inverter_name} Battery Low Alarm"
fault_inverter_over_current:
name: "${inverter_name} Fault Over Current"
warning_over_load:
name: "${inverter_name} Warning Over Load"
fault_code:
name: "${inverter_name} Fault Code"
switch:
- platform: pipsolar
pipsolar_id: inverter0
output_source_priority_utility:
name: "${inverter_name} output_source_priority_utility"
output_source_priority_solar:
name: "${inverter_name} output_source_priority_solar"
output_source_priority_battery:
name: "${inverter_name} output_source_priority_battery"
input_voltage_range:
name: "${inverter_name} input_voltage_range"
It looks like the same sequence of bytes going out everytime and a different sequence coming back each time. And I suspect this is coming from the inverter because swapping tx/Rx on either side of the converter results in all timeouts. And unplugging the rj45 on the inverter or switching the rj45 over to the BMS plug also gives timeouts.
Thanks for the logs of the raw messages. You are right. This is a response of the inverter (no echos here). I will try to decode the response manually. It looks like the inverter responds with the same answer every time (independent of the request/command).
The meaning of 28:4E:41:4B:73:73:0D
is NAK
. The inverter rejects all requests.
Does this mean that the rs232-ttl converter wiring is likely correct?
Also, I just noticed that within the Solar Power App that I have connected to the inverter per the instructions that came with the unit, it shows the Machine Model as Infinisolar V II LV. Which appears to actually be this Voltronic unit: https://voltronicpower.com/en-US/Product/Detail/InfiniSolar-VII-6KW-(Split-Phase)
The Axpert King II that I thought this unit was appears to have slightly lower specs and is not split-phase like this one. Otherwise, they look identical.
And this is the unit I am working with: https://sungoldpower.com/collections/hybrid-solar-inverter/products/6000w-48v-hybrid-solar-inverter-split-phase-120-240vac
Yes. The wiring is correct!
May be the protocol of your inverter is a bit different like this: https://github.com/jblance/mpp-solar/issues/33
Could you try to use mppsolar (it already supports the different protocol). Please ping me if you have success.
As I already written, I used without any problem for a friend the oroginal PIPsolar code with an King II .... so I am pretty sure it's a problem of wiring and the choice of a right adapter. I remember I spent some time to make it working. If you want I can ask him some photos.... and the GPIO I used.
Here is the photo :
The DB9 cable was the one shipped with the inverter and the RS232 TTL converter is this model : https://fr.aliexpress.com/item/1005003095210072.html?spm=a2g0o.order_list.0.0.5aea5e5bLKmgTm&gatewayAdapt=glo2fra
Be aware to take the right gender according to your DB9 cable. It was a bit a nightmare to find the right converter. I tested 3 other models....
This traffic
[09:49:31][D][uart_debug:114]: >>> 51:4D:4F:44:49:C1:0D
[09:49:31][D][pipsolar:772]: checking crc on incoming message
[09:49:31][D][pipsolar:775]: CRC OK
[09:49:31][D][uart_debug:114]: <<< 28:4E:41:4B:73:73:0D
shows the inverter is able to receive data and responds with NAK
. IMO the wiring is fine and the protocol is probably a bit different. I found a bug report above at the mppsolar project which describes a similar behavior (responds NAK
to every command) which could be solved by sending commands to the inverter without appending a checksum.
I assume you mixed up issues here. ;-) This issue is indeed caused by wrong wiring/components: https://github.com/syssi/esphome-pipsolar/issues/21
I haven't had a chance to try the jblance code directly yet. But I will soon. However, I did get an answer back from my dealer and they provided this excel with the protocol details.
@SeByDocKy sorry for the confusion, I updated the title of this issue. It seems that my unit is a bit different than the King II and is actually identical to the Infinisolar V II. The biggest difference being that mine and the infinisolar are both split phase and have a few higher ratings. Otherwise, they look identical on the outside. But it seems like maybe there was a change to the protocol on these newer split phase models.
@syssi Ok, I was finally able to get around to trying out mpp-solar on my device. After playing around with it a little bit, it appears that I am able to successfully query my device using the PI18 protocol that mpp-solar implements. Is this project utilizing the PI18 protocol?
Could you provide an request and response example of the QPIGS
command or could you provide some details about the PI18 protocol?
I've checked the PI18 protocol implementation of mppsolar and the protocol definition. The pipsolar component uses a different command set and doesn't support ^P0...
commands yet.
There is no QPIGS command for the PI18 protocol. So it gives me:
'full_command not found for QPIGS in protocol b'PI18''
But the GS command gives the following:
Parameter Value Unit
grid_voltage 118.2 V
grid_frequency 59.9 Hz
ac_output_voltage 0.0 V
ac_output_frequency 0.0 Hz
ac_output_apparent_power 0 VA
ac_output_active_power 0 W
output_load_percent 0 %
battery_voltage 54.3 V
battery_voltage_from_scc 0.0 V
battery_voltage_from_scc2 0.0 V
battery_discharge_current 0 A
battery_charging_current 0 A
battery_capacity 100 %
inverter_heat_sink_temperature 47 °C
mppt1_charger_temperature 0 °C
mppt2_charger_temperature 0 °C
pv1_input_power 0 W
pv2_input_power 0 W
pv1_input_voltage 0.0 V
pv2_input_voltage 0.0 V
setting_value_configuration_state Nothing changed
mppt1_charger_status abnormal
mppt2_charger_status abnormal
load_connection disconnect
battery_power_direction charge
dc/ac_power_direction AC-DC
line_power_direction input
Interesting. I wonder if there is a setting on the Inverter that might need to be changed. Others have reported this working on an identical Voltronic model. But maybe SunGoldPower has made some modifications to their units beyond the blue paint and logo on the case.
On Sun, Jul 17, 2022 at 11:33 AM Sebastian Muszynski < @.***> wrote:
The meaning of 28:4E:41:4B:73:73:0D is NAK. The inverter rejects all requests.
— Reply to this email directly, view it on GitHub https://github.com/syssi/esphome-pipsolar/issues/22#issuecomment-1186586224, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ3CY2G3D24AXH67RXX6JTVURGZDANCNFSM53Y5VDSQ . You are receiving this because you authored the thread.Message ID: @.***>
There is aN experimental version of the PI18
protocol now. Please give it a try: https://github.com/syssi/esphome-pipsolar/pull/62
So I am seeing a lot of CRC NOK as well as a few CRC OK. Which makes me think that I must have things wired up correctly, maybe? But I am just getting everything reported as 0.0 or off.
Could this be a compatibility issue? The SunGoldPower has identical specs and looks physically identical on the outside (except the paint job) as the Voltronic Axpert King II which is also the same as the MPP Solar lvx6048, so I am assuming they are all the same unit. I am running this on an esp8266 D1 mini if that makes a difference.
Here are some of the logs:
Any help is greatly appreciated! And thanks again for all your volunteer work on this project. I'm already using your code to integrate my jkbms and smart shunt into Home Assistant.