0%
Dernière modification : il y a 2 semaines, 3 jours
Mainteneur : Rom1
Participants : altf4, Frawni, Herrgrim0, iTitou, miniGrim0, Morti, Pinebook, Thibault
Je veux participer !



Tâches

Introduction

Bon, la première itération de HAL (N°0) est morte, il est temps d'en faire une nouvelle version : HAL1 !

Puis comme tout le monde en parle mais personne ne formalise ... voici donc le projet WIP pour le nouveau HAL. N'hésitez pas à compléter/documenter/interagir avec cette page.

Channel IRC

Rassemblons nous sur : #UrLab-HAL1 pour parler de HAL1 !

Description

Pour éviter que HAL1 ne meurt seul dans la nuit comme HAL0, on va essayer de le faire plus robuste en décentralisant son intelligence (un peu comme internet, quoi !) !

  • Pour ce faire, HAL1 sera basé sur un MQTT. (à lire également: pub-sub sur wikipedia.)
  • L'essentiel de HAL1 sera composé de Wemos mais n'importe quel device pouvant faire du MQTT est le bienvenu.
  • Des éléments du hs comme Lechbot, l'incubateur ou pamela pourraient également être inclus dans HAL1.
  • Un broker MQTT fonctionnera quelque part dans le HS et /doit/ être facile à maintenir et redéployer en cas de crash (Un truc aussi simple que "git clone && ./run.sh" ou "docker run" ça serait cool).
  • (on va pas faire un deuxième AP, pour le moment on partagera notre wifi avec hal1 et s'il devient trop encombrant, on avisera) Un deuxième AP / réseau wifi sera mit en place juste pour l'IoT de HAL (Wemos) afin de ne pas engorger le wifi des utilisateurs (WIP / à définir, cfr: altf4 et Rom1).

Broker MQTT

Comme broker MQTT, on va peut-être utiliser un broker wamp (un autre format de pubsub) mais qui gère aussi MQTT histoire de profiter des avantages d'un serveur overkill tout en gardant des clients MQTT.

URFC (UrLab RFC)

Pour s'assurer de la maintenabilité de HAL1, il est essentiel de documenter en détail (par exemple, sur une page du wiki ou un tableur) les différents éléments de HAL1. De par la décentralisation de "l’intelligence", ça peut vite finir anarchique et plus personne comprends qu'est-ce qui fait quoi.

Pour éviter cela, il est essentiel de :

  • définir précisément les topics et les informations qui doivent passer dessus.

Pour chaque client du MQTT (chaque wemos) :

  • définir les topics auquel le client a souscris
  • définir les topics sur lesquels le client va publier

Idées de topics

Quelques idées/exemples de topics et ce qu'ils pourraient faire :

  • "sonnette": la sonnette publie un événement quand on sonne à la porte. "Un truc qui fait dingdong", les strips led², les matrices et Lechbot sont abonné au topic et réagissent chacun à leur manière.
  • "opening": Le levier et Lechbot (avec le sudo !open/!close) publie l'ouverture/fermeture du HS. Des trucs réagissent à ça (exemple: pamela se ferme/ouvre, les leds s'éteignent, etc ...).
  • "daisy_belle": un capteur de son écoute le bruit au HS et publie sur daisy_belle quand on fait du bruit. La lumière s’éteint, les strips led clignotent rouge et les matrices leds nous disent cordialement de la fermer.
  • "reminder": Un topic pour prévenir les gens qu'ils doivent s'occuper des poubelles (cfr: link). Les matrices leds leur rappel quoi faire en même temps que Lechbot.
  • "temperature": Différents senseurs de température publient la température dans le HS (cuisine, salon, etc ...). D'autres trucs font des trucs cool avec ces données.
  • "incubator": L'incubateur publie un événement sur ce topic quand quelqu'un fini une tâche d'un projet. "Le truc qui fait dingdong" joue alors une musique de victoire dans le HS.
  • colorfull LED's: plus de RGB que jamais au HS