## 4 Implementation
### IoT Nodes
#### 4.1.3 Master Node  
The communications subsystem of a Master node is composed of a ZigBee and a WiFi module. Regarding the ZigBee module, the PRO version was not used in the HAS, since it is more expensive, consumes more power and, in ZiWi's design, the necessity for developing more features than the ones included in the default Xbee firmware was not planned (it is enough to configure properly the network and the analog inputs). As for the operating frequency, 2.4 GHz was chosen, although it would be straightforward to replace the Xbee modules with others working in the 900 MHz frequency band if the environment presents propagation problems. In relation to the WiFi modules, a NodeMCU module was used. Figure 10 shows the Master node's electronic schematic, which details how all hardware components are connected: the NodeMCU and the Xbee module exchange data through a serial connection, a piezoelectric buzzer is used as an alarm, and a power connector provides current through the micro-USB port of the NodeMCU. Figure 11 shows an actual prototype of the node. Figure 10: Electronic schematic of the Master node. Figure 9: Prototype of the sensor node. Regarding the software developed for the NodeMCU, it is aimed at performing two tasks as Master node:  
* To establish a serial communication with the Xbee module that acts as ZigBee coordinator. Note that in Figure 10 the pins RXD2 and TXD2 of the NodeMCU are used because RXD0 and TXD0 are dedicated to the serial connection of the NodeMCU with the USB. The frames received from the ZigBee network consist of several bytes that include information regarding different ZigBee fields. For example, a ZigBee frame generated by a node that collects data from a sensor connected to a single ADC input would be:
* [leftmargin=*] 7E 00 12 92 00 13 82 00 40 38 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83  
Computers (SBCs) that usually include a processor with the necessary processing power, storage capacity, small size, low-cost and reduced power consumption. Thus, there are devices like the Raspberry Pi Zero, the Orange Pi One or the CHIP that can be connected to the home network both through an Ethernet port or a WiFi adapter. There are also more powerful and less restricted devices like Raspberry Pi, Beagle Bone, Banana Pi or Intel Galileo. Among all these alternatives, the Raspberry Pi 1 model B+ was selected. While it is true that there are more recent hardware versions, this model has enough resources to respond quickly to events and requests that occur in a regular HAS. As an inconvenience, it is worth noting that it presents larger boot times than other SBCs when loading certain services, although, in practice, such services are not restarted frequently. It is important to note that ZiWi was designed to minimize the computational load on the IoT nodes, so the main software components are executed on the home controller. Among the open-source home controller software analyzed in Section 2.4, OpenHAB [107] was selected due to the following reasons:  
* It can run on any device capable of using a Java Virtual Machine (JVM). * It supports a really large number of technologies, so the number of potential devices to be integrated and combined to carry out home tasks is huge. * A growing community provides support to many ARM-based SBCs (e.g., Banana Pi, ODROID, Cubieboard...), while other platforms are focused almost exclusively on the different versions of the popular Raspberry Pi. However, note that OpenHAB was not conceived for providing fog computing applications, but its main features make it ideal for providing home automation fog services through local gateways:  
* It is designed to be completely vendor- and platform-neutral, without the need for using specific hardware or protocols. * It has a powerful rule engine. * It offers a flexible web-based user interface for PCs and mobile devices with different types of interfaces for managing dashboards, reports, configurations and performance benchmarks.