This last section presents a simple building automation system that can also be used for home automation. As a matter of fact, a set of system’s features were defined having the application at residences in mind.
Again, it is an academic prototype that has been developed at UNINOVA, Portugal, and offers the benefits of presenting associated key concepts without problems with trademarks and proprietary solutions.
The system is based around a low-cost microprocessor based controller, named as TinyDomot (the name can be seen as an acronym for Tiny Domotic Robot), that can be remotely monitored and configured. The network of TinyDomots can be seen as an example of distributed automation system.
All controllers and adaptors were developed using low-cost micro-controllers, with free-of-charge or low-cost development environments, in order to allow their usage by a wide number of users. In fact, each TinyDomot is developed around a Microchip PIC microcontroller (although the port to a different platform based on the Atmel ATmega128 is under way).
The TinyDomot controller
Two types of TinyDomots are foreseen:
- To allow direct interaction with users;
- To be embedded into equipment or into an appliance.
Each TinyDomot of the first type can have a simplified user interface, composed by keyboard and display.
In this sense, usage of TinyDomot can be very flexible; it ranges from being completely embedded into an appliance (for instance a light bulb), where the only communication with the user is accomplished through the communication network, to a device for direct interaction with the user, as a small controller centre including touch-buttons or switches associated with the main appliances of the room (or of the floor), like lighting, HVAC, and so.
Each TinyDomot accommodates several inputs from sensors (temperature and light sensors, presence detectors, and so), and outputs to actuators (lamps, fan, several equipments), and can be equipped with one network interface.
Among the main features of the TinyDomot controller, we can refer to a set of functionalities targeted to home control and monitoring. As an example, we can refer to the capability to associated one specific TinyDomot input to a set of outputs in the TinyDomot network; in this sense, we can actuate on an input of the TinyDomot located in one room and switch off the lamps in several locations (if they are switched on), like garage, hactic, and so, in order to prevent energy’s waste due to forgetfullness.
Another example is the capability of programming periodic events associated with specific outputs (like lighting on and off a set of lamps during holiday period to simulate owner’s presence, or to switch on and off HVAC equipment in a regular basis during working days, assuring that the HVAC equipment is switch on/off one hour before/after regular working hours).
In this sense, every TinyDomot can broadcast commands to the network, addressing a specific TinyDomot, whenever an event occurs. This means that the network is not working in a master-slave basis, but in a peer-to-peer basis.
Topology and connectivity
The structure of a network of TinyDomots is shown in Figure 1, where some workstations are also presented.
Several communication supports are possible, from high-speed LAN (Ethernet), to dedicated low-speed LAN (RS-485), wireless and through power-line distribution lines.
Specific adaptors making the bridge between the different sub-networks are available (bridging wireless and power-line, point-to-point RS-232 to multi-drop RS-485, and so on).
It has to be noted that as far as each physical media has a specific rate for data transfer (for instance, RS-485 or power-line), the adapter has to implement a functionality of traffic manager, buffering commands from slower media into faster media support.
Figure 1 presents several connectivity possibilities. Anyway, each TinyDomot will have a unique address in the network, which allows him to receive commands from the other controllers.
Remote access for monitoring or for configuration is possible from a workstation connected to the network or through an internet connection.
Figure 1. Topology of the network for home appliances control
A case study – architecture
For the current section, a specific TinyDomot network set-up is considered, installed at the building of UNINOVA (the same building already referred in a previous section).
For didactic demonstration purposes, three building systems are considered:
- Lighting system, considering that every office has one light and one switch for control;
- HVAC system, considering that every office has the capability to switch on or off its own equipment;
- Intrusion detection system, considering that every office has one presence detector installed; it is possible to individually switch on and off the power to every presence detector; there are also several presence detectors installed in common areas and corridor.
One workstation (PC running Windows) is responsible to allow configuration of the controllers in the network, and also to provide internet connectivity (this means that an http server is running in the workstation, allowing the usage of a browser in the remote workstation to have access to the TinyDomot controller network).
One TinyDomot controller is associated with every two offices, which means that out TinyDomot network is composed by nine controllers. The TinyDomots are interconnected through a RS-485 network, which imposes the usage of a specific bridge between the serial-line interface provided by the PC (a point-to-point RS-232) and multi-drop serial-line interface RS-485.
Figure 2 illustrates the topology used in the application.
Figure 2. Topology to be applied to a floor at UNINOVA building
A case study – synoptic
Figure 3 presents a user interface containing a synoptic for building monitoring that can be accessed remotely (through the internet) or at the workstation managing the configuration of the TinyDomots network.
Each office has representations for the appliances installed there, namely:
- One light, that can be turned on (yellow state) or off (brown state), and associated control switch;
- One HVAC equipment, that can be turned on (light green state) or off (dark green state), and associated control switch;
- One presence detector, which has a status led (red for active state and brown for non-active state), and an associated power supply control switch (light green state when switched on, and dark green state when switched off).
Figure 3. User interface
A case study – operation
Every switch can be individually turned on or off remotely; also the state of every appliance can be remotely sensed and updated in the synoptic. This is accomplished using specific messages through the network.
Figure 4 presents the overall architecture of the case study TinyDomot system. In order to allow a better interaction by the user exercising the system (not disturbing actual occupants), an emulator board, which mimics building appliances, was prepared containing emulators for the referred appliances. The TinyDomot controllers are directly connected to this emulator board.
Figure 4 Case study system architecture
The general structure of a message flowing in the TinyDomots network is the following:
- Starting preamble (1 byte);
- Total number of bytes in the message (1 byte);
- Address of origin (2 bytes, being the low byte first, and high byte after);
- Destination address (2 bytes, being the low byte first, and high byte after);
- Type of command (1 byte);
- Associated data (1 byte);
- Cyclic redundant code – CRC (1 byte).
As a simple example of the type of messages that can flow through the network, we can consider the following message to switch on the light of office 2.13:
After the reception of that message, the TinyDomot in charge of office 2.13 will reply acknowledging message reception, through the following message:
A case study – future trends on didactic aspects
The set-up presented in previous sub-sections can be enlarged covering new building systems and adding new functionalities (with interest for new didactic exploitations).
In the following considerations, we intend to address two different types of experiments in order to reach different levels of exploitation, namely:
- First level is based on the remote control and monitoring of already available systems (as described in the previous sub-sections);
- Second level foresees (limited) remote configuration, reconfiguration or/and reprogramming of specific sub-systems.
Clearly, first level is associated with “regular” users, supporting remote operation and “play for fun” (like the one presented in Error! Reference source not found. and Error! Reference source not found.), while second level supports intermediary and advanced topics where the users can change configuration (at some extend).
In the following, some specific potential developments will be commented.
The first situation is considering the TinyDomot functionality associated with the heating, ventilation and air-conditioning control system (HVAC equipment), where three levels of didactic exploitation can be foreseen:
- At the introductory level, the user can only monitor house variables for every room; as in the previous example, it is possible to know the status of the equipments and switch them on and off; another possible monitoring activity is associated with the visualization of the current value for temperature and humidity, for instance;
- At the intermediate level, the user can change the set points (desired temperature) and operative modes (week-days, week-ends, holidays, and so);
- At the advanced level, the user can change everything, even the control algorithm (from a PID controller to a fuzzy controller, for instance), through the reprogramming of the associated controller. Afterwards, the user can access to the variable evolution and conclude about the effectiveness of their control strategies. For this level is necessary to have full control access to the equipment (which is not an easy procedure, normally).
As a second example, we consider the access control subsystem, which was not included in the previously presented case study.
At the first level (introductory level), the user can remotely monitor the activity of the different access control controllers (registered entrances and exits, for instance). Although, at the second level, one can change configuration of specific access control sub-systems in several ways, for instance:
- We can change the users’ database characteristics, namely users and associated privileges (intermediate level),
- We can change parts or the whole controlling program, as far as the system supports dynamic reconfigurability (advanced level). This feature will allow the user to download specific control strategies to the controller. As a specific example, one can think about a different algorithm to be used for biometrics identification, for instance, through hand-geometry or fingerprint recognition (just to mention a few).
In this way, the referred experiments can accommodate didactic support for a large spectrum of system designs in the building automation systems area.