LV5048 not recording pv_input_power in influxdb

[cowpen]

The LV5048 protocol document indicates this parameter exists:

And the QPIGS query from mpp-solar appears to capture this data:

However the field doesn't exist in influxdb. Currently I'm calculating PV watt production from "pv_input_current_for_battery" and "pv_input_voltage" but this is proving inaccurate since PV power for inverter output isn't included in the results.

Is support for this parameter possible? Thanks for your help!

[nigel16494]

I fixed that a while back and John integrated it. You need the latest level of qpigs.json.

[cowpen]

Thanks... I'm already running v. 0.4.5 and your recent changes to qpigs.json are included:

pi@powerpi:~ $ tail -20 mpp-solar/mppsolar/commands/qpigs.json
                "is_charging_on",
                "is_scc_charging_on",
                "is_ac_charging_on"
                ]
            ],
            ["int", "RSV1", "A"],
            ["int", "RSV2", "A"],
            ["int", "PV Input Power", "W"],
            ["flags", "Device Status2", [
                "is_charging_to_float",
                "is_switched_on",
                "is_reserved"
              ]
            ]
          ],
    "test_responses": [
            ["(000.0 00.0 230.0 49.9 0161 0119 003 460 57.50 012 100 0069 0014 103.8 57.45 00000 00110110 00 00 00856 010", "248C"]
        ],
        "regex": ""
}

Could similar changes be required for qpigs-lv.json for the LV5048?

pi@powerpi:~ $ tail -20 mpp-solar/mppsolar/commands/qpigs-lv.json
            ["float", "PV Input Voltage", "V"],
            ["float", "Battery Voltage from SCC", "V"],
            ["int", "Battery Discharge Current", "A"],
            ["flags", "Inverter Status", [
                            "is_l1_scc_ok",
                "is_l1_ac_charging_on",
                "is_l1_scc_charging_on",
                "is_battery_over",
                "is_battery_under",
                "is_l1_line_not_ok",
                "is_load_on",
                "is_configuration_changed"
                ]
            ]
        ],
    "test_responses": [
            ["(000.0 00.0 230.0 49.9 0161 0119 003 460 57.50 012 100 0069 0014 103.8 57.45 00000 00110110 00 00 00856 010", "248C"]
        ],
        "regex": ""
}

[nigel16494]

It looks similar to me, I confirmed the end bytes by testing . I looked at the inverter at the same time as getting the bytes back from the python to verify the amount of PV watts. I also found the extra flags worked by switching the inverter on and off. It's an easy to change to copy and check it out.

[jblance]

this looks like my mistake - ill have a look at it today

[jblance]

updated - can you try now.... (version 0.4.6)

[cowpen]

Thank you!

Did a git pull. Confirmed the new paramater was in qpigs.json. Restarted the service, but still not seeing the field available in influxdb. Did I miss a step?

[cowpen]

It is showing in the actual command output though:

[cowpen]

Another thing I was wondering about. Since the LV5048 model includes 2 inverters and 2 SCC's. I suspect the "pv_input_power" parameter from the QPIGS query is only reporting data from the first SCC. QPIGS2 provides info for L2 and PV2. Since the most recent LV5048 protocol documentation for the QPIGS2 query doesn't mention "pv2_input_power", but the bundled "watchpower" software reports pv power for both controllers, do you suspect an error in their protocol documentation? Would there be a way to determine if pv2_input_power could actually be queried?

[jblance]

PIGS2 provides info for L2 and PV2. Since the most recent LV5048 protocol documentation for the QPIGS2 query doesn't mention "pv2_input_power", but the bundled "watchpower" software reports pv power for both controllers, do you suspect an error in their protocol documentation? Would there be a way to determine if pv2_input_power could actually be queried?

does qpigs2 output show unknown values in response?

[jblance]

Did a git pull. Confirmed the new paramater was in qpigs.json. Restarted the service, but still not seeing the field available in influxdb. Did I miss a step?

Doesnt look like a step has been missed What is being published to MQTT broker? What is the config of the service?

[cowpen]

Here's the service config:

pi@powerpi:~/mpp-solar $ more /etc/mpp-solar/mpp-solar.conf
[SETUP]
pause=5
mqtt_broker=127.0.0.1

[Inverter1_L1]
model=LV5048
port=/dev/ttyUSB0
baud=2400
command=QPIGS
tag=Inverter1
format=influx2

[Inverter1_L2]
model=LV5048
port=/dev/ttyUSB0
baud=2400
command=QPIGS2
tag=Inverter1
format=influx2

Here's the raw output from QPIGS2. I might be able to pick out a Watt-like value if it wasn't dark right now. :)

pi@powerpi:~/mpp-solar $ mpp-solar -c QPIGS2 -M LV5048 -R
['123.7', '59.9', '120.0', '60.0', '0012', '0011', '000', '0000', '000.0', '55.70', '0000010']

[cowpen]

MQTT config files"

[pi@powerpi:~/mpp-solar $ more /etc/telegraf/telegraf.d/mqtt-input.conf
[[inputs.mqtt_consumer]]
  servers = ["tcp://127.0.0.1:1883"]
  topics = [
    "#",
  ]
  data_format = "influx"
]

And:

pi@powerpi:~/mpp-solar $ more /etc/telegraf/telegraf.d/influx-output.conf
[[outputs.influxdb]]
  urls = ["http://127.0.0.1:8086"]
  database = "mppsolar"
  skip_database_creation = true
  username = "pi"
  password = "**************"

[cowpen]

Sorry. I neglected to reinstall after pulling the update. Saw the new qpigs.json and thought I was good. Apologies for that newb error. pv_input_power is populating now.

I'd still like to help dig for pv2_input_power if you think it's doable.

[jblance]

great re pv2 input power - its doable if we can find where / what command is used....

[jblance]

also, can you check to see if it is pv charging power (as per doc), or pv inout power from the numbers you get (in the daylight

cheers

[cowpen]

Success! pv_input_power is a much more accurate W value than what I've been calculating in grafana and is the same as what's displayed on the front LCD panel.

Still no clue as to how they query for pv2 W. There's nothing at all in the protocol docs, and nothing in the QPIGS2 debug output (attached). I guess I could try a wireshark USB capture while running watchpower, but trying to filter for a rapidly moving W value that's not human-readable seems kind of hard. LOL

QPIGS2-out.txt

[jblance]

A wireshark capture might work, have used them before the clarity commands. Worth a shot if you have time and the inclination

[cowpen]

OK. I've just emailed Andy at MPP Solar support inquiring about the missing parameter. I'll try a capture if I don't hear back from them soon.

[cowpen]

LV5048-Watchpower-USBCap3.zip Sorry to leave this hanging open. I still haven't had a response from MPP-Solar support.

Anyway, I ran Watchpower and Wireshark captured the USB traffic (attached). I had one eye on the inverter LCD, and one eye on Watchpower. PV2 input watts were reporting 460 W in both places and I captured until they both changed to 517 W.

Unfortunately, I've been through every packet in the capture, and don't see either of these two numbers. No clue at this point.

[jblance]

No new commands in the capture as far as i can see (maybe QBEQI which I havent implemented) QPIGS, QPGS0 and QP2GS0 seem to be doing the work Early in the dump QP2GS0 is giving (11 92911908100043 B 00 121.5 59.99 120.1 59.95 0421 0421 016 57.5 000 093 109.5 08 10100010 With a battery voltage of 57.5 and battery charging amps of 08 (460W) The last response to QP2GS0 in the dump is (11 92911908100043 B 00 121.4 60.00 120.0 59.99 0429 0429 017 57.5 001 093 108.7 09 10100010 battery voltage of 57.5 and amps of 09 (517.5W)

So maybe Watchpower is just doing the math?

[cowpen]

Great find, thank you! I hadn't even considered they might be using battery voltage instead of pv_input_voltage. They must be doing the same math inside the unit to show PV Watts on the front panel. Incidentally, here's what I received back from MPP Solar on the subject:

Hello Sir The unit currently isn't authorized to provide the communication protocol of PV 2 input power, thus we suggest that please calculate the PV2 input power by PV input voltage * PV input current.

Thank you.

Multiplying those parameters wildly overestimates watts - more than my panels are capable of. Clearly, they don't know what you figured out yourself.

Thanks for your help on this. Appreciate all the work you do on this project.