É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.
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 роки тому
É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.cli.py
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 :
ou
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.
Fetch function : OK
Beginning Supervise
Supervise : OK