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
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: https://diysolarforum.com/threads/monitoring-mpp-clone-systems-with-freeware-pi-grafana.15712
Specifically using this python package from github (which is excellent btw): https://github.com/jblance/mpp-solar
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 (https://github.com/jblance/mpp-sola...cols/PI18_InfiniSolar-V-protocol-20170926.pdf) 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 PI18.py 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 PI18.py 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 PI18.py protocol file and add this JSON to the portion where the COMMANDS variable is defined and add this one to it
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...
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):
- This is a software error
- It occurs because the unit "loses the serial number"
- It happens after 60 days of operation
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: https://diysolarforum.com/threads/monitoring-mpp-clone-systems-with-freeware-pi-grafana.15712
Specifically using this python package from github (which is excellent btw): https://github.com/jblance/mpp-solar
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 (https://github.com/jblance/mpp-sola...cols/PI18_InfiniSolar-V-protocol-20170926.pdf) 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 PI18.py 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 PI18.py 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 PI18.py protocol file and add this JSON to the portion where the COMMANDS variable is defined and add this one to it
Code:
"ID": {
"name": "ID",
"description": "Query Parallel info",
"help": "ID",
"type": "SETTER",
"response": [["ack", "Command execution", {"NAK": "Failed", "ACK": "Successful"}]],
"test_responses": [
b"^1\x0b\xc2\r",
b"^0\x1b\xe3\r",
],
"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...
