In my setup I’m using a Lynx Distributor without a Lynx Smart BMS. I’m still interested in the information of the Lynx Distributor about broken fuses and therefore looking about information about the data protocol used between the Lynx Distributor and the Lynx Smart BMS.
Does anyone has any information about the physical protocol (I2C, UART, RS485, …) and/or software protocol being used?
@twam
Ich wäre auch interessiert.
Evtl kann diese Datei ein Start für Reverse Engineer sein:
VG
Björn
@BjoernK haven’t seen this code so far, but it looks like GUI code which most likely talks another protocol to the Lynx Smart BMS.
However, I played at little bit with the hardware yesterday and found out how it works:
It’s an I²C interface. The cable has the following mapping:
Pin 1 - yellow - 5V
Pin 2 - green - SDA
Pin 3 - red - SCL
Pin 4 - black - GND
You need a pull-up on SDA/SCL to 5V.
The device answers on I²C address 0b000001AA where AA is set by the address jumper. So in default configuration the address is 0x8.
Any reads on the device will always return the same status byte with the following meaning:
0b00000000 - Everything allright (center LED is green)
0b00000010 - No supply on bus bar (center LED is orange)
0b00010000 - Fuse 1 open (center LED red, first fuse LED red)
0b00100000 - Fuse 2 open (center LED red, second fuse LED red)
0b01000000 - Fuse 3 open (center LED red, third fuse LED red)
0b10000000 - Fuse 4 open (center LED red, forth fuse LED red)
If multiple fuses are open multiple bits are set (just or the values).
I’m now thinking about the best way how to use the I2C bus from the Cerbo GX (or any other device running Venus OS). My current favourite solution is to use FTDI’s FT232H (or similar variant) chip and its MPSSE mode. There would be already a ready-to-buy cable (C232HM-EDHSL-0) which only needs to two pull-up resistors. The only problem is to find an easy solution to use the MPSSE mode on Venus OS.
This is why you can daisy chain only 4 Lynx devices distributors if it’s connected to a Lynx BMS…
Now, after you make or buy that hardware interface, you just need to write your piece of code that will populate the dbus with the proper values that will mirror the fuse and power statuses.
com.victronenergy.battery
/NrOfDistributors <= Number of connected distributors (up to 8)
Note that this does not reflect which distributors are connected,
i.e. B & D can be present whithout A & B being present
/Distributor/A/Status <= 0=Not available, 1=Connected, 2=No bus power, 3=Communications Lost
/Distributor/A/Alarms/ConnectionLost <= 0=Ok, 2=Alarm
/Distributor/A/Fuse/0/Name <= UTF-8 string, limited to 16 bytes in firmware
/Distributor/A/Fuse/0/Status <= 0=Not available, 1=Not used, 2=Ok, 3=Blown
/Distributor/A/Fuse/0/Alarms/Blown <= 0=Ok, 2=Alarm
/Distributor/A/Fuse/n/* <= Repeat for every fuse in the distributor
/Distributor/B/... <= Repeat for every distributor (A-E)
...
/Distributor/E/...
Info from here: dbus · victronenergy/venus Wiki · GitHub
This is why you can daisy chain only 4 Lynx devices distributors if it’s connected to a Lynx BMS…
Yes. This could be worked around with an I²C multiplexer, an FTDI with multiple MPSSE channels, or just multiple FTDI chips/cables. However I don’t know if there is really a need for more than 4 channels.
Thanks for already finding out the DBUS values. This will come in handy.
I though you might want to emulate a Lynx BMS for the fuses on VE.CAN. So I searched for Lynx in git.
Keep me posted when you get something working and need a secound tester. I am not a hardware guy 
I now have a hacky implementation of MPSSE in Python which only requires pyusb which is available as a pip package on Venus OS.
I have the 3.3V version of the mentioned cable (C232HM-DDHSL-0) only supplying 3.3V which seems to suffice.
By default Venus OS loads the serial driver for the cable and immediately starts to use it with serial-starter so I changed its PID/VID to avoid this.
Then my Python script can read in the data without any problems:
root@cerbo-gx:~# python3 i2c.py
Lynx Address 8:
Bus bar voltage: OK
Fuse 1: OK
Fuse 2: OK
Fuse 3: OK
Fuse 4: OK
Lynx Address 9:
Not reachable
Lynx Address 10:
Not reachable
Lynx Address 11:
Not reachable
When removing power on the bus bar:
root@cerbo-gx:~# python3 i2c.py
Lynx Address 8:
Bus bar voltage: Not OK
Fuse 1: ?
Fuse 2: ?
Fuse 3: ?
Fuse 4: ?
Lynx Address 9:
Not reachable
Lynx Address 10:
Not reachable
Lynx Address 11:
Not reachable
Only point left is to clean it up and publish the data on DBUS. 
Also integrated it into DBUS. Now it shows up in the GUI:
Unfortunately it needs to be modelled as a battery as described in the Wiki. If anyone has hints or ideas to work around this, I’d love to hear them.
Clicking on fuses lists the distributors:
If a fuse is blown it is shown in the distributor detail view:
We also get an alarm in this case:
For now I’m quite happy except for the battery modelling.
Just an idea…
Delete or hide the rows you don’t need from the qml files. E.g. “Battery”, “State of charge”, etc.
This by defining a variable in the PageBattery.qml that will have a true or false value (your choosing) when the “battery” is in fact your “emulated” distributor.
The simplest way is to define a proprietary dbus path, that when present, it means that your hardware/software is present.
Then, for the rows you don’t want to show, introduce the show: your_variable
@BjoernK If you (or anyone else) want to play with it: GitHub - twam/dbus-lynx-distributor: Plugin for Venus OS to readout Lynx Distributor with Lynx Smart BMS
Thank you for sharing ! 
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
