JO+e Posted September 30, 2019 Posted September 30, 2019 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. Ironman and francois 1 1 Quote
hancock Posted October 1, 2019 Posted October 1, 2019 This is interesting. Will be following this topic judiciously. Expecting my Pylontech batteries October ending. I have always liked the simplistic nature of the Venus CCGX interface on a pi. It just gives you a quick glance to all the important datas thanks for this Quote
___ Posted October 1, 2019 Posted October 1, 2019 12 hours ago, JO+e said: 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. Yeah... the author of that port figured including the overlays is a good idea, but left the actual implementation as an exercise for the tinkerer Otherwise, a very very nice summary of how to get it done. Just remember that many of the CAN hats don't have galvanic isolation. Be careful if you also power the Pi itself from the same battery. I far prefer the Texas Instruments ISO1550, it is very close to pin-compatible with the MCP2551 that is usually used, except the battery side of course needs to be powered. Quote
hancock Posted October 2, 2019 Posted October 2, 2019 on a second thought, having a BMV 712 battery monitor connected to the Pylontech batteries should be able to also give an accurate SOC? I already have the BVM, will be going this route. Quote
JO+e Posted October 9, 2019 Author Posted October 9, 2019 On 2019/10/01 at 9:43 AM, plonkster said: Yeah... the author of that port figured including the overlays is a good idea, but left the actual implementation as an exercise for the tinkerer 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 On 2019/10/01 at 9:43 AM, plonkster said: Just remember that many of the CAN hats don't have galvanic isolation. Be careful if you also power the Pi itself from the same battery. I far prefer the Texas Instruments ISO1550, it is very close to pin-compatible with the MCP2551 that is usually used, except the battery side of course needs to be powered. 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! Wilfred 1 Quote
___ Posted October 11, 2019 Posted October 11, 2019 On 2019/10/09 at 1:08 PM, JO+e said: powered from mains Then you should have nothing to worry about. Mains power supplies are by necessity isolated. Quote
Tim_Pylontech Posted October 21, 2022 Posted October 21, 2022 On 2019/09/30 at 9:21 PM, JO+e said: 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. Hi Jo+e, thanks a lot for your guide. It worked fine for me. My Setup is an Pi 4b and a Waveshare Board. I had to change the bottling to: dtoverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000 because of the 12M Chip. Then it worked. Great job! Quote
JO+e Posted October 21, 2022 Author Posted October 21, 2022 Hey Tim, glad it helped I recently set up a Pi Zero 2W with a Waveshare board for a trolley type backup system and actually found that there is a utility that can do the whole setup for you - I followed some other guide for the Pi and struggled getting comms to the battery until I can across the shell script which sorted things out. If I remember, I'll go looking for it again and post a link to it here which might be helpful to any future attempts. Quote
MarcoGER Posted November 6, 2022 Posted November 6, 2022 @Tim_Pylontech Can you send me the Pin connection from your Rpi4b to the RS485 Waveshare? Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.