Any news? This is the most awesome initiative! If it’s good for the automotive industry, it’s good enough for me! I’ll kick the hell out from that wireless crap for sure! And it’s better than modbus for sure!I would rather install the cables than to wrestle with the unreliable wifi. The esp32 has a Can controller, and for a line driver a tja or mcp. The ideal HW would be an Esp32 can to ethernet or to serial one i think! I never was a fan of the Pic stuff more an AVR guy., but if the Pic is built with more superior guts, is ok for me too!The
2 Likes
This is really awesome! I have also thought about going the way via CANopen. Thanks Xavier for the first steps. I would really like to contribute in some way. And I even think that some people would be interested in contributing as well.
Are there any updates on your progress? I am currently developing an ESP32 Ethernet board that I would like to use as an CANopen gateway. Later I would like to develop switches that fit into the frames of my home installation.
Best Regards
Alex!
1 Like
Made an account just to say I’m also really interested in this project. I found this site that talks about a bootloader that can flash AVR chips with an MCP2515 over the CAN bus. Should be able to modify it to use SDOs:
1 Like
I’ve had some good results with using CANopenNode on STM32 boards. It also comes with a basic IO module example, so you shouldn’t have to much issues getting your module to work. As for the gateway features, there is some implementation available but you have to write your own mqtt protocol converter. Unfortunately my modules are not very usuable for home automation, they’re developed for special purpose.
1 Like
Furthermore you may look into the following document regarding how to bridge CANopen and MQTT networks: https://can-newsletter.org/uploads/media/raw/9be01f99cda5ed8f27af55ec34f9ca8c.pdf
1 Like
Hi Xavier, and all contributors so far,
This is a great post and has inspired me to re-investigate the alternatives to KNX and Lon for field-level automation systems.
I have a decent amount of experience with KNX professionally, and although 15 years has now passed, I did my engineering dissertation project using CANbus. In my professional life, I have always stuck with open protocol systems in my projects to avoid vendor lock-in, however, this means the upfront cost is higher than with proprietary protocols.
Since I last looked at CAN in detail, the CANopenFD and CANcrypt have become readily available, which looks like it provides an off the shelf mechanism to build an open-source twisted pair based home automation system. HomeHAB looks great, except for the re-invention of the CANopen layer. It is a big risk to use any system without a large company guarantee or an ISO stamp on any commercial installation.
This series of posts are mainly about the base layers of the stack, I have a few questions which are more general about the system. I am wondering if CAN can be a real alternative to KNX and Lon, and having already been bitten by many of the pitfalls of KNX, I would like to understand if these can really be avoided with a CAN system.
Has anyone got any plans to launch an open-source soft and hardware project around this? The KNX ETS philosophy of a single method to programme the entire system, all parts, and all features of all parts acts as a safe haven for KNX and I would advocate a similar approach, although not an identical approach, for a CAN based system.
A big advantage of KNX is the power and data over the same twisted pair. Is this in any way possible with the CAN?
When the device limit is reached on KNX, lines are coupled together via a backbone line. Traditionally these were TP lines, but now generally the coupling is done at the IP level. This is possible because of KNXNet/IP (KNX telegrams encapsulated in an IP packet), however, the standardization of the encapsulation means there is vendor independence between the KNX/IP gateways. The IP network is also operating at much high baud rates so latency between lines is unnoticeable. Is there any standardized approach to this in the CAN world?
Is it possible to download applications and firmware updates to the network devices via the bus cable? I am thinking that an IP gateway device could also be updating the firmware of the devices, but the obvious risk is that the firmware causes other issues on the network. Again, this is where the expensive systems are amazing, they still work after update, without fiddling…!
All field bus systems over the last few years have put a lot of effort into either creating a wireless physical medium or closely integrating with an existing wireless medium. This is a very useful additional tool in the box when delivering projects as there is always an application where a wireless device or 2 saves a huge amount of cash.
Resilience is my area of expertise/interest and I would ideally be able to include detect cable faults on the bus line. Cable fault identification is a tough problem in all comms systems, however, fire alarm systems automatically isolate a cable fault out of the ring, by switching to 2 radials and removing the damaged leg. Does anyone know of any examples of this application using CAN?
I have attached a screenshot of ETS (my home installation project) as well as a couple of photos: a 4 buttons sensor, a thermostat sensor, and a wall PIR during installation (combined into one image in the next post due to forum restrictions). This kit is pricey, but it does the job really well, it provides all the features needed for both residential and commercial projects which are generally at a massive scale. It doesn’t go wrong (well, very rarely) and I can trust it to work constantly for 20 years or more.
Is CAN going to provide an alternative? Should I be putting some time in to help to make it a real thing?
Ste Mulvenna
London
1 Like
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 ?
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
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
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
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
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
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
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
Yes, exactly 
. 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” 
).
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
Hmm, for some reason I don’t have any canbus messages anymore on my mcp2515 or canable… I don’t understand…
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.
I don’t get it, can i brick something if i only use H and L connections? I didn’t use the gnd