Voltronic 48/3000 not showing any data

[Robbedoes2000]

Hi, I found this awesome integration, and wanted to use it to buy cheap energy and sell expensive. However, I get responses without any data. It seems like only the switch (binary) sensors are working. I really do get a response, but without data?

[syssi]

Could you enable the debug output of the uart component and provide another log (plaintext preferred). See https://github.com/syssi/esphome-pipsolar#debugging

[Robbedoes2000]

Hi,

I made a log using the protocol sniffer you provided, which I should have done before posting this issue. It seems like my inverter is not supported, is it?

[11:11:58][D][uart_debug:158]: >>> "QPIGS\xB7\xA9\r"
[11:11:58][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:11:59][D][uart_debug:158]: >>> "QPIRI\xF8T\r"
[11:11:59][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:00][D][uart_debug:158]: >>> "QPIWS\xB4\xDA\r"
[11:12:00][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:01][D][uart_debug:158]: >>> "QT\'\xFF\r"
[11:12:01][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:02][D][uart_debug:158]: >>> "QPGS0?\xDA\r"
[11:12:02][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:03][D][uart_debug:158]: >>> "QPGS1/\xFB\r"
[11:12:03][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:04][D][uart_debug:158]: >>> "QPGS2\x1F\x98\r"
[11:12:04][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:05][I][main:561]: Testing PI41 split phase / multiple strings commands...
[11:12:05][D][uart_debug:158]: >>> "QPIGS2h-\r"
[11:12:05][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:06][D][uart_debug:158]: >>> "QP2GS0\x14\x05\r"
[11:12:06][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:07][D][uart_debug:158]: >>> "QP2GS1\x04$\r"
[11:12:07][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:08][I][main:585]: Testing unsupported PI18 commands...
[11:12:08][D][uart_debug:158]: >>> "^P005PIq\x8B\r"
[11:12:08][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:09][D][uart_debug:158]: >>> "^P005GSX\x14\r"
[11:12:10][D][uart_debug:158]: <<< "^D1062295,500,2297,500,0275,0047,009,524,000,000,001,000,042,015,000,000,0000,0000,0000,0000,0,0,0,1,2,2,0,0\x8B\xC8\r"
[11:12:10][D][uart_debug:158]: >>> "^P006MOD\xDD\xBE\r"
[11:12:11][D][uart_debug:158]: <<< "^D00503\xB9Y\r"
[11:12:11][I][main:609]: Testing unsupported PI17 commands...
[11:12:11][D][uart_debug:158]: >>> "^P003PI\r"
[11:12:12][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:12][D][uart_debug:158]: >>> "^P004MOD\r"
[11:12:13][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:13][D][uart_debug:158]: >>> "^P005FLAG\r"
[11:12:14][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:14][I][main:633]: Testing unsupported PI16 commands...
[11:12:14][D][uart_debug:158]: >>> "QPI\r"
[11:12:15][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:15][D][uart_debug:158]: >>> "QMOD\r"
[11:12:16][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:16][D][uart_debug:158]: >>> "QPIGS\r"
[11:12:17][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:18][D][uart_debug:158]: >>> "QPIRI\r"
[11:12:18][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:12:19][D][uart_debug:158]: >>> "QMOD\r"

If it isn't supported, I'll close this issue. However, I still want to control my inverter. Do you have a suggestion to make this possible? Is it doable to inplement it myself?

[syssi]

This looks like a valid response:

[11:12:10][D][uart_debug:158]: <<< "^D1062295,500,2297,500,0275,0047,009,524,000,000,001,000,042,015,000,000,0000,0000,0000,0000,0,0,0,1,2,2,0,0\x8B\xC8\r"

The protocol is called PI18. Please try this branch:

https://github.com/syssi/esphome-pipsolar/tree/pi18
https://github.com/syssi/esphome-pipsolar/blob/pi18/esp32-example.yaml

[Robbedoes2000]

Hi, thanks for the quick reply!

I indeed found the branch and already tested it, but got some errors. It seems like the protocol is slightly different:

[11:53:46][D][pipsolar:655]: timeout command to poll: ^P007GS
[11:53:46][D][uart_debug:158]: >>> "^P005FWS^\x9F\r"
[11:53:46][D][pipsolar:739]: Sending polling command : ^P005FWS with length 8
[11:53:46][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:53:51][D][pipsolar:655]: timeout command to poll: ^P005FWS
[11:53:51][D][uart_debug:158]: >>> "^P005ETN\x91\r"
[11:53:51][D][pipsolar:739]: Sending polling command : ^P005ET with length 7
[11:53:51][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:53:56][D][pipsolar:655]: timeout command to poll: ^P005ET
[11:53:56][D][uart_debug:158]: >>> "^P007PGS0)\xB6\r"
[11:53:56][D][pipsolar:739]: Sending polling command : ^P007PGS0 with length 9
[11:53:56][D][uart_debug:158]: <<< "^D1091,3,00,2302,499,2295,499,0668,0577,00668,00577,022,019,519,013,000,000,037,0000,0000,0000,0000,0,0,1,2,2,034\r"
[11:53:56][D][pipsolar:672]: checking crc on incoming message
[11:53:56][D][pipsolar:682]: CRC NOK expected: F1 3A but got: 33 34
[11:53:57][D][uart_debug:158]: >>> "^P006MOD\xDD\xBE\r"
[11:53:57][D][pipsolar:739]: Sending polling command : ^P006MOD with length 8
[11:53:57][D][uart_debug:158]: <<< "^D00503\xB9Y\r"
[11:54:02][D][pipsolar:655]: timeout command to poll: ^P006MOD
[11:54:02][D][uart_debug:158]: >>> "^P007FLAG\x8E\x18\r"
[11:54:02][D][pipsolar:739]: Sending polling command : ^P007FLAG with length 9
[11:54:02][D][uart_debug:158]: <<< "^D0200,1,1,0,0,0,0,0,2I\xCC\r"
[11:54:07][D][pipsolar:655]: timeout command to poll: ^P007FLAG
[11:54:07][D][uart_debug:158]: >>> "^P007PIRI\xEE8\r"
[11:54:07][D][pipsolar:739]: Sending polling command : ^P007PIRI with length 9
[11:54:07][D][uart_debug:158]: <<< "^D0892300,130,2300,500,130,3000,3000,480,500,550,480,560,560,2,040,060,0,1,0,9,1,0,0,1,1,01B\x96\r"
[11:54:07][D][pipsolar:672]: checking crc on incoming message
[11:54:07][D][pipsolar:682]: CRC NOK expected: C0 64 but got: 42 96
[11:54:08][D][uart_debug:158]: >>> "^P007GS6t\r"
[11:54:08][D][pipsolar:739]: Sending polling command : ^P007GS with length 7
[11:54:08][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:54:13][D][pipsolar:655]: timeout command to poll: ^P007GS
[11:54:13][D][uart_debug:158]: >>> "^P005FWS^\x9F\r"
[11:54:13][D][pipsolar:739]: Sending polling command : ^P005FWS with length 8
[11:54:13][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:54:18][D][pipsolar:655]: timeout command to poll: ^P005FWS
[11:54:18][D][uart_debug:158]: >>> "^P005ETN\x91\r"
[11:54:18][D][pipsolar:739]: Sending polling command : ^P005ET with length 7
[11:54:18][D][uart_debug:158]: <<< "^D01100000000\xDC\xC0\r"
[11:54:23][D][pipsolar:655]: timeout command to poll: ^P005ET
[11:54:23][D][uart_debug:158]: >>> "^P007PGS0)\xB6\r"
[11:54:23][D][pipsolar:739]: Sending polling command : ^P007PGS0 with length 9
[11:54:23][D][uart_debug:158]: <<< "^D1091,3,00,2302,499,2293,499,0687,0604,00687,00604,022,020,519,014,000,000,037,0000,0000,0000,0000,0,0,1,2,2,0_\x8D\r"
[11:54:23][D][pipsolar:672]: checking crc on incoming message
[11:54:23][D][pipsolar:682]: CRC NOK expected: 13 51 but got: 5F 8D
[11:54:24][D][uart_debug:158]: >>> "^P006MOD\xDD\xBE\r"
[11:54:24][D][pipsolar:739]: Sending polling command : ^P006MOD with length 8
[11:54:24][D][uart_debug:158]: <<< "^D00503\xB9Y\r"
[11:54:29][D][pipsolar:655]: timeout command to poll: ^P006MOD
[11:54:29][D][uart_debug:158]: >>> "^P007FLAG\x8E\x18\r"
[11:54:29][D][pipsolar:739]: Sending polling command : ^P007FLAG with length 9
[11:54:29][D][uart_debug:158]: <<< "^D0200,1,1,0,0,0,0,0,2I\xCC\r"
[11:54:34][D][pipsolar:655]: timeout command to poll: ^P007FLAG
[11:54:34][D][uart_debug:158]: >>> "^P007PIRI\xEE8\r"
[11:54:34][D][pipsolar:739]: Sending polling command : ^P007PIRI with length 9
[11:54:34][D][uart_debug:158]: <<< "^0\e\xE3\r"
[11:54:39][D][pipsolar:655]: timeout command to poll: ^P007PIRI
[11:54:39][D][uart_debug:158]: >>> "^P007GS6t\r"
[11:54:39][D][pipsolar:739]: Sending polling command : ^P007GS with length 7
[11:54:39][D][uart_debug:158]: <<< "^0\e\xE3\r"

[Robbedoes2000]

Well it seems like there is sometimes a correct message. Most sensors have been updating overnight at random points in time.

[syssi]

If a sensor is mentioned at the YAML configuration the dedicated request command gets added to the queue. If you remove all unavailable entities from your YAML configuration the unsupported commands won't be issued anymore.

Please provide another log as soon as you have cleaned up your YAML configuration. Are there any "timeout command to poll: ...." lines left?

[Robbedoes2000]

I tried to remove message by message, but even if I have only a single sensor assigned which did show up overnight, nothing happens. Still all messages are coming through on the debugging logs. They are messy now because I just added the ANT_BMS.

For me it seems like the problem is on my side with too much interference, which is kind of unlikely because logs show normal messages, or a problem on your side with CRC. I guess I can make my own branch with CRC disabled just to rule out the possibility?

[syssi]

Please share your logs another time. :-)

[Robbedoes2000]

Is there a way to suppress the ANT logs? It's all over the place so I need like 4 pages of data for all pipsolar stuff to come through. Or lots of labor filtering them out :)

[syssi]

logger:
  level: DEBUG
  logs:
    ant_bms: DEBUG
    ant_bms_ble: DEBUG

[Robbedoes2000]

Can't get it to surpress correctly, but I made a mistake and kept one text sensor in place, that's why it was still polling on multiple messages. Right now it's only the message above, which it doesn't want to read at all.

It's right the esp does receive a message, but just not what it is expecting?

[syssi]

Could you provide a complete plaintext log? The screenshot doesn't provide enough details.

[Robbedoes2000]

I'll make the logs if I've time today, or Monday. Can't make them using my phone apparently.

The single sensor has been updated to the correct value though. I guess we need the logs to see what's going on.

Sorry that I keep doing other things than following your suggestions, but a small question: do you know if there's a way I can force the inverter to start charging from the grid and start discharging to the grid? That's the whole goal for me. There is a time slot for charging, but that's including solar. So outside the time slot it'll just inject into grid instead of using solar to charge my battery.

[syssi]

do you know if there's a way I can force the inverter to start charging from the grid and start discharging to the grid?

I cannot help here.

[Robbedoes2000]

logs_voltronic_logs.txt

I cannot help here.

No problem, just wondering. I'll implement this myself and if you're interested I can keep you updated.

[syssi]

This is the important part of your log:

[09:26:59][C][pipsolar:762]: Pipsolar:
[09:26:59][C][pipsolar:763]: used commands:
[09:26:59][C][pipsolar:766]: ^P007PIRI

[09:27:03][D][uart_debug:158]: >>> "^P007PIRI\xEE8\r"
[09:27:03][D][pipsolar:739]: Sending polling command : ^P007PIRI with length 9
[09:27:03][D][uart_debug:158]: <<< "^0\e\xE3\r"
[09:27:08][D][pipsolar:655]: timeout command to poll: ^P007PIRI

[09:27:08][D][uart_debug:158]: >>> "^P007PIRI\xEE8\r"
[09:27:08][D][pipsolar:739]: Sending polling command : ^P007PIRI with length 9
[09:27:08][D][uart_debug:158]: <<< "^0\e\xE3\r"
[09:27:13][D][pipsolar:655]: timeout command to poll: ^P007PIRI

The pipsolar issues the ^P007PIRI command because you are using one (or multiple) of these sensors:

pipsolar/pipsolar.h:  // P007PIRI values
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(grid_rating_voltage, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(grid_rating_current, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(ac_output_rating_voltage, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(ac_output_rating_frequency, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(ac_output_rating_current, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(ac_output_rating_apparent_power, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(ac_output_rating_active_power, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(battery_rating_voltage, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(battery_recharge_voltage, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(battery_redischarge_voltage, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(battery_under_voltage, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(battery_bulk_voltage, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(battery_float_voltage, P007PIRI, float)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(battery_type, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(current_max_ac_charging_current, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(current_max_charging_current, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(input_voltage_range, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(output_source_priority, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(charger_source_priority, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(parallel_max_num, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(machine_type, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(topology, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(output_mode, P007PIRI, int)
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(solar_power_priority, P007PIRI, int)  // 24 Z
pipsolar/pipsolar.h:  PIPSOLAR_SENSOR(mppt_string, P007PIRI, int)           // 25 a
pipsolar/pipsolar.h:  //            PIPSOLAR_SENSOR(pv_power_balance, P007PIRI, int)
pipsolar/pipsolar.h:  //            PIPSOLAR_TEXT_SENSOR(last_qpiri, P007PIRI)
pipsolar/pipsolar.h:  PIPSOLAR_SWITCH(output_source_priority_switch, P007PIRI)
pipsolar/pipsolar.h:  PIPSOLAR_SWITCH(solar_power_priority_switch, P007PIRI)
pipsolar/pipsolar.h:  PIPSOLAR_SWITCH(charger_source_priority_solarfirst_switch, P007PIRI)
pipsolar/pipsolar.h:  PIPSOLAR_SWITCH(charger_source_priority_utility_switch, P007PIRI)
pipsolar/pipsolar.h:  PIPSOLAR_SWITCH(charger_source_priority_solaronly_switch, P007PIRI)

This is the expected response of a PI18 compatible device:

^D0892300,243,2300,500,243,5600,5600,480,470,530,440,554,544,2,040,090,1,0,1,9,0,0,1,0,1,00\xD9\xA1\r

This is the response of your inverter:

^0\e\xE3\r

[syssi]

Let's focus on a single command/request (^P007PIRI) for now. A few days ago you was able to receive a valid response:

[11:54:07][D][uart_debug:158]: >>> "^P007PIRI\xEE8\r"
[11:54:07][D][pipsolar:739]: Sending polling command : ^P007PIRI with length 9
[11:54:07][D][uart_debug:158]: <<< "^D0892300,130,2300,500,130,3000,3000,480,500,550,480,560,560,2,040,060,0,1,0,9,1,0,0,1,1,01B\x96\r"
[11:54:07][D][pipsolar:672]: checking crc on incoming message
[11:54:07][D][pipsolar:682]: CRC NOK expected: C0 64 but got: 42 96

At the moment your inverter returns just ^0. Do you know why?

A few days ago I didn't realized you was already on the right track. Let's disable or fix the CRC check for your device. The valid response was rejected because of an invalid checksum.

[syssi]

If I pass the response into my testbench ESP it can be decoded properly without CRC issues:

[10:44:15][D][uart_debug:158]: >>> "^P007PIRI\xEE8\r"
[10:44:15][D][pipsolar:737]: Sending polling command : ^P007PIRI with length 9
[10:44:15][D][uart_debug:158]: <<< "^D0892300,130,2300,500,130,3000,3000,480,500,550,480,560,560,2,040,060,0,1,0,9,1,0,0,1,1,01B\x96\r"
[10:44:15][D][pipsolar:672]: checking crc on incoming message
[10:44:15][D][pipsolar:675]: CRC OK
[10:44:15][D][pipsolar:435]: Decode P007PIRI
[10:44:15][D][sensor:093]: 'pipsolar grid_rating_voltage': Sending state 230.00000 V with 1 decimals of accuracy
[10:44:15][D][sensor:093]: 'pipsolar grid_rating_current': Sending state 13.00000 A with 1 decimals of accuracy
[10:44:15][D][sensor:093]: 'pipsolar ac_output_rating_voltage': Sending state 230.00000 V with 1 decimals of accuracy
[10:44:15][D][sensor:093]: 'pipsolar ac_output_rating_frequency': Sending state 50.00000 Hz with 1 decimals of accuracy
[10:44:15][D][sensor:093]: 'pipsolar ac_output_rating_current': Sending state 13.00000 A with 1 decimals of accuracy
[10:44:15][D][sensor:093]: 'pipsolar ac_output_rating_apparent_power': Sending state 3000.00000 VA with 1 decimals of accuracy
[10:44:15][D][sensor:093]: 'pipsolar ac_output_rating_active_power': Sending state 3000.00000 W with 1 decimals of accuracy

[Robbedoes2000]

Hi, I did not change anything. It seems like every now and then the CRC does match, and updates the value. My first guess from my experience as embedded hardware and software engineer is that the initial CRC integer is not reset properly so it revolves around and around until it matches by luck. But I'm a C developer, not C++ lol

I think I need to sniff using an uart tool, just to make sure I don't have any hardware issues, as I repurposed a TI max232 chip from a converter I had laying around.

[Robbedoes2000]

your test seems to indicate a problem with my inverter. I'll try to get contact with voltronic, as I also want to charge and discharge from and to the grid. It seems like you can update these inverters.

[syssi]

Please make sure you are using a MAX3232. If you use a MAX232 (5V TTL) it's used out of spec.

[syssi]

This is my guess: If the request cannot be transmitted properly and gets received with errors from the inverter it gets rejected by the ^0\e\xE3\r response. Only if the inverter is able to receive a valid request (including a matching CRC) you get a response which is probably error-prone too.

This is the part I don't understand:

If you try to decode this response it gets rejected with a CRC error:

[11:54:07][D][uart_debug:158]: <<< "^D0892300,130,2300,500,130,3000,3000,480,500,550,480,560,560,2,040,060,0,1,0,9,1,0,0,1,1,01B\x96\r"
[11:54:07][D][pipsolar:672]: checking crc on incoming message
[11:54:07][D][pipsolar:682]: CRC NOK expected: C0 64 but got: 42 96

If I feed the same response into my ESP (pipsolar@pi18) it gets decoded / there is no CRC issue. May be the CRC check of the pi18 branch is buggy too.

[Robbedoes2000]

Please make sure you are using a MAX3232. If you use a MAX232 (5V TTL) it's used out of spec.

I checked and it is a MAX3232. I still need to log using the uart converter. I think it's a good reason to purchase a handheld oscilloscope though, to truly check the signal integrity.

[Robbedoes2000]

This is my guess: If the request cannot be transmitted properly and gets received with errors from the inverter it gets rejected by the ^0\e\xE3\r response. Only if the inverter is able to receive a valid request (including a matching CRC) you get a response which is probably error-prone too.

This is the part I don't understand:

If you try to decode this response it gets rejected with a CRC error:

[11:54:07][D][uart_debug:158]: <<< "^D0892300,130,2300,500,130,3000,3000,480,500,550,480,560,560,2,040,060,0,1,0,9,1,0,0,1,1,01B\x96\r"
[11:54:07][D][pipsolar:672]: checking crc on incoming message
[11:54:07][D][pipsolar:682]: CRC NOK expected: C0 64 but got: 42 96

If I feed the same response into my ESP (pipsolar@pi18) it gets decoded / there is no CRC issue. May be the CRC check of the pi18 branch is buggy too.

Yeah it seems like we have multiple issues. I'll debug the issue where the inverter isn't responding first.

[Robbedoes2000]

[12:17:34] [D] [pipsolar:739]: Sending polling command: P007PIRI with length 9
[12:17:36] [D] [uart_debug:158]: <<<<<

"^D1062266,499,2266,499,0249,0171,008,552,000,000,000,053,070,026,001,000,0000,0000,0000,0000,0,0,0,1,1,1,1,0\xC2)\r"

[12:17:36] [D] [pipsolar:672]: checking crc on incoming message

[12:17:36] [D] [pipsolar:682]: CRC NOK expected: 14 E2 but got: C2 29

Can you check this message on CRC? I get lots of responses with CRC NOK.

I looked a bit around and maybe I can use the switches 'solar first' and 'utility first' for my cheap charging. Do they actually send a message to the inverter upon changing the switch, or is it only for showing the current state of the inverter?

Edit: Yes this is actually working!! I need to switch multiple times before the inverter listens, but then it starts charging or stop charging. The switch state goes back and only updates once very hour or so, just like other sensors. So yeah I still need to debug.