Étape 2: Serveur nœud mise en œuvre de la PPA
Comme nous l’avons vu il y une autre couche de réseau entre les utilisateurs finaux c'est-à-dire les gens du commun et de la wsn. Cette couche se compose d’un serveur ou les nœuds de serveur. Notre idée était d’avoir une batterie de serveurs qui coordonne le wsn toute la région pour une réponse plus rapide. Pour le prototype modèle en raison du manque de ressources et de durée de la seconde couche a un nœud de serveur unique. La principale raison que nous sommes allés pour un nœud de serveur est de fournir qu'une interruption basé système et système en temps réel comme la question que nous nous efforçons de traiter est sensible et décalage dans le temps n’est pas toléré.
L’idée est que la couche inférieure de WSN de transmettre les objets JSON vers le nœud de serveur à un rythme constant, c'est-à-dire le débit moyen de l’eau (en corrélation avec la pression) et la teneur en humidité du sol. Nous avons ensuite convet les objets JSON au format csv format et puis le charger à la base de données. La structure de fichiers de base de données et de la réception du code de données de capteur est inclus dans les fichiers.
Nous sentant le débit d’eau moyen par minute et ensuite comparer avec moyenne jusqu’ici, que nous déciderons si le niveau d’eau est alarmant ou pas. Ensuite, nous avons le système d’alerte basé sur le module IFTTT du boulon unité de traitement. Le mieux adapté à capteurs étaient des capteurs de débit de l’eau et les sonars car ils sont un moyen plus précis de la profondeur de l’eau qui est un facteur majeur dans la détection des inondations. Puis nous avons déménagé à tracer des graphiques en utilisant les données que nous avons stockées à l’aide de terrain gnu qui sera ensuite chargé sur le portail web de l’utilisateur final a expliqué dans la section suivante. Implémentation de nœud de serveur Structure de SGBD
