Hier, 08:50 AM
(Modification du message : Hier, 08:51 AM par FastFrench.)
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.
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.