How long can the control cable be without errors?
Installed runs reach 20 m straight-line and 50 m including branches; a 100 m spool passed lab tests without data loss [Elektroda, nuclear, post #21532172]
Modular home automation system
Hi,
I have finally decided to share the design of a home automation system that I have implemented at my home and has been running successfully for several years. To begin with, I would like to describe the assumptions and general outline of the whole thing and in the following parts I will focus on specific parts.
.
.
Design assumptions
The project is not new, the first elements started to be created about 10 years ago, and the whole thing has evolved since then but the main assumptions and communication protocol have remained unchanged. The aim of the project was to create a low-cost yet easily expandable home automation system from scratch, originally for lighting, with the possibility of expanding as required. Because of the price, I decided on a distributed topology with wired communication, i.e. one main control module and simple actuators connected to it by a control cable, placed where they are needed, e.g. directly at buttons and receivers. As a result, the routing of power cables was simplified - only the control cable is led to the light switches and the relays are placed in boxes on the ceiling directly next to the lamps. The second consideration was flexibility, i.e. the possibility of moving and attaching new modules. To this end, I decided to use a protocol allowing for multiple modules connected to a common bus. The system had to be as cheap as possible, so I decided to use one of the cheapest uCs I was already familiar with at the time, the Attiny family, in the modules. As I didn't expect to need to achieve any crazy transfer rates - after all, what does it take to switch on a light or send data from some sensor - I decided to experiment with a simple 4x0.5mm intercom cable, where 2 wires will be used to power the modules and 2 will be used for communication.
Communication protocol basics
With these assumptions, I decided to use the USI peripheral chip implemented in Attiny and implement CLK + DATA synchronous serial communication, a bit like I2C with changes to allow the transfer to be initiated by each module, with simultaneous collision detection.
The CLK signal is given by the master module and it also transmits the frame start signal, so it is basically a slotted bus network. The low clock frequency (about 5kHz in the current version) makes the signal propagation time on the bus negligible, which also made it easier to implement collision detection. This is implemented in such a way that each module has a unique 8-bit address on the bus and this is transmitted as the first byte of the frame. In combination with the fact that each transmission is started by the control module, we obtain an address competition and in the event of a collision - i.e. more than one module starts transmission at the same time, all but one module that wins will notice the collision and cease transmission. Of course, this causes some modules to have priority over others, but with the number of frames being transmitted, this does not matter much. The master module always has its address at 0x00, which means it always has the highest priority in transmission. The simplicity of the algorithm has made it possible to fit the programme into modules of less than 2kB while maintaining high transfer reliability. the number of theoretically supported modules on the bus is 254 (addresses 0x00 and 0xFF are not allowed) but this can be increased by using several buses, the current implementation of the control module supports 8 buses. Each module has a unique permanently programmed 32-bit address, the 8-bit address is not permanently assigned to the modules - it is assigned by the master module during initialisation. The purpose of this solution is to shorten the transmitted frames.
I/O modules:
To date, several types of executive modules have been developed, the basic ones being input modules - 3 channel and 6 channel - and output modules - with 2 and with 4 relays. In addition to these, single modules have been developed that support 8 outputs and combine input and output functions. Another module is a module for humidity and temperature measurement, it supports the DHT11 and DHT22 sensors. There is also a module for atmospheric pressure sensor and a module with 3 PWM outputs for controlling RGB led lines. More modules are planned, for example for measuring electricity consumption. Despite the small flash memory, I managed to pack in the most important functions in the programme, such as error checking, retransmissions or protection against duplicate frames. The programme has been running for the last 10 years without any changes, mainly because any changes would require the extraction and reprogramming of all the dozens of modules buried in the boxes; so far I have not found a bug requiring such a service action. Below I give a schematic diagram of the pushbutton module, the number of components is minimal which translates into the price and size of the module.
.
Control module:
This element of the system has the most eventful history over the years various versions were created in succession and of course each time it was to be the final version, well that I like to experiment and improve so changes were inevitable. The first versions were realised using an Atmega32 uC, which worked but was quite simple and slow, then I moved to ARM chips, which made the whole thing work smoothly, and most importantly, the possibility of communication via ethernet appeared, which made it possible to realise a simple http server and support for an SD memory card.
The main module in the current version is based on the STM32H725 chip. It supports 8 buses. An ethernet input supporting http, telnet and ftp protocols is used to configure and communicate with the module - operation is possible from a web browser and via a telnet terminal. An SD memory card is used to store data collected from the sensors and html files, the basic system configuration is stored in the uC's flash memory for greater reliability. The power supply part of the module, in addition to the inverter that provides power to the entire network, also contains circuits for measuring voltages and currents at important points in the module and a module that supports a gel battery to power the system in the event of a mains power failure. The software is based on the FreeRTOS real-time system and uses the HAL library, the rest of the code is already written by me from scratch. Below is a schematic diagram of the main module.
.
.
.
.
Next time I will describe in more detail what the communication protocol looks like, what frames are transmitted.
If someone is not afraid of messing around and would like to see the soft for the executive modules and for the main module, it can be found on github. There is also a project of the main module board there in KiCad format
https://github.com/r-gal/LON_devices/
https://github.com/r-gal/LON_v2/
https://github.com/r-gal/CommonLibs_v2/
I have finally decided to share the design of a home automation system that I have implemented at my home and has been running successfully for several years. To begin with, I would like to describe the assumptions and general outline of the whole thing and in the following parts I will focus on specific parts.
.
.
Design assumptions
The project is not new, the first elements started to be created about 10 years ago, and the whole thing has evolved since then but the main assumptions and communication protocol have remained unchanged. The aim of the project was to create a low-cost yet easily expandable home automation system from scratch, originally for lighting, with the possibility of expanding as required. Because of the price, I decided on a distributed topology with wired communication, i.e. one main control module and simple actuators connected to it by a control cable, placed where they are needed, e.g. directly at buttons and receivers. As a result, the routing of power cables was simplified - only the control cable is led to the light switches and the relays are placed in boxes on the ceiling directly next to the lamps. The second consideration was flexibility, i.e. the possibility of moving and attaching new modules. To this end, I decided to use a protocol allowing for multiple modules connected to a common bus. The system had to be as cheap as possible, so I decided to use one of the cheapest uCs I was already familiar with at the time, the Attiny family, in the modules. As I didn't expect to need to achieve any crazy transfer rates - after all, what does it take to switch on a light or send data from some sensor - I decided to experiment with a simple 4x0.5mm intercom cable, where 2 wires will be used to power the modules and 2 will be used for communication.
Communication protocol basics
With these assumptions, I decided to use the USI peripheral chip implemented in Attiny and implement CLK + DATA synchronous serial communication, a bit like I2C with changes to allow the transfer to be initiated by each module, with simultaneous collision detection.
The CLK signal is given by the master module and it also transmits the frame start signal, so it is basically a slotted bus network. The low clock frequency (about 5kHz in the current version) makes the signal propagation time on the bus negligible, which also made it easier to implement collision detection. This is implemented in such a way that each module has a unique 8-bit address on the bus and this is transmitted as the first byte of the frame. In combination with the fact that each transmission is started by the control module, we obtain an address competition and in the event of a collision - i.e. more than one module starts transmission at the same time, all but one module that wins will notice the collision and cease transmission. Of course, this causes some modules to have priority over others, but with the number of frames being transmitted, this does not matter much. The master module always has its address at 0x00, which means it always has the highest priority in transmission. The simplicity of the algorithm has made it possible to fit the programme into modules of less than 2kB while maintaining high transfer reliability. the number of theoretically supported modules on the bus is 254 (addresses 0x00 and 0xFF are not allowed) but this can be increased by using several buses, the current implementation of the control module supports 8 buses. Each module has a unique permanently programmed 32-bit address, the 8-bit address is not permanently assigned to the modules - it is assigned by the master module during initialisation. The purpose of this solution is to shorten the transmitted frames.
I/O modules:
To date, several types of executive modules have been developed, the basic ones being input modules - 3 channel and 6 channel - and output modules - with 2 and with 4 relays. In addition to these, single modules have been developed that support 8 outputs and combine input and output functions. Another module is a module for humidity and temperature measurement, it supports the DHT11 and DHT22 sensors. There is also a module for atmospheric pressure sensor and a module with 3 PWM outputs for controlling RGB led lines. More modules are planned, for example for measuring electricity consumption. Despite the small flash memory, I managed to pack in the most important functions in the programme, such as error checking, retransmissions or protection against duplicate frames. The programme has been running for the last 10 years without any changes, mainly because any changes would require the extraction and reprogramming of all the dozens of modules buried in the boxes; so far I have not found a bug requiring such a service action. Below I give a schematic diagram of the pushbutton module, the number of components is minimal which translates into the price and size of the module.
.
Control module:
This element of the system has the most eventful history over the years various versions were created in succession and of course each time it was to be the final version, well that I like to experiment and improve so changes were inevitable. The first versions were realised using an Atmega32 uC, which worked but was quite simple and slow, then I moved to ARM chips, which made the whole thing work smoothly, and most importantly, the possibility of communication via ethernet appeared, which made it possible to realise a simple http server and support for an SD memory card.
The main module in the current version is based on the STM32H725 chip. It supports 8 buses. An ethernet input supporting http, telnet and ftp protocols is used to configure and communicate with the module - operation is possible from a web browser and via a telnet terminal. An SD memory card is used to store data collected from the sensors and html files, the basic system configuration is stored in the uC's flash memory for greater reliability. The power supply part of the module, in addition to the inverter that provides power to the entire network, also contains circuits for measuring voltages and currents at important points in the module and a module that supports a gel battery to power the system in the event of a mains power failure. The software is based on the FreeRTOS real-time system and uses the HAL library, the rest of the code is already written by me from scratch. Below is a schematic diagram of the main module.
.
.
.
.
Next time I will describe in more detail what the communication protocol looks like, what frames are transmitted.
If someone is not afraid of messing around and would like to see the soft for the executive modules and for the main module, it can be found on github. There is also a project of the main module board there in KiCad format
https://github.com/r-gal/LON_devices/
https://github.com/r-gal/LON_v2/
https://github.com/r-gal/CommonLibs_v2/
Comments
Thanks for sharing the project, it's nice that you call it real and don't succumb to fashion - home automation, not marketing smart home. I will tell you that creating a home automation that will work... [Read more]
Interesting, everyone has practically thought about it but few have realised :) . Idea, design, realisation, corrections, trouble-free operation, these are the next rungs and each one is an order of magnitude... [Read more]
Thanks for the good word, I think several factors contribute to the stability of the system's operation, above all the simplicity of the protocol and the use of wired communication. I will now briefly... [Read more]
What is the longest cable between the control module and the executive module? [Read more]
. Currently, the distance from the control panel to the furthest module is about 20 metres, but taking into account the branches, the total cable length on the most extended bus is about 50 metres. However,... [Read more]
Thank you very much for your extensive and detailed explanations. Congratulations on your determination and cool project. Is it possible to make available also an older version under atmega32? Perhaps... [Read more]
I will look for the sources for this version but, as far as I remember, it was not yet a sufficiently stable version and would need to take into account later patches. [Read more]
Sure. Thank you in advance. [Read more]
It would be cool to record a podcast with you, you can see you really know each other and the project is really interesting. All you need is a microphone. [Read more]
In this section, I will focus on the core module itself. The main functions of this module are: -Operating the actuator modules, i.e. detecting them, configuring them and cyclically checking their... [Read more]
I am interested :-) . [Read more]
How much power does this system consume? How often is it useful to have the function of switching the lights on and off in the room while you are out? (It seems to me that most of the installation cost... [Read more]
With the lights off about 5W measured after the power transformer, Each light on adds 120mW to this to power the relay. Modules with bistable relays could be considered, especially for outputs that are... [Read more]
Tie it through some simple router with openwrt and the way to the world open with tunnels ;) [Read more]
And what happens when different settings switch the same output? I understand, although the history of w(y)-connected outputs can be useful for looking for anomalies in the operation of appliances,... [Read more]
. I didn't design it for such an application, but as I think about it, it should conditionally work. If the reading is inside the hysteresis, then there is no problem for another source to override... [Read more]
I am adding the promised short description of the code structure in the main module. With this level of complexity, I decided to use a real-time system, I chose the already known FreeRTOS. This allowed... [Read more]
Hi, As there has been a request to be able to provide a simplified version for a different uC I will provide a short instruction on how to customise the project. Generally in the current version two... [Read more]
Hi, I've finally put together a short description of the most important commands, I haven't yet described here the commands for networking, sockets etc, I'll do that as I'll be describing how to include... [Read more]