Adding commands for LV5048.

[DMIINC]

LV5048 5KW protocol-20190222 for customer.pdf Hello,

Thank you for your help last week. I was in touch with MPP Solar and they provided communication protocol for LV5048. See attached. Is there way to integrate some of these commands with what you have written so far?

[jblance]

Yes if they are direct USB from the Pi to the Inverter they will appear and 3 different hidraw devices If they are 3 USB-serial converters they will be 3 different /dev/ttyUSBn devices (where n is a number like 0,1,2,3 etc) Originally I had 2 USB-serial converters (one to each inverter) and no other USB devices on my pi and the 2 devices were /dev/ttyUSB0 and /dev/ttyUSB1

Note if you connect both the USB and serial ports on the inverter problems occur (at least for me only one worked)

[jblance]

just copy the entire line below on the command line for x in 1 2 3 4 5; do echo $x; sudo mpp-solar -c QP2GS0 -M LV5048; done and hit enter it should run the mpp-solar command 5 times

[DMIINC]

No I only have USB to Serial cables on Raspberry Pi with wireless keyboard and mouse Of course. I do understand.

[DMIINC]

pi@raspberrypi:~ $ for x in 1 2 3 4 5; do echo $x; sudo mpp-solar -c QP2GS0 -M LV5048; done 1 error Invalid response response (NAKss
2 error Invalid response response (NAKss
3 error Invalid response response (NAKss
4 error Invalid response response (NAKss
5 error Invalid response response (NAKss
pi@raspberrypi:~ $ for x in 1 2 3 4 5; do echo $x; sudo mpp-solar -c QPGS0 -M LV5048; done 1 error Invalid response response (NAKss
2 error Invalid response response (NAKss
3 error Invalid response response (NAKss
4 error Invalid response response (NAKss
5 error Invalid response response (NAKss
pi@raspberrypi:~ $

[jblance]

at least it is consistent :-( just on the off chance that we have some other ID can you try for x in 0 1 2 3 4 5 6 7; do sudo mpp-solar -c QPGS${x} -M LV5048; done

if all USB-serial adapters are on the same device you should get info from the other inverters with sudo mpp-solar -c QID -d /dev/ttyUSB0 sudo mpp-solar -c QID -d /dev/ttyUSB1 sudo mpp-solar -c QID -d /dev/ttyUSB2

QID should be the serial number

[jblance]

@cowpen

Very glad to see you guys working together on a solution to this. I have an LV5048 and have been struggling for a couple of months trying to get a data logged in a useful format with "solar-sis" for the 4048. Your efforts are very much appreciated!

Is it working for you?

[DMIINC]

pi@raspberrypi:~ $ for x in 0 1 2 3 4 5 6 7; do sudo mpp-solar -c QPGS${x} -M LV5048; done error Invalid response response (NAKss
error Invalid response response (NAKss
error Invalid response response (NAKss
error Invalid response response (NAKss
error Invalid response response (NAKss
error Invalid response response (NAKss
error Invalid response response (NAKss
error Invalid response response (NAKss
pi@raspberrypi:~ $

[DMIINC]

pi@raspberrypi:~ $ sudo mpp-solar -c QID -d /dev/ttyUSB0 serial_number 92912001100085
pi@raspberrypi:~ $ sudo mpp-solar -c QID -d /dev/ttyUSB1 serial_number 92911906100045
pi@raspberrypi:~ $ sudo mpp-solar -c QID -d /dev/ttyUSB2 serial_number 92911906100023
pi@raspberrypi:~ $

All of the inverters are there. Serial number correspond to physical stickers on them.

[DMIINC]

Check this out

pi@raspberrypi:~ $ sudo mpp-solar -c QPIGS -d /dev/ttyUSB2 ac_input_frequency 59.9 Hz ac_input_voltage 123.5 V ac_output_active_power 0426 W ac_output_apparent_power 0444 VA ac_output_frequency 59.9 Hz ac_output_load 017 % ac_output_voltage 123.5 V battery_capacity 100 % battery_charging_current 000 A battery_discharge_current 00000 A battery_voltage 56.10 V battery_voltage_from_scc 00.00 V bus_voltage 226 V inverter_heat_sink_temperature 0039 Deg_C is_battery_voltage_to_steady_while_charging 0 True - 1/False - 0 is_charging_on 1 True - 1/False - 0 is_configuration_changed 0 True - 1/False - 0 is_load_on 0 True - 1/False - 0 is_sbu_priority_version_added 0 True - 1/False - 0 is_scc_charging_on 0 True - 1/False - 0 is_scc_firmware_updated 0 True - 1/False - 0 pv_input_current_for_battery 0000 A pv_input_voltage 000.0 V unknown_value_in_response 110
pi@raspberrypi:~ $ sudo mpp-solar -c QPIGS2 -d /dev/ttyUSB2 CRITICAL:MPP-Solar:Command not found pi@raspberrypi:~ $ sudo mpp-solar -c QPIGS2 -d /dev/ttyUSB2 -M LV5048 is_l2_ac_charging_on 0 True - 1/False - 0 is_l2_line_not_ok 0 True - 1/False - 0 is_l2_scc_charging_on 0 True - 1/False - 0 is_l2_scc_ok 0 True - 1/False - 0 is_load_on 1 True - 1/False - 0 l2_ac_input_frequency 59.9 Hz l2_ac_input_voltage 124.2 V l2_ac_output_active_power 0242 W l2_ac_output_apparent_power 0260 VA l2_ac_output_frequency 59.9 Hz l2_ac_output_load 010 % l2_ac_output_voltage 124.2 V l2_battery_voltage 56.20 V pv2_battery_charging_current 0000 A pv2_input_voltage 000.0 V reserved 0 True - 1/False - 0 pi@raspberrypi:~ $

[jblance]

If you add -M LV5048 to the QPIGS command the response should be more like the QPIGS2 command

So at least you can query all of the inverters - no idea why my parallel commands don't work

There is also an undocumented command that sends info to a MQTT broker if that is useful (it might need tweaking to support the new model parameter

[DMIINC]

Once again thanks for all the support you have provided so far. I see you closed other thread. Still want to buy you a lunch regardless. HaHa.

More elegant solution, of course would be using -QPGSn or -QP2GSn. Why we can't do that I do not know. Last time I wrote some ""serious" code was in 1990 using BASIC, LOL. So I do understand basic principles of programming and how difficult it can be to debug. So question I can ask would be:

1. Would updating Python to latest and greatest help?
2. Reinstalling OS on Pi to something that you know it works?
3. Shift focus away from trying to get those commands to work to start implementing database and Grafana.

[cowpen]

Just a suggestion. Since Watchpower comms work with all 3 inverters, a wireshark capture of USB serial queries and responses might prove useful. Would like to help, but I only have a single unit.

[DMIINC]

Which software you would recommend to do that with?

[cowpen]

www.wireshark.org - you'll want the Windows version to capture while watchpower is talking / listening.

[DMIINC]

I will give it a try.

[jblance]

@DMIINC re your questions:

1. I don't think so - we're not getting a python error
2. as above
3. err, that sounds big :-) I do want to graph my results, but was heading the way of having the inverter Pi as simple as possible and using MQTT to send data to a broker and then get the information from the broker to whatever display is used - thoughts welcome

My thoughts on the QPGSn command not working

• the other commands are working (so not a fundamental issue)
• the QPGSn worked (as i dont have access to my inverter at the moment to check my setup)
• the LV5048 is getting a command and replying successfully, but is replying with the equivalent of 'huh?' Its possible that the CRC calculation is incorrect for the LV5048 - so a wireshark trace from watchpower to the inverters might help

[DMIINC]

Thanks.

1. and 2. was worth asking for just in case.

   3 I have learned a lot in past couple of weeks however I am not on your level of understanding yet. So, ignorant statement is incoming. How is what I am trying to do different then your #3 point? I am assuming that your method might be easier to implement with different devices.

Installed wireshark and ran it. Have no clue what I am looking at. Other then something is going on.

[jblance]

Hi My #3 would have this code base finish with sending MQTT messages - I (and you would then need to implement our own versions of the storing and displaying) As a note MQTT to Influx is quite commonly done by others

It's looking more like the CRC calc to me I've found the java that does it and it does look different (why the other commands work I dont know) For example the original used the below lookup table:

[0x0000, 0x1021, 0x2042, 0x3063,
 0x4084, 0x50a5, 0x60c6, 0x70e7,
 0x8108, 0x9129, 0xa14a, 0xb16b,
 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef]

Whereas the decompiled java has

['\0', '\u1021', '\u2042', '\u3063', '\u4084', '\u50a5', '\u60c6', '\u70e7', '\u8108', '\u9129', '\ua14a', '\ub16b', '\uc18c', '\ud1ad', '\ue1ce', '\uf1ef', '\u1231', '\u0210', '\u3273', '\u2252', '\u52b5', '\u4294', '\u72f7', '\u62d6', '\u9339', '\u8318', '\ub37b', '\ua35a', '\ud3bd', '\uc39c', '\uf3ff', '\ue3de', '\u2462', '\u3443', '\u0420', '\u1401', '\u64e6', '\u74c7', '\u44a4', '\u5485', '\ua56a', '\ub54b', '\u8528', '\u9509', '\ue5ee', '\uf5cf', '\uc5ac', '\ud58d', '\u3653', '\u2672', '\u1611', '\u0630', '\u76d7', '\u66f6', '\u5695', '\u46b4', '\ub75b', '\ua77a', '\u9719', '\u8738', '\uf7df', '\ue7fe', '\ud79d', '\uc7bc', '\u48c4', '\u58e5', '\u6886', '\u78a7', '\u0840', '\u1861', '\u2802', '\u3823', '\uc9cc', '\ud9ed', '\ue98e', '\uf9af', '\u8948', '\u9969', '\ua90a', '\ub92b', '\u5af5', '\u4ad4', '\u7ab7', '\u6a96', '\u1a71', '\u0a50', '\u3a33', '\u2a12', '\udbfd', '\ucbdc', '\ufbbf', '\ueb9e', '\u9b79', '\u8b58', '\ubb3b', '\uab1a', '\u6ca6', '\u7c87', '\u4ce4', '\u5cc5', '\u2c22', '\u3c03', '\u0c60', '\u1c41', '\uedae', '\ufd8f', '\ucdec', '\uddcd', '\uad2a', '\ubd0b', '\u8d68', '\u9d49', '\u7e97', '\u6eb6', '\u5ed5', '\u4ef4', '\u3e13', '\u2e32', '\u1e51', '\u0e70', '\uff9f', '\uefbe', '\udfdd', '\ucffc', '\ubf1b', '\uaf3a', '\u9f59', '\u8f78', '\u9188', '\u81a9', '\ub1ca', '\ua1eb', '\ud10c', '\uc12d', '\uf14e', '\ue16f', '\u1080', 'ยก', '\u30c2', '\u20e3', '\u5004', '\u4025', '\u7046', '\u6067', '\u83b9', '\u9398', '\ua3fb', '\ub3da', '\uc33d', '\ud31c', '\ue37f', '\uf35e', '\u02b1', '\u1290', '\u22f3', '\u32d2', '\u4235', '\u5214', '\u6277', '\u7256', '\ub5ea', '\ua5cb', '\u95a8', '\u8589', '\uf56e', '\ue54f', '\ud52c', '\uc50d', '\u34e2', '\u24c3', '\u14a0', '\u0481', '\u7466', '\u6447', '\u5424', '\u4405', '\ua7db', '\ub7fa', '\u8799', '\u97b8', '\ue75f', '\uf77e', '\uc71d', '\ud73c', '\u26d3', '\u36f2', '\u0691', '\u16b0', '\u6657', '\u7676', '\u4615', '\u5634', '\ud94c', '\uc96d', '\uf90e', '\ue92f', '\u99c8', '\u89e9', '\ub98a', '\ua9ab', '\u5844', '\u4865', '\u7806', '\u6827', '\u18c0', '\u08e1', '\u3882', '\u28a3', '\ucb7d', '\udb5c', '\ueb3f', '\ufb1e', '\u8bf9', '\u9bd8', '\uabbb', '\ubb9a', '\u4a75', '\u5a54', '\u6a37', '\u7a16', '\u0af1', '\u1ad0', '\u2ab3', '\u3a92', '\ufd2e', '\ued0f', '\udd6c', '\ucd4d', '\ubdaa', '\uad8b', '\u9de8', '\u8dc9', '\u7c26', '\u6c07', '\u5c64', '\u4c45', '\u3ca2', '\u2c83', '\u1ce0', '\u0cc1', '\uef1f', '\uff3e', '\ucf5d', '\udf7c', '\uaf9b', '\ubfba', '\u8fd9', '\u9ff8', '\u6e17', '\u7e36', '\u4e55', '\u5e74', '\u2e93', '\u3eb2', '\u0ed1', '\u1ef0' ]

It will take a while to try to turn the java to python as it is all bitwise calcs on bytes which is a PITA...

[DMIINC]

I see your point.

Meanwhile, would you need any data from wireshark. If so, what kind?

[jblance]

the bits where watchpower is sending commands to the inverter, especially the QPGS0 (1,2) and/or the QP2GS0 (1,2) commands

[DMIINC]

I hope you are not pulling your hair out now!!!!!!!!! I so want to be of more help but.... where do I go from here?

[jblance]

I havent used wireshark (for decades anyway) Try capturing all USB traffic while running Watchpower and see what you get?

[DMIINC]

This is what i see

[DMIINC]

It is capturing

[jblance]

do you see Q & P anywhere in the capture

[DMIINC]

[DMIINC]

The above message repeat it self

[DMIINC]

What youy are looking for I do not see

[cowpen]

I'll hook one up later this evening and upload a capture.

[DMIINC]

Can you tell me how to do it? We are trying to figure out parallel commands

[cowpen]

Here's the capture I grabbed. I adjusted "back to discharge voltage" during the capture so there's more than just queries and responses.

All you have to do is start the capture, let it run a while. Maybe send some commands in Watchpower. Then stop the capture and save it.

LV5048-Watchpower-USBCap.zip

[cowpen]

The URB_CONTROL out segments are the queries. Here's a QP2GS:

[DMIINC]

awesome

[jblance]

OK, so that is QP2GS7 with CRC of 0x64 0xE2 0x64 is int 100 0xE2 is int 226 This is what the current CRC calculation gives too Interesting is the ID is 7 though...

[DMIINC]

[DMIINC]

[jblance]

I need the 2 bytes after the command so QP2GS0 and the next 2

[DMIINC]

[jblance]

I dont see the CRC in those captures unfortunately A quick test seem to show that the 2 CRC tables give the same result..... Now I am wondering if it is a retries type of issue (java seems to try 3 times to send a command)

[DMIINC]

ok. Does wireshark captures everything or some things get left out?

[cowpen]

It captures the entire bitstream. Both directions.

[DMIINC]

Bummer :(

[cowpen]

Now I am wondering if it is a retries type of issue (java seems to try 3 times to send a command)

I think only if it gets a NAK in response. Here's one in response to QPGS8 in the capture I uploaded. Seems like it tries 4 times before moving on to a QSID query"

[DMIINC]

[DMIINC]

With everything expanded

[jblance]

@cowpen what happens when you run mpp-solar -c QPGS4 -M LV5048 -I and mpp-solar -c QP2GS4 -M LV5048 -I (I think your inverter is at ID 4) Actually no, the trace has IDs from 0-8??? And the trace that you uploaded earlier doesnt seem to capture any actual response data?

[DMIINC]

I think we are stuck. Is there anything else that I could request from MPP Solar that would be helpful?

[jblance]

Re MPP-Solar info - I dont think so unfortunately. Maybe do a full trace - with only 1 inverter attached. Starting with Watchpower not running (including any task tray icons), Start the USB trace, start watchpower and click once on each inverter, then stop the trace Then we can look for all the QP* commands and responses (hopefully). The trace from @cowpen didnt seem to have any responses visible.

[jblance]

Was also interested to see if @cowpen got any actual data in response to commands that use a parallel ID

[DMIINC]

ok