The board from your link is a normal MCP2515 board. There are no RX/TX pins.
If you are referring to the CAN bus driver itself, it has some kind of “RX/TX” pins, which are usually wired to either a stand-alone CAN bus controller (like the MCP2515) or a microcontroller with integrated CAN module.
Thats why I switched over to the STM32F103 or STM32F303 microcontrollers instead of Arduinos, because the have exactly that integrated CAN module, so I only need the bus driver IC.
Yes , link is confusing , you see pictures about mcp2515…
But i mean this board : https://www.waveshare.com/sn65hvd230-can-board.htm
ahhhh… I see 
. This is basically just the transceiver (bus driver). As said, that one alone requires either a stand-alone CAN bus controller (like the MCP2515) or a microcontroller with integrated CAN module.
Have a look at the MCP2515 board. There is another IC on it, which is the entire transceiver. But it is surely the TJA1050 or the MCP2551. So the SNHVD230 alone is quite useless without an “intelligent” CAN controller.
ah ok, clear!
mayeb usefull for others with HassOS, i created an PR , its approved and merged now, to support canbus on HassOS system, in next release of HassOS, kernel will be compiled to support this hardware : canable + peak => drivers to can be loaded gs_usb (candlelight) / slcan / vcan / peak
that will be sufficient for now
Very good! This is the first and essential step for HassOS 
!
At a first glace at your PR, I saw “slcan” -> I am not familiar with the relationships, but this should be only one part of the drivers to include. But from your description I think you are aware of this.
https://www.kernel.org/doc/html/latest/networking/can.html#can-network-drivers
yeah, slcan is somekind of firmware used for canable for example
but i think if its merged, il will use the candlelight firmware , makes it easier to bring the can0 interface up, dont need to mount it anymore from the USB
indeed first step, that way i can work with it too on a HassOS system
and indeed , first i only added vcan and slcan, but later i added more : to also include Peak and Candlelight
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_VCAN=m
CONFIG_CAN_SLCAN=m
CONFIG_CAN_DEV=m
CONFIG_CAN_GS_USB=m
CONFIG_CAN_PEAK_USB=m
i am struggling to add the can-utils as a package with bash script , seems the “apk add can-utils” command doesnt work in hassio container, while it works with in ssh
to bring up the interface i need the “slcand” tool, thats part of “can-utils”
to install it with a custom component, we can add it with a requirement, but i cant find “can-utils” as a package on Pypi, i am not sure of “cantools” is the equivalent for python, that includes slcan
EDIT: just installed cantools, but slcand is not part of the toolset
so i dont know how to install slcand , so its sticky after a core update
anyway, i can also use candlelight , then i dont need slcand anyway , and dont need tools at all
or alternative is making a add-on, but thats an overkill
slcand vs candlelight (to make can0 up)
#slcand :
sudo slcand -o -c -s0 /dev/ttyACM0 can0
sudo ifconfig can0 up
sudo ifconfig can0 txqueuelen 1000
or
#candlelight:
ip link set can0 up type can bitrate 500000
Why do you need slcand? Are you for some reason bound to serial communication scheme? I personally don’t like slcan that much, because of its overhead and I personally have never seen any application for slcan 
.
But great job so far.
I hope I will find some free time to get in touch with some developers to implement a new component in HA. I read everywhere, that it is so simple. So I have no regrets 
…
yes, slcan is needed to bring up the interface, but i have found a way now to install can-utils , gonna test it later
but i have now installed candlelight firmware, then there is no can-utils needed, just with 1 command “ip link” i can bring up the interface , the stick is recognized with the “gs_usb” driver in kernel as native
for sland you need to mount the ttyusb device to can0 , thats why slcand is needed
Ok firgured it out why can-utils didn’t install, seems the Hassio docker is running alpine 3.12, and can-utits is part of 3.13… that’s why it succeeded with the ssh add-on (based on 3.13) , and not on base Hassio docker (based on 3.12)…
So if I first download the apk package local, then do an apk add command , then it succeeds… So this approach can be used for guys who need slcand…
But i think I am going to use the alternative candlelight firmware, then there is no extra tool needed to bring up the can0 interface…
Thnx for tip @xtra !
Anyway @Jojo-A , what interface do you use? What do you need todo to bring up interface?
I am going to wait now for next HassOs release untill my PR is merged, i need to wait for a beta / rc release to update my HassOS , cause I don’t know how I can upgrade to an development release of HassOS
Unless someone starts a custom component, maybe we can work together on it, then i am going to setup a nother test instance
@pergola.fabio
currently I use a USB-to-CAN interface from PEAK. On Linux Mint (Ubuntu) no extra drivers needed and working ootb.
Do bring up the interface, I just followed the link above/below:
https://python-can.readthedocs.io/en/master/interfaces/socketcan.html#pcan
I started creating a custom component and currently I stick to the approach to have a dedicated CAN platform which can be chosen as “platform” when creating a new sensor component - more or less as I described here:
But I am totally stuck because I have zero python programming skills, so I currently don’t understand how to interact with the python-can library.
Because of this I dropped a PM to @OpenJeDi if he is willing to assist me in this. I try to do as much as possible by myself. But with zero knowledge, this is pretty hard…
Next month I will order a canable-adapter (china clone) to have similar testing conditions as you in addition to my PEAK adapter.
Python is not that difficult , but if indeed if @OpenJeDi could give us a a start, i am sure we can complete it :+)
Don’t think you need to buy that canable, it’s the same process as canable to bring up the interface (candlelight) , i also bought mine on Aliexpress
…
Allthough i forgot maybe to add the peak_pci in the PR, i only added peak_usb , are both needed?
(CONFIG_CAN_PEAK_PCI=m)
Buts that’s only for HassOs users anyway, we can add later if someone needs it
About python:
yes, I agree that it is basically not that difficult. But I am coming from the Embedded C world. So the programming style is very different in many ways. So currently there is just the knowledge foundation missing. If the foundation is there, the progress would be much more fluent 
.
About PEAK_PCI:
well, of course it “might be”, that someone uses this kind of adapter. But regarding HassOS, I think it will be not necessary to be added. HassOS is (mainly) targeting SBCs, which usually don’t have a PCI interface. So the scenario of HassOS + PEAK-PCI would be very rare. So if needed, it can be added later. But currently I don’t think that it will be needed…
First local addon is up and running, see below, canbus.py , didnt post yet, still testing with it, i am already reading messages, thats working, now testing with some rest api calls…
that host_network, priviliged, kernel_modules, is needed to bring up the hardware in the container
also in run.sh, you see i bring down the can0 interface first, while testing and a lot of restarts of the add-on, it was more stable to bring it first down , when it was already up after a restart of the container
ARG BUILD_FROM
FROM $BUILD_FROM
ENV LANG C.UTF-8
RUN apk add --no-cache python3 py3-pip
RUN pip install python-can
COPY run.sh /
COPY canbus.py /
RUN chmod a+x /run.sh
CMD [ "/run.sh" ]
#!/usr/bin/with-contenv bashio
lsmod
ifconfig -a | grep can0
ip link set can0 down
ip link set can0 up
ip link | grep can0
python3 canbus.py
{
"name": "Dobiss CAN",
"version": "3",
"slug": "dobiss",
"description": "Doobiss CAN system",
"startup": "application",
"arch": ["aarch64", "amd64", "armhf", "armv7", "i386"],
"kernel_modules": false,
"host_network": true,
"privileged": ["NET_ADMIN"],
"homeassistant_api": true,
"hassio_api": true,
"options": {},
"schema": {}
}
here is already some dirty code that i can use to make REST api calls , based on a canbus message, in this example , when i see this message : “01 45 01 00” , i toggle a input_boolean.test1
@tvds , you can use this already , or extend the switcher with 3 variables… now my third variable is fixed to “toggle” ,we can make it like “toggle” , “turn_on” , "turn_“off”, and use this 3th one in the url
import can
import json
from requests import post
def can_message(argument):
switcher = {
'01 45 01 00': "input_boolean.test1",
'01 45 08 00': "input_boolean.test3",
'01 45 09 00': "input_boolean.test2",
}
return switcher.get(data)
## REST API auth
headers = {
'Authorization': 'Bearer xxxxx',
'content-type': 'application/json',
}
## CAN BUS
bus = can.interface.Bus(bustype='socketcan', channel='can0', bitrate=125000)
while True:
message = bus.recv()
#data = "[{}]".format(message.dlc)
data = ""
for i in range(0,message.dlc):
data += " {:02X}".format(message.data[i])
data = str(data.strip())
print ("Canbusdata: " + data)
#print ("Switcher result: " + str(can_message(data)))
if can_message(data) is not None:
api = str(can_message(data)).split(".")
url = "http://localhost:8123/api/services/" + api[0] + "/toggle"
data_json = {"entity_id": api[0] + "." + api[1]}
#print(str(url) + " --- " + str(data_json))
response = post(url, headers=headers, data=json.dumps(data_json))
print(response.text)
final step is better handling for the bus to bring up/down, want todo it in python itself, i sometime have timeouts when bringing up after many restarts , then the add-on fails to start offcourse
EDIT :
for now changed = >
ip link set can0 up type can bitrate 125000
to
ip link set can0 up
so also removed iproute2 from the APK packages , seems iproute2 is not that stable, iproute2 was not needed to set bitrate, but this is not needed also, since bitrate is configured in python
Sorry guys for not stopping by for some time… 
.
I have been busy in my “real life” and could not spend time for other things…
Your progress looks amazing 
! Am must confess that I am a little bit embarrassed that you progress straight forward while I am just stuck.
Could you explain very basically your workflow? For comparison:
I just followed the workflow HERE what brought me to the point where Python programming skills are needed (but missing). So I have a canbus.py for my new platform, a new sensor.py for my new component (based on the canbus platform) and the manifest -> more or less the usual development workflow.
BUT: your progress seems to be much more mature. At least you have much more code 
. Are you still following the approach with the REST API or what is the current status?
Greetings
!