PCF

Presence Control Firmware

Le système de détection d'ouverture d'hackens, pour pouvoir recevoir des gens et ne pas devenir sourd à cause du baby :)

Design général

flowchart TD

S[Senseurs] -->|Serial| m[hackens-mileu]
    -->|local network socket| E[ESP-32, LEDs]
m -->|websocket| org[hackens-org]
    --> web[Site web];
org -->|websocket| w[Systèmes extérieurs]

Il y a trois composants au système:

• La boîte de contrôle en arrière, avec le sketch arduino fourni dans le répo (./control_module/)
• Le software qui orchestre tout qui tourne sur hackens-milieu (./milieu/)
• Les clients, qui reçoivent le signal ouvert/fermé depuis hackens-milieu (./clients/)
  • Une ESP-32 qui tourne proche de la porte de l'avant, qui allume et éteint l'indicateur en recevant des commandes du réseau local (./clients/indicateur/)
  • Un daemon serveur à faire tourner sur hackens-org, qui expose un websocket avec l'état d'ouverture (/.clients/websocket/)

Dans l'idée: L'ESP-32 est la plus stupide possible, c'est juste un actuateur.

Orchestration centrale

La boîte de controle en arrière et hackens-milieu implémentent une machine à état. On ne peut pas faire confiance à hackens-milieu de garder fidèlement un état -- les gens l'éteignent tout le temps, les services ça crashe. Donc, l'arduino garde un état X = (A, S). Ici A c'est l'état des senseurs (combien de fois on a appuyé sur l'override depuis le dernier switch, et est-ce que le loquet est inséré) et S c'est l'état de l'automate (qui est aussi reflété sur la LED)

hackens-milieu peut récupérer X, et est notifié à chaque fois que A change. À chaque changement, c'est le job d'hackens-milieu de faire tourner la machine à état et renvoyer S' dans les 10 secondes. Si ce n'est pas le cas, l'Arduino default sur un état S déconnecté blanc. Ça permet à l'automate d'évoluer au fil des besoins, et donne du feedback utilisateur lorsque le système n'est pas fonctionnel.

L'autre boulot d'hackens-milieu est de transmettre l'état ouvert/fermé aux différentes interfaces avec l'extérieur. Pour l'instant, cela inclut une ESP-32 en avant utilisée pour contrôler les LEDs de la porte, ainsi que hackens-org, qui expose l'état au public sous la forme d'un websocket.

hackens-milieu publie l'état à tous ses clients à chaque changement d'état ainsi que toutes les 5 secondes.

Configuration de l'ESP-32

L'ESP-32 est configuré avec une addresse IPv4 statique définie dans secrets.py, et écoute en TCP sur le port défini dans secrets.py.

À la réception d'un paquet \x00, les LEDs s'éteignent.

À la réception de n'importe quel autre paquet, les LEDs s'allument.

Par défaut, à l'initialisation, les LEDs sont éteintes.

Le mot de passe et le SSID du WiFi local sont également définis dans secrets.py.

Configuration de hackens-org

hackens-org a comme but d'agir comme un buffer entre les requêtes extérieures et le système en hackENS. Dans l'idée, il a 2 websockets. L'une, sous authentification, reçoit les messages de la part de hackens-milieu, le notifiant des changements d'état d'ouverture. L'autre, publique, sert d'endpoint pour le monde extérieur.

Les credentials pour l'authentification sont définis dans le secrets.py attenant.

hackens-org garde le dernier état en mémoire. Comme la connection est active (websocket), il suffit de réagir quand la connection se ferme, après quoi il considère que le système d'indicateur est down et expose l'état "UNKNOWN".

TODOS

-> Pour l'instant y'a rien de proprement installé. Faut faire un package pour le software local, une unit qui l'appelle et une règle udev pour l'Arduino.

-> Ça pourrait être bien d'intégrer un système similaire à l'indicateur KF sur le site d'HackENS. Il suffit de déployer le software sur hackens-org et de porter le javascript sur le site.