And finally came the part that makes sense of everything. A central computer that receives events from all installed vesta devices, sends data and reads information at the user’s request. The Vesta philosophy considers that the data must reside in each module and the computer link allows them to be read and written transparently. To do this, each device is replicated in the structure of the home automation project, already detached from the physical dependence on the module to which it belongs.

The “controller” device is responsible for managing the low-level tasks (encoding, sending, receiving and decoding), so that replicas of the data from the physical device will reside in each logical device. In the same way that a vesta device is created by this same compiler, the hierarchy of classes that link to it is created by the compiler itself. In this way, if a new type of device appears or if a new version of an existing one is released, the compiler will be in charge of providing all the functionality so that both link perfectly.

The milestone that has been achieved today is the generation of this code, fixing all the syntax and semantic errors that have appeared. There are still structures to replicate (arrays, structure vectors and floats), although they will be left for later. The next step will be to implement binary socket communications between the server computer and the Vesta module. This phase is actually two: The first is device discovery and the second is communication itself.

Vesta has two types of messages. Those of data request, sent in TCP packets and device events, in UDP packets. There are two types of events: “heartbeats” and simple events. Heartbeats are cyclical pulses that devices emit so that the server is informed of which devices are working. A timer for each device will allow knowing which of them has stopped emitting pulses, even if there are no events.

Local and Remote modes

Vesta devices incorporate their own time counter, which is reset every time they receive a packet from the server. After the preset time, a device that has not received information will go into local mode, which defines an alternative behavior totally different from online mode. A new data packet received while in local mode will be enough to return to online mode, automatically, without user intervention. The goal is for the home automation system to be managed automatically without human intervention and to adapt to the network circumstances in every moment. The goal is that both the server and the modules under control are aware of any network failure and act accordingly.