Linux and RTAI for Building Automation
The main control task, the network access-control task and the software driver for the physical layer of the RS-485 network are the tasks that run in the real-time executive. An RS-485 driver was developed for RTAI. This driver is similar to any other serial driver, except for the 9th-bit protocol used in this application, as described above.
The other real-time task is the network access-control task, which is in charge of periodically sending packets to each network node. This packet can be a command to generate an IR signal, a poll to see if the node is active or a command to the microcontroller to transmit the actual room temperature. The node answers with an acknowledgement to the first two types of packets and with the actual room temperature to the last one. The information about the actual state of every node is available to the main control task, which in turn informs the user interface if a node fails.
The main control task, using information retrieved from the database, operates the air-conditioning equipment in the building, as programmed. This task also can receive instructions from the user interface that overrides the programmed configuration, using two RT-FIFOs. RT-FIFOs are an interprocess communication routine for communication between real-time tasks and normal Linux tasks. To communicate with the PostgreSQL database, a Linux dæmon was developed. This dæmon communicates with the main control task using two more RT-FIFOs. An additional important function of this dæmon is to send to the main control task the system date and time; no support for reading it exists in RTAI.
The developed system sends commands to the air conditioners, eliminating the need for local remote controllers. We do not interfere with the air-conditioner temperature control system, nor do we touch any internal circuitry. Each air conditioner has its own temperature control system built-in, and the temperature sensor in each microcontroller supervises that the equipment is working fine. Figure 4 shows the microcontroller board installed.
The Linux tasks are in charge of presenting the user interface through a Web server and running the PostgreSQL database engine, which is the main data repository. As described above, another Linux side task is a dæmon used for the RTAI main control task to access the system date/time and the database.
The user interface is simple. The first page presents information about the actual state of each air conditioner. Every type of user can access this page. In order to change the program or send commands to a particular air conditioner, the system asks for a user name and password. PHP is used to generate the Web pages dynamically to present the information retrieved from the database.
In the PostgreSQL database, the system stores general information about the air conditioners, such as BTU, location, brand and microcontroller network node address; the programmed operations; and the IR commands needed to operate each air conditioner.
An important part of the system is the module that reads the air-conditioner remote controller signals and stores the information, associated with the corresponding equipment, in the database to reproduce it using the networked microcontrollers. This module is used only when adding a type of air conditioner that has a different brand and/or different remote controller commands.
Two tasks are part of this module: the first is a real-time task that reads the IR signal. The LIRC Project as well as the Ripoll and Acosta paper in the on-line Resources, present detailed information about IR remote controllers and sample implementations using normal Linux and RTLinux, another real-time executive for Linux. The other task for this module is the user interface that runs on Linux. The two tasks communicate using an RT-FIFO.
Due to the small amount of RAM available in the microcontroller and the long IR signal duration, an important function of this software is to help the user obtain repetitive patterns within the different IR remote controller signals associated with each button or combination of buttons. These patterns are coded in the firmware of the microcontroller and are used to reconstruct the command to control the equipment. For example, if there are ten different patterns, the information sent to the appropriate microcontroller in the network is something like: repeat pattern one ten times, then pattern two three times and so on, until the complete command is reconstructed. This technique has the advantage of using fewer resources for signal reconstruction. The disadvantage is the software of the microcontroller needs to be changed to introduce the patterns of the newly added equipment whenever a new air conditioner is introduced.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide