Thread Rating:
  • 2 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Limiter inverter with RS485 load setting
Hi, I was browsing Aliexpress and stumbled across this image of the same inverter, showing that there might be a new firmware update, or perhaps the image is displaying an older firmware? If you want the link I'll send it over but due to being aliexpress the URL is a mile long, you can probably find the product yourself easier.

Hi all,

I've updated some of MasterTH's code to control the inverter with either JSON or MQTT. It allows multiple units and a hard limit on maximum output, and a buffer amount which also includes the ability to export.

I am hoping to test it as soon as some max3232 UART/TTL/RS232 breakout boards arrive so I can make a reliable serial port on my Rpi. The USB to serial adaptors seem to constantly freeze due to driver problems.

If anyone would like to do code review or had any comments on it please let me know!

I've made a file to allow it become a system service too, it's all in the repo.
completelycharged and CarlosGS like this post
Add in handling of the packet from the units, which returns the voltage at the terminals and the input amps. Volt meter accuracy is not that great though... also sense check the voltage as incoming packets do collide and get voltage readings all over the palace. Frequency of data packet is about the frequency of coulds in the sky...

myBytes22 = 14 byte buffer / packet

batVolts = ((myBytes22(5) * 256) + myBytes22(6)) / 10
batAmps = ((myBytes22(7) * 256) + myBytes22(8)) / 10

Then.... with the volts (either from this reading or a more accurate reading from your BMS) you can then create a proxy formula to estimate the battery Wh remaining..

lblWhRemaining.Text = (-(1) * (-21.6661623 * (batVolts ^ 3) + 3569.24955115 * (batVolts ^ 2) - 197572.81504691 * batVolts + 3637661.56366712)).ToString("#,##0Wh")

This gives me a rough indication of Wh remaining with accuracy of +/- 15% of pack capacity. Yeah, not "ideal" but more than good enough to use consistently without worrying about coulomb counting resets and drift.

Tip : You don't need to be a math guru to get the formula.... just use Excel. Get a few readings from your battery Wh and volts... add them into a scatter plot....... add a polynomial trend line...... edit the trend line to show the formula...... change the formatting to add enough digits to get the values accurately....... you have your formula withut any working out...
Cell-King likes this post
If you can't quantify how much they cost, it's a deal, I'll buy 5 of them for 3 lumps of rocking horse ......
I've been finding that the devices are not working consistently. When I was using the limiter which was supplied with the devices they only worked for several hours and rarely made it through the day before going crazy- outputting a high rate constantly until they drained the battery or were restarted.

The entire purpose for replacing the limiter box with a software solution was to solve this problem but it seems like it is still there! I've been working on the software and including time of day features for night rates, which I have in my house, and also features for adapting the output based on if there is a lot of power coming from the panels along with other checks and exception catching.

I know the problem is with the inverters because I have a kill script that I can run when they operate normally and once started the output will drop to zero. When the inverters are going crazy they will not obey the kill script.

All this time it seems that the inverters cannot make it through a single day without needing to be shut down, this is not great because while i'm in the house a lot at the moment, I cannot depend on them when I'm back going to the office again.

Does anyone have a solution because I'm at my wits end here! The only thing I can think of is hope for a firmware upgrade that perhaps solves this issue!

I've attached a photo of the inverter going rogue. It was set to output at a low value then all of a sudden it went bananas.

There is something a little odd with the units, however in my case (same issue of inverter stopping responding to RS485 data) the issue was the transmitter end and at the time seemed to occur IF the low voltage cut-off was reached. With the inverter running between the normal voltage range the iverter worked fine and has done for over a month. This was part of the reason I ended up adding in a voltage detection and control override on the power output to prevent the unit from reaching battery cut-off. I ended up setting the cut-off voltage at near 0kWh (effectively emergency cut-off) and just control the ouput on/off purely with the separate code.
If you can't quantify how much they cost, it's a deal, I'll buy 5 of them for 3 lumps of rocking horse ......
The saga continues with this P.O.S., please excuse my french. So to quickly summarise what I have done so far to get this working:

The inverters would only work correctly for several hours before ignoring their output commands and start exporting a random amount to the grid (they never made it through a full day without breaking), so I presumed it was an issue with the external meter box. I tried everything to get it going including replacing the meter but couldn't get it fixed.

Then I removed the meter box as the control for the inverters and wrote some software that runs on a raspberry pi which takes a demand reading from my emonpi meter box and sends the required output command over a serial cable to the inverter. This also would only work for a while until the inverters decided to do whatever they like and output a random amount of power.

I connected a switching relay to my serial port cable chip (a max3232) because I found that if you unpowered the serial chip and powered it up again the systems would often respond properly again, so I thought the max3232 was crashing. The relay runs every 15 minutes and restarts the max3232 chip for a second but this still hasn't solved the problem.

I've written a loop that increments an outputted watt value every 0.5 seconds from 0 to 400 and I can see that the inverters do somewhat respond properly, the output draws a sawtooth waveform on my graphs as you would expect so the inverters are somewhat obeying my commands. It's the intermittent nature of this issue that makes it very hard to fix.

I'm starting to think that I might need to include a "ramp rate" feature in my software to get the inverters to better "track" what I am asking of them. For example, in my live system, if the demand goes from 400 to 800 watts perhaps I need to send output values along the lines of: 400, 450, 500, 550, 600, 650, 700, 750, 800 over the timespan of a second instead of what I currently do which is: 400, 800. 

I've also contacted SoyoSource on Aliexpress several times and they've "read" my message but have not replied. My opinion at this stage is unless there's a firmware update for this equipment I would really recommend against this product and would instead go for a Sunpower with limiter. I'm unsure if they make a 24 volt option which is what my system is based on but it will be something I will look into. 

@MasterTH I came across a slight error in your code:
            if bezug > 20:
                byte4 = int(bezug / 256)
                if byte4 < 0 or byte4 > 256:
                    byte4 = 0
                byte5 = int(bezug) - (byte4 * 256)
                if byte5 < 0 or byte5 > 256:
                    byte5 = 0
                byte7 = (264 - byte4 - byte5)
                if byte7 > 256:
                    byte7 = 8

Because you lack the <= and >= sign you will have values which are over 256 being sent to the wire at specific output values. This might or might not lock up your serial port.

To correct it, simply modify it to something like the following:

            byte4 = int(demand/256) ## (2 byte watts as short integer xaxb)
            if byte4 <= 0 or byte4 >= 256:
                byte4 = 0
            byte5 = int(demand)-(byte4 * 256) ## (2 byte watts as short integer xaxb)
            if byte5 <= 0 or byte5 >= 256:
                byte5 = 0
            byte7 = (264 - byte4 - byte5) #checksum calculation
            if byte7 >= 256:
                byte7 = 8


I'm only getting around to re-reading your post now:

>This was part of the reason I ended up adding in a voltage detection and control override on the power output to prevent the unit from reaching battery cut-off. I ended up setting the cut-off voltage at near 0kWh (effectively emergency cut-off) and just control the output on/off purely with the separate code.

This is very interesting, my cut off is 22v and my startup is 23v, perhaps I will lower them and simply output zero when I get into the lower battery range because it does seem to happen more frequently at night and also early morning when the battery would be low . I'll report back in a few days.
Hi @Cell-King outputting 0W still draws power. Maybe you can have a simple sonoff at the AC output to allow completely disabling the inverter.
Edit: I use a Sonoff POW R2 at the AC output to achieve this. It also measures output power quite accurately.
What rate do you send packets? As well as ramping the output you could try limiting the rate you send packets. Or limiting changes for a time after you receive a packet. I have had comms issues when sending or responding too quickly on other unrelated devices.

Also, have you tried to break it? If you can trigger the communications to drop out on purpose it may help you avoid that scenario. You could send packets as fast as possible, send it multiple large power changes (if safe to do so), do both at the same time or anything else you can think of (bad checksum).

Forum Jump:

Users browsing this thread: 1 Guest(s)