JO+e

Hi Rid00,
Not sure if you've come right, but I'm busy toying with this exact situation (for my father-in-law). You can have a look at GitHub - celsworth/lxp-bridge: A bridge to MQTT for communications with the LuxPower range of inverters. So far I've managed to get it running on a Pi Zero W 2 and was able to retrieve info from the inverter and publish via MQTT during a quick test over the weekend. I haven't set up anything with the automation (via OpenHab) yet (in progress) so I can't yet comment beyond that, but so far it looks pretty promising.
You can have a look at the list of pulled and published metrics here lxp-bridge/inputs.md at master · celsworth/lxp-bridge · GitHub. Seems you can also issue some commands at present, but for my current use-case I'm not really interested in that (yet, anyway).
Happy to field more questions if you get stuck. I should be in a much better position after commissioning the little system over the weekend and then keeping an eye on what it's up to.
Cheers
Joe

Hi Rid00,
Not sure if you've come right, but I'm busy toying with this exact situation (for my father-in-law). You can have a look at GitHub - celsworth/lxp-bridge: A bridge to MQTT for communications with the LuxPower range of inverters. So far I've managed to get it running on a Pi Zero W 2 and was able to retrieve info from the inverter and publish via MQTT during a quick test over the weekend. I haven't set up anything with the automation (via OpenHab) yet (in progress) so I can't yet comment beyond that, but so far it looks pretty promising.
You can have a look at the list of pulled and published metrics here lxp-bridge/inputs.md at master · celsworth/lxp-bridge · GitHub. Seems you can also issue some commands at present, but for my current use-case I'm not really interested in that (yet, anyway).
Happy to field more questions if you get stuck. I should be in a much better position after commissioning the little system over the weekend and then keeping an eye on what it's up to.
Cheers
Joe

Hi all,
So I decided to be “clever” and try get a Venus Pi running instead of a GX device as part of my upcoming solar installation. I expected the integration with the Pylontech battery to give me the most headache and wasn’t far off, so I figured I’d document what I did to get it running here in case it helps anyone in future.
Hardware/Software:
•    Raspberry Pi 3B+
•    Waveshare RS485 CAN HAT (https://www.robotics.org.za/W14882?search=wave%20rs485)
•    Venus OS Firmware version 2.23
A bit about the CAN HAT: I saw here (https://github.com/victronenergy/venus/wiki/RaspberryPi-CAN-Interfaces) that the MCP2515 chip was supported in the Venus image, although this specific HAT wasn’t documented – I just figured I could hack it to work.
OK, on to the instructions (Disclaimer: I don’t really know what I’m doing, and relied heavily on information from other similar threads e.g. https://groups.google.com/forum/#!topic/victron-dev-venus/C4-3JhHpbcY). The guide assumes you’re familiar with SSH and have access to the terminal via PuTTy (Windows) or similar.
1.
Add the following text to /u-boot/config.txt
[all] dtparam=spi=on dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=25,spimaxfrequency=1000000 2.
Create /data/rcS.local and add the following text to bring the CAN interface up
ip link set can0 up type can bitrate 500000 2 a)
You can then check the interface with the following command to make sure it’s up and running:
Ifconfig can0 can0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:0 (0.0  TX bytes:0 (0.0
If the battery is connected and powered on, you should see numbers for RX packets (including some dropped packets which seems to only happen initially – my battery was not connected when I ran ifconfig hence all 0’s).
2 b)
You can also verify communication from the battery using candump can0, which should return something as follows:
  can0  359   [7]  00 00 00 00 01 50 4E
  can0  351   [6]  14 02 72 01 72 01
  can0  355   [4]  45 00 64 00
  can0  356   [6]  80 13 00 00 D5 00
  can0  35C   [2]  C0 00
  can0  35E   [8]  50 59 4C 4F 4E 20 20 20
  can0  359   [7]  00 00 00 00 01 50 4E
  can0  351   [6]  14 02 72 01 72 01
  can0  355   [4]  45 00 64 00
  can0  356   [6]  80 13 00 00 D5 00
3.
Then there is some fiddling to make the CAN interface visible to the Venus software (i.e. show up in the services menu).
First create the following missing symlinks (each one is a separate command):
ln -s /opt/victronenergy/can-bus-bms/service /service/can-bus-bms.can0 ln -s /opt/victronenergy/dbus-motordrive/service /service/dbus-motordrive.can0 ln -s /opt/victronenergy/dbus-valence/service /service/dbus-valence.can0 ln -s /opt/victronenergy/vecan-dbus/service /service/vecan-dbus.can0 ln -s /opt/victronenergy/mqtt-n2k/service /service/mqtt-n2k.can0 Note that all symlinks must be added – I initially got stuck as I only added the BMS which caused gui/ssh instability.
Then you need to make Venus aware of the CAN interface by executing the following command, which creates the file canbus_ports with a link to the can0 interface:
echo "can0" > /etc/venus/canbus_ports At this point it should have worked (after step 4), but I still had no joy getting the battery to show up in the Venus UI. Eventually I replaced “DEV” with “can0” in the following script file:
/opt/victronenergy/can-bus-bms/service/run
#!/bin/sh exec 2>&1 exec softlimit -d 100000000 -s 1000000 -a 100000000 /opt/victronenergy/can-bus-bms/can-bus-bms --log-before 25 --log-after 25 -vv -c socketcan:DEV –banner 4. 
Reboot
Follow the steps in Section 5 of https://www.victronenergy.com/live/battery_compatibility:pylontech_phantom
Reboot (not 100% sure if this is necessary – I’m compiling this guide from memory, and I had many, many detours along the way), and with a bit of luck, the battery should pop up in Venus, like so:

Extra: During the troubleshooting I used the following command to test. Running it from the console immediately (within 2s or so) brings up the battery in the Venus UI. Killing the command results in the battery showing as “Disconnected”. This is why it’s necessary getting Venus aware of the interface and getting the service running automatically (step 3):
/opt/victronenergy/can-bus-bms/can-bus-bms -c socketcan:can0 --banner --log-before 25 --log-after 25 -vv Hopefully I didn’t mess up the order too badly or omit any steps. As mentioned, this took me a little while to figure out and I’m doing this from memory which is admittedly shoddy at the best of times, so please forgive any obvious errors. Note that firmware upgrades wipe some of the modifications made above (I think maybe the symlinks but definately the changes to /opt/victronenergy/can-bus-bms/service/run (Step 3)) so just be aware of that.
Questions or comments welcomed, and hopefully this helps someone in future.
 

Cool, thank you. Always eager to learn a bit more about how things work.
Quite possible, yeah. As mentioned, I'll keep it in this configuration for a while and see how it behaves. Additionally, I've moved one of my Z-Wave temperature sensors into the cupboard to log the ambient temperature and see whether there's any correlation (crude as it may be) to throttling. 
Is there any way to monitor how much power the inverter is supplying (from DC) in VRM or otherwise? I noticed yesterday that the PV Charger (Venus) would report more than 2.4 kW at times, and it's a bit difficult seeing what the inverter is actually doing (AC loads + Critical loads - Grid =? PV Charger - I'm aware there will be some losses though)
I'll report back once I have any further detail from the testing. I do however suspect that there might be an issue with the configuration of my system as several of the charger settings were not according to the parameter values detailed in the Victron reference info (I didn't install/commission/configure the system initially), but let's first see about confirming or ruling out the temperature component.
Thanks again for all the assistance, and your patience with me 😉

Let me explain how it works, then you can maybe figure out what is going on.
When you feed excess PV into the grid, the solar chargers are instructed to charge the battery to 0.4V higher than the normal charge voltage. I don't want to go into too much detail about the "charge voltage", it depends on many things, but generally it is whatever the BMS requested or what the Multi was configured for.
After this, the Multi will feed as much power into the grid as is required to eliminate this "over voltage" and get the voltage down, while the solar chargers will work as hard as they need to to raise the voltage by 0.4V.
As long as your solar chargers and the Multi is calibrated fairly closely, and in the fast majority of installations they are, this works very well. The additional proviso is that your cables must be adequately sized. If you have an 0.4V voltage drop on the cable at power level X, then the maximum power the system can feed in is X. End of story.
Once the calibration differences combined with any voltage drops on cables come to 0.4V, feed-in is limited.
One way to get around it, which is unfortunately not easy, is to increase the offset. For this you need to root the venus device and set the value internally. This is also where things get even more tricky, cause the Pylontech batteries switch off at 54V, so you don't have much space to work with. The charge voltage for a pylontech battery is hardcoded at 52V, which technically leaves you with a whole 2V or room, though I would not increase the offset by more than 1V.
So here is how you do it. After rooting the venus device, ssh to it and run this command:
dbus -y com.victronenergy.system /Debug/BatteryOperationalLimits/SolarVoltageOffset SetValue 0.6 This will add an additional 0.6V to the 0.4V causing the solar chargers to aim for 53V and the inverter to aim for 52V.
If that improves the feed-in, then you have confirmed the problem. If not, then something else is wrong.
Remember that this setting is volatile... it is lost on reboot. Other things are needed to make it permanent. I'm telling you about it for testing and educational purposes 🙂

Hi all,
So I decided to be “clever” and try get a Venus Pi running instead of a GX device as part of my upcoming solar installation. I expected the integration with the Pylontech battery to give me the most headache and wasn’t far off, so I figured I’d document what I did to get it running here in case it helps anyone in future.
Hardware/Software:
•    Raspberry Pi 3B+
•    Waveshare RS485 CAN HAT (https://www.robotics.org.za/W14882?search=wave%20rs485)
•    Venus OS Firmware version 2.23
A bit about the CAN HAT: I saw here (https://github.com/victronenergy/venus/wiki/RaspberryPi-CAN-Interfaces) that the MCP2515 chip was supported in the Venus image, although this specific HAT wasn’t documented – I just figured I could hack it to work.
OK, on to the instructions (Disclaimer: I don’t really know what I’m doing, and relied heavily on information from other similar threads e.g. https://groups.google.com/forum/#!topic/victron-dev-venus/C4-3JhHpbcY). The guide assumes you’re familiar with SSH and have access to the terminal via PuTTy (Windows) or similar.
1.
Add the following text to /u-boot/config.txt
[all] dtparam=spi=on dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=25,spimaxfrequency=1000000 2.
Create /data/rcS.local and add the following text to bring the CAN interface up
ip link set can0 up type can bitrate 500000 2 a)
You can then check the interface with the following command to make sure it’s up and running:
Ifconfig can0 can0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:0 (0.0  TX bytes:0 (0.0
If the battery is connected and powered on, you should see numbers for RX packets (including some dropped packets which seems to only happen initially – my battery was not connected when I ran ifconfig hence all 0’s).
2 b)
You can also verify communication from the battery using candump can0, which should return something as follows:
  can0  359   [7]  00 00 00 00 01 50 4E
  can0  351   [6]  14 02 72 01 72 01
  can0  355   [4]  45 00 64 00
  can0  356   [6]  80 13 00 00 D5 00
  can0  35C   [2]  C0 00
  can0  35E   [8]  50 59 4C 4F 4E 20 20 20
  can0  359   [7]  00 00 00 00 01 50 4E
  can0  351   [6]  14 02 72 01 72 01
  can0  355   [4]  45 00 64 00
  can0  356   [6]  80 13 00 00 D5 00
3.
Then there is some fiddling to make the CAN interface visible to the Venus software (i.e. show up in the services menu).
First create the following missing symlinks (each one is a separate command):
ln -s /opt/victronenergy/can-bus-bms/service /service/can-bus-bms.can0 ln -s /opt/victronenergy/dbus-motordrive/service /service/dbus-motordrive.can0 ln -s /opt/victronenergy/dbus-valence/service /service/dbus-valence.can0 ln -s /opt/victronenergy/vecan-dbus/service /service/vecan-dbus.can0 ln -s /opt/victronenergy/mqtt-n2k/service /service/mqtt-n2k.can0 Note that all symlinks must be added – I initially got stuck as I only added the BMS which caused gui/ssh instability.
Then you need to make Venus aware of the CAN interface by executing the following command, which creates the file canbus_ports with a link to the can0 interface:
echo "can0" > /etc/venus/canbus_ports At this point it should have worked (after step 4), but I still had no joy getting the battery to show up in the Venus UI. Eventually I replaced “DEV” with “can0” in the following script file:
/opt/victronenergy/can-bus-bms/service/run
#!/bin/sh exec 2>&1 exec softlimit -d 100000000 -s 1000000 -a 100000000 /opt/victronenergy/can-bus-bms/can-bus-bms --log-before 25 --log-after 25 -vv -c socketcan:DEV –banner 4. 
Reboot
Follow the steps in Section 5 of https://www.victronenergy.com/live/battery_compatibility:pylontech_phantom
Reboot (not 100% sure if this is necessary – I’m compiling this guide from memory, and I had many, many detours along the way), and with a bit of luck, the battery should pop up in Venus, like so:

Extra: During the troubleshooting I used the following command to test. Running it from the console immediately (within 2s or so) brings up the battery in the Venus UI. Killing the command results in the battery showing as “Disconnected”. This is why it’s necessary getting Venus aware of the interface and getting the service running automatically (step 3):
/opt/victronenergy/can-bus-bms/can-bus-bms -c socketcan:can0 --banner --log-before 25 --log-after 25 -vv Hopefully I didn’t mess up the order too badly or omit any steps. As mentioned, this took me a little while to figure out and I’m doing this from memory which is admittedly shoddy at the best of times, so please forgive any obvious errors. Note that firmware upgrades wipe some of the modifications made above (I think maybe the symlinks but definately the changes to /opt/victronenergy/can-bus-bms/service/run (Step 3)) so just be aware of that.
Questions or comments welcomed, and hopefully this helps someone in future.
 

Well, I for one am extremely grateful for your efforts porting it to the Pi, and you did a great job with it - the system has been rock solid since July.
Having had everything else in my system installed for me, it's the one piece of the install I can take a little pride in 😁 I just need to still figure out why the system appears to throttle feed-in 🙄
Absolutely no idea whether the waveshare HAT has galvanic isolation (unfortunately I only have a very basic grasp of electronics, but I don't see anything that looks like an optocoupler on the board), but I've got it powered from mains (on the essentials output side). The TI looks interesting, but I really just went with what I could find that looked like I'd be able to hack to work, which I did (thankfully).
Thanks for the bit of advice when I bothered you via PM as well!