(14-08-2025, 08:50 AM)FastFrench a écrit : Intéressant. Il y a aussi un autre petit oubli dans le cas du Shelly Pro (pas regardé pour les autres): on utilise l'API pour identifier le Shelly utilisé, et son paramétrage (mono ou triphasé notamment, car ça change la structure des données renvoyées). Mais après cet appel, on oublie de faire un client.stop() avant de faire la connexion suivante.
Par contre lors des mesures par la suite, on pense bien à faire le client.stop() après.
Pour les temps de réponse, j'invite ceux qui ont un Shelly à essayer (ou adapter) le script Python que j'ai donné plus haut: ça vous donne une bonne vision des temps de réponse du Shelly.
Sur une heure, j'ai lancé plus de 30 000 requêtes, sans aucun échec. Par contre à deux reprises (seulement), le temps de réponse était entre 2 et 3 secondes. Et à une dizaine de reprises autour de 1 seconde. La très grand majorité des fois (et en moyenne), c'est autour de 100ms.
Dans mon test, c'était tout en filaire (Shelly sur RJ 45, interrogé depuis un PC connecté aussi en RJ 45): pas de Wifi.
wiifi ou filaire les connexions doivent etre refermées, ou en tout cas etre maitrisées, pour ne pas ouvir une connexion toutes les 200ms sans les refermer
pour le shellypro je ne suis pas tout à fait ok avec l analyse de Fast French...pour obtenir le device info on fait bien un get sur une connexion ouverte avant, il ne fait donc refermer la connexion apres ce get car il y en a d'autres Get apres, par contre tout comme le shelly EM la connexion est ouverte toutes les 200 + ralenti ms , mais n'est jamais refermé tant qu'il n'y a pas un falied, qui finit donc forcement par arrivé, et de plus le failed ferme une connexion parmi la pile donc le failed suivatn arrive très vite...
idem pour les module RMS_Externes et source_externe, source_smartG il manque un clientESP_RMS.stop apres le dernier get ( sans erreur de timeout)