Support for CAN Bus (Peak, Ixxat, canable etc)

Jojo-A · January 3, 2022, 3:33pm

Yes, hardware is not a big deal for CAN bus. IIRC there is even the possibility to connect a Standalone-CAN-Shield to the RPi (to the SPI pins) and it will appear as a native CAN interface on the RPi.
Your confusion about where to start might lead from the fact, that there is no “physical” bus master in a CAN bus network. Each node can drop a message to the bus which will then be received by all other nodes (ID filters are currently not in scope ).
So you can define the “logical” master by yourself - in most cases this is a PC or some kind of PLC with a CAN interface/dongle. In our case the master could be the system where HA is running on. BUT REMEMBER: there is currently NO native CAN bus support implemented in HA! That’s why we started this thread.

A step-by-step guide is not that easy. Either a device manufacturer uses a “standard” higher-level protocol (like CANopen) or he defines his own “protocol”.
In both cases it all comes down to two things: which identifier is used and what is the message content.
Example (from my current system): I went for a CAN communication that is close to CANopen. That means that I have two types messages:

so called SDOs, which I use to drop commands from my “master” to the nodes
so called PDOs which I use for my nodes to publish their process data / status information

My previous setup was similar. But I did not stick to the CANopen scheme with SDOs and PDOs. I just defined the IDs for each message by myself.
Example:

ID 0x100[n] contains temperature data, sent periodically from each node [1…n] to the master
ID 0x200[n] contains position data, sent periodically from each node [1…n] to the master
ID 0x110[n] contains positioning commands, sent from the master to the specific node [1…n]
…

But again: there is currently NO native CAN bus support implemented in HA! This means that everything regarding CAN bus will require programming by … well… you. Of course there are many “easy-to-use” projects out there for Arduino + CAN-bus-shield. But you will have to program the nodes behavior by yourself (because there are very rare CAN devices for home automation).
If you are willing (or actually able) to do the programming part I am very sure that you will get a CAN-based system running - it is not that hard. But without any programming skills it will be just harder .

Jpsy · January 4, 2022, 10:46am

Hi Matt,

I think your research would best be placed in its own topic in this forum. As @Jojo-A rightfully said it does not make sense to pollute this feature request with discussions about the optimum system for you to use.

You may leave a link here to your new topic once you created it. If you have specific questions re KNX you are also welcome to post them as comments to the KNX Cookbook guide in this forum.

This being said, I think that another option for you would be HA with ESPHome microcontroller nodes as user interfaces, sensors and actors. They can communicate based on WiFi. But if you wan’t them wired instead of WLAN based, this is also easily possible by using standard CAT-7 cabling with POE (Power-over-Ethernet) power supply. The only thing you have to decide now is the kind of cabling that you put into your walls. This will be very different for CAN, KNX and IP based systems. Different in terms of cable type and in terms of topology (line vs. star vs. mesh …). Everything else can be changed and improved later but the cabling is close to impossible to change once your house is built.

But as said: Better open up a dedicated thread for discussion.

aerodolphin · January 6, 2022, 1:48am

Jojo-A:

Basic idea (or more my personal strict rule) was to have everything running independent from the domotics system, so my domotic system is build “on top” of the hardwired stuff and acts as “alternative triggers” on parallel to the physical switches/buttons.

Actually my setup consists of one big cabinet where the following thing come together:

electric roller shutters for eight windows

reed contacts for eight windows

physical up/down switches for eight windows

lights for eight places

physical buttons for eight lights
The heart of that cabinet is just an STM32F103 dev board with a CAN bus transceiver plus a bunch of I2C port expanders.

Now the control cabinet acts as a client on the CAN bus: different CAN IDs are used to perform different actions. Example:

ID 0x0101 sets the target position for window 1

ID 0x0101 RTR triggers the client to publish position of window 1

ID 0x0102 sets the target position for window 2

ID 0x0101 RTR triggers the client to publish position of window 2

…

ID 0x0201 toggles light of place 1

… and so on and much more

Every item (light, sensors, covers…) are set up as MQTT components in HA.
Now the MQTT-to-CAN gateway comes in: it converts the MQTT topic into the CAN bus ID and than the MQTT payload into the CAN bus data field - and vice-versa.
So HA sends something like “mqtt-to-can/0x0101/set/50” (set target position for window cover 1 to 50%), the gateway converts that into a CAN data message with the ID 0x0101 with one byte of data (50).
In return, the cabinet answers via CAN with the actual cover position on ID 0x0101. The gateway converts the CAN message into a MQTT message “mqtt-to-can/0x0101/state/60”, “mqtt-to-can/0x0101/state/55”, and so on.

When I have everything set up “pretty” enough, I will publish it here more in detail

Let me see if I understood.
Now you have in a cabinet a device [STM32F103 Dev Board with CAN bus transceiver and some IO port expanders] acting like one can bus client? And connected to that device you have electric roller shutters, door sensors, physical switches, lights, etc? And the CAN bus is connected with HA by a CAN-TO-MQTT Gateway based on ESP8266 device + MCP2515 via Wifi network. This gateway is running ESPHome or other code?

In that case If we press one physical switch, that system alone can tun on a light, so, it means that it’s not HA dependent, right? But the CAN message of that switch is sent to the CAN bus? And can be received by any connected device, including the gateway? This means you have a very specific software on the STM32F103 dev board?

Please tell me if can be done this way. Have a CAN bus client (ESP Home, ESP8266, STM32F103, etc), called ROOM-HUB, per room with all sensors, switches, roller shutters connected to the him?And connect all ROOM-HUBs to the same CAN bus and then have the CAN-to-MQTT gateway or in future the USB-to-CAN dongle?

That ROOM-HUB (CAN bus client) can be an ESPhome device?

I’m thinking on this concept:

Do you think will work? This way I can develop dome devices that are CAN nodes with several things connected to each one.

Jojo-A · January 7, 2022, 5:51pm

Basically yes !
My CAN bus system is set up in a way that each node can still fulfill its purpose even without HA. Means That I can still open and close my window shutters even without any network at all . This way and is crucial for me - no exceptions (at least for the really important stuff like lights, windows and so on).
My HA instance is “just” the frontend to display data and to drop control commands. And as you correctly understood, this is actually done through my MQTT-to-CAN gateway (ESP8266+MCP2515) with own code.
And also correct is, that one could also use an USB-to-CAN dongle for that and a PC to process all the CAN traffic stuff). And at this point I wish that HA would natively support CAN devices so that we won’t need a detour over MQTT and ethernet/WiFi.
A possible HA component could then listen to a specific CAN ID instead of a MQTT topic.

The picture you’ve drawn is totally possible with CAN bus. No problem at all. Not with basic CAN nor with CANopen. The only drawback will be that you would have to write most of the node’s code by yourself (what I also do).
When I have time I could try to create a similar picture of my setup as well, just for clarification and documentation .

aerodolphin · January 7, 2022, 6:08pm

Talking about what is working today, your MQTT-to-CAN gateway can work by ethernet instead of wifi? Can you share the code?

pergola.fabio · January 7, 2022, 7:02pm

Hi, there is a can2usb support, that PR was a long time ago submitted in HassOS

I wrote an custom script to load the dongle and listen for traffic, I update my sensor, based on that traffic…
With shellcommand, with cansend, I send stuff to the bus

Jojo-A · January 7, 2022, 8:00pm

Yeah, but IIRC the PR was only about the integration of the basic linux CAN driver module, right?

I think both our approaches are kind of “so far, so good”, where your PR was surely the first step into the right direction.

pergola.fabio · January 7, 2022, 8:22pm

I think I included 5 drivers , don’t remember anymore

But you always add more

Jojo-A · January 7, 2022, 9:05pm

As discussed on Discord, I had it working both on an ESP8266 with WiFi as well as on an Arduino Uno with an ethernet shield. The MQTT libraries and the code for translating the messages forth and back was identical.

If I find the code and manage to tidy it up a little bit I can share it via github.

aerodolphin · January 10, 2022, 1:54pm

Thanks a lot @Jojo-A

What is the hardware you are using to control the roller shutters? Any two relay board with snubber filter? I’m looking for something like Shelly 2.5 but wired (without wifi).

Jojo-A · January 11, 2022, 8:56pm

At the beginning I planned to use these very wide spread dirty-cheap relay modules as they can be found on Aliexpress and so on (two-channel because one channel for up and one for down).
But I was not happy with the fact that I design an own board but have to add another cheap-a** chinese module to it. So meanwhile I think I will design the relays directly into my node board. Doing so, I can either solder the relay directly onto my board or I can use a relay socket so that I could exchange the relays later on (if necessary).
As snubbers I will use premade modules (R+C+Varistor) which I will solder directly on my board.

gavindjharper · April 30, 2022, 7:59pm

Hey -
I have a boiler system which has a CAN interface which is used with a proprietary standard.
I want to read out everything on Home Assistant and possible alter variables e.t.c.

The manufacturers Estyma, also do some really nice cheap boiler controls, and whilst I was originally planning to implement controls in KNX, if I could talk to their CAN system using Home Assistant, I’d be tempted to use their CAN bits, which are really good value.

I have seen the following CAN gateway…
https://www.systec-electronic.com/en/products/interfaces-gateways-amp-controls/sysworxx-can-ethernet-gateway-v2

Obviously there are cheaper ways out of this with homebrew stuff, but this is an off-the-shelf robust solution, and time is also a factor…

There are a couple of homebrew projects, where they have written Python code to build devices that will interface with the CAN code of the boiler controls… I think I am probably out of my depth and it would be worth trying to find someone to pay to write something to take the output from the boiler and translate it into home assistant usable form, but the fact that someone has reverse engineered the protocol, or obtained it, as it is proprietary and is using it in another project gives me hope that it can be done, even if I don’t quite have the skills to do it:

Kematics Pelle project looks promising…

github.com

kematic/pelle/blob/4a388b674f5f9ab9c0a0cde2b18ec7e694c2be4f/canparser.py

# 1 SOF
# 11 ID
# 1 RTR
# 1 IDE
# 1 r0
# 4 DLC (number of bytes)
# 0-64 DATA
# 15 CRC
# 1 delimiter
# 1 ACK
# 1 delimiter
# 7 EOF
from datetime import *
from collections import defaultdict

module = defaultdict(lambda: defaultdict())


def map_can(node_id, data):
    hex_id = hex(node_id)

This file has been truncated. show original

The project has a good Wiki on the CAN protocol:

Another project here:

Any idea where to start on this! Anyone interested in taking it on as a job?

RubenKelevra · May 1, 2022, 1:03am

Hm instead of integrating an USB adapter-support into HA, why not improve the ESPHome module for the ESP32 - which got CAN-support build into the SoC?

ESPHome can already talk to HA via it’s API which avoids writing an extension for HA, as it would be readily supported as a device.

Jpsy · May 1, 2022, 6:41am

I think this is a good approach. ESPHome already talks CAN. I have a setup like this running for our car. Works nicely. Even if you want to use CAN as your home automation bus, this is a great solution. You don’t have to connect your bus wire physically to your Home Assistant hardware. Instead you use an ESP as a bridge and put it wherever your bus is accessible. You can even create multiple bus lines that are not directly connected (i.e. in different parts of the house). The needed hardware is extremely cheap.

Jojo-A · May 2, 2022, 8:02am

Hm, on the one hand I agree with you because of exactly the arguments you mentioned.

On the other hand: what do one expect from HA? If we say that the (physical) interface support should happen on totally independent external projects (like ESPhome), HA will only be a frontend with an API.
I think this should not be the claim of HA - it already supports interfaces natively (Serial, Modbus). Why not CAN bus as well? Most stuff (arbitration, error handling, etc…) is handled by the Linux driver or by the python-can library. So on HA side it would be “only” ID and data handling.

I know that HA can not support every manufacturer-specific interface OOTB/natively. But CAN bus is kind of standard like Modbus.
Other thing to be taken into account then relaying on “external” projects:

the user has to take additional steps to get it working (set up an ESP-board, including programming, soldering…)
problems can be either on HA-side or an the other side (ESPhome). So where to report? Who will be willing to help?
what if a community-driven project like ESPhome is canceled?
when HA develops to be only a frontend for external integrations, HA won’t be able to run in a stand-alone environment.

@Jpsy I agree with your points! These points are definitely one of the advantages when one wants to de-centralize a system.
But my concerns from above will still remain. And it looks to me as if this becomes more a political as a technical decision

Greetings!

Hedda · August 24, 2022, 7:55pm

Just read about the ”WiCAN” crowdfunding campaign from MeatPi Electronics on Crowd Supply for an an open source ESP32-C3 based CAN adapters with either USB or OBD-II/OBD2 in (addition to Wi-Fi and BLE support) which made me want to request for an integration based on python-can or similar?

https://www.crowdsupply.com/meatpi-electronics/wican/updates/our-campaign-is-now-live-on-crowd-supply

https://github.com/meatpiHQ/wican-fw

Hedda · August 25, 2022, 6:27am

WiCAN currently supports three protocols; ReadDash, slcand, and saavycan GVRET Binary Protocol available for third-party integrations;

github.com/meatpiHQ/wican-fw

Some Questions

opened 12:04PM - 18 May 22 UTC

mickeyl

Congratulations for releasing the interface and the software! Having just pur…chased the WiCAN (which should be shipping soon), I wonder about some things – perhaps you can clarify. 1.) What is "the native" protocol on the TCP socket? Right now it looks like "realdash" and "saavycan" protocols are implemented – guessing that the former refers to https://github.com/janimm/RealDash-extras/blob/master/RealDash-CAN/realdash-can-protocol.md, could you point me to a documentation for the saavycan protocol? 2.) Is the current firmware implementing ISOTP on the controller level, so that we can send the full 4095 bytes of payload in one go? 3.) Can we configure the CAN bitrates through the API? For the use with arbitrary vehicles, it would be a pity, if customers would have to edit the settings via web. 4.) Is there any documentation beyond the https://github.com/meatpiHQ/programming_examples/tree/master/CAN – which seems to refer to VSCAN API. Is this the same API that slcand speaks? 5.) Does the device support BLE5 queued writes? 6.) Are all the supported protocols active _in parallel_? Thanks a lot. Looking forward to working with the device.

github.com

collin80/M2RET/blob/ad9d5af67d8e7c3330c0281e0403c2750e023f1c/CommProtocol.txt

GVRET Binary Protocol:

0xE7 enables binary sending of incoming frames. Prior to this command it is configurable whether incoming
frames will be output as ascii or binary. Once 0xE7 is seen while IDLE the comm will be binary. However, any time
a binary command is not in process one can use the text based console. As such, it is possible to turn off binary sending
mode from the console even if it has been enabled by the 0xE7 command.

0xF1 character signifies the beginning of a binary mode command. After this byte is processed the firmware will be looking for
command data in binary mode. The response to a command (if applicable) is 0xF1 followed by the command byte being responded
to, followed by response. SO, basically it's the same data sent to it plus any relevant replies.

Binary mode command byte:
0 - Send a frame out one of the buses
1 - Time Sync - Output the current time since start up in microseconds
2 - Get state of digital input pins
3 - Get state of analog input pins
4 - Set state of digital outputs
5 - Set CAN bus configuration
6 - Get CAN bus config
7 - Get device info

This file has been truncated. show original

github.com

janimm/RealDash-extras/blob/c5028e5f8785402179e56fb92a81a39fe45c07e6/RealDash-CAN/realdash-can-protocol.md

&nbsp;
# **RealDash CAN protocol**

The *RealDash CAN* protocol was designed to easily connect to existing CAN network and transfer the data to RealDash. However, this protocol can also be used with custom and DIY devices.

A single *RealDash CAN* frame uses 8 byte header that specifies the frame identification tag, and CAN frame ID number. The header is followed by frame payload data, and on some frame types the CRC check value.

Three different frame types can be received by RealDash. In all frame types, first 4 bytes identify the frame type. This *tag* is also required for RealDash to 'catch-up' and synchronize on ongoing stream of protocol data.

Each frame payload can contain *any data* in *any arrangement/format*. How data is arranged and how RealDash interprets it is described in XML file that is imported to RealDash connection settings. The RealDash CAN XML description file is explained in detail [here](./realdash-can-description-file.md).


&nbsp;
## **The CAN *44* frame**

The *44* frame is a simple, constant size frame that contains 8 byte header and 8 bytes of payload data. Name *44* is from first header byte *0x44* that identifies the frame. This frame type allows easily pass CAN device data to RealDash, just by setting the header and copying the 8 CAN frame bytes.

    RealDash CAN '44' frame:
    4 bytes - 0x44,0x33,0x22,0x11
    4 bytes - CAN frame id number (32bit little endian value)

This file has been truncated. show original

flix-one · November 30, 2022, 2:53pm

I started investigating into the topic of CAN-bus as part of my home automation and think the idea is still great.
I bought a Canable USB-to-CAN from Aliexpress and flashed the original firmware from canable.io → Candlelight, so gs-usb onto it.
When connecting it to a spare raspberry pi with raspbian, I see the interface with ip link list, but in Home Assistant (running with Home-Assistant OS on another raspberry pi), I can’t see the interface.
I thought after your PR, that all the modprobes are activated or do I miss something here?

What is needed to get the canable running on Home Assistant OS?
Do I have to activate some additional drivers? If yes, where to put the configs?

I hope this topic is still being worked on, as I think the option to have Home Assistant with CAN bus is really interesting, especially as an alternative to KNX.
As far as I’ve done my research, there is no real “wired” alternative to KNX available, which is a possibility for further USP.

pergola.fabio · November 30, 2022, 2:58pm

Hi, no the PR was only to include the driver support for different type of can adapters
You still need to modprobe it…
I do it in a python script that i load with a custom component, you can do it for example in an automation on startup HA

i use this in my .py file:

subprocess.call(['modprobe', 'can'])
subprocess.call(['modprobe', 'can_raw'])
subprocess.call(['modprobe', 'slcan'])

os.system("apk add /config/python_scripts/canutils.apk")
os.system("slcand -o -c -s4 /dev/ttyACM0 can0")
os.system("ifconfig can0 txqueuelen 1000")
os.system("ifconfig can0 up")

Btw, i use SLCAN firmware on it, i had better experience with it
if you use candlelight firmware, then i dont think you need to use the slcand/ifconfig commands, but i believe you still need to modprobe it

pergola.fabio · November 30, 2022, 3:01pm

you also see i do the canutils.apk manually, i do for tools like candump, cansend etc…
seems canutils is not part of the edge alpine main repo, only from the community

grab it from here:
https://pkgs.alpinelinux.org/packages?name=can-utils&branch=edge&repo=community&arch=&maintainer=

and

https://dl-cdn.alpinelinux.org/alpine/latest-stable/community/