##Hardware architecture The hardware architecture of the system may be pictured as follows (click on the diagram for a bigger image):
General architecture overview
Every block represents a physical entity of our system, every line a physical connection between them.
The description of most interesting blocks follows.

###Central Raspberry PI The central Raspberry PI will be in charge of running the core process, control the output lights and sounds, fetch information from the input through APIs and run the web-application acting as server.

###Connections The connections linking the central Raspberry PI to the buttons and to the speakers will be realized through wires. On the other hand all the lines having the label “LAN” or “Internet connection” could be implemented in both way wireless or by means of wires.

###Buttons The only hardware components developed by ourself will be the two buttons. The will be realized in a very simple way, we are going to use a pull-up resistance of about 4.5-5 kOhm, a capacitor in the order of hundreds of nF acting as debouncing element and the button itself.
Note that is possible to add easily a flipflop as buffer if the process on the PI checking it turn out to be so slow to miss in some input.

###User Device A very important choice of our design has been decide not to create an application for a smartphone as user interface, but a web-application. This choice let the user freely decide which Device to use in order to control our system: a computer, a tablet, smart tv, so and so on!

###Top-Right Raspberry PI The Raspberry PI you can find at the top-right of the image will be the middleware between us and Z-Wave and ZigBee products. It will act as both: server running the Dog Gateway and client fetching data from devices

##Software architecture The system has been developed mostly thanks to python for the core, javascript and Django as framework for the database and web application The software architecture of the system may be pictured as follows (click on the diagram for a bigger image):
General architecture overview

Every block represents either a process of our program or a function that can be recognized by the presence of the brackets, every line is a function call or a fork of the current process.
The description of most interesting blocks follows.

###Core Process This process will control every function and process of the system and it will always be running in our program.
It is in charge of retrieving information from Facebook, Google calendar and Dog Gateway calling the methods able to fetch these data.
Once this operation is performed the core will compute priority of each notification by means of an algorithm inside manage() method that takes in account user’s preferences, past conversation and events of the user, then it will decide if it’s time to display a notification or not.
If it’s time to display the notification, it will call the output_proc() method that will take in account how to display it. After that the core updates its own algorithm by means of the new retrieved data and loops again.

###Output_proc methods This method receives a dictionary containing all the information about the notification to be shown and in which way to display it and has to decide how to perform this action looking to room conditions, user settings and to user calendar.
Output_proc has access to the database and to the timesystem in order to find the most suitable way to act on lights and with sounds. For example a user managing settings could decide not to be bothered by a particular type of notification, by some user or during a determined hour. Moreover the process always check that somebody is inside the house and that there is light inside the room. Even lights or sounds could be completely deactivated if the user prefer this configuration.

###Dismiss Button Process This process, created as soon as a notification is displayed takes care to poll the pin connected to the button. If the user press that button the notification is stopped, an exception will be sent do the core that will handle it; the default action is to don’t bother the user with new notifications for one hour.

###Input Methods Input methods are in charge of retrieve data from respective servers through APIs, update the database, construct notification and send information to the core process.

###Database SQL lite database containing all the information about the user and about the room condition, periodically updated by core methods. Implemented through a Django framework and stored directly into the pi. The stored data will be kept even in case of failure or in case of power off of the system.

###Web Application Where a normal user can easily act on settings, add new contacts or events. The possibility to set an alarm has been introduced as well as the possibility to display the whole calendar. Moreover Room conditions and related notifications are always visible at the top-right of the page