Aquarium intelligent et connecté !

Salah, DAHMOUL, salahdahmoul@gmail.com, AL
Kevin, BUISSON, buisson.kevin2@gmail.com, AL
Thibault, OBER, thibault.ober@gmail.com, IAM

Définition d’un utilisateur du système : Bob, est un aquariophile, il possède de nombreux aquariums avec divers espèces de poissons qui nécessite tout un traitement approprié (température de l’eau, qualité, …). Bob aimerait que ces aquariums puissent se gérer de manière autonome en prenant en compte les spécificités de chacune de ses espèces de poissons.

• Scénario 1 : En tant que Bob, je veux pouvoir être averti en cas d’alerte critique dans un des aquariums.
• Scénario 2 : En tant que Bob, je veux que mon aquarium ajuste son niveau d'eau de manière autonome
• Scénario 3: En tant que Bob, je veux pouvoir spécifier le niveau de nitrate et le volume de mon bac afin de pouvoir rééquilibrer le niveau par ajout d’eau saine dans le bac
• Scénario 4: En tant que Bob, je veux pouvoir récupérer suivre l'état des différents relevés sur mon téléphone en spécifiant la période concernée

• Gestion automatique du niveau de l’eau à l’aide d’une pompe.
• Affichage de la qualité de l’eau à l’aide de différents capteur (ph, turbidité, salinité…).
• Gestion de la qualité de l'eau avec l’utilisation de pompe pour ajouter/remplacer de l'eau.
• Pouvoir réguler la température de l’eau à l’aide de capteur de température et d’une thermo-résistance.
• Afficher un état de l’aquarium sur mon téléphone a la demande.

On compte réaliser un composant par capteur/actionneur.
Les composants communiqueront avec la partie metier (intelligente) à l'aide de BlockingQueue (1 pour les capteurs et 1 par actionneurs) à l'aide de messages. Ces messages permettront de mettre à jour le status courant de l'objet et d’appeler les actionneurs si nécessaire.
Notre objet connecté se veut autonome, la partie métier est calculée en interne, dans l'objet. On pourrait avoir recourt à des webservices locaux pour discuter avec nos composants mais cela aurait pour effet d’alourdir la tache de ces derniers, un canal de communication dédiée entre différent thread par l'intermédiaire de Queue est plus facile à mettre en place, on évite la lourde de tache de pulling des données à intervalles régulier, ce sont les capteurs qui remplissent quand bon leur semble leur canal de communication.

Dans une seconde étape, nous mettrons en place des webservices pour offrir la possibilité de piloter l'objet et de récupérer ses données par un serveur intermédiaire qui pourra être implémenté à l'aide de WCOMP. Ce serveur intermédiaire/orchestrateur pourra nous être utile pour notre client mobile ou pour entretenir un cloud, envoyer des notifications …
L'ajout de nouvel fonctionnalité se veut facile et indépendant de l'objet.
Par exemple: Je récupère l'état courant de l'aquarium, si le niveau d'eau est trop bas je génère une requête post pour allumer l'électrovalve (composition de webservice).

Nous aurons:

• 1 webservice pour récupérer le status de l'objet, l'état courant de la machine, accessible en HTTP GET
• 1 webservice par actionneur en fournissant l'état voulue dans le corps de la requête, accessible en HTTP POST.

Nous n'avons pas encore décidé entre une implémentation SOAP ou REST, REST est plus facile à mettre en place mais interdis toute découverte automatisée. Nos besoins sont assez simple, récupérer l'état des différents capteurs et activer/désactiver un actionneur. Nous verrons au moment voulue sur quelle approche partir.

Exemple de HTTP get sur /status:

{

• alert:0,
• temperature:25,
• PH:7.2,
• water_level:10,
• light:1

}