I personally would really like to see CANopen (or something similar) implemented in HA, because of all the points you just raised (versatility, low-cost, low-complexity)…
Most of these advantages are also pointed out in threads like mine HERE.
But all this would require, that the fundamental hardware is supported natively (or at least without a lot of tinkering). Setting up the higher-level protocols is then nothing more but how the data is handled. As you said, there are open source protocol stacks out there and they are proven and widely used. But for some reason CAN bus (and with it CANopen) has not made it yet into the “mainstream”, because it is still seen as a pure industrial bus (and in most cases it as seen as a automotive-exclusive bus).
@pergola.fabio has already done great success in communicating with CAN devices over his CAN-to-USB dongle. But he created a custom device with a REST API (IIRC, please correct me if I am wrong). But we both agreed, that this approach should not be the final solution, because there is just no real/nativ CAN support.
So from my point of view, the first step should be to have native CAN support onboard with all the underlaying data management, and having a dedicated CAN platform which then could be used by different components as described HERE. Note: just a proposition, not a solution.
With native CAN support we will be limited to 127 nodes, right?
What do you think about this concept?
Several ESPHome devices with ethernet (as Room Hub) and each one with their CAN BUS where all the sensors, switches or motor driver’s connects? The Room Hubs will then connect to Home Assistant by ethernet MQTT.
Only when it comes to basic CANopen. CANopen is kind of restrictive here.
CAN itself uses either 11 bit or 29 bit identifiers which are used for arbitration. This is the part in a CAN message that is important to talk to a specific node or in return to identifier which node has dropped the message to the bus. As you can see, 29 bit for node and/or message identification is really much.
I think that even 127 nodes will be hard to reach in a normal house. Lets see. Per room we assume a basic setup:
light switch (sensor)
light relay (actor)
window blinds switches (sensor)
window blinds motor (actor)
window open sensor
temperature sensor
Makes 6 nodes per room. Lets assume 10 rooms - and you still won’t hit the limit of CANopen. And of you can afford a house with 10 rooms you might also be able to afford KNX .
I personally decided to go for CANopen (or at least sticking close to it). In fact I created my current nodes by myself. This means that I decided to NOT separate switches and actors to individual nodes. As my window blinds switches will always be there in combination with the motor, I decided to make nodes which combine switches/sensors and the corresponding actors. So each window blind node provides access to switch/sensor states and the actor (plus node-internal stuff like operation time and so on…). So in my setup one single window node is enough for all stuff regarding that window.
When I have finished my setup I will share it here.
My system is not ready, yet. What I have is two prototype boards which work as expected. Also the software is working, regarding it’s basic functions. This includes CAN communication in CANopen style (means I do not cover everything to declare my nodes as “official” CANopen compliant, but regarding they behave very similar), moving covers by wall switches or alternatively by positioning commands from HA, reporting information about position, IO states and temperature to HA.
Currently I am writing a routine for a semi-automated learning of the times needed to roll the shutter up or down. This information is needed for position calculation. Currently this information is given to eah node by a write-SDO to the corresponding object in my CANopen object dictionary. Later both methods will work (sending roll-times via CAN or learning it).
I do NOT use ESPhome, because the current CAN implementation seems not to be what I want.
I have programmed an ESP8266 to be a “transparent” MQTT-to-CAN gateway. The CAN identifier is the last part of the topic and the CAN data field is the payload, separated byte-wise by a comma or semicolon.
Maybe ESPhome could do this, too. I just don’t know. But my self-written solution is already relatively old. At that time ESPhome did not support CAN, yet.
So my system is not finished, yet. But the software-side already works and the hardware is working with two prototypes.
Why you do not use current CAN implementation? I’m planing to use it and wanted to find out if any issues. I’m thinking to use STM32 chips. I looked already and it seems pretty good. I have a plan to design few boards and order them on jlcpcb or pcbway. What I liked about jlcpcb is that you can preview the parts they have and the prices
2 most important things for me is STM32Fxxx JLCPCB SMT Parts Library & Component Sourcing
and MCP2551-I/SN | Microchip Tech | CAN ICs | JLCPCB to make connection
In theory The performance of the STMF0 will be enough but not sure if the flash size is enough for a program. I did not like the way STM chips are programmed, the IDE for this chips and what people do was really ClickOps (to many clicks before you even start programming). May be it was possible to do another way. I hope that the clicks they did turned out into a code which does some setup using some sort of enum values. I did not finish watching. I hope I can program using Rust. I wish to learn Rust as my background C#/F# and C++
Hi and nice to see that this topic is still interesting to some people .
Why I don’t use the ESPhome CAN implementation? Three easy reasons:
no time (of course )
no clue about how to implement it
no need because my current solution works
Reason 2 is the main reason. What I currently have is a fully transparent MQTT-to-CAN gateway (GitHub - Jojo-A/MQTT-CAN-Gateway: A fully trasparent MQTT-CAN gateway).
So for the ESPhome solution, I would need to set the CAN bus filters so that it accepts any CAN message and converts it into an MQTT message of a specific layout (CAN ID part of the MQTT topic and CAN data field split into bytes and put into the MQTT payload). As I understand the ESPhome documentation, this all must be done in “lambdas”. And now reason 1 kicks in: I had no time to dive so deep into the docs and the lambdas.
I have also created custom PCBs for my application. Beside all other stuff, the PCBs carry the MCU board (STM32F103 bluepill). have created them with KiCAD and ordered via PCBWay.
See photos (current installation, eight of these boxes, one per window).
Don’t be too confused by the ST development environment. Yes, the STMCubeMX requires a few clicks. But it makes your life sooo much easier compared to studying datasheets, register descriptions and so on. CubeMX generates the initialization code for you and the rest can be written “by hand”.
So back to your question: sooner or later I will maybe switch over to ESPhome, but not yet.
Yes, I need some help. Never did design PCB. I only did manually when I was teenager in high school. I used nail polish to draw connections and then put in FeCl3 to remove copper.
When I saw video guy was saying how to locate elements manually and draw connections manually. My question why he did this manually? I believe there should be an automatic placement and drawing connections should be done automatically.
The other thing is why you have chose a full bluepill board instead of taking just a chip and putting whatever is required? I’m thinking to go chip route instead of board.
I’m planning to make a kinda generic board with STM32 , which will have
step down controller to drop voltage from 23V to 3.3V
connectors for 4 PIR sensors
controlling 6 LED lights ON/OFF with ability to raise voltage from 6 to 12V for dimming
6 pin connectors to control relays or solid state relays
mcp2551 for can
extensions for sensors
I have not made decision about wired connectivity.
I have already Cat6 but I really don’t like it as it is single wire and can break. But from the other side I have 4 extra wires for the case if I need anything. But I really don’t know what I may need. I only see 2 wires CAN and 2 wires power 20V. All data I can pass via CAN bus so technically I do not see anything what I need to have use for these 4 extra wires.
This is an interesting thread. I did some HA stuff a couple of years ago to add automation to my Mitsubishi heat pumps used for winter time heating.
Our house has a Lonworks based system that controls lights/ security/ occupancy etc, that is years out of support and the original installer and vendors are out of business. The good thing is that the RS485 TP (signal plus DC power) cabling already exists and would be usable for a CANBus based replacement. I’ve looked at KNX and reluctantly ruled it out due to the proprietary nature and cost.
I’ve bought a starter kit from omzlo for their NoCan project and experimented writing some code/tooling to sit on top of their protocol to do things like configuration time binding of input/output nodes. E.g. a light switch being able to control a/several lighting circuits (on/off/dim etc) and the output node sending status feedback to all switches bound to that dimmer channel.
I’ve used the existing Lonworks concept of network variables to get me started as this provides a standardised was of describing and binding devices together.
My next step is to build some actual hardware (4 channel trailing/leading edge dimmer, 3 channel relay, 6 channel switch input node) so I can set up a small test system and get some electrical safety assessments done. The output nodes all reside in a couple of DIN rail cabinets, and the switch nodes (including occupancy/temp etc) are in wall mounted flushboxes. I can reuse the existing switch plate hardware, with a new NoCan node behind.
Anyway, if anybody is interested I’d be happy to share what I got up to so far. My next step is to build the evaluation boards for the dimmer design and stress test them (PCBs arrived last week)
@fastbike I’m interested since I’m still looking for a solution for the problem in my house: an old home automation system is failing and I only have 2 wires available in a bus network behind each switch. I would be happy to learn more from you.
By two wires, is that 2x twisted pair (i.e. 4 wires total) or just two wires ?
I have a TP of around 24awg which are used for the signal, and a thicker pair which I’m guessing would be around 18awg used for the power.
For background, my current system has around 50 input nodes (switches, indoor occupancy, indoor security, temp sensors, outdoor occupancy, smoke sensors etc) and around 30 DIN rail mounted output nodes (a mixture of 4 channel mosfet dimmers, and 3 channel bistable 16A relays). I’m looking to replace this hardware.
The NoCan design appeals to me as it is fully open source, and allows for over the wire node firmware updates/configuration.
I’m wondering if I should start my own thread rather than hijacking this one ?
@fastbike there are 4 wires, but only 2 are patched consistently.
I have 102 switches, divided over 56 wall boxes.
(let’s start a new thread indeed)
@pergola.fabio yes it is failing, and it will cost me at least 3-5k to replace the old Dobiss system with new Dobiss hardware. So I’m not quite happy with that as you can imagine.
They say that it is normal because it’s 20 years old.
My wall switches randomly don’t respond or switch other lights than the one they are configured for. And this is getting worse and worse.
So I have to replace everything…
You make me nervous. My dobiss is already 25 years old! It’s a dobissII upgraded with a Max200 10 years ago.
But I’m rather surprised : the technology behind the push button is rather simple. Are you line(s) for the buttons connected to the relay module or directly to the CPU? Do you reboot the CPU?
They are simple indeed, but according to Dobiss it’s ‘normal’ that they show this kind of behaviour after so many years.
I’m not sure what you mean with CPU? My buttons are connected to the 6 boards I have in my cabinet.
.
.
)
