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
HassOS 6.0 now also supports can devices 
2 Likes
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
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:
- It is open source, free to use
- It is well documented
- It has open source implementations that can run on many chip families
- 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
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.
Thank you, you are totally right about that!
I personally would really like to see CANopen (or something similar) implemented in HA, because of all the points you just raised (versatility, low-cost, low-complexity)…
Most of these advantages are also pointed out in threads like mine HERE.
But all this would require, that the fundamental hardware is supported natively (or at least without a lot of tinkering). Setting up the higher-level protocols is then nothing more but how the data is handled. As you said, there are open source protocol stacks out there and they are proven and widely used. But for some reason CAN bus (and with it CANopen) has not made it yet into the “mainstream”, because it is still seen as a pure industrial bus (and in most cases it as seen as a automotive-exclusive bus).
@pergola.fabio has already done great success in communicating with CAN devices over his CAN-to-USB dongle. But he created a custom device with a REST API (IIRC, please correct me if I am wrong). But we both agreed, that this approach should not be the final solution, because there is just no real/nativ CAN support.
So from my point of view, the first step should be to have native CAN support onboard with all the underlaying data management, and having a dedicated CAN platform which then could be used by different components as described HERE. Note: just a proposition, not a solution.
Greetings!
1 Like
With native CAN support we will be limited to 127 nodes, right?
What do you think about this concept?
Several ESPHome devices with ethernet (as Room Hub) and each one with their CAN BUS where all the sensors, switches or motor driver’s connects? The Room Hubs will then connect to Home Assistant by ethernet MQTT.
Only when it comes to basic CANopen. CANopen is kind of restrictive here.
CAN itself uses either 11 bit or 29 bit identifiers which are used for arbitration. This is the part in a CAN message that is important to talk to a specific node or in return to identifier which node has dropped the message to the bus. As you can see, 29 bit for node and/or message identification is really much.
I think that even 127 nodes will be hard to reach in a normal house. Lets see. Per room we assume a basic setup:
- light switch (sensor)
- light relay (actor)
- window blinds switches (sensor)
- window blinds motor (actor)
- window open sensor
- temperature sensor
Makes 6 nodes per room. Lets assume 10 rooms - and you still won’t hit the limit of CANopen. And of you can afford a house with 10 rooms you might also be able to afford KNX 
.
I personally decided to go for CANopen (or at least sticking close to it). In fact I created my current nodes by myself. This means that I decided to NOT separate switches and actors to individual nodes. As my window blinds switches will always be there in combination with the motor, I decided to make nodes which combine switches/sensors and the corresponding actors. So each window blind node provides access to switch/sensor states and the actor (plus node-internal stuff like operation time and so on…). So in my setup one single window node is enough for all stuff regarding that window.
When I have finished my setup I will share it here.
2 Likes
I will read more about CANopen. You have a system HW/SW working right now? Involves ESPHome?
1 Like
My system is not ready, yet. What I have is two prototype boards which work as expected. Also the software is working, regarding it’s basic functions. This includes CAN communication in CANopen style (means I do not cover everything to declare my nodes as “official” CANopen compliant, but regarding they behave very similar), moving covers by wall switches or alternatively by positioning commands from HA, reporting information about position, IO states and temperature to HA.
Currently I am writing a routine for a semi-automated learning of the times needed to roll the shutter up or down. This information is needed for position calculation. Currently this information is given to eah node by a write-SDO to the corresponding object in my CANopen object dictionary. Later both methods will work (sending roll-times via CAN or learning it).
I do NOT use ESPhome, because the current CAN implementation seems not to be what I want.
I have programmed an ESP8266 to be a “transparent” MQTT-to-CAN gateway. The CAN identifier is the last part of the topic and the CAN data field is the payload, separated byte-wise by a comma or semicolon.
Maybe ESPhome could do this, too. I just don’t know. But my self-written solution is already relatively old. At that time ESPhome did not support CAN, yet.
So my system is not finished, yet. But the software-side already works and the hardware is working with two prototypes.
1 Like
Why you do not use current CAN implementation? I’m planing to use it and wanted to find out if any issues. I’m thinking to use STM32 chips. I looked already and it seems pretty good. I have a plan to design few boards and order them on jlcpcb or pcbway. What I liked about jlcpcb is that you can preview the parts they have and the prices
2 most important things for me is STM32Fxxx JLCPCB SMT Parts Library & Component Sourcing
and MCP2551-I/SN | Microchip Tech | CAN ICs | JLCPCB to make connection
In theory The performance of the STMF0 will be enough but not sure if the flash size is enough for a program. I did not like the way STM chips are programmed, the IDE for this chips and what people do was really ClickOps (to many clicks before you even start programming). May be it was possible to do another way. I hope that the clicks they did turned out into a code which does some setup using some sort of enum values. I did not finish watching. I hope I can program using Rust. I wish to learn Rust as my background C#/F# and C++
Hi and nice to see that this topic is still interesting to some people 
.
Why I don’t use the ESPhome CAN implementation? Three easy reasons:
- no time (of course
) - no clue about how to implement it
- no need because my current solution works
Reason 2 is the main reason. What I currently have is a fully transparent MQTT-to-CAN gateway (GitHub - Jojo-A/MQTT-CAN-Gateway: A fully trasparent MQTT-CAN gateway).
So for the ESPhome solution, I would need to set the CAN bus filters so that it accepts any CAN message and converts it into an MQTT message of a specific layout (CAN ID part of the MQTT topic and CAN data field split into bytes and put into the MQTT payload). As I understand the ESPhome documentation, this all must be done in “lambdas”. And now reason 1 kicks in: I had no time to dive so deep into the docs and the lambdas.
I have also created custom PCBs for my application. Beside all other stuff, the PCBs carry the MCU board (STM32F103 bluepill). have created them with KiCAD and ordered via PCBWay.
See photos (current installation, eight of these boxes, one per window).
Don’t be too confused by the ST development environment. Yes, the STMCubeMX requires a few clicks. But it makes your life sooo much easier compared to studying datasheets, register descriptions and so on. CubeMX generates the initialization code for you and the rest can be written “by hand”.
So back to your question: sooner or later I will maybe switch over to ESPhome, but not yet.
Let me know if I can help you somehow !
Greetings!!
1672656932678|690x388, 75%
Yes, I need some help. Never did design PCB. I only did manually when I was teenager in high school. I used nail polish to draw connections and then put in FeCl3 to remove copper.
When I saw video guy was saying how to locate elements manually and draw connections manually. My question why he did this manually? I believe there should be an automatic placement and drawing connections should be done automatically.
The other thing is why you have chose a full bluepill board instead of taking just a chip and putting whatever is required? I’m thinking to go chip route instead of board.
I’m planning to make a kinda generic board with STM32 , which will have
- step down controller to drop voltage from 23V to 3.3V
- connectors for 4 PIR sensors
- controlling 6 LED lights ON/OFF with ability to raise voltage from 6 to 12V for dimming
- 6 pin connectors to control relays or solid state relays
- mcp2551 for can
- extensions for sensors
I have not made decision about wired connectivity.
- Use Cat 6 cable
- Use 22/4 22 AWG cable https://www.amazon.com.au/NavePoint-Security-Burglar-Alarm-Unshielded/dp/B0711KFHD2
I have already Cat6 but I really don’t like it as it is single wire and can break. But from the other side I have 4 extra wires for the case if I need anything. But I really don’t know what I may need. I only see 2 wires CAN and 2 wires power 20V. All data I can pass via CAN bus so technically I do not see anything what I need to have use for these 4 extra wires.
We will continue this via PM to not litter up this thread.
This is an interesting thread. I did some HA stuff a couple of years ago to add automation to my Mitsubishi heat pumps used for winter time heating.
Our house has a Lonworks based system that controls lights/ security/ occupancy etc, that is years out of support and the original installer and vendors are out of business. The good thing is that the RS485 TP (signal plus DC power) cabling already exists and would be usable for a CANBus based replacement. I’ve looked at KNX and reluctantly ruled it out due to the proprietary nature and cost.
I’ve bought a starter kit from omzlo for their NoCan project and experimented writing some code/tooling to sit on top of their protocol to do things like configuration time binding of input/output nodes. E.g. a light switch being able to control a/several lighting circuits (on/off/dim etc) and the output node sending status feedback to all switches bound to that dimmer channel.
I’ve used the existing Lonworks concept of network variables to get me started as this provides a standardised was of describing and binding devices together.
My next step is to build some actual hardware (4 channel trailing/leading edge dimmer, 3 channel relay, 6 channel switch input node) so I can set up a small test system and get some electrical safety assessments done. The output nodes all reside in a couple of DIN rail cabinets, and the switch nodes (including occupancy/temp etc) are in wall mounted flushboxes. I can reuse the existing switch plate hardware, with a new NoCan node behind.
Anyway, if anybody is interested I’d be happy to share what I got up to so far. My next step is to build the evaluation boards for the dimmer design and stress test them (PCBs arrived last week)
@fastbike I’m interested since I’m still looking for a solution for the problem in my house: an old home automation system is failing and I only have 2 wires available in a bus network behind each switch. I would be happy to learn more from you.
By two wires, is that 2x twisted pair (i.e. 4 wires total) or just two wires ?
I have a TP of around 24awg which are used for the signal, and a thicker pair which I’m guessing would be around 18awg used for the power.
For background, my current system has around 50 input nodes (switches, indoor occupancy, indoor security, temp sensors, outdoor occupancy, smoke sensors etc) and around 30 DIN rail mounted output nodes (a mixture of 4 channel mosfet dimmers, and 3 channel bistable 16A relays). I’m looking to replace this hardware.
The NoCan design appeals to me as it is fully open source, and allows for over the wire node firmware updates/configuration.
I’m wondering if I should start my own thread rather than hijacking this one ?
is your dobiss failing?
@fastbike there are 4 wires, but only 2 are patched consistently.
I have 102 switches, divided over 56 wall boxes.
(let’s start a new thread indeed)
@pergola.fabio yes it is failing, and it will cost me at least 3-5k to replace the old Dobiss system with new Dobiss hardware. So I’m not quite happy with that as you can imagine.
Omg , frustrating, so what is failing then, does it work sometimes and sometimes not? Or just a module that’s not compatible with the rest?