This site is now in read-only archive mode. Please move all discussion, and create a new account at the new Victron Community site.
After installing Venus OS 2.92 on a Raspberry Pi 3B+ and installing the necessary software to support the waveshare single channel the interface was named NAME_PH and not can8 as expected. Except for the strange name the device is working correctly and is communicating with the Pylontech BMS
Hi It's also the case for me that the name I entered was not taken over. Is maybe a mistake. Thanks
I just renamed VeCanSetup.rules in /etc/udev/rules.d to VeCanSetup.rules.save to disable the udev rule for the spi0.0 and now it shows as can0 (still not the expected can8 but much better), I need to dig into the udev config to find the correct syntax for this to be named can8 as it should
Should be fixed now. VeCanSetup v3.3 just released. Just rerun the setup script after the package updates. A reinstall should be fine to update the name. If not, you'll need to redo the configuration.
i tried to update the package via package manager but the name was still wrong, then I removed and re-installed the package using the SetupHelper, still the service name is still NAME_PH and the interface name is DEVICE_PH, manually changing the rule manually to the content of the repository on github changed the name to NAME1_PH and DEVICE1_PH.
Hello Kevin
The problem with the name doesn't seem to be solved yet, does it?
I have the same name in it Name_PH
I suggest you delete the configuration from within VeCanSetup and add it back in.
Hello Kevin
User -> cbscpe write but what others see post before?
Hi That means I uninstall the VeCanSetup under the Venus GX interface, see picture, then restart the Venus OS and then I reinstall VeCanSetup using the Install button and then start the setup under SSH with the command (( /data/VeCanSetup/setup )) or Canbus interface? Thanks
Don’t need to uninstall the package. Just run the setup script, select install the replace the config for your interface
This is not OK or?
See you is this OK?
You are only allowed ONE hat. You must delete the existing one before you can add a new one.
Hi I did that, see the last picture at the bottom, is that correct?
Is it possible to test the CanBus or the CanHat module with a command or something, unfortunately I don't have a Pylontech US5000C yet, it hasn't been delivered yet! Can one assume that based on the picture showing the installation, everything is ok, i.e. the module is recognized etc. and is running?
You should see can8 in the Settings / Services menu if everything is set up properly.
Apparently candump doesn't see CANbus hat activity, or it may be that since I have no traffic candump simply has nothing to report.
Hello Kevin See You
THIS is also OK?
The Can8 is then found automatically or by the Pylontech?? Or how should I imagine that? Why is the can installed with can8 and not with can0 or something. Thanks
Hi may I disturb you? Why is the can installed with can8 and not with can0 or something? Does the whole thing now work for you according to the installation with the CanHat https://www.waveshare.com/rs485-can-hat.htm
The issue is that as of v2.90, Venus OS automatically detects USB-connected CANbus adapters and begins assigning them at can0. This will most likely conflict with can0 as used for a CANbus hat. The first one discovered will function, the next ones will not. Assigning hats to can 8 and 9 and USB CANbus adapters starting at can10 avoids any conflicts.
There is also a problem with dual-channel CANbus hats in that the channel to can port is random. Sometimes spi0 connects to can0 and sometimes it connects to can1.
VeCanSetup also allows naming the ports to avoid confusion when there is more than one CANbus port.
With USB-connected CANbus adapters, you can probably do without VeCanSetup and let Venus OS automatically configure them. (Scan-based interfaces are not supported with auto configuration and are not recommended since they can drop packets.)
Without VeCanSetup, you would need to manually install the overlay calls in /u-boot/config.txt and optionally manually create rules to fix spi0 to can0, etc. But that is certainly an option and your only choice if you really want your interface on can0.
Hello Kevin
Thanks now I understand with can8 why that is! I have the Waveshare CanHat module 12000Mhz Crystal see picture. So there are no problems anyway, as I said, everything is recognized, etc. see my screenshots above.
There shouldn't be any problems with the Pylontech and BMS
Thanks
Be careful to remove the solded Terminator from the Waveshare CAN Hat if your Bus is already terminated!
It is labeled as 120 ohms and sits near the can-connector.
This is strange, I upgraded to Venus OS 2.93 which put a new VeCanSetup.rules in udev rules and then the device name was again set to NAME_PH. So I decided to re-install the VeCanSetup, but to my surprise after uninstalling the package the CAN Bus interface was still there, now named CAN0 and the Battery was immediately detected. Any idea what happened here?
The weird name was a problem a long time back due to a bug in VeCanSetup. You need to make sure the latest VeCanSetup is installed then run it's setup script from the command line, delete the configuration and reenter it.
As of v2.9-something, Victron included automatic configuration of USB CANbus ports (other than slcan). So VeCanSetup is optional now. VeCanSetup provides port naming and insures CANbus ports are always attached to the same interface. It is also needed for CANbus hats on Raspberry PI platform.
