Retours d'expérience sur la configuration des actions

[FastFrench]

Les mesures sont ralentis quand on est loin de l'equibre de régulation. Si par exemple vous consommez 2000w et vous avez un seuil à zero, vous n'allez probablement pas rejoindre l'équilibre dans les 200ms qui suivent.
André

D'accord, merci pour cette précision. Dans mon cas (où la régulation ne marche pas... encore), j'ai l'impression que ce ralentissement aggrave le problème. J'aurai peut-être un autre point de vue quand ça marchera

---

@Lolo69: je crois que j'ai bien compris le problème que tu as soulevé. Du coup le correctif est simple (ajouter un client.stop() après utilisation.

client.connection()
.. utilisation du client
client.stop()

Pour l'instant, le .stop n'est fait qu'en cas d'erreur.

A noter qu'on pourrait aussi envisager de garder la connexion ouverte (ni connection() ni stop() en utilisation normale). Pour une mesure toutes les 100ms, on chargerait moins le Wifi en agissant ainsi. Mais alors il faudrait vérifier la connexion à chaque utilisation, et rétablir la connexion (.stop + .connection) en cas de problème (timeout notamment).

---

c'est finalement assez simple de debugger à distance - via WiFi. Si ça intéresse du monde, je peux faire un p'tit tuto

Bonjour,

  intéressé de connaitre la méthode utilisée

  Pour le tuto, certainement aussi, (ou un lien ailleurs qui explique)

D'accord ça marche. Je vais essayer de ne pas oublier de faire ça, à mon retour dans qqs jours. 
Dans les grandes lignes, on peut le faire sans aucune librairie supplémentaire (juste Wifi qu'on utilise déjà). Il suffit de lancer un serveur Wifi (2 lignes) et écrire une petite fonction qui permet d'envoyer un message, qui remplacera les Serial.println().
Pour afficher les messages Debug, il faut juste lancer un client TelNet avec l'IP du routeur et le port utilisé pour le Debug. Telnet ou Putty par exemple. 

J'ai essayé RemoteDebugger au préalable, mais c'est bien plus lourd (le croquis devenait trop gros), et ne m'apporte rien de plus.