My path on the blue brick road (Victron Multiplus install)

[Louisvdw]

Over the last several months I have been installing my inverter system bit by bit. Here is my progress (written as a bit of a guide if it helps someone else).

Planning
My goals are: 

1. Have UPS power
2. Offset the cost a bit by adding solar
3. Stay within my limited budget.
4. Be modular for "add-as-you-go" option

I don't want to go off grid - that is just too expensive. So I can install a smaller inverter. 
As I will be doing most of the work myself I wanted something that has very good support and documentation. The natural choice for me was a Victron system.

I started off by finding my usage patterns(when) and consumption(how much).  
The easiest option was to use the Victron VRM cloud. I already had a Raspberry Pi3 that could be used for this purpose, so all that I needed to do was to install the open source VenusOS using the steps from here. (the other option is to buy 'n VenusGX device that already have all the required inputs/outputs). Leave it to get some stats over a month (or 3 if it is lockdown).

The ET112 energy meter (about R1100) is a good option to hook up into my DB. You install the meter between the earth leakage and the the rest of breakers. 

 
You also need a 3 wire cable (4core security cable or 6core network cable will work fine) and a RS485 USB converter like this one to make the meter talk to the Pi3. The negative(blue wire) go to terminal 6 of the ET112, and the Data A & B goes to terminals 4 &5.
 

Batteries
For batteries I decided to build my own using a LiFePO4 cells(4kWh) and a smart BMS.  

The 15S 100A BMS was ordered from AliExpress and arrived just after the first loackdown lifted, and the cells came from a mismatch special from Sinetech. I created cell connectors from 3mm aluminium bar and connected all the cells in parallel few 3 weeks to equalize. The smart BMS also has a cell balance option, and that helped a lot to get the cells in shape and on the same charge state. There is a 125A mega fuse on the 35mm2 cable to the battery. All the settings on the battery is set using the bluetooth app on your phone that also includes all the battery stats.
 

And built a battery case 
 

Inverter
Finding that our normal usage is around the 2000W a Multiplus II 3000/48 was the inverter of choice. All the peaks can be handled by the utilities, and if there are loadshedding the stove and kettle will not be in use.
For connection to the Pi3 a MK3-USB cable is used.

I used 4mm2 surfix wire to connect the DB to the inverter, and another 4mm2 wire for the return. There is a 63A change over switch to bypass the inverter (this is to keep the wife happy while I fiddle). For a month or so I just had the inverter and batteries running on the workbench hooked into to DB. Worked well for the first set of post lockdown loadshedding. 

Solar panels
I installed 4x 335W ArtSolar panels using SolarStrut bar and PowAR snap clips.
They are set up 2S 2P using 6mm2 solar cable and 16A Ceramic DC fuses for each cable and a DC breaker between the panels and the charge controller.

And using a 100-20 (48V) SmartSolar charge controller. I created a bit of extra heat sink to help with the heat dissipation. 
The SmartSolar controller is connected to the Pi3 with a VE.Direct to USB cable.

 

Final Mounting

All up on the wall. I still need to clean up the wires a bit.

 

 

Edited August 2, 2020 by Louisvdw

[___]

2 minutes ago, Louisvdw said:

RS485 USB converter like this one

Interesting! Venus actually detects it as an RS485 converter?

I have a similar one, or at lest it looks very similar, except mine converts TTL serial to RS485. It has two terminals (you can tie them together, as one is inverted) that control whether the chip sends or receives. Of course I got it because I intend to use a cheaper oscilloscope that has basic serial decoding functionality together with this device to decode RS485 (normally only available on much more expensive scopes). But that is another topic...

 

[Louisvdw]

2 minutes ago, plonkster said:

Venus actually detects it as an RS485 converter?

Yes it was plug and play

[___]

3 minutes ago, Louisvdw said:

Yes it was plug and play

Luck shot. There are just three types it recognises, the udev config says:

ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="FT232R_USB_UART",            ENV{VE_SERVICE}="rs485:default"
# Older versions have specific id_model so that is rs485 for sure
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="USB-RS485_Cable",            ENV{VE_SERVICE}="rs485"
# Isolated rs485
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="USB485_Iso_stick",           ENV{VE_SERVICE}="rs485"

And I happen to know that last one is the Hjemlslund isolated dongle, so it's really just two. If I had to guess, yours probably is a FT232R.

[jykenmynie]

9 hours ago, Louisvdw said:

I used 4mm2 surfix wire to connect the DB to the inverter, and another 4mm2 wire for the return.

If you’ve got 20A breakers, that should be fine for the wire. Just be aware that the 3kVA Multi can transfer 32A (and invert another 13A) as far as I am aware. Not sure what all feeds off the Multi’s Output, but you might get trips on the breakers  if the demand goes too high even though the multi would’ve been able to keep up while transferring.

[Louisvdw]

1 hour ago, jykenmynie said:

If you’ve got 20A breakers, that should be fine for the wire. Just be aware that the 3kVA Multi can transfer 32A

Yes, good catch there. I did set the multi to limit draw to 19A. I don't get close to that though. The stove does not go through the Multi and without that the peak is at 2kW for the rest.

 

11 hours ago, plonkster said:

yours probably is a FT232R

Correct yes. And as the MK3 and VE.Direct USB cables use similar chips I am pretty much guaranteed that it would work  

[Louisvdw]

I'm busy building a driver for the battery. The BMS use RS232 to communicate and I managed to send commands to request the stats of the battery and read the results.

Next step is the add this to a separate thread and use @plonkster DummyCanBms.py to publish these results to the VenusOS.

[___]

8 minutes ago, Louisvdw said:

Next step is the add this to a separate thread and use @plonkster DummyCanBms.py to publish these results to the VenusOS.

Since you have all the cell voltages, also publish the maximum cell voltage/temperature and the address of the cell to:

/System/MaxCellVoltage
/System/MaxVoltageCellId
/System/MinCellVoltage
/System/MinVoltageCellId

And put your total installed capacity in /InstalledCapacity.

[Louisvdw]

2 minutes ago, plonkster said:

and the address

Is the address just the cell number? So I can publish 0 for the first cell and 14 for the last cell (or is it 1 based?)

[___]

And put the version in /FirmwareVersion. It has to be hex coded though, so you want to send 0x202 (version 2.02), or 514 in decimal.

To translate the ascii, take the character value and subtract 0x30 (48, or ascii zero). The difference is the digit number. Then simply shift that number left by 8 bits (512) and bitwise OR on the remainder.

Edited August 14, 2020 by plonkster

[___]

3 minutes ago, Louisvdw said:

Is the address just the cell number? So I can publish 0 for the first cell and 14 for the last cell (or is it 1 based?)

The address is ascii, the idea is to make it flexible so battery makers can use their own representation. Most of them simply use integers. It gets more interesting when you have multiple modules making up a larger battery. Then the high cell might be in module 12, cell 4...

 

[Louisvdw]

2 minutes ago, plonkster said:

The address is ascii

OK perfect. So it is just for display then. 

 

8 minutes ago, plonkster said:

And put the version in /FirmwareVersion. It has to be hex coded though, so you want to send 0x202 (version 2.02), or 514 in decimal.

To translate the ascii, take the character value and subtract 0x30 (48, or ascii zero). The difference is the digit number. Then simply shift that number left by 8 bits (512) and bitwise OR on the remainder.

Thanks. The version should actually be 1.6. As I am trying to decode it from the hex it goes to 2.2. You description makes more sense than the Chenlish I have from the BMS (The chenlish just says: 0x10 means 1.0 version ). Looks like the same encoding so I can just pass the bytes along in my driver.

[___]

16 minutes ago, Louisvdw said:

The chenlish just says: 0x10 means 1.0 version ). Looks like the same encoding so I can just pass the bytes along in my driver.

Not exactly. If you want 0x10 (16) to show up as 1.01 (the closest possible under the Victron scheme), you need to change it into 0x101, or 257. Not that hard luckily, just bitwise AND with 0xF0 to get the MSB, shift left by 8 bits, then add the LSB (which is the original bitwise-AND with 0x0F).

[Louisvdw]

@plonkster I am seeing strange behavior, so I expect I am doing something wrong.

My python code that is reading my battery is running fine on a separate Pi Zero on Python3.

Then when I plug the FT232 USB device into my Venus Pi3 (running 2.58) it does not want to read the RS232 data (on Python2.7). I am looking at the correct USB device (it's on ttyUSB3 on the Venus Pi). I'm using PySerial (installed using PIP3 on the Zero, and opkg list-installed show the VenusPi has python-pyserial - 3.4-r0

Any suggestion what I can look at?

Quote

 File "/usr/lib/python2.7/site-packages/serial/serialposix.py", line 501, in read
    'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
 

 

Here is a snippet of the code that I use to write and then read. If I add the inWaiting() section it just waits in that loop. I also tried to resend the command in that loop after a few iterations, but that did not help either. I must be missing something the is different in the opkg pyserial vs. pip3, or there is a serial service already running that in consuming my device as well?

with serial.Serial('/dev/ttyUSB3', baudrate=9600, timeout=0.1) as ser:
  
    ser.write(command)

    toread = ser.inWaiting()
    while toread < 4:
        sleep(0.1)
        toread = ser.inWaiting()
            
    # toread = 4
    res = ser.read(toread)
    start, flag, command1, length = unpack_from('BBBB', res)

 

Edited August 18, 2020 by Louisvdw

[___]

1 hour ago, Louisvdw said:

multiple access on port

That ^^^

Venus has something called serial-starter. When it sees a USB device, it tries to start some kind of "driver" for it, usually vedirect or the cgwacs RS485 software. When that happens, two processes are reading the same serial port, and you get this sort of behaviour: The serial port reports that there is data, but by the time you get there to read it, the other process has already removed the data from the buffer.

If you want serial-starter to leave the port alone, tell it like so:

# /opt/victronenergy/serial-starter/stop-tty.sh /dev/ttyUSB3

After running that command, serial-starter will stop attempting to find something to do with that device...

[Louisvdw]

4 minutes ago, plonkster said:

serial-starter will stop

Can you start it later again? And is this how you match the USB device to the driver (I was wondering how to do this and not hard code the USB)

[___]

dfsdf

[___]

OK.... the forum software does not want me to tell you more. Sorry... it keeps giving me 403 if I type path names.

[___]

Let's try this again.

Venus starts one process after the other.

The process is defined in a file called slash etc slash venus slash serial dash starter dot conf. Sorry about typing that out... but I am seriously forbidden from just typing it.

Once your driver works, you can add it to that file. The rule is that if your software doesn't detect the expected hardware, it simply terminates. Serial-starter then simply calls one process after the other until one sticks.

Edited August 18, 2020 by plonkster

[___]

Also see here: https://github.com/victronenergy/venus/wiki/howto-add-a-driver-to-Venus

[___]

10 minutes ago, Louisvdw said:

Can you start it later again?

Yes. Call start-tty.sh instead.

[___]

Testing testing...

/ etc /venus /serial-starter.conf

But if I take the spaces out... it complains.... gaah...

Edited August 18, 2020 by plonkster

[Louisvdw]

11 hours ago, plonkster said:

Once your driver works, you can add it to that file. The rule is that if your software doesn't detect the expected hardware, it simply terminates. Serial-starter then simply calls one process after the other until one sticks.

Great! This is super useful info! 

And now the script runs on the Venus Pi as well   

[Louisvdw]

12 hours ago, plonkster said:

# /opt/victronenergy/serial-starter/stop-tty.sh /dev/ttyUSB3

This was a life saver. I have been pulling my hair out on this since Friday. (And there are already not that many left 

[___]

18 minutes ago, Louisvdw said:

This was a life saver. I have been pulling my hair out on this since Friday. (And there are already not that many left 

A very almost chucked a USB-ttl-serial converter in the bin once... only to discover I had accidentally left some process running in the background that periodically tried to talk to any detected serial ports.

That script is also used a lot when debugging something or doing support. You can rip the process out of the serial-starter loop, and run it manually. When done, simply put it back into the loop with the start script.

Something I did not mention last night, which you will also have to figure out in time: Daemontools. Venus manages those services using daemontools. You'll have to create a service directory for it (just borrow one from the others and modify). This then gets symlinked into /service, and the service is automatically started when Venus boots.

But... during firmware updates, your symlink will be destroyed. Not an issue though, Venus will run /data/rc.local at boot, so you can use that to restore the symlink if it does not exist.

Further to that, if you put a file called venus-data.tar.gz (or venus-data.zip) on an sd-card, and put it in the GX while booting, it will automatically unpack this in /data.

With all that information, you can literally build an installer that unpacks your code into /data, and using rc.local, symlink the service into place. Customers install it by putting a zip file on an sdcard, inserting and rebooting. Easy peasy

Edit: For those who wonder what the hell a symlink is... it's like what Windows used to call a "shortcut"... except the file system handles and file operations transparently, and Unix had it in 1984 already.

Edited August 19, 2020 by plonkster