Limiter inverter with RS485 load setting

Hi All,

This is a great thread, good work so far. Today, I finally got two of these units wired up and ready to go. The problem that I am having is the external meter seems to become "stuck" at sending a high voltage request to the units after a few minutes of operation. This results in exporting battery capacity to the grid! I am eager to get to the bottom of it, by perhaps replacing the meter for a different type, or going the R-pi, MQTT route. The meter seems quite badly designed, for example it doesnt respond to the bottom to add units responsively, i've had to spend minutes pressing the button for it to finally receive the input.

Last month, during my testing with a single unit, it worked fine for several hours (about 10kwh over 3/4 days on and off). I think there is a problem with the meter working correctly in cold conditions. This is the only explanation that I can come up with. Since having two complete systems (two inverters and two meters). I have been trying different situations so this is only thing I can think of, it was warmer last month during testing, also the meter works for several minutes when brought from my warm kitchen today out to the outside meter box.

I have a RS485 adaptor that I will attach to the wire tomorrow and finally see if the issue is with signalling from the meter and not the inverters. I'll also put a temporary heater into the electricity box and report back with findings. If anyone has any other suggestions I would be eager to hear them because it's taken me months to build 9kwh of 18650 cell packs and mount 3kw of panel on the roof!!!
 
To follow up with last night's post- I am really disappointed in this product and I would hesitate to recommend it to anyone. It only worksintermittently so I don't think I'll be able to rely on it.

Just to remind you, I have two inverter units and a meter box that is set to "2 Unit". They are connected with a twisted pair of a cat 6 cable that runs from the electricity supply box to my shed. One of the inverter units is daisy chained to the other for RS485 communication.

From last night's idea I attached a small travel router to the back of the meter box to see if I could warm up the unit, in the case that cold weather is affecting the microcontroller inside. I've attached some thermal photos of the before and after but it didn't improve the situation of exporting energy to the grid. There doesn't seem to be a pattern to the oversupply. The system will occasionally follow the rules and then all of a sudden export about 120 to 200 watts more than it needs to.

I've restarted both the units, and the meter box to no avail. I put an RS485 adaptor inline with the wire to sniff for packets and the strange thing is it seems to be missing some data, perhaps someone could try to make sense of it? It might be an issue with my terminal program removing zero valueinformation.I've attached a graph from openCMS showingbehaviour.

For the time being I've turned off one of my two units so that the system still generates power, but does so to a level definitely below what is being consumed by the house. I can see see how one of the units "proportionally" generates half the power that it should where it is waiting on the other unit to pick up the slack.

One possible solution I have is to set the meter to "3 Unit" and let the two inverters share what is being requested by the house. This should mean the two units generate the power that the meter is "telling" three units to do (so two thirds, or slightly more if it goes into over-generation).This may keep me below the level of exporting to the grid but it's a far cry from the solution as it was sold to me.

If anyone had any advice on this it would be greatly appreciated.

Code: 
24 56 21 6d 24 56 21 6d 24 56 21 6e 24 56 21 6e 24 56 21 6d 24 56 21 6d 24 56 21 6d 24 56 21 73 24 56 21 75 24 56 21 73 24 56 21 6e 24 56 21 6c 24 56 21 6d 24 56 21 6c 24 56 21 6c 24 56 21 6d 24 56 21 6c 24 56 21 6d 24 56 21 6c 24 56 21 6d 24 56 21 6d 24 56 21 6c 24 56 21 72 24 56 21 75 24 56 21 72 24 56 21 74 24 56 21 6e 24 56 21 6d 24 56 21 6d 24 56 21 6e 24 56 21 6c 24 56 21 6d 24 56 21 6d 24 56 21 6d 24 56 21 6c 24 56 21 6b 24 56 21 6e 24 56 21 6b 23 63 5c 24 56 21 6d 24 56 21 6f 24 56 21 6e 24 56 21 6d 24 56 21 6c 24 56 21 6d 24 56 21 6c 24 56 21 6d 24 56 21 6c 24 56 21 6c 24 56 21 6c 24 56 21 6c 24 56 21 6e 24 56 21 6c 24 56 21 6d 24 56 21 6e 24 56 21 6d 24 56 21 6c 24 56 21 6d 24 56 21 6c 24 56 21 6c 24 56 21 74 24 56 21 6e 24 56 21 6e 24 56 21 6e 24 56 21 6d 24 56 21 6e 24 56 21 6c 24 56 21 6d 24 56 21 6c 24 56 21 6c 24 56 21 6c 24 56 21 6b 24 56 21 6c 24 56 21 6c 24 56 21 6d 24 56 21 6e 24 56 21 70 24 56 21 6c 24 56 21 6b 24 56 21 6f 24 56 21 6c 24 56 21 6d 24 56 21 6d 24 56 21 6b 24 56 21 6c 24 56 21 6c 24 56 21 6d 24 56 21 6d 24 56 21 70 24 56 21 70 24 56 21 6e 24 56 21 6c 24 56 21 6b 24 56 21 6c 24 56 21 6c 24 56 21 6c 24 56 21 6d 24 56 21 6c 24 56 21 6c 24 56 21 6d 24 56 21 6f 24 56 21 6d 24 56 21 6d 24 56 21 6d 24 56 21 6c 24 56 21 6d 24 56 21 6c 24 56 21 6e 24 56 21 6c 24 56 21 6c 24 56 21 6c 24 56 21 6f 24 56 21 6d 24 56 21 6d 24 56 21 6d 24 56 21 6e 24 56 21 6c 24 56 21 6c 24 56 21 6c 24 56 21 6c 24 56 21 6c 24 56 21 6c 24 56 21 6b 24 56 21 75 24 56 21 76 24 56 21 70 24 56 21 6d 24 56 21 6d 24 56 21 6d 24 56

image_oxetkk.jpg

image_evyxkq.jpg

image_hpfkwg.jpg
 
Cell-King said:
Just to remind you, I have two inverter units and a meter box that is set to "2 Unit". They are connected with a twisted pair of a cat 6 cable that runs from the electricity supply box to my shed. One of the inverter units is daisy chained to the other for RS485 communication.
Click to expand...

With the RS485 the cable may need a termination resistor adding depending on length of the cable. Read up on the reasons for termination resistors.

The sample values in hex appear to be only half of the packet showing only the first 4 bytes for a period of time and then showing a full packet. The dropouts occur at the 00 packet, which would make it look like the RS485 timings are out or a terminator resistor is needed on the line. How long is the cable run ?

The meter that is supplied with the unit I'm not impressed with, although I have 3 installed and they have been working ok without issue for quite a while. The CT's on them are split core and the only issue I have had is with them being not aligned fully which showed a lower reading. The worryign bit is that they are a plug because a CT left disconnected from a load will try and generate a massive voltage (because it is effectively a step up transformer) and then the CT wil effectively destroy itself through internal arcing. This is under a reasonable loadpassing through the cable it's clamped to.

The units themselves do seem to be ok once the RS485 data feed is clear and ok. My issue early on turned out to be the adapters I was using making a mess of the packets, which still didnot resolve 100% as I suspect that the units don't cope well with data packets that are not 100% reliable and the unit then sticks and holds whatever output it has.

I think the units have a timout on the packet reception, which is not long enough and it ends up merging received packets together, although again I'm only 20% convinced of this logic.

The meters are quite basic but the other odd aspect is with them the single unit selection outputs the data quite fast and then when you change it to 2 untis the meter only halves the reading output but for some reason (I think it is a failed attempt to manage the rate of change in load following) the update rate decreases. This is what conflicts with my initial thought about the packet timout creating issues.

The other element is that the output data from the units, which shows the voltage and curren, is pushed out onto the RS485 line seemingly at random and with multiple unit chained together they don't appear to have any way to syncronise the packet output and collisions do occur. This does not seem to impact the running appart from colliding with an update meter reading/settin. Ths again probably drops my 20% logic to 2%...

They can work ok....

Ahhh, another issue which you are yet to experience..... or not.

If you have this setup :

Mains Incomming --> CT --> Breaker box --> Inverter

Then the inverter will ramp up to full load when the power flows to export.

The reason is that the CT measurement does not register direction and therefore if you export 50W the inverter sees 50W "load" and outputs 50W which then results in 100W export and the inverter increases again, until this process ends up at full inverter output.

They have to be setup with the inverter output connected before the CT measurement point as per the diagram in the instructions.
 
Thank you so so much. I cannot thank you enough. I added a resistor across the line in the shed and both units are now working fine with less than 50 watts imported. It's early days but it looks like this is the solution to the issue. My cable run is about 15 meters. Luckily enough the circuit to the shed terminates in a way where I have the CT clamp "after" the inverter so I shouldn't have this issue. Thanks again!

EDIT: It seems I needed TWO 110 ohm resistors, one at each end of the cable, directly where the green RS485 plug connects to the unit. One resistor improved operation a lot but two has completely fixed it.
 
I'm finding that this system continues to import around 75 watts continuously. Ideally I'd like to get that down to something closer to zero. I've tried a different CT clamp, i've tried cleaning the interface between the split in the metal core and i've also tried reducing the cable length between the CT clamp to the meter box to as short as possible to remove any losses. If anyone could suggest any other way to reduce the import figure it would be greatly appreciated.
 
The accuracy of a small split core CT is never going to give you good accuracy over the full current range. At what power output / import / export level is the 75W difference showing up ?

I ended up going the control route to work around this and optimise the power output as well to avoid pushing power out at lower efficiency when there is not enough sun to balance out the daily energy need.

The way I worked around the reading it is to have a meter also on the overall import/export so that this "residual" is then used to correct any issues the other CT's may be showing in terms of over or under reading. Plus the other easier option with separate control is that you can also add a small export buffer (over balance by a few W). If the load is 200W then output 205W. There are also other reasons this can help if the load is not a smooth current draw.
 
Hi CompletelyCharged, I started to collect values to graph them to demonstrate but the system started acting up again, the same problem of over supply to the grid. It took two days to troubleshoot and the intermittency of the problem is really frustrating. I swapped resistor values, I changed the topology from a "bus" network to a "star" network and I added a 10 watt router as a heater in case it was the cold that was affecting it (the problems would also mostly happen at night time too, and it was the only thing I could think of). Nothing helped and it would just send data to the grid until I flipped the breakers.

I assume the issue is with the meter as my packet captures still seems to occasionally have incorrect values.

I have been able to hack together the code by MasterTH and I already have an Rpi at both the electricity box and at the location where the batteries are so I will remove the meter, call the json value from the CT clamp, and put the new values out on the wire and see if I can bypass the meter completely.

One question I have is when using multiple inverter units- I'm guessing that the meter halves the requested power, (as part of the "Unit" button) and both units pick up the same packet and drive to that? If this is the case I will modify MasterTH's code to reduce the power value in half and post my version when I have some extra error protection built in.

One more feature I would like is to lower the maximum output power slightly if there is less power from the panels, to lesson the stress on the batteries. I'm running these in 24 volts setup and two 900 watt inverters would pull about 60 amps off a 24 volt pack which i want to avoid, even though I designed my packs for about that amount. This should be easy enough to implement but it might take me some time.
 
There may be schrodingers cat in one of the units, whereby the problem on exists when your not looking at it.

Ah, forgot about the "random" errors.... I filter those out before sending the command to the inverter units. From the meter they are not that frequent but the returned valus from the inverters are corrupted relatively frequent.

Yes, the meter just halfs the output value.

For winter the power level reduction is what I do. If you don't have the energy to offset all the load all of the time then only offset the load at the maximum efficiency. This also means turning off at night if the load is below say 80W because the efficiency starts to drop again.

Also in the code try and avoid the units switching on and off at a marginal load level (i.e. switch on at say 120W and then off at say 70W). This is more relevant for winter time with less available energy.

What CT are you using to get a JSON response ???
 
Thanks for the advice, I'll report back with any progress. I am using the emonpi system which allows a lot of manipulation with the CT clamps- JSON, http, MQTT etc.
 
Has anyone noticed that this product WILL allow you to output power to your house loads when you get it running and then DISABLE your battery (solar direct to loads), but it WONT power your loads if you start the unit with it only being connected to the solar controller?

It's as if the internal resistance of both the unit and the solar inverter been to be brought down by a load for power to be transferred in the first place. Just an observation. It would be useful if you were servicing your battery for a few days to be able to let the unit still power the house directly from the panels.
 
Not entirely clear on what your indicating (load / solar output watts), but the solar controller would lack the ability to deliver the initial higher current draw to get the unit syncronised.

The input stage for the inverter has an internal capacitor which buffers most of the switching current draws but the initial startup may require a brief higher current draw, which the solar on it's own cant deliver...

The units I thought were partly switchable between solar and battery mode, but have not tried them off solar directly. The coment above was for battery mode.
 
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.



image_vbnvpc.jpg
 
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.

https://github.com/drcross/virtualmeter
 
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...
 
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.

image_xvcdyw.jpg
 
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.
 
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 theiroutput commands and start exporting a random amount to the grid(they never made it througha 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 meterbut couldn't get it fixed.

Then I removed the meter box as the control for the inverters and wrote some software that runs ona raspberry pi whichtakes 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 whateverthey 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 properlyagain, so I thought the max3232 was crashing. The relay runs every 15 minutes and restarts the max3232 chip for a secondbut 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 thatthe invertersdo somewhat respond properly, the outputdraws 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 productand 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 Icame across a slight error in your code:
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 likethe following:

Code: 
		  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

@completelycharged

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, sendit multiple large power changes (if safe to do so), do both at the same time or anything else you can think of (bad checksum).
 
You must log in or register to reply here.
Back
Top