Hi All,
i started some research about a way to implement a domotic system for my new house and thanks to my friend i discover home assistant. Starting from here and based on my experience on industrial automation field i tried to understand if there is a way to get a robust and ‘as full as possible’ solution based on wired bus instead of wifi solution and i found this topics. I read all messagges and also some related post made by @Jojo-A and @pergola.fabio. Based on my poor knowledge you made a great project. My ideal requirements are the same of the first post, but i’m trying to figure out if canbus solution is in my possibilities (about knowledge not money). Reading on this forum seems that wired bus solution isn’t so popular, so i’d like to know if your project(s) end with a succesfull solution and if you can drive me i little to built my own or if is still a complex and\or high level skills needed solution. Thanks for any advice,
I am a strong advocate of bus / wired solutions in home automation. The reliability is unmatched.
If needed you can use Home Assistant to add other components to such a wired core system (i.e. WiFi, Zigbee and IR based components).
One of the really established bus standards in home automation is KNX. Home Assistant provides a mature integration for it. The beauty of KNX is that you can make it completely self sufficient. It will run on its own without HA and it is rock solid. HA can be used to provide all “higher brain functions” and complex automations. This is the way I built my smart home and I am very happy with it.
KNX has existed for a very long time (over 30 years, starting under the name EIB). You get KNX components from over 200 suppliers. Actuators, sensors, switches, weather stations, whatever you want. The large number of suppliers ensures that you will not depend on one system owner who might drop support. And it allows you to buy switches from the same manufacturer that designed and built your wall sockets - so they all look the same.
The downside ist that KNX is not cheap. Each wall switch will cost you between 50 and 100 bucks. The software to program the KNX components (ETS) costs 500 to 1000.
I solved that by creating a hybrid system with HA bridging the worlds.
The backbone is KNX with light switches, heating control, shutter control and some motion sensors. That is the part that I never want to fail.
All other elements are added through HA using other systems and much cheaper components. These are the convenience functions, like more motion detectors, air quality and humidity control, weather components, smoke detector bridging, energy monitoring, car charging, plant/soil monitoring, irrigation control, voice control, all higher automations, visualization and control through smart phones and wall mounted tablets.
Where you draw the line between both worlds is up to you. My only recommendation is that you make sure that if HA goes down, your house remains habitable and your family remains happy.
@Jpsy Hi Jörg,
thank you for sharing your experiences! It is nice to know that there are still some more “wired” advocates out there 
. Your points about KNX might all be correct. But I would kindly ask you to not get in detail about here, because it might litter up the thread - and the threads topic is CAN bus. I totally don’t wanna start a CAN-KNX battle. I just want to try to keep the focus 
.
@mrgoodcat84
from the current state I would say that CAN bus requires a little bit more tinkering compared to some other solutions. But from my point of view it is really not that difficult. Most of the CAN bus specific stuff is handled totally independant inside of the individual CAN controller. So you (as the user/operator) have only to think about “identifiers” and “data field” (payload).
As long as you stick to bare CAN bus, you are totally free in how you manage your messages. For example you can use the identifiers to distinguish between the CAN bus node as well as the content/topic of the message (for example: CAN message ID 0x1001 contains temperature data of node 1, message ID 0x1002 contains temperature data of node 2,… and whatever you want)
If you go for a higher level protocol (like CANopen) you are bound to the specifications, but you can set up your system in a more “standardized” way.
To get familiar with CAN bus I would recommend to just buy a few boards (like the canable.io). It is not expensive and gives you the possibility to collect first impressions/experiences with CAN bus.
To sum it up (from my point of view): no CAN bus is not difficult to understand. As it is not widely used in end-user home automation systems it might require some tinkering but it will definitely be possible - otherwise we won’t be here .
Greetings!
Hi @Jpsy,
thanks for your feedback.
KNX was the only wired bus for civil application I had heard of, but due to the costs related was not on top of my preferences, just because with a similar budget i can probably use a semi-industrial solution with a PLC (just because i work with them and i have a bit of knowledge around). But for sure KNX is a full robust solution and your feedback is another confirmation about. the only negative note is for the architecture of system with KNX. What i really like (or in this moment im oriented on that) is a system able to work in parallel with a standard electrical system and, for my poor knowledge on KNX, using it the system is based on it, so “any” component is KNX based (like the wall switch you mention). What i’d like to understand is if i can reach, at a reasonable price and study-time, something that add smart functions to a standard system that i can switch off without lost the main functions, as you tell for the family happiness .
Not only HA should be a plus, but also all the not standard electrical parts.
Yes, i sentence it because i’m not familiar with KNX , i know that with a well done solution it is very reliable and stable, but this is a moment i’d like to learn something and try to do by mylsef and if something goes wrong i need light remain on.
Hi @Jojo-A ,
thanks for your reply.
I have a bit of feeling with bus comunication and how to manage, but not in this field and with this HW. Reading on web and in particular this post i understand that canbus could be a possibility with good results and not so expensive, but where to start ? I mean, i’m not in the final decision stage, but i’d like to put on short list 2 or 3 possible way and then decide with which one go on and start to study. KNX and PLCbased are selected and i can found a lot of info and example (i should know how to start and figure out some test\results). Canbus should be the third choice and is very interesting, but it’s very difficult for me find a step by step guide to move the first steps. Among other things, I already have a raspi 4+, some sensors and other stuff related, purchased for another project that I never carried out due to time problems, but probably i already have most of the HW needed. But software parts is a blank table. I saw ESPhome site and seems to be the right place where found solutions, is it ?
Thanks for support,
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 .
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.
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.
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 .
Talking about what is working today, your MQTT-to-CAN gateway can work by ethernet instead of wifi? Can you share the code?
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
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.
I think I included 5 drivers , don’t remember anymore
But you always add more
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.
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).
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.
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…
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?
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.
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.
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!