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

Hardware
11

Hi all,

Sorry guys for the very long absence (1year and 5 month), I come back to share with you my progress.

On the home assistant side, I played a lot with my homeassistant (on a RPI3) in order to properly understand how everything works and linked together. MQTT seems to be the road to go when people want to avoid the writing of a painfull platform driver. If the CANOpen choice is maintained, I think I will build a Canopen<->MQTT bridge.

Progree on the HW side :

  • In order to save time and use HA with actual hardware, I bought and tried some of the chineese coolcam devices (motion sensor, wall switch and curtain switch). Cheap but I will definitively not use both switch as I found these VERY unpleasant to use (slow, cheap plastic plate…) and the internal design is not safe.
  • I also investigated the “mysensor” open source project project as their seems to be well supported by HA and claim to have a wired (RS485) solution. I am familiar with this bus and it is a sensible choice for bus with only one master. However in my mind, home automation has to be decentralized then RS485 (and mysensors) is a no go for me.
  • I had great hope with the HAPCAN project but after further investigation it is not fit to my intended use. Moreover, I don’t like the fact there is a custom application layer above the CAN protocol built just for this application. I do like well defined standards like CANOpen (or others). Indeed, in such protocol a good custom application layer is a lot of work (documentation, debugging tools, custom gateway, custom library, etc…) and reinvent the wheel is not my hobby.
  • Inspired by design from https://www.openhardware.io which convert Livolo wall switch into mysensor wall switch, I ordered some VL-C701-11 with the idea to convert them to CAN. I am very pleased with the outside lookin and finish of the livolo products. However the inside power electronic do not fit my quality agreement (low cost, not even a fuse there!). So, I will only keep the outside and build my own electronic inside.

On the firmware side:

  • Inspired by the HAPCAN hardware, the microcontroler PIC18F seems to be a good candidate for my application. I looked at the microchip AN945 (from 2004!) which implements a canopen stack for old PIC18F microcontroler. This code is not maintained and are not compatible with up to date PIC18F26K80, code adjustment has to be done. However I don’t really know if I can modify (and redistribute) this stack as the code is marked “All rights are reserved”. I don’t understand Microchip policy… No go.
  • I was looking for open source Canopen stack and I (re)discover the CanopenNode stack was initially intended to PIC18F but is not today anymore (no more 8-bit microcontroler support). So I digged up in the old sourceforge repository for the last version (V1.10) marked as compatible with (quite old) PIC18F. It is important to notice this old canopennode stack is very basic compared to the last version but I think there is everythink I need and the last version is too big to fit in a PIC18F.
  • I have to look in bigger microcontroler compatible with Canopennode (PIC32,…) to ease the dev… I am not very familiar with microchip products.

On the experimental side:

  • I started to build a prototype on an experimentation board with CAN transiver and a PIC18F26K80 on it. I succed to build a project and enable a CAN communication between my computer and the microcontroler. Note : i use a CANable USB to CAN cable.

That it!

See you soon

Xavier

1 Like
12

Hi guys,

After a code analysis and some tests, the CanopenNodeV1.10 is the way to go. Indeed the last CanopenNode stack is very complete and awsome but way to big to fit in a PIC18F and the V1.10 functionalities seems to be good enough for the application with 2 exceptions.

  1. No RPDO dynamic mapping, I intended to use this feature to link/pair devices together. I have to work on this but it’s not a big deal…
  2. No LSS slave feature. LSS is a way to dynamically assign node ID (and baudrate). I am not familiar with this protocol and at this stage it’s just a nice to have.

I am wondering about the application layer on top of Canopen and I do not want to reinvent the weel. I do want to use standards and eventually existing code. I read this z-wave Command class which seems to me well designed. I was unable to find a similar document for zigbee and mysensors, any clue?

Have a good day

Xavier

1 Like
13

Hi guys,

After reading most of the z-wave command class (and others), I will inspire my command layer close to the z-wave one.

Here are my actual though, as mention before do to reliability reasons, I don’t want any central node/controler/switch for the system to work. In other words, I want it fully decentralized excepts for configuration.

A Canopen network can be composed upto 127 nodes, each node is one device for example a 4 channels wall switch with temperature sensor and presence detection features is only one device. Each features rely on a data model, different devices features will be linked together in groups with the same data model.
Canopen has different “messages” types to communicate with nodes, everyone of them has its purpose:

  • The NMT master/slave messages, this is mainly used to “manage” the network. Turn ON/OFF nodes and so on.
  • The “Heartbeat” consumer/producer message. This message is produced cyclickly by every active node/device and consumed by ‘other’ devices tracking theses messages. This enable the surveillance of the nodes. If a node goes dark, ‘other’ nodes in the group will notice and possibly report it.
    • The “Emergency” message is similar to the “Heartbeat”, this enable the reporting of something going wrong with a very high priority on the can bus. However only special nodes monitor theses messages.
    • The “SYNC” broadcast message is used to retrieve the state of every node/feature in the network at once. The master of the network (probably the node linked with Home assistant) will send this message when needed.
  • “SDO” message system is a classic client/server feature (GET/SET commands). In other words, you can set and get parameters/values from the so called Object Dictionary (data structure which canopen is build around). This OD will contain every parameters of the device/node for their network configuration (name, ID, groups,…) and also parameters for each embedded feature (sensors, switches, lamp,…).
  • “PDO” is a producer/consumer protocol. This one will be used for two things:
    • To broadcast commands to a particular group. For example, lets say we have a system with 2 lamps controlled by 2 wall switches. In order to do so, every device feature will be part of the same group (with a group ID). The lamps will “consume” the PDO message ‘produced’ by the wall switches as they will emit a CAN message with a particular ID. A question arise here, is the wall switches has to keep track of the “state” of the lamps? My intuition tells me it is better to send absolute command such as “set the lamps to 70% in 3sec” than relative messages “increase the lamps light by +30% in 3sec”… I am not sure…
    • To report the state of a node. For example each node “lamp” will broadcast its state every minute when nothing append, on transition/event and every 100ms during transition.

It important to notice, a PDO messages is considered good if one of the network node can read it properly (even if it do not consume it). A PDO message can be properly produced but not received to all nodes. This seems to me unlikely as the CAN network is very reliable on a proper network hardware with a properly selected baudrate (125kbit/s will be selected for the application which is recommanded for network upto 500m). Although if this became a issue, an acknowledgment PDO message can be done (not part of the canopen norm and will make the system a lot more complex)) or perhaps use SDO individual SDO messages with this acknowledgment. Time will tell.

Few words on the firmware development (no breakthrough yet!), I focused my attentions on the hardware devices:

  • I can now retrieve a unique ID (will be used as a MAC adress) from a cheap 1-wire Dallas 18B20 temperature sensor. It is the cheapest way I know to get a 64bit unique ID as every 1-wire device as a 64bits unique address. This can be use to identify without doubt any device on the network.
  • I can also read and write part of the PIC16F FLASH like a EEPROM like fashion, this is in feature of the microcontroler : this is well documented and went easy, I think there is no need for an external EEPROM after all. :slight_smile: . However there is one drawback, I am not able to reprogram the µC with my PICKIT3 without clearing the EEPROM :frowning:. It is inconvenient for develpment won’t be an issue once the updates will be done by a CAN bootloader (TODO).
  • I am porting the CanopenNode V1.1 to the PIC18F25K80 and XC8 compiler. I solved all the compilation problems and I begin the stack configuration.

See you soon,

Xavier

2 Likes
14

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
15

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
16

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:

https://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fwww.kreatives-chaos.com%2Fartikel%2Fcan-bootloader

1 Like
17

…there’s also CANFestival, which has AVR support: https://canfestival.org/doc

18

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
19

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
20

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

ETS Screenshot
ETS Screenshot3197×1729 549 KB

1 Like
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