5 minutes ago, plonkster said:

you can literally build an installer

Again, super useful info! Thanks!

@plonkster I assume this line

gobject.timeout_add(SAVEINTERVAL, save_counters)

will ask the global object to call save_counters() for each SAVEINTERVAL ?

I can't seem to find where gobject is defined. Don't see it in velib_python

Also I assume the interval is in milliseconds?

1 hour ago, Louisvdw said:

will ask the global object to call save_counters() for each SAVEINTERVAL ?

Correct. It waits for SAVEINTERVAL milliseconds, and then it calls save_counters. If save_counters returns true, then it will be called again after the same interval. So I know that code is from the digitalinputs code... and that part saves the counter values to localsettings so that in the event of losing power, you don't lose the entire count value.

gobject is usually imported higher up. Venus currently uses a very old version of the gtk integration stuff and the gobject event loop. But a future version will use the newer gi stuff (it's already being ported).

First version of the serial battery driver is working. SOC and DC values are published and updated. 

2 hours ago, Louisvdw said:

First version of the serial battery driver is working. SOC and DC values are published and updated. 

Nice.

One small change I can immediately suggest: make the last part of the service name something that incorporates the serial device, eg: com.victronenergy.battery.ttyUSB2.

Also, /Mgmt/Connection can show this info, eg it could show "serial /dev/ttyUSB2" or something like that.

The last part of the service name is never used to do anything, it just helps to identify it by sight.

For any alarms that are not supported, I suggest you publish None (it will show as a - in dbus-spy). That way the GUI can hide them, so that you don't have alarms on the list all showing OK when those alarms are not even supported by the battery 🙂

Other than that... nice. Really nice.

Edited August 21, 20205 yr by plonkster

54 minutes ago, plonkster said:

service name

I started off naming the service completely different using my own domain URL, but then the Venus system does not pic it up. I guess it checks  for "com.victronenergy.*". But I'll make it more descriptive. I already updated the Mgmt/Connection after those screen shots where made.

Thanks for the info on the alarm paths. That will make it a bit cleaner.

Edited August 21, 20205 yr by Louisvdw

Still need to add a few versions and IDs, but all the rest of the data and alarms are there

 

Still need to figure out where these items are set as they are not in the published dbus list for batteries that I could find

2 hours ago, Louisvdw said:

Still need to figure out where these items are set as they are not in the published dbus list for batteries that I could find

Those are in /System/MinCellTemperature, /System/MaxCellTemperature, /System/MinTemperatureCellId, /System/MaxTemperatureCellId, /System/NrOfModulesBlockingCharge,  /System/NrOfModulesOnline, /System/NrOfModulesOffline, /System/NrOfModulesBlockingDischarge, /InstalledCapacity, and /Capacity.

If your battery doesn't have them, just leave them out. They are optional paths, for diagnostic purposes.

An even more interesting project would be to do clever voltage control. As soon as you have a high cell (one that is above 3.6V, set the charge voltage to the sum of the voltages of all the cells (or some maximum safe value, whichever is lower). Theoretically you've now created the perfect condition for the balancer to do its job, shoveling charge away from the high cell. Over time, as the lower cells pick up, this will cause your charge voltage to be raised as well, thereby maintaining conditions for the balancer to work well. Using this method, you should never have to adjust the maximum charge and discharge currents. You only adjust those as a last resort.

Of course, normally, the BMS should work out these voltages, but in this case I think it might be interesting to implement some smarts yourself, since you have the luxury of having all the cell voltages.

Edit: A figure an explanation may be needed about the capacity paths. InstalledCapacity would be how much is actually installed, while available capacity is how much is online right now. In multi-module batteries, those values might be different when one module disconnects itself for whatever reason. In your battery, they will likely just be the same value, or you may choose to show only the Available capacity since that's what the BMS gives you.

Edited August 21, 20205 yr by plonkster

All the parameters are working nicely. I'm busy making the changes so the driver will be installed and started with the serial-starter script.

 

Most of these changes was done over the weekend, but then I also tackled by DB. It was on the todo list to cleanup and install a bigger box since before the lockdown when I added the ET112 meter.

If anyone has done some fishing you would know a "kraaines". The 12 place DB could only fit 8 in slots of CB and when I added the double slot ET112 meter push wires into all the corners to make space. Here is my "kraaines" being taken apart. No way to know which neutral and live goes together.

 

It was a full day of work! Every person turning the corner would have a comment like "Spagetti!" "Spiderweb" or "Is it going to work" 😬

 

In the end I finished 5:20pm. (made it just in time for the braai  ) Much nicer now and my change over switch actually fit inside the DB.

Just, wow. That should qualify for some makeover award! Nicely done.

On 2020/08/22 at 12:08 AM, plonkster said:

An even more interesting project would be to do clever voltage control

I've implemented this. Now I just need the sun to come charge my battery to full so I can test if it actually does something. ⛅

2 hours ago, Louisvdw said:

I've implemented this. Now I just need the sun to come charge my battery to full so I can test if it actually does something. ⛅

If you get this right... well... you should send your CV to some battery makers. Cause few of them get it right... 🙂

 

1 hour ago, plonkster said:

Cause few of them get it right

Still have to wait and see if my implementation does work. It is only 6 lines, so you make me worry 😬

PS. Is there a way for my driver to ask for input in the Remote Console, or is this coded in the RC? It would be nice if you can for instance switch this option ON/OFF or set the max cell voltage where you want it to kick in, etc.

28 minutes ago, Louisvdw said:

Still have to wait and see if my implementation does work. It is only 6 lines, so you make me worry 😬

To be fair, I've not actually tried it. It is a theoretical concept. The idea is to have two modes, so to speak.

1. In normal mode, all your cells are balanced. You charge until the charge voltage is 56V, and because the cells are balanced, all of them end up around 3.5V, give or take.

2. In "balancing mode", your cells are not perfectly balanced. One of them is beyond 3.6V. You then lower the charge voltage so that this cell does not rise even higher.

If you set the charge voltage to the sum of the present cell voltages, then in theory no further charging happens. If there are calibration differences, then maybe you end up pushing a little bit above 3.6V per cell, but that should be fine. You can go up to 3.8V without any danger.

To use an example from  real battery I had. This battery reported its lowest cell as 3.35V, and the highest would go over 3.8V. Using some simple math, I figured that 3.35*15+3.8 = 54.05V, and this was precisely what we observed: The battery would raise alarms when we went over 54V.

Using my method, you'd aim for 56V, and then the moment you see a high cell (as you near 54V) the BMS would drop the charge voltage to 54V. This prevents the high cell from going over-voltage. The BMS can now take its sweet time shovelling charge towards the other cells. As the other cells rise, the charge voltage will slowly creep up, until the balance is restored. Then you can go back to "normal mode".

The things that will cause some issues: delays in measurement. If the voltage measurements are several seconds old by the time you get them, you may not be able to react fast enough. LFP cells above 3.55V spike up really quickly. Therefore, running a control loop based on the highest cell, where that cell sits between 3.6V and 3.8V, may be a fools errand unless your measurement delays are low enough.

🙂

 

21 minutes ago, plonkster said:

delays in measurement

Yes I though this could be an issue, but we will test this . My loop is every 3sec. and I think that should be fast enough (from what I have seen happening on my battery)

Lucky, my battery also have one cell (no. 13) that goes into a spike earlier than the rest, so perfect for testing this. It will jump to over 3.6V while the rest is still at 3.45V

What I do it to limit the charge if any cell is above 3.6V and they are not all above 3.5V and the battery is doing balancing (else what it the use). 
Here is my function that does it

    def manage_control_charging(self, max_voltage, min_voltage, total_voltage, balance):
        # If all cells are low then we can charge at max
        if max_voltage < 3.50 or not balance or min_voltage > 3.5 or total_voltage > MAX_BATTERY_VOLTAGE:
            self.control_charging = False
            self._dbusservice['/Info/MaxChargeVoltage'] = MAX_BATTERY_VOLTAGE
            logging.info(">STOP< control charging min {0} max {1} tot {2}".
                         format(max_voltage, min_voltage, total_voltage))
            return

        # Limit the charge voltage if a few cells get too high
        if max_voltage > 3.60 and min_voltage < 3.50 and balance:
            self.control_charging = True
            self._dbusservice['/Info/MaxChargeVoltage'] = min(MAX_BATTERY_VOLTAGE, total_voltage)
            logging.info(">START< control charging min {0} max {1} tot {2}".
                         format(max_voltage, min_voltage, total_voltage))
            return

 

1 hour ago, Louisvdw said:

My loop is every 3sec

The danger is that you could end up pushing the voltage up, then down, then up, then down... etc. This might not matter too much when you're not feeding your excess DC into the grid, but when you're feeding DC into the grid (more common overseas), then this causes the Multi to go into a charge/discharge loop. So sometimes you need to dampen/low-pass/exponential filter it a bit. Exponential filter usually works well.

I was running my driver today testing the charge management routine for when a cell is reaching the overcharge limits. What I found is that the run away cell keeps on increasing voltage, even though the max charge voltage was set to the pack voltage. After playing with the numbers a bit, it does seem that the measurements are not always as precise you expect them and the tolerance is also a factor of your voltage value. 

So while the BMS measure the fine voltage for each cell and the tolerance (say 5%) on 3.5V is very small (0.00175V), the inverter is working with the much bigger battery voltage (52V) and a tolerance on that number (5%) is much larger (0.26V). 

So it seems that charge voltage from the inverter was around 0.2V-0.3V higher than the max voltage I was specifying. It did help to reduce the change current as well.

The gaps is when my tests failed and the battery did a reset. Oops

23 minutes ago, Louisvdw said:

So it seems that charge voltage from the inverter was around 0.2V-0.3V higher than the max voltage I was specifying. It did help to reduce the change current as well.

Another way is to add a negative term to the charge voltage. If any cell is higher than some threshold (say 3.65V), then subtract that delta from the total, in other words design it so that it doesn't merely stop charging, but actually causes a slow discharge. This again accounts for calibration differences, if you go a bit over, it starts pushing the charge voltage down, until the two meets somewhere in the middle.

My own experiments with this (which involved a BYD battery, I was trying to see if I can do better than their BMS, which doesn't do very good voltage control) wasn't very successful, again because of measurement latency (you only get a value every 2 seconds), and because that high up it spikes up too easily.

On 2020/08/18 at 11:35 PM, plonkster said:

/ etc /venus /serial-starter.conf

It seems that I might be missing something again. 

My driver is running happily in the background in a "screen" for more than a week now. No problems there.
However I am trying to get the serial-starter config set up so that it will run my driver instead of the manual way I have been doing it up to now.

I've created a service subfolder with a run command which is a copy from dbus-systemcalc-py \ service \ run.
This has a symlink into the service folder (dbus-serialbattery -> / data / etc / dbus-serialbattery).
I created a file / data / conf / serial-starter.d with 

Quote

service sbattery       dbus-serialbattery
alias  default       sbattery

 

When I stop my driver and run the start-tty script I get an error

Quote

/opt/ victronenergy / serial-starter / start-tty.sh / dev / ttyUSB2
ln: / dev / serial-starter / ttyUSB2: No such file or directory

Is something else using / dev / ttyUSB2 ?

PS. All this is in the serial-starter branch here. It might be easier to look at in Github

PPS. Sorry for the spaces. The forum software does not like things that look like a folder or URL it seems.

Edited September 2, 20205 yr by Louisvdw

3 minutes ago, Louisvdw said:

Is something else using / dev / ttyUSB2 ?

Let me explain quickly how it works, then hopefully you can figure it out.

udev is configured to create symlinks when it recognises things of interest. See . This also sets, using the VE_SERVICE environment variable, what kind of services could potentially be supported on there. This in turn is configured in serial-starter.conf, which is in / etc / venus, but you can add stubs in / data too, the main config file pulls that in (so you can make it survive firmware updates in this manner).

Serial starter then copies your service directory, replaces TTY in the script with the one detected, and attempts to start it... once. If it fails, it moves on to the next one... continuously in a circle until something sticks.

8 minutes ago, plonkster said:

udev is configured to create symlinks

To be more accurate, udev creates a symlink to the real device in / dev / serial-starter. Serial starter (which is a bash script) scans that directory periodically, and then handles them according to the rest of the rules.

In this setup you don't symlink it into /service yourself. Serial-starter will do all of that for you, creating run scripts from the provided template (and filling in TTY).

OK seems I had it on the wrong side creating links in service. I'll give it a look through tonight

The driver is now started by serial-starter when the device boots.
 

Quote

@400000005f508d903107ac84 *** CCGX booted (0) ***
@400000005f508d9732e29a8c INFO:__main__:dbus-serialbattery
@400000005f508d980b6d4524 INFO:__main__:SP15S008C-L15S-100A
@400000005f508d9821bc48ac INFO:__main__:Battery connected to dbus from /dev/ttyUSB1

 

1 hour ago, Louisvdw said:

The driver is now started by serial-starter when the device boots.

Cool. Now build an sd-card installer for it, and then ship it 🙂

 

13 minutes ago, plonkster said:

Now build an sd-card installer for it, and then ship it

Now you sound like my project manager