Accès rapide au Shelly

[FastFrench]

Bonjour, 

je reste confronté au problème récurrent du temps d'accès au Shelly (Pro 3EM dans mon cas) par l'API REST.
A tel point que j'ai plusieurs messages de TimeOut au niveau du routeur chaque jour. 

Dans 80% des lectures, j'ai un temps d'accès très correct autour de 80ms. 
Il y a environ 15% des requêtes restantes qui se font en-dessous de 120ms, ce qui reste correct. 
Mais pour les 5% restant, ça peut monter jusqu'à 1200ms voire plus (moins de 1% des requêtes dépassent 800ms).

J'ai essayé de supprimer tout ce qui n'est pas nécessaire au niveau du Shelly (tout désactivé sauf la connexion Ethernet): aucun changement flagrant. 
Et en arrêtant les autres clients qui se connectent au Shelly, là c'est sensiblement mieux, mais trop contraignant !



J'ai donc tenté une autre approche: expérimenter l'accès avec ModBus. Mais si en l'activant au niveau du Shelly, celui-ci semble bien à l'écoute du port dédié (502), mais c'est tout. 
Je n'est pas réussi à lire le moindre registre par ModBus (Par exemple le registre 1013 qui devrait contenir la puissance active). 

Et cela aussi bien avec une implémentation perso, qu'avec des outils dédiés comme ModPoll et Modscan64 en testant toutes les plages de registres possible dans les 4 modes. 

Quelqu'un aurait-il réussi à communiquer avec un Shelly Pro en utilisant ModBus ?

Sinon, il reste bien d'autres options: MQTT (en s'abonnant aux notifications), ou les WebSockets (mais il semble que ce soit limité à un seul client).

Ce que je n'aime pas avec MQTT, c'est que le Shelly publie des messages à rallonge, avec des tonnes d'informations inutiles. On peut toujours les filtrer, mais ce n'est pas très optimal comme implémentation. De plus le fait de passer par un broker MQTT augmente d'autant la latence (donc le délai entre lequel la mesure est effectuée et le moment où le routeur en prend connaissance). On peut espérer des temps de l'ordre de 100 à 300ms d'après des retours utilisateurs. Donc à priori nettementmoins bons que par l'API REST dans au moins 80% des cas.

[Lolo69]

Pour le mode modbus, avec modscan je suppose que adresse ip num de port slave id étaient ok car tu avais la connexion.
Code fonction modbus tu as bien 04 pour « lecture holding register » ?
En réponse tu as 0 ou des valeurs bizarres ?

Ps : pourquoi autant d acharnement à stresser ton Shelly pour des mesures aussi rapides sachant que derrière la commande ne pourra pas être aussi rapide et que de toute facon ton Shelly met les valeurs à jour que toutes les secondes ?

[FastFrench]

Pour le mode modbus, avec modscan je suppose que adresse ip num de port slave id étaient ok car tu avais la connexion.
Code fonction modbus tu as bien 04 pour « lecture holding register » ?
En réponse tu as 0 ou des valeurs bizarres ?

Ps : pourquoi autant d acharnement à stresser ton Shelly pour des mesures aussi rapides sachant que derrière la commande ne pourra pas être aussi rapide et que de toute facon ton Shelly met les valeurs à jour que toutes les secondes ?

En fait avec ModScan, j'ai essayé à peu près toutes les possibilités (large plages de N° de registres, avec chacune des 4 fonctions proposées). Dans tous les cas, il retourne 0. 

PS: comme le routeur ne marche pas de façon fiable sur une longue durée chez moi, et que j'ai toujours des TimeOut dans la lecture Shelly quand je passe sur le code non modifié (la dernière version), je pense que c'est le premier aspect que je dois maîtriser (et optimiser) avant de passer à la régulation proprement dite.  Histoire de ne pas construire sur du sable. 

D'ailleurs j'ai fait un constat intéressant: 
  -> en modifiant le code de mon outil avec un TimeOut de 100ms, l'idée étant que quand il part sur un cycle de lecture long j'arrête et je recommence, en tablant sur le fait que plus de 90% des lectures prennent moins de 100ms. Mais ça ne change à peu prêt rien sur les statistiques des temps de lecture. Comme si quand la lecture doit prendre 1.2s, ça prendra de toutes façons ce temps au minimum quoi qu'on fasse, les données n'étant visiblement pas dispo avant ce délai. 

Cela me laisse penser que la stratégie que l'on adopte de mettre un timeout à 2s et réessayer une seconde fois en cas de TimeOut n'est pas utile. Ça marcherait sensiblement de la même façon en mettant simplement un timeout de 4s, sans réessayer. Ce serait même un poil mieux (on perd du temps à réessayer).

[FastFrench]

En optimisant d'avantage les données récupérées, sur le Shelly Pro 3EM j'arrive à réduire pas mal les temps de lecture.
Ainsi je passe à moins de 40ms en moyenne, avec 99% des lectures se faisant en moins de 90ms. Le pire temps constaté en 1 heure, à raison d'une lecture par seconde, est de 489ms.