#12 CLI specifications

Closed
opened 4 years ago by maxime-alves · 4 comments

Écrire les specifications du CLI et écrire les fonctions suivantes :

  • pyheatpump run : Lance le serveur HTTP de l’API.

  • pyheatpump fetch : Récupère les valeurs de l’automate et les insère dans la base de données.

  • pyheatpump supervise : Envoie les valeurs modifiées depuis la dernière mise à jour et récupère les ordres du superviseur.

Écrire les specifications du CLI et écrire les fonctions suivantes : - [x] `pyheatpump run` : Lance le serveur HTTP de l'API. - [x] `pyheatpump fetch` : Récupère les valeurs de l'automate et les insère dans la base de données. - [x] `pyheatpump supervise` : Envoie les valeurs modifiées depuis la dernière mise à jour et récupère les ordres du superviseur.
maxime-alves added the
cli
label 4 years ago
maxime-alves added the
specifications
label 4 years ago
maxime-alves commented 4 years ago
Collaborator
[cli.py](https://git.yannweb.net/maxime-alves/pyHeatpump/src/branch/master/pyheatpump/cli.py)
maxime-alves commented 4 years ago
Collaborator

Toutes les fonctions seront stockées dans un seul fichier pour faciliter la lecture des tâches “critiques”.

La fonction run ne sera pas forcément executée en production, étant donné qu’elle présente une faille de sécurité critique (possibilité de modifier toutes les configs), mais pour le moment nous l’activerons par défaut pour le client puisse facilement débugger son matériel.

La fonction fetch est critique, elle permet de mettre à jour la base de donnée locale de la passerelle avec les données de l’automate (récupérées en Modbus). Si elle échoue, cela signifie que :

  • la passerelle est mal configurée (port/baudrate/…)

ou

  • le matériel est défaillant

La fonction supervise envoie au superviseur les données récemment modifiées de la base de données, ceci dans une requête POST en HTTP, et au format JSON. Si le serveur répond “Ok” avec un code 200, la reqête à fonctionné.

De plus, supervise récupère des ordres stockés dans la base de donnée serveur et les applique à l’automate par modbus. Elle récupère ces ordres en HTTP avec la méthode GET sur une URL dont le chemin termine avec l’adresse MAC de la passerelle. Si le serveur renvoie une chaîne JSON valide, contenant son adresse MAC et des ordres, avec le code 200, la passerelle applique les ordres à l’automate.

Si supervise n’arrive pas à contacter le serveur pour quelquoncque raison, on logge les codes d’erreur avec la requête envoyée.

Il faudra permettre à l’utilisateur de vérifier que fetch et supervise fonctionnent et de consulter les logs de ceux-cis, par une route de l’API, où par une commande SSH simple. On peut même imaginer une commande renvoyant un lien vers un pastebin à linker dans le rapport de bug, qui contiendrais tout les logs utiles.

Toutes les fonctions seront stockées dans un seul fichier pour faciliter la lecture des tâches "critiques". La fonction **run** ne sera pas forcément executée en production, étant donné qu'elle présente une faille de sécurité critique (possibilité de modifier toutes les configs), mais pour le moment nous l'activerons par défaut pour le client puisse facilement débugger son matériel. La fonction **fetch** est critique, elle permet de mettre à jour la base de donnée locale de la *passerelle* avec les données de l'automate (récupérées en Modbus). Si elle échoue, cela signifie que : - la passerelle est mal configurée (port/baudrate/...) ou - le matériel est défaillant La fonction **supervise** envoie au superviseur les données *récemment modifiées* de la base de données, ceci dans une requête **POST** en HTTP, et au format JSON. Si le serveur répond "Ok" avec un code 200, la reqête à fonctionné. De plus, **supervise** récupère des ordres stockés dans la base de donnée serveur et les applique à l'automate par modbus. Elle récupère ces ordres en HTTP avec la méthode **GET** sur une URL dont le chemin termine avec l'adresse MAC de la passerelle. Si le serveur renvoie une chaîne JSON valide, contenant son adresse MAC et des ordres, avec le code 200, la passerelle applique les ordres à l'automate. Si **supervise** n'arrive pas à contacter le serveur pour quelquoncque raison, on logge les codes d'erreur avec la requête envoyée. Il faudra permettre à l'utilisateur de vérifier que **fetch** et **supervise** fonctionnent et de consulter les logs de ceux-cis, par une route de l'API, où par une commande SSH simple. On peut même imaginer une commande renvoyant un lien vers un pastebin à linker dans le rapport de bug, qui contiendrais tout les logs utiles.
maxime-alves added spent time 4 years ago
4h
maxime-alves commented 4 years ago
Collaborator

Fetch function : OK

Beginning Supervise

Fetch function : OK Beginning Supervise
maxime-alves commented 4 years ago
Collaborator

Supervise : OK

Supervise : OK
maxime-alves added spent time 4 years ago
4h
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Total Time Spent: 8h
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.