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

well, :slight_smile:
I just played with it, had some time :slight_smile:

i just created an add-on, actually to test the hardware and the PR i submitted for HassOS, so now testing a dev version… i think we need to create an addon, especially for HassOS users , since the hardware itself can only be loaded with extra tools installed
for SLCAN => we need can-utils
for CAN => we need iproute2
both tools are not part of HassOS, so i added them to my add-on container
SLCAN is for me stabler, easier to bring down/up =>> while can was sometimes giving timeouts

anyway, i just played with it , for my project, i am already pleased if i can turn on/off services based on the canbus messages i receive, thats my first goal, thats why i created this add-on , so i dont need the esphome/mcp2515 anymore

next step is offcourse making an component, and not use restapi offcourse, but i am not a developer at all, i just google for scripts :slight_smile:
if he is able to make a custom for our domotic system at home (dobiss), i thnk you will have a nice working example

so we need @OpenJeDi to help us :slight_smile:

anyway @OpenJeDi , i tested canbus, i was able to turn on lights by sending canbus messages, works verry good!! also there is specific canbus message, if we put that on the bus, it will receive the states of all relays!! its like the poll sensor based on TCP we use now , so thats also verry good
that means, we dont need to use TCP at all anymore

basicly we can use your custom already, the send part should be ease to change, instead of sending to TCP, we need to send to canbus, the messages are about the same

for reading/polling states, not sure , i think you need to change code here, because, its not just 1 string that contains all relays, every canbus message is a state, so not sure how you can do this?

Ah, okay. Thanks for the description! Now I can follow again :sweat_smile: .
You might be right about the additional tools that are needed. Currently I don’t know the why how this is handled in HA. A containerized custom component could be one solution. Or maybe it could be loaded/installed just on demand when the platform “canbus:” is added to the configuration.yaml . But as said, I don’t know if this is a common way for integrations in HA…

About the polling:
as I understood it, this could be handled be the python file of the integration itself. It could call the read-function from the python-can library with a specific timeout (like 0,1 s). Other integrations work quite similar.

About the payload (in case of a sensor component):
I would like to handle that as other integrations also do: we should be able to handle it “directly” (use the decimal representation of a specified amount of bytes) or process it as a json payload so we could extract the desired information just from somewhere inside if the CAN bus data field. With a very flexible message processing, we would be able to create both numerical sensors as well as binary sensors.

All my ideas are open for discussion. Please feel free to kick in, if it is just too much crap :wink: .

yeah, gonna strat building my addon this week for my domotica system the control all lights/switches/covers… with a live polling state
i already work with scripts, based on TCP socket, just need to convert them to canbus

@pergola.fabio how is your progress building the addon?

I’m a programmer and could help with the development of the add-on if you need help with python.

My idea is to use esp3266 with MCP2515 running ESPHome and connect them to Home-Assistant running on a raspberry-pi using a “Canable” USB to CAN-bus adapter.

Appreciated, do you also use a dobiss system?
My addon works, i use the canabla as hardware…
With rest API calls i just update the sensors i wants , so good enough :slight_smile:

I also used the ESP before with the MCP board…

But since HassOs 6, i updated the drivers there , so canable is able to load with HassOs…
It’s a cleaner solution, no esp needed anymore

Right now I’m just looking for a solution to use a bus system for wiring my smart home. So, no, I’m not using dobiss. I came across Can-Bus and think this is a pretty solid solution.
I haven’t bought any hardware yet, still looking into it, thats how I ended up at this thread :slight_smile:

Did you create a dedicated HA- Add on or are you still using the script from your post from february

1 Like

Yeah, still using that… But it’s more based on the dobiss system, ideal would be a custom component, not an addon… The custom component needs to load the SLCAN driver…
Then somekind of service to send an can message and an sensor to receive can bus messages…
More an universal component, that everyone can use…

@engal Hi Christoph and nice to see that this topic is still of interest for some people. So: welcome :slight_smile: !
Basically for you: am personally am a big fan of CAN bus, even for home automation. The advantages are already stated here (at least from my point of view): Support for CAN Bus (Peak, Ixxat, canable etc)
Maybe these points help you on your way to a decision.

@pergola.fabio has already done a great job in creating his addon. But I definitely share his opinion, that a dedicated “component” would be better. This is sadly the point where I can not help because of just no knowledge in HA component creation. Yes, I know the documentation and it is great! It is just a case of my mental limitations :sweat_smile: .

I DON’T think, that the SLCAN driver should be loaded or used at all, because I see any advantage to sacrifice the CAN bus’ versatility just for better (?) readability.
SocketCAN should be sufficient and in the Linux kernel since ages. Additionally there is a python library (python-can) that utilizes SocketCAN.

indeed, while testing i had issues with socketcan, specially on HassOS addon , i need to load the driver there
in HassOS, if you want to load additional drivers in kernel, you need to modify the kernel files, so for me as testing slcan was the easiest route
allthough i prefer indeed socketcan, nothing is needed then, but it should be accessible from the custom component (driver)

I’m curious why did you choose CAN bus and not CANopen?

I’m preparing to add CAN to my home and not sure which one to go for. I am also asking because I am thinking to start a more general and open hardware/software setup for others to use as well for CAN in home automation.

My observation is that there is a serious lack of open setups (hardware and software) for wired buses (KNX being really odd with that licensed software and expensive devices).

I guess CANopen would require more powerful hardware, but brings a standard framework instead of each user having some home cooked convention/protocol on top of CAN bus.

Also, what hardware did you use for the actuators/clients? Besides ready made boards, some details on self-made boards would be cool.

Thanks.

1 Like

In my case i had no choose, my whole domotica is based on canbus, it’s a closed system…
So to integrate lights and sockets in HA, i placed a can adapter between it to capture and send messages… So now i have control over my lights/sockets/ventilation …

1 Like

Don’t mix up things. CANopen is still based on the normal CAN bus. CANopen is just a higher level protocol. So you can use the exact same hardware. You just have to stick to the CANopen specifications. That means you can not choose freely which identifiers you use and so on, because the specifications tell you which identifiers you have to use and how your nodes “should” behave.
At first, CANopen is more complicated to understand and to set up. But later on, you will have a “standardized” system which will be easier to adjust.

For now, we started with individual “protocols” based on CAN bus, because this is the fastest way at the beginning. You define by yourself which identifier you use for which purpose. One will get it working it “no time”. And having CAN bus at all would be needed for higher-level protocols like CANopen anyway.

About my boards: nothing special here. It depends on your system. If you have a system that already brings the CAN bus controller internally (like many 32 bit microcontrollers) you only need a transceiver (TJA1050 or so). If your system does not have a CAN bus controller (like most Arduinos) you’ll need an external CAN bus controller like the popular MCP2515 + transceiver). Let me now your system details and I could tell you what else might be needed.

Greetings!

1 Like

Yes, I know CANopen is at higher level, on top of CAN bus.

Right now I have no CAN hardware, I’m still documenting.
Eventually I’ll want to build my own boards based on MCP2562 or TJA1051T, but as first step I think would be quicker to get a ready made board and connect it to Arduino UNO for tests.

  1. What would you recommend in terms of ready made boards and building my own boards?

  2. What I am not sure now if it’s doable to have as DIY ECUs some small Attiny, like Attiny 13, with MCP2562 if using CANopen or more more powerful microcontrollers are needed when using CANopen (for protocol overhead - implemented in software)? I’m assuming Attiny13 with MCP2562 is usable as simple switch or relay board on a CAN bus. I’m trying to go minimalistic with the boards and not use Arduino/ESP8266/power stuff for a very basic ECU.

I also have some questions regarding the physical bus:

  1. I read something about the CAN bus used to power the ECU’s. Is that correct: is this setup made of just 3 wires: ground, CAN high and CAN low. And also use the ground to (let’s) say High as power bus? Or is this totally false and 4 wires are usually used: CAN high, low, ground, VCC?

  2. For longer busses, up to 250m, 250 kbit/s would be good, especially as I don’t estimate high traffic (just some light switches, temperature sensors etc.). Is CAT5 or CAT6 cable fine for bus + VCC? (making sure voltage drop on the cable is accounted for on the source). Or is there generally another cable suited for this?

As you can see, I’m pretty confused here with various hardware pieces.

Thanks for your help.

Basically the ready-to-use boards work just fine. But until now I have only found boards based on a stand-alone CAN bus controller like the MCP2515 (HERE). Those are totally fine when your target controller has no integrated CAN bus controller, like many Arduinos. My first prototypes were based on an Arduino Nano with such CAN bus modules. There are libraries that provide easy access to the MCP2515 through the SPI interface.
Now, I have made my own board based on a STM32 blue pill board. My PCB has a socket for the blue pill and the transceiver.

From my point of view, the protocol overhead that comes with CANopen can definitely be handled by low power microcontrollers like Attinys or Atmegas. Keep in mind, that everything you do in Arduino IDE might come with a potentially bigger overhead than the CANopen stuff would need.
Of course it depends on the implementation. But you won’t need to implement the whole specification-compliant CANopen stack. For your case it would be sufficient to implement only the mandatory objects, like a SDO channel. PDOs (and all the mapping stuff) are not needed. Also the node management will not be needed (or is optional). So only expedited SDOs and an object dictionary with <10 objects. No problem for an Attiny or an Atmega.
So the easiest way to get things running is to use a Arduino Nano board, together with a MCP2515 module, a library and the Arduino IDE.

I don’t know of such a solution. This does not mean that it is impossible, I just don’t know. It would be easier to just use a 4th wire for +5V…

In this case I personally would supply the nodes with a higher voltage (like +12V) to make the voltage drop less significant. For the CAN bus the length should no be a problem. But I would recommend to lower your baud rate. As you say, there will only be very low traffic with low amount of data. So you could go for 125 kBit or even 50 kBit. This would give you more robustness.
Basically there is special “CAN bus cable” like THIS, but I also used ethernet cable for my application. No problem.

I hope this helps! Feel free to ask if there are more questions.

1 Like

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.

1 Like

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

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

Greetings!

1 Like

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