Open discussion around home automation based on wired connection
2 Likes
Hi there !
This is my first post on this forum and, first of all, I would like to thank all the HA crew (dev, admin and the community) for this great piece of freedom 
.
To shortly introduce myself, I am like a lot of new people here : I want to begin the automation of my house and I want to find the āāābestā"" (or the least worst 
) solution given my constraints (see below). Moreover, like others, I donāt know much about home automation but I am very familiar with industrial automation, sensors, electronic system dev. (my job), linux and python. I want to mention, I am not really expecting someone else to spend time on my project but I will be glad if I can have some feedback from you. Finally, english is not my native language so I apologize hurting your eyes with this post.
To begin, let speak about my system ārequirementsā, I want :
-
A dedicated wired system: I donāt trust wireless technology to be robust enough for this kind of job and believe me you donāt know my wife!
- An open and common bus/protocol: I want to be able to use existing hardware and develop my own.
- Not third party dependent: I want to be able to configure my system without using an expensive software such as EIT (KNX bus).
- Decentralized: I want the basic automation (lights, switchs, alarm,ā¦) to be able to work even if the hub failed.
-
Low power: this is not to save money but I donāt like wasting energy.
So, I spend a lot of time online but I only found 2 widely used solutions :
- The MQTT over Ethernet solution : MQTT is widely used and HA support itā¦ But, it rely on a central node (the broker), each node has to have itās own ethernet port and finally itās not low power at all!
- KNX solution : this is the most professional one and fulfill most of my requirements. However, even simple devices are very expensive, custom hardware are nearly impossible to do and, as I said above, KNX force using their expensive software for configuration. Not acceptable.
A little set back. Few years ago, I developed a whole decentralized acquisition system (electronic hardware, firmware and software) with CanOpen over Can protocol (for the oil and gas industry). And I though, āwhy not the Can bus?ā. I was convinced many solutions already exist for home automation with Can and Canopen. Sadly I was once again disappointed by my online research results : nearly nothing on the Can bus except outdated and small open source projects and nothing on Canopen!
Few words on Canopen and the CAN bus. The CAN bus is a robust low level bus based on a single twisted pair shared with all nodes. In CAN bus there is no master node. As you maybe already know, the CAN bus is widely used in industrial automation, cars, planes, etc for many years now. On top of the CAN, there is a few different protocols mainly depending on the application. The Canopen protocol is meant for automation and provide a lot of different high level mechanism (which are very impressive). Moreover Canopen standardized also the devices family, for example the CiA 401 document explains how to implement an I/O device (which can be used for switches, lamps, sensors,ā¦). So, in theory, any Canopen I/O device (of any brand) has the same interface (read driver and library). In practice, each brand implements additional features that are not in the Canopen Cia 401 which are de facto not compatible across brands (but only the additional features). For further information on canopen, I recommend to visit the [https://www.can-cia.org/](http://Canopen website).
So letās evaluate what a system like this needs :
- Device : custom board with a ĀµC PIC18F25K80 with the Canopen stack from microchip (AN945) and a simple CAN transceiver. Other hardware (sensor,ā¦) will depend on the application. I donāt know yet if I should implement a CiA401 device on it or not. This part will take some time but I am used to this kind of development so nothing to worry here.
- Hub (Hardware) : a raspberry 3 + CAN cape (with Home assistant on it).
-
Driver lib : To handle Can, I hope the CAN cape is compatible with CAN socket (I need to investigate further). To handle Canopen, there is some python libraries (I need to investigate further here too) or I will wrap Canopen festival (C++) with python (I can tell you : this is not the easy way!). Once the canopen lib in place, writing the device python lib will be easy.
- Home assistant component : If I understand correctly, I have to write a new Canopen platform and a custom component for each device type (switch, lamp,ā¦). I think I have to spend a lot of time to get used to HA but I have no idea how long this dev can take.
Before going futher, I am very interested by your feeling on this project.
Thank you,
Xavier
3 Likes
Hi all,
I made some small progress here :
System wide :
- I read again the Cia401 (Canopen Device profile for generic I/O module). I definitively think I should implement it for home automation. Sadly, the standard does not cover all the functionalities I want and I will have to extent the functionality belong the Cia401 (which is by the way authorized in the Canopen standard).
For the Raspberry pi/linux/Home assistant :
-
Good news on the MCP2515 (IC which is present on most of the CAN cape/shields) seems to be compatible with CANSocket. See https://harrisonsand.com/can-on-the-raspberry-pi/ for further details on a raspberry pi.
-
I found a Python 3 canopen library from Christian Sandberg : [https://github.com/christiansandberg/canopen] (https://github.com/christiansandberg/canopen). It seems to implement most of the base core functionality (ie Cia301) but not the Cia401. It will be my contribution.
On the hardware/firmware side :
- I started a MPLABX project to implement the Canopen stack from microchip. This stack seems to not be written for the ECAN module version present in the PIC18F25K80 (CAN micro-controler). However microchip seems to upgrade their ECAN IP to be retro-compatible. I let you informed.
Have a good we,
Xavier
3 Likes
Hi @hpopols!
How is it going?
Could you share your progress?
Have the same things here, and going to implement something similar. Is canopen good enough?
Hi,
I am looking about the same things as you. I have the same requirements.
I just discovered HAPCAN : https://hapcan.com/project/basis/
1 Like
I reached this post looking for projects that could share my ideas on the field, also for my own home automation.
When researching for this Iāve reached very similar conclussions about knx (really expensive) , and about using can bus I totally agree. Iāve much experience using microchip microcontrollers from 8 to 32 bits, si I would like to know about your progress and ideally try to make some sinergy together and with other people that would like to join us in doing something like you propose.
We are 2 engineers , we work on embeddedd devices and as hobbies we already have some hardware design with dspic33 and pic32 using the microchip can bus modules and transceivers.
Iāts been about 10 months sin your post but may be you are still there
1 Like
maybe also worth checking is https://www.unipi.technology/ uses open source software and I assume low power as well.
1 Like
The device is not opensource, it provides an API and uses some extramodules but is propietary.
I was talking about doing something as a team to be shared among us and any that it is interested.
Of course if there is an Open Source project that is related or similar, is better to join such project but I havenāt seen one yet
PLS have a look at this device. Itās open source HW and SW.
https://ucandevices.github.io/uccb.html#!#python
Iām using it for other project and now want to connect my existing CAN device to Home Assistant.
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
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.
- 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ā¦
- 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
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. . However there is one drawback, I am not able to reprogram the ĀµC with my PICKIT3 without clearing the EEPROM
. 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
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