Canopen (Can bus) for home automation, a good idea or not?

Hardware
21

combined
combined2710×1236 721 KB

1 Like
22

hi @hpopols

are you using this USB stick? https://canable.io/
how to get that to work with HA
i am running HassOS, is there a way to read data from it?

or someone else has an alternative? maybe with MCP2515 ?

23

Hi,
I personally am really convinced about using CAN bus (CANopen or conventional CAN) for home automation. Maybe you like to take a look or join my thread here:

It is about to integrate native CAN bus support into HA. From my point of view it would be really nice to have a native support for a real (industry) standard bus, similar to modbus (while “Modbus” does not really specify the bus but more a kind of protocol).
For my system at home, I have made all “clients” as CAN devices. But to communicate with HA, I’ve built a MQTT-to-CAN gateway (based on a ESP8266). But this seems to be more a workaround, because CAN is not supported by HA.
Sure, MQTT is easier to set up for less experienced users. But when it comes to safety and reliability, it is obvious, that one can not relay on (WiFi) network stuff

What do you think?

Greetings,
Joachim

1 Like
24

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 :

2 Likes
25

Hi,

What actual sensors/actuators do you have on your CAN bus? Are they also DIY’d or does someone manufacture ready-to-use devices?

Best,
BarnabĂĄs

26

Hello BarnabĂĄs,

my current status is, that I use exclusively DIY CAN bus devices. Thats clear, because there is no CAN bus support in HA yet, so all stuff regarding CAN bus must also be DIY.
If (and I mean only just in case) there will be CAN bus support in the future, it will surely be very basic - at least in the first stage.
The only “ready-to-use” devices that I know, use higher-level-protocols like CANopen, which is even more far away from being implemented in HA.

So short answer: only DIY stuff, no ready-to-use stuff.

Greetings!

1 Like
27

Hello Jojo,

Right now I’m looking at rolling something simple of my own using the LPC11C24. It even has some CANOpen drivers in-ROM.
However, if there were something tried-and-tested, it would make me happier.

What ready-to-use devices do you know of?
May I ask if you have open-sourced anything of your devices? If not, could you please share some basic info about them?

Thanks!

1 Like
28

I know that there is industrial stuff out there like flow meters, temperature sensors, etc that bring a CANopen interface. But right now I don’t have a device number in my head, sry.

I have not published anything, yet, because it is not “ready enough” to be published. But the way I did it until now was very easy and straight forward. From the “client device” view, I just poll cyclic for new CAN messages. Depending on the identifier, there is bunch of “switch-case”-es that make the device perform an action - depending on the identifier and the data content.

Example:

Master device sends a message on ID 0x100 as data message DLC1: set window blind[0] to position [data field byte0].
Master device sends a message on ID 0x101 as data message DLC1: set window blind[1] to position [data field byte0].

Master device sends a message on ID 0x300 as RTR message DLC0: request current position from window blind[0] → window blind[0] device answers with current position with ID 0x300 data message DLC1 with current position in [data field byte0].

As said, very basic but on the other hand totally easy to implement and (in my case) very reliable. It does not comply with any standard like CANopen, but as long as this is not a strict requirement, this won’t be an issue.

Greetings!

2 Likes
29

Thanks, I also only know of industrial devices, not residential, home automation stuff.

Do I understand correctly that you’ve designed and built the PCBs as well? Did it need much work or was it mostly tailoring the schematics found in the datasheets? Could you please share what MCUs, CAN transceivers, etc. are you using on the boards?

1 Like
30

Yes, exactly :slight_smile: . In my current design I centralized most stuff on one huge self-designed PCB where all switches, window-blinds and so on are connected to. There is only one ”C that manages all data (in the home automation time domain the data management is quite relaxed
) and only one CAN bus transceiver (“bus driver” :laughing: :bus:).

But generally: I have chosen components which are well known and broadly available:

  • My ”C is an STM32F103C8T6. In fact I have just chosen a “blue pill” board. This controller brings an integrated CAN bus module so only an additional transceiver is needed (attention: CAN bus and USB are not possible to use at the same time on the F103!!!).
  • as transceiver I’ve chosen the TJA1050 (nothing special here).

Breaking it down to “plug-able” components, have a look here:
https://www.aliexpress.com/item/32649400326.html?spm=a2g0o.productlist.0.0.47bb3aadKLiHoe&algo_pvid=e6615840-c7fb-4833-af80-0d1c8aca47f1&algo_expid=e6615840-c7fb-4833-af80-0d1c8aca47f1-0&btsid=2100bdd716153937306106822e8f84&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_
(attention: there are many fake chips out there)
and:
https://www.aliexpress.com/item/1005001424199574.html?spm=a2g0o.productlist.0.0.49675435ontetz&algo_pvid=64611093-7330-40b7-9b10-10d29d5dc6e0&algo_expid=64611093-7330-40b7-9b10-10d29d5dc6e0-2&btsid=2100bdd516153938217562735ec7df&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

Basically this is my setup. I go with ST controllers, because (from my point of view) the provide a good combination of price and performance. And they offer a complete development software ecosystem for free.

1 Like
31

Hmm, for some reason I don’t have any canbus messages anymore on my mcp2515 or canable
 I don’t understand


32

Oh no

For those reasons, I usually implement some kind of “heartbeat” messages, which are sent by the devices in a fire-and-forget style (at least during development phase) - similar to the “telemetry” data frames, which are sent by some MQTT devices.
Doing so, I can sure say that there MUST be something on the bus as long as the hardware is physically okay.

33

I don’t get it, can i brick something if i only use H and L connections? I didn’t use the gnd

34

For those reasons, I usually implement some kind of “heartbeat” messages, which are sent by the devices in a fire-and-forget style

CANopenNode supports this kind of feature for CANopen networks. You can also setup heartbeat node guarding, for example the master node can guard any slave nodes. When that nodes goes into error, the master node automatically detects the heartbeat timeout an may leave the operational state. I’m not sure you want that, because it may render your complete netwerk unusable. It’s useful for machines that need to be safe, but for controlling some lights and so on that may be too restricted. It’s your choice in the end, you’re not enforced to use it.

I don’t get it, can i brick something if i only use H and L connections? I didn’t use the gnd

Normally that shouldn’t happen. Off course it is better to use GND, than not. It will make a better network when condition are harse.

Has anyone got any plans to launch an open-source soft and hardware project around this?

I’d love to bring my own device, but lack the time currently and I may not be able to do that due to work related restrictions.

Is it possible to download applications and firmware updates to the network devices via the bus cable?

At least CANopenNode doesn’t support it out of the box, but you can add your own extensions. I’ve done exactly that at work, I’m updating my devices through the CANbus it is working well so far.

1 Like
35

Well, seems it’s bricked in my case
 Verry strange, don’t see anything anymore with a candump

Gonna try to attach gnd later as a final test, but i don’t think it will make any difference

36

ESPHome, which integrates well with Home Assistant (to the point of being acquired by Nabu Casa), supports CAN Bus https://esphome.io/components/canbus.html.

1 Like
37

HassOS 6.0 now also supports can devices :slight_smile:

2 Likes
38

For using ESPHome you’d need to add a CANopen master stack. it could also be a simple CANopen node if any of the other nodes that you want to hookup to over CAN is self-starting.
In that case you have your CANopen devices connected wirelessly to your HA controller.

It would make more sense to connect your CAN devices directly to the HA controller.

1 Like
39

I think some people posting in this thread are confused about what CAN is and how it can be used in home automation.
CAN consists of physical (ISO 11898-2) and data link layer (ISO 11898-1) standards. These standards describe the wires and signals used for communication and the message structure and protocol that allows devices to send and receive arbitrary data.
Saying that two devices support CAN is the same as saying that two devices support UART or Ethernet.
In order for two devices to understand each other, they need to agree not only on HOW they exchange the data, but also on WHAT the data actually is and what it means. This is usually described in application level standards and protocols.
An application level protocol for home automation could, for example, describe different device types (switch, lamp, shade motor) and message types (turn on, turn off, get temperature).
Most people who say they developed home automation on CAN bus only use CAN bus data link layer and have developed their own application level protocols. In other words they just came up with their ideas what bytes mean that a switch is pressed or a lightbulb is turned on. This means their solutions are proprietary and not interoperable with other implementations.
CANopen is a set of higher level protocols (built on top of CAN bus) that allows building industrial automation solutions. It has support for basic inputs and outputs as well as extensions (device profiles) for different industrial devices (elevators, inclinometers, transmissions). If it could be applied to home automation, it would be a very promising solution, because of these features:

  1. It is open source, free to use
  2. It is well documented
  3. It has open source implementations that can run on many chip families
  4. It covers many different scenarios like device provisioning, configuration, heartbeat monitoring, firmware update, etc.

It would mean that if CANopen had a home automation profile, a smart switch developed by John would work fine with a smart relay developed by Mary, because all aspects from baud rates to message structures would be defined and standardized. Just like in KNX, but without the crazy price tags.
Unfortunately, while CANopen supports many low level device types like digital inputs and outputs, it does not have device profiles for more complex devices like curtain motors, dimmers, etc.
For example, Zigbee home automation or Z-wave have all those things defined. That’s why you can use an IKEA button with a Philips Hue bulb.
And it’s a shame, because CANopen on CAN bus bus could be a very promising low-cost open source KNX replacement for home automation. Perhaps a community effort could be launched to develop those missing device profiles, because I believe many people who are building new houses are looking for wired solutions and are left to choose between crazy expensive KNX and proprietary implementations that lock you in with a specific vendor.

7 Likes
40

CANopen might be a starting point for designing a CAN-based open smart building protocol, but I believe that it would not be as simple as just adding profiles.
It has a strict limitation of 127 individual node addresses that can not be extended without breaking too many things in the spec. I believe that this makes it infeasible to be used - 127 nodes per line is an acceptable limitation but there would be no simple way to join these lines into one system.