#12 CLI specifications

Закрито
4 роки тому відкрито maxime-alves · 4 коментарів
maxime-alves прокоментував(ла) 4 роки тому

É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 додав(ла) мітку
cli
4 роки тому
maxime-alves додав(ла) мітку
specifications
4 роки тому
maxime-alves прокоментував(ла) 4 роки тому
Співавтор
[cli.py](https://git.yannweb.net/maxime-alves/pyHeatpump/src/branch/master/pyheatpump/cli.py)
maxime-alves прокоментував(ла) 4 роки тому
Співавтор

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 додав(-ла) витрачений час 4 роки тому
4h
maxime-alves прокоментував(ла) 4 роки тому
Співавтор

Fetch function : OK

Beginning Supervise

Fetch function : OK Beginning Supervise
maxime-alves прокоментував(ла) 4 роки тому
Співавтор

Supervise : OK

Supervise : OK
maxime-alves додав(-ла) витрачений час 4 роки тому
4h
Підпишіться щоб приєднатися до обговорення.
Етап відсутній
Немає виконавеця
1 учасників
Загальний витрачений час: 8h
Дата завершення

Термін виконання не встановлений.

Залежності

Ця проблема в даний час не має залежностей.

Loading…
Відмінити
Зберегти
Тут ще немає жодного змісту.