On 2020/03/08 at 6:26 AM, Coulomb said:

I suspect that 88.88 is an invalid version number. Perhaps the Bluetooth processor did not respond in time. It seems common for 88.88 to come up after the display firmware has been updated to 02.00. I believe it will "come good" in time, and will be back to version 00.21.

hi there, did you managed to get the rid of U3 88.88?

On 2020/04/02 at 12:01 PM, Gnome said:

I don't think they are malicious about it.  Software developers cost a lot of money to hire.  Especially engineers that are comfortable with coding for a platform like the inverter is running.  It is probably being written as C code that runs directly on a CPU.  It is a lot more tedious to write code for something like that than it is to write for example Java/Python/etc.

As for them not fixing the bugs that @Coulomb, I suspect one of two reasons:

1) They don't consider it a bug

2) Their engineers aren't aware of what is being produced by people like @Coulomb.  This is pretty common actually and even more so if you are speaking a completely different language (ie> Chinese).

The way they operate is pretty close to how 99% of companies work, they put out a product and only make updates if they need to.

I think @Gnome is being incredibly generous.

First prize is that you hire competent programmers, and test and fix your software before releasing it.  If/when you provide updates, you document the changes.

Second prize is that you release software full of bugs, and have your customers test it for you.  You then fix the problems, and provide well-documented updates to your customers. (Microsoft?)

Last prize is to release buggy software, ignore all feedback, deny all bugs, and release new updates only to those who buy new hardware.  You never provide release information.  This is Axpert.

As far as I am concerned the "they don't' understand English" argument does not wash.  If you look at the contents of ".out" files provided with eg 71.86 you will see that variable and routine names are in very correct English - I would guess that their developers are completely proficient in English.  Anyway, it is not an excuse.  Their Chinese customers are experiencing the same bugs.

The "they don't consider it a bug" argument also does not wash.  Many of the bugs, and how to demonstrate them, have been extensively documented in these pages.  The King inverters are close to dysfunctional - I remember reading @Coulombsaying a few months back that he would not recommend buying the King until the firmware is fixed.  Even now the Kings simply do not work when used in parallel mode with Pylon batteries.

They market the King as suitable for "mission-critical loads such as servers and ATMs" - they are surely joking.  Their hardware represents excellent value for money.  Their software is a disgrace.

 

Quote

Last prize is to release buggy software, ignore all feedback, deny all bugs, and release new updates only to those who buy new hardware.  You never provide release information.  This is Axpert.

That is a very common pattern.  A lot of phone manufacturers do the same with Android updates.  The same for cars, cars stop being updated when their manufacturing ends.  Keeping software up to date is something the software industry does, the hardware and manufacturing industry does not subscribe to this model.

And frankly the only reason the software industry is able to do this is because the margins.  I work for a company that did retail only, our margins were low, 3-5%.  We built a software devision and within less than 10 years it overtook the retail business which was a giant.  The reason is simple, the margins on software are in the 100s of percentage points.

When you build a hardware device, there is no money to be made post sales.  Not to mention the margins are razor sharp.  Some companies get past this by selling hardware that requires a "cloud" plan or similar.

Also again, I don't think many people get just how much different the software industry is to other industries because of the chronic undersupply.  There are a lot of factors at play that make it VERY expensive when you want to enter the software industry.

Quote

They market the King as suitable for "mission-critical loads such as servers and ATMs" - they are surely joking.  Their hardware represents excellent value for money.  Their software is a disgrace.

It depends what you use it for.  I use it as a double conversion UPS.  In that role, it is better than anything provided by the competition at the price point.  In fact I don't even know of other inverter manufacturers that offer double conversion on their inverters.

The product is well priced and it sells well.

You are being a bit disingenuous in saying that it is crap.  There are a lot of crap inverters out there.  Tons of them.  None of them are making the sales the Voltronic devices are.  The reasons aren't their marketing divisions.  It is because they've built a relatively good quality product for very little money.

Edited April 6, 20206 yr by Gnome

On 2020/04/05 at 11:56 PM, Calvin said:

As far as I am concerned the "they don't' understand English" argument does not wash.  If you look at the contents of ".out" files provided with eg 71.86 you will see that variable and routine names are in very correct English - I would guess that their developers are completely proficient in English.

Not all of the developers have a good command of English. At the end of every successful firmware upload is the cheerful message "Updata sucess!" or similar. Even in the main firmware [ edit: where the English is vastly better ] , you can find functions with names like "_sbGetEepromFauldCode()". Sure, it's just a typo, but there are several of them and they persist version to version and model to model.

Edited April 7, 20206 yr by Coulomb

4 hours ago, Coulomb said:

Not all of the developers have a good command of English. At the end of every successful firmware upload is the cheerful message "Updata sucess!" or similar. Even in the main firmware [ edit: where the English is vastly better ] , you can find functions with names like "_sbGetEepromFauldCode()". Sure, it's just a typo, but there are several of them and they persist version to version and model to model.

@Coulomb, fair enough so they don't all write prefect English. The context of the original comment by @Gnome was that their English is not good enough to be aware of the work that you are doing.  To achieve that they need only one engineer or developer who can read English.

Okay guys,

I am making a quick mission to my clients house today to install the ICC hardware and see how it goes running it off of state of charge via ICC instead of off of the Voltronic battery settings.

I have setup VNC on the ICC hardware here at home, and tested it, so I know it works.

I'll be able to monitor and make changes if necessary from the comfort of my office (fingers crossed).

I'll let you now how this inverter behaves running via ICC...

OMG!

This is driving me nutz! And my client as well, which is not good for business!

Please can someone help me...

After connecting up the Pi and plugging in the special cable from the Pylon 2.4kwH x 2 batteries to the Pi unit, the Pi worked perfectly and I could monitor it and VNC into it as well if I needed to make remote changes.

Because this is the Kodak King unit, the communication cable between the Pi and the inverter needs to be in the inverters micro USB port. It also needs to be an expensive cable, not the cheap R30 cables you can buy. They wont work. I tried many!

So, I set the inverter up as follows:

Battery Type : Use

Voltage settings as mentioned on this and other forums for Pylon batteries.

Use Time for Control : 7am - 7pm setup as SUB as client wants to run off solar with battery only as backup if needed (loadshedding). 7pm - 7am setup in SBU mode. Obviously there is no solar at this time so the inverter runs on batteries at this time.

Use SOC for Control : Back to grid set at 50%. This means that if the batteries reach 50% overnight then they will stop discharging and utility will take over, saving them for a possible worst case scenario of an overcast rainy day, and loadshedding.

So, with it setup in this manner, all was working well, batteries were at 99% SOC, and all communication was working perfectly.

Got home last night and at around 8pm decided to logon and see what was happening with the batteries, which would have now been running the installation for an hour.

Logged in and found that grid watts was zero. Perfect. Saw that the batteries were still at 99%. A bit odd, but possible, as the load was only around 500w.

Logged off and made supper. Logged back on around midnight as I was climbing into bed. Batteries still sitting at 99%!

Obviously this was impossible.

I did a restart of the Pi and waited for it to come back up.

When it did, I saw that the grid was now running the installation, and the batteries were showing zero. Also impossible.

I checked the Thread Info, and the Pylontech info was blank....

I then clicked on Info Logs, and saw Error Connecting to Pylontech Port...

It was after midnight now, so I thought to call round in the morning.

This morning, around 10am, I returned to my client, again, to check what was happening.

The batteries showed full LEDs lit, 100% charged! The Pi showed zero with a comms problem as mentioned above.

I restarted the Pi again and everything came right!

I failed the mains and checked that everything was being displayed properly on the Pi.

Solar was running, so I pulled the fuses on that. This left the batteries running the installation and discharging, no grid watts, no solar. Perfect.

Reconnected solar and mains, and watched the batteries charging back up again. Perfect!

Said goodbye and promised to monitor and find that "sweet spot" for my client.

Around 5pm I logged in and all was still fine.

Logged in again around 8pm, an hour after switch over to SBU mode, so the inverter should be running on battery now...

Again, this was the case, however battery was reading 99% again...

Checked the Thread info and found that the Pylontech field was blank again!

Once again the Pi could not connect to the Pylontech port! This was connected and running perfect all day, and at 5pm too.

I can only think that when the inverter switched over to SBU mode, it lost connection to the batteries! The same as last night! I have no idea why though?!

So, i restarted the Pi, and waited for it to come online again and reconnected to it.

Still no battery connection. Restarted again. Still no battery connection.

No matter what I tried, or what sequence of stopping and starting and changing settings and restarting, I cannot get the Pylon batteries back online!

The best that i got was the inverter running the batteries off of its own management system. The Pi being basically useless. Just a manner of VNC'ing into the unit remotely.

I am so upset with this installation. I keep going back to my client again and again and again!

Not only is he getting rather annoyed with me, but I am losing faith in these Voltronic inverters and Pi monitoring systems.

Please, if anyone has any input, please impart your knowledge

Tomorrow I will need to return AGAIN!

I am going to reconnect the cable from the inverter to the Pylon batteries. The one that came with the inverter. The King inverters can manage the battery via its own BMS.

Unfortunately, the reason that I am using the Pi method is because the inverter was doing strange things when running on Battery Type: PYL.

I'm at a loss other than that and hope that with this SOC method and the Pi connected, I can get this unit to run like i need it with no further issues...

😥

Edited April 16, 20206 yr by DeeJay

Got hold of the ICC guys today, and they VNC'd into the ICC at my clients.

Turns out a couple of settings I had input were not right.

We disconnected the inverter from the batteries, and connected the ICC battery cable from the ICC to the batteries.

We left the time settings for control as they were, and the SOC control settings as they were.

Since 1pm the Pi has been running perfectly and measuring all data correctly.

I am eagerly awaiting 7pm so that I can see if this has worked without any more issues.

I'll report back tomorrow, after 24h of, hopefully, flawless logging and monitoring...

Hi do you perhaps know which settings were incorrect?

”Turns out a couple of settings I had input were not right.”

Greetings

Albert

The guy I was speaking to whizzed around and changed things, so I am not 100% sure.

The settings now are as follows...

Back to Grid Voltage - 46v

Back to Discharge Voltage - 48v

Battery Cutoff Voltage - 54.5v

Bulk Charging Voltage - 53.2v

Float Charging Voltage - 53.2v

Charger Source - Solar Only

AC Input - Appliance

Battery Type - User

An update though....

I had a lengthy chat this evening to the owner of Centurion Solar and the programmer behind the ICC software.

He VNC'd into the Pi and queried the system to see where the issue lay, as the battery once again froze up and I could not get any data out of it.

The long and short of it is this...

The battery's were not designed to have their comms ports as a permanent data transfer port. None of the comms ports on the battery are designed in this manner.

They are more akin to an upgrade port.

As such, they auto shutoff. This is based on the internal computer in the battery. It decides this.

When these ports close, the monitoring cable loses connection. Usually 2-3 reboots of the Pi solve this, but every now and again, the port shuts down, and only a hard reset of the battery will wake it up again.

Unfortunately, this is the issue with my battery.

I have 2 batteries in parallel, so he suggested that I swap the batteries around and make the other one the master, and try its' comms port as communication, and maybe I'm lucky and it works better.

Unfortunately, all lithium batteries are designed this way. It is not just a design fault with Pylon batteries. In fact, it is not a design fault by nature, as the batteries were not designed to transfer data full time through these ports.

He is presently working with Pylontech, and busy writing a script of code which will embed itself in the battery, and will query these ports. If they go to sleep, it will try and wake them up again, so that this loss of communication does not happen for an extended time period. He says it's about 70% successful in doing this, but the other 30% of the time the battery will still require a hard reset.

I am unlucky in that the battery I have set up as a master is losing its' connection every day. This is far from ideal, as I cannot seem to wake it up by soft resetting it

If the Pi can't see it then the inverter will not know when to recharge the batteries, or what level they are at to stop discharging them.

So I will try and swap the batteries around and see if that helps.

The only battery so far that he has solved this problem for, by working with the manufacturer, is the Blue Nova range.

The only way to work around this 100% of the time, is to buy a Victron BMV battery monitor, and plug it into the Pi to use as SOC. Then to use the Pi as usual to control the inverter based on accurate SOC with no resetting necessary. Bear in mind that you will need the VE Direct to USB cable as well to plug the BMV into the Pi.

Mine has been a bumpy road with my first full solar install, but I have learnt a LOT along the way in the last 3 months.

Looks like I will be coughing up for a BMV monitor so that my client will be happy.

From now on I will be including these in the quoted cost of the installation so that I don't run into this issue again.

I hope this helps anyone else out there with similar issues...

✌️

Ps: The King version of these inverters has an issue with the firmware. The cable supplied to connect the inverter to the battery works perfectly until you connect solar to the installation. As soon as solar is connected, you get the 69 warning, and charging of the batteries stops, solar is lost, connection is gained, charging starts, solar connects, warning 69, and an endless loop of this situation continues every 10 seconds or so.

Also note that if you want to connect the Pi to a King version, you need a USB to micro USB cable. And it needs to be a decent, expensive cable. A cheap R30 cable does not communicate between the Pi and the inverter. Just the way it is.

These are some of the things I have learnt along the way... 👨‍🔧

Edited April 17, 20206 yr by DeeJay

6 hours ago, DeeJay said:

The King version of these inverters has an issue with the firmware. The cable supplied to connect the inverter to the battery works perfectly until you connect solar to the installation. As soon as solar is connected, you get the 69 warning, and charging of the batteries stops, solar is lost, connection is gained, charging starts, solar connects, warning 69, and an endless loop of this situation continues every 10 seconds or so.

Is it possible that this due to is the solar balance setting that Kings can't view or set from the front panel? See this AEVA post for details. You can set it (you want it enabled) with a command, or with Watchpower. ICC may have a setting for it.

Edited April 18, 20206 yr by Coulomb
Added "due to"

@Coulomb

My client was not very happy with me this morning, as I had to return again after the comms port shut itself down.

Due to this, and the fact that I DO NOT want to have to return there for a while, I have taken the cautious route until after lockdown.

I have disconnected the Pi's battery cable. I have reconnected the King's battery cable to the batteries.

I have rebooted the Pi and observed that it is seeing battery SOC as FULL.

While the Pi rebooted, the usual 69 fault came up on the screen, during which time the charger was disconnected and the loop started again.

After my chat to Johan at ICC last night, I understand that the reason for this fault code is because the BMS inside the Pylon is telling the inverter it is already fully charged, and not to charge more. However the inverter wants to throw more charge at it. But, because of the message from the BMS through the cable to the King, it disconnects the charger, and at the same time (not sure why), it disconnects the solar input (maybe because solar is setup as the only charging method, which forms part of "charging" in general).

Now, in my mind, the way to solve this would be to lower the bulk and float charge? Surely??

So, I dropped the bulk charge from the recommended 53.2v to 52v, and the float charge from the recommended 53.2v to 51v, and guess what??

NO 69 FAULT CODE!!!

Batteries read 98% (which is obviously what 52v equates to), and they sit perfectly at between 52 and 52.2v charging and discharging as they float on "full" or 98% in this case.

This is with the King's battery cable connected to the Pylons and battery type set up as PYL!

Therefore the inverter (as per manufacturers specs) should now be measuring SOC from the BMS of the battery.

The Pi is still connected, but is getting its' battery SOC from the inverter, which is obviously getting it from the BMS.

So this is perfect now! With no battery cable connected from the Pi to the Pylons.

Obviously one would need to note that this cannot be done with an inverter that does not allow the batterys' BMS to talk to it.

One would need a King or VMIII for this function.

It would seem that my problems have been solved!!

I don't want to get too happy just yet though. We will see if this runs through the night from 7pm on SBU and the batteries deplete and then charge up again in the morning at around 10am when solar is sufficient. 

🤐

Edited April 18, 20206 yr by DeeJay

@SnoopySniper

You asked me which settings were incorrect.

As per my post above, the bulk and float charging voltages in my case were too high.

If the battery cable is connected between the King/VMiii and the Pylon, and battery type in setting 5 is set as PYL, and on the LCD display you are seeing a flashing battery, it indicates that the BMS is talking to the inverter.

Right.

Now, I am no expert, but if, in this state, the LCD screen is coming up with a warning 69, it is because the BMS, which is in place to, among other things, protect the battery, is telling the inverter to stop sending charge as the battery is already fully charged and possible damage will occur if more charge is forced into the battery.

Now thats fine.

All you do is lower the bulk and float charge, and hey presto, BMS and battery are happy. All for the cost of 2% battery power. I would guess it can be notched up slightly from 52v until the error comes back, and then dial it back by a 0.1v adjustment to get it at its max.

To be honest, I'm happy at 98%!

For all those that have Pylon batteries installed with no BMS monitoring the battery, and they have the bulk and float charge set as high as 53.2v, in my humble opinion, this will be doing damage to the battery. I have no idea how much damage, but if the BMS is stopping charge at that voltage, then I'm assuming it's not a good thing...

I hope this helps?

✌️

Edited April 18, 20206 yr by DeeJay

1 hour ago, DeeJay said:

So, I dropped the bulk charge from the recommended 53.2v to 52v, and the float charge from the recommended 53.2v to 51v, and guess what??

NO 69 FAULT CODE!!!

✌️

Not sure what happened here - both @Coulomband I suggested doing exactly this on 1 April. You read it and replied.....

4 minutes ago, Calvin said:

Not sure what happened here - both @Coulomband I suggested doing exactly this on 1 April. You read it and replied.....

😵

What a plonker! My bad! U did indeed! Somehow I read it but did not implement it! Had so many hassles with this install. It's all a bit of a blur!

As u guys both mentioned, solved the problem straight away!

🤭

@Calvin

Do you think there is any need for a BMV on this system? Does the King & Pylon BMS communicate okay?

With my inverter set to PYL and if I change the charge voltages, the king automatically changes back to 53.2v. Im assuming it gets this number from the batteries.I also noticed the charge current decreases on the settings page as the battery nears full. Im running 71.86 and wondering if you're able to change the charge voltage and it stays at the new set voltage that this could be a change in firmware 71.90 ? or possibly different firmware in the batteries?

Now i thinking out loud here. Could this be part of the problem is that for whatever reason maybe the batteries are not communicating the charge voltage correctly to the inverter? 

Thanx guys for the help over the last few days.

I wish I had actually taken in what was being offered as a solution and tried it...

Everything is working perfectly. The battery drained to around 48.4v, which was equivalent to 21%.

Didn't want to risk the batteries switching off and have to go back again tomorrow to turn them on.

Batteries are charging back up now.

I did notice that the Pi reboot itself once tonight. When it did, the bulk and float voltages reset to 53.2 in the inverter settings tab.

I did not click set.

I will see if this value is just a default or if it changes the value back. I'll know in the morning.

None of the other values seem to have changed...

16 hours ago, DeeJay said:

@Calvin

Do you think there is any need for a BMV on this system? Does the King & Pylon BMS communicate okay?

The King and the Pylon communicate fine at an electronic level, BUT:

a. For some weird reason they use 53.2V, which, as you have seen, is way too high and causes all sorts of issues.

b. If you use the Kings in parallel (as I do) it does not work at all.

So, at this time (firmware 71.86) the only practical way of running them together is as you are now doing.

The downside of this is that you do not get good SOC information.  This can be obtained by interrogating the batteries directly using ICC or similar, or any device that can communicate via RS232.  I have developed my own system using an Arduino.  This an the additional advantage of allowing one to get around the well known PYLON issue with SOC values above 89%.  I implemented a self-calibrating Coulomb counter to give accurate SOC all the way up and down the scale.

15 hours ago, RichieRich said:

With my inverter set to PYL and if I change the charge voltages, the king automatically changes back to 53.2v. Im assuming it gets this number from the batteries.I also noticed the charge current decreases on the settings page as the battery nears full. Im running 71.86 and wondering if you're able to change the charge voltage and it stays at the new set voltage that this could be a change in firmware 71.90 ? or possibly different firmware in the batteries?

Now i thinking out loud here. Could this be part of the problem is that for whatever reason maybe the batteries are not communicating the charge voltage correctly to the inverter? 

@RichieRichLooking at the Pylon communications protocols, I do not see anything that looks like it can send a Charge voltage number to the inverter.  I suspect that the 53.2V is hard-coded into the Axpert firmware.  Remember, the PYL setting is specifically for the Pylontech batteries.

It would be nice if Axpert made that a variable parameter. But then. they have no history of doing things that would seem obvious to me......

OK, so this morning I have the following to report...

Last night the inverter ran perfectly, as mentioned above.

Even though it was set to only charge via solar, I see that the grid was trickle charging the battery from 21% at a rate of 2 amps, until 7am when the solar woke up and took over charging. At this point the batteries had recovered to 40%.

Solar charged the batteries back up to 52v, 99% by 11am.

The restart I mentioned above did change the values visually on the inverter settings page, but these values were not sent to the inverter.

It stopped charging at 52v, the settings I set on it before the restart occurred.

All seems to be running perfectly 🙏

Edited April 19, 20206 yr by DeeJay

I've uploaded Axpert King firmware to the files section:

* Main firmware version 71.92

* MCU/remote display firmware 02.40, which has support for direct connection to several lithium battery BMSs. [ Edit: there is now version 02.49. ]

These are designed to work together, though if you don't care about lithium support for now, you could probably omit the remote display firmware.

Edited July 19, 20205 yr by Coulomb

Thanks Coulomb, I downloaded, will try and give feedback.

There is no later SCC version than mine isn't it?

14 hours ago, MJS said:

There is no later SCC version than mine isn't it?

I don't have any King SCC firmware. But they don't seem to change very often.

On 2020/07/16 at 10:26 AM, Coulomb said:

I've uploaded Axpert King firmware to the files section:

* Main firmware version 71.92

* MCU/remote display firmware 02.40, which has support for direct connection to several lithium battery BMSs.

These are designed to work together, though if you don't care about lithium support for now, you could probably omit the remote display firmware.

Any idea what they changed?