MPP Solar LV2424 Hybrid Inverter Error 90 Fix


New Member
Jan 19, 2021
Even though I've resolved this issue for myself I'm just posting for the sake of documenting this issue since as I was searching for an answer I came across several people who were asking similar questions with no answers. While it's unlikely the root cause is the same my experience may be helpful to someone.

Yesterday, my LV2424 stopped AC output, AC input, and solar charging effectively stopping any operation while still powering on. The error code shown was 90. Checked the manual for error 90 fault code. Nothing.

Almost the only substantive info was in this video (which is Spanish but you can get the gist of it with the auto-translated subtitles):
. The key points though are
  • This is a software error
  • It occurs because the unit "loses the serial number"
  • It happens after 60 days of operation
Somehow the video maker had some manufacturer piece of software to "reapply the serial number" which I of course do not have. There was also this info in a powerforum post about an axpert inverter

Error 90 (fault code 90) results from a mismatch between what is in the bootloader and what is in the rest of the firmware. I believe it was designed to catch out clones who copy the firmware but not the bootloader.

You might be able to update to factory firmware version 72.70, which doesn't have the error 90 check, or patched firmware version 72.70c or 73.00e. But first check which model yours are a clone of, or you could brick the inverter. See Can I update my firmware, and to what? and Do I own a clone? . Not all models can be update in this manner.

Unfortunately, some clones aren't able to be updated at all. If that's the case, you need to get a new control board (it plugs in to the main board) for each machine from your supplier, with new firmware that solves this problem. I assume that most clone manufacturers will have sorted this out by now. Don't bother attempting to source control boards from a legitimate importer; they will ask for a serial number, and specifically won't help anyone with a clone.

It's an ugly war between the original manufacturer (Voltronic Power), and the clone makers, and unfortunately people like you are getting caught in the crossfire.

Well I ordered mine from watts247 so I know I don't have a clone or some bootlegged hardware and I've been operating this thing for over a year. So how did I end up with this error.

I had implemented some of the software in this thread:

Specifically using this python package from github (which is excellent btw):

The problem I had was that while this package is capable of interacting with a variety of inverters the PI18 protocol it uses to interact with LV2424 does not implement any functions to modify the settings which is what I wanted so that I could programmatically switch the load source priority between battery and grid in order to better manage the discharge behavior.

The protocol documentation (and I have no idea where the package author got it is here ( and as the quote above implies this originated with InfiniSolar.

The document describes the commands needed to set various settings that are not implemented in the package so I just added command definitions the to the file and now I can modify settings as well as read the status. Great.

My problem was that while this documentation is helpful, it is not verbose. There is a command described as "Set solar configuration" and while I was creating and troubleshooting my new additions, I thought that this was basically the equivalent of an "Apply" command. Basically you issue commands for what settings you want to change and then follow it up with this "Set solar configuration" to which you supply the unit serial number command to really seal the deal. I thought that perhaps this was why the set functions weren't implemented since the command would have to be different for each unit it was used on. This is not the case and the other setting commands require no follow-up. There was no need for me to ever issue that command to my unit ever.

This command, and I have no idea why this exists, updates the unit's serial number. This would not have been a problem for my but when I was experimenting with it my serial number format was wrong so I ended up truncating the last 6 digits of the true serial number. This caused the described mismatch described in the earlier quote. The kicker was that this causes absolutely no problems until 60 days of mismatch has elapsed which is exactly how long it had been since I had made my changes to the command definitions.

So for any other poor soul who is equally stupid or more likely has another origin of this problem if you need to update the serial of number of your unit without the Spanish man's magic Infinisolar software here is what you do.

First, grab the mpp-solar package from that github. Hook it up and query your unit status or something to make sure it works without edits.

Second, find the protocol file and add this JSON to the portion where the COMMANDS variable is defined and add this one to it
    "ID": {
        "name": "ID",
        "description": "Query Parallel info",
        "help": "ID",
        "type": "SETTER",
        "response": [["ack", "Command execution", {"NAK": "Failed", "ACK": "Successful"}]],
        "test_responses": [
        "regex": "ID([0123456789])*",

Then you will be able to issue a command to your unit that looks something like [CODE}mpp-solar --protocol PI18 -c ID14SERIAALNUMBEREXTRAZEROS[/CODE]

That first number after the ID is the length of the serial number but you still have to provide 20 digits after that and pad the right side of the serial number with 0s to get it to 20. This is syntactically odd and what tripped me up. So since my serial number was 14 digits long I put the ID[The number 14][My actual serial number's 14 digits][6 extra 0s since it still needs 20.

Restarted the unit and that fixed it.

If you were in a situation as described with a cloned unit and mismatching serial numbers you would need to know the bootloader serial number in order to make it match and perhaps there is some way to examine the unit to determine what that is (or get it from the clone mfr) but that is beyond the scope of what I needed to do here because I just made my totally legitimate unit think that it wasn't real...