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

Feature Requests
1

Dear community,
dear developers,

I’d really like to see support for real CAN bus devices like USB-to-CAN dongles.

Why CAN bus?
CAN bus has become very popular not only in vehicles. Also industry plants and machines communicate via CAN bus.
The following points make it really interesting for “private” use and also for domotic / home automation applications:

  • well known, lots of documentation
  • easy to understand/use
  • cheap
  • robust
  • broadly available
  • flexible

From home automation view, the bus is easy to install and there is no need for WiFi stuff, which in turn improves security and peace of mind. It will still work even of the WiFi router crashes and the user can always physically access the bus to see whats going.

“Big players” in that field (like Ixxat or PEAK) provide drivers and APIs. Linux brings the popular package of drivers “socketcan”. There is also a python library called “python-can”, which could be useful for a potential integration.

When thinking about “conventional” CAN (not CANopen), we could work with a similar approach as with MQTT:
while we have “topics” in MQTT, we could use “identifiers” with CAN bus to filter messages to where they belong.
The MQTT “payload” is the “data field” in the CAN frame.

In fact I already have a system running, consisting of 8 window covers (including position), light swithes (including feedback), servaral IOs and sensors completely based on CAN bus. But to integrate this into my HA, I had to additionally create a CAN-to-MQTT gateway (based on a ESP8266), which translates the MQTT topic into a CAN ID and the MQTT payload into the CAN bus data field - and vice-versa!
This works.
But obviously it is a little bit odd to take this indirect route through the WiFi network - a USB-to-CAN dongle is about 100 bucks (big-brand) or much less like 30-50 bucks (see devices like this HERE), with native Linux support - which in return gives you a true industry standard bus with all advantages mentioned above.

I personally am familiar with CAN bus, but not with Linux programming and with HA development. I am very willing to help, if I “can” :wink: .

What do you think?

Greetings,
Joachim

2

Hi,
i have now a live canbus system in my HA
i used an ESP8266 with MCP2515

there is an active PR going , you can already load it as dev

and for doc and wiring :

3

i also bought that canable.io , but its much cheaper on ali
would be cool if i could use it too instead of esphome

4

Hi Fabio,

yes basically the canable-device is what I was asking for to be supported by HA. With the correct firmware it appears as a native CAN bus device on the USB host. So from this point on it does not matter if it is canable, ixxat, peak, whatever…
Your effort about esphome+MCP2515 is really impressing and very similar to what I’ve set up here. But the native CAN bus support would still be the better solution and less “hacky” and more sustainable…

5

yeah, offcourse, i like the idea of using a canable.io

i bougth that, but not using it yet … now using the esphome for a few weeks

my domotics is a closed system, i i am now reading the canbus to control my lights and power plugs
now i can also use my wall switches to turn on services in HA :slight_smile:

but i want to use the canable in a final stage, no diy shit :slight_smile:

6

whay do you have setup anyway ?

7

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 :slight_smile: .

8

But again:
although this works, I am dependent on my WiFi network (or network in general).
It seems too odd to my to be able to set my domotic system nonoperational only by switching off my router…

9

Yeah, you have the same exact setup as me, also using it for roller, blinds, switch, plugs…

Yeas ,we are wifi independent, that’s why indeed want an usb option too

10

Are you also using the mcp2515?

11

Exactly same for me. USB-to-CAN is very cheap, universal and reliable. Even when your domotic master device crashes, you can still access the bus physically to check whats going on or to control it. Thats why I am really hoping for a native CAN bus integration to not be forced to take the route through the (wireless) LAN…

12

Yes, a Wemos D1 board (form factor as a Arduino Uno) together with a Seeed Can bus shield.

13

Ok, well esphome is already a nice step forward, I am using yaml now for my can id’s

14

Thats definitely true. Sadly I have not much experiences with esphome due to just a lack of time. There are so many systems out there (esphome, tasmota, espeasy…) with their specific advantages and disadvantages. So sometimes it is hard to follow up :wink: .

15

esphome is VERRY easy, much easier then your setup , for sure !

here is an example how i turn on a service in HA when i recieve a can message …

canbus:
  - platform: mcp2515
    id: my_mcp2515
    spi_id: McpSpi
    cs_pin: GPIO14
    can_id: 4
    on_frame:
    - can_id: 0x100ff00
      use_extended_id: true
      then:
        - if:
            condition:
              lambda: 'return x[1] == 0x57 and x[2] == 0x03 and x[3] == 0x01;'
            then:
            - homeassistant.service:
                service: light.toggle
                data:
                  entity_id: light.led_badkamer

### example canbus data:

# [13:55:13][D][canbus:062]: received can message ext can_id=0x100ff00 size=4
# [13:55:13][V][canbus:071]:   can_message.data[0]=0e
# [13:55:13][V][canbus:071]:   can_message.data[1]=57
# [13:55:13][V][canbus:071]:   can_message.data[2]=03
# [13:55:13][V][canbus:071]:   can_message.data[3]=01

yes , thats it… :slight_smile:

16

Oh… okay… that indeed looks quite easy. When I have time I can try to switch over. I will let you know :slight_smile: . Thanks for sharing!

17

Np, anyway, the canable is still the best approach…

Or maybe , isn’t it possible to hookup the Wemos or nodemcu by usb and read/write the serial connection ?

18

maybe @danielschramm can help us out, he also did the PR’s and development for the ESPHome
If he has time, he can maybe make somekind component/integration

19

For this, the ESP would not be (necessarily) needed. Your canable’s firmware can appear as a virtual serial device.
For other devices, it should be possible to implement the “Serial Line CAN” protocol (http://www.can232.com/docs/canusb_manual.pdf)
But: afaik there can only be one serial sensor in HA to access a serial interface. I thought about this approach as well, but it still is a workaround - and not even a good one. So I decided to not go for slcan.

20

Yeah, why not? Are you already in contact with him? I personally have no experiences in this kind of programming :frowning: .

My approach would be to integrate CAN basically similar to MQTT (as described in my opening post). But I have no clue if this is the best approach and also how difficult this is.