Je rencontre pas mal de soucis de stabilité et de fonctionnalités du RT3 depuis que je l’ai reçu.
J’ai ajouté le status pour les soucis mineurs.
Voici la liste
Intégration du RS485/MODBUS
Connectique des torres espacée par rapport au RT2 et X400CT. Très bon point. On ne force plus ou on ne tord plus les connectiques.
IHM plus moderne que le RT2
Blocage du software et de la réponse au ping du RT3 (le watchdog si il existe, semble ne pas fonctionner pour rebooter le produit) si on perd la communication avec les autres devices sur le bus EBX notamment sur l’activation de relais ou sur sauvegarde de la configuration dans certains cas ou sur manipulation des états des relais au bout d’un moment.. C’est particulièrement problématique si on est hors site surtout pour des fonctions qui ont des impacts importants sur des consommations donc facturation…
Bug sur l’IHM, entre autre sur la liste des objets (liste déroulante vides) dans les règles. Il semble falloir se déloguer / se reloguer pour que ça revienne (si on a pas perdu la conf entre temps). A priori probleme de cache quelque part.
Impossible aléatoirement de sauvegarder. Les sauvegardes qui ont fonctionné ne sont pas restaurables (Erreur upload fichier). Perte du réseau (ping) du RT3 lorsque l’on lance la sauvegarde ou la restauration.
Perte partielle de configuration (configuration des torres et des entrées, noms des relais, liste des regles dans les scénarios). Très problématique car les valeurs index et autres récupérées en API dans Home Assistant pourrissent l’historique de data HA.
Bug les objets Tempo utilisé dans les scénarios (Il y a des influences entre les différentes tempo. L’activation de l’une entraine la désactivation des autres). On peut tester facilement sans scénario dans l’interface web des tempos.
Dans l’IHM menu Objet, la valeur des torres en mA semble représenter une valeur non exploitable. Dans mon cas sur le Grid en 0 injection la valeur affichée oscille entre -2300mA et +2300MA. Ma puissance réelle sur le GRID oscille entre allez grand max 40W et - 40W. (voir détail dans le commentaire plus bas dans ce post). Il faudrait mieux afficher ici une valeur exploitable en W (avec en dessous plus petit pourquoi pas la puissance apparente en VA et le courant effective en A plutôt qu’un courant apparent en mA). Afficher le CosPhi sous chaque torre peut etre une excellente idée aussi.
Toutefois notamment dans le menu config tout n’est pas uniforme. Des popus ou des pages suivant le menu. Ce qui empêche de pouvoir revenir en arrière intuitivement.
Possibilité de nommer les objets (torres, compteur,…)
Le facteur de puissance global est un % et non un power factor entre 0 et 1. Ca peut troubler sur des petites consommation ou le PF est proche de 0. Le mieux serait de rajouter un % ou de l’afficher entre 0 et 1.
On peut renseigner une position GPS. Très bien. Il aurait été plus intuitif, d’aller chercher le nom d’une commune ou afficher un fond de carte OSM par exemple et d’aller positionner le curseur pour calculer la position GPS automatiquement.
Avec les API, impossible de modifier l’état d’un relais unique, on est obligé de passer le tableau complet (soit sur les relais interne, soit sur les relais du X8R)
Dans MQTT topic TIC, on n’a pas les étiquettes de téléinfo.
Dans MQTT manque cruellement des informations (power factor, intensité, …)
Dans MQTT et API organisation par tableau (notamment les index). C’est très lourd. De vrais objets JSON (avec le nom des index par exemple) auraient été bien plus moderne et plus portable pour les évolutions futures tout en minimisant les regression possible et plus facile pour récupérer les infos. Une modification des compteurs dans le RT3 peut modifier les tableaux. Ce ne sont pas des bonnes pratiques d’utiliser des tableaux en dur en 2026
Watchdog hard/soft inexistant ou non fonctionnel. J’ai eu plusieurs cas de plantage et me suis retrouvé avec un RT3 bloqué ne répondant plus au ping. Très compliqué quand on y pas accès…
Pas d’API (ou pas de doc ?) sur un reboot possible par API
Problèmes de stabilité sur la version firmware 1.0 (perte partielle de conf, blocage, plusieurs tempos simultanée ne fonctionnent pas)
Temps de Rafraichissement des puissances Torres dans MQTT non exploitable (toutes les 30 ou 40 secondes) empechant toute gestion d’énergie fine.
Les valeurs de puissance Torre dans l’API et MQTT sont éronnées et toujours positives malgré une consommation négative. On dirait que c’est la valeur absolue qui remonte (sans le signe). Exemple : 1000 W de puissance soutirée = 1000W dans l’API => OK . 1000W de puissance injectée sur le GRID = toutjours 1000W dans l’API alors que ça devrait être - 1000W. Ce fonctionnement est OK mais pour les compteurs uniquement par pour les torres qui ne doivent pas avoir de traitement du signe.
Pas de pb pour moi. il faudrait joindre la sauvegarde concernée pour @Developpers_GCE.
Sous firefox je présume (quel navigateur ? version ?) ? On a rencontré le problème mais il ne se produit que sous ce navigateur (qui est le plus strict sur les problèmes de refresh)
Pour le reste, il faudrait donner plus d’éléments…pas de problème de bouclage d’appel API ou MQTT vers l’ED3 ? La charge réseau est normal ?
J’utilise Chrome dernière version exclusivement. Suite aux problèmes j’ai tenté d’essayer Firefox mais même problème. J’ai fait un ticket à GCE en leur mettant mon dernier fichier de sauvegarde. J’ai du recréer à la main mes configs torres et entrée pour l’instant pour ne pas continuer à pourrir mon HA comme je n’arrive pas à restaurer.
Pour ton 2ème point chrome également. Ca ressermble à un probleme de cash mais un simple Refresh F5 de la page ne résoud pas le problème.
En revanche je fais des appels API toutes les 5 secondes vers ces différents endpoints :
A noter que depuis ce we je ne fais plus d’appels API MODBUS ni RELAIS. Je passe par MQTT pour les relais mais ils ne sont pas encore utilisés en live donc pas d’action MQTTT. Le broker est en revanche connecté.
Donc 3 endspoints utilisé toutes les 5 secondes
Charge réseau oui, j’ai que du matos pro et mon infra est ultra stable. Aucun soucis réseau. Mon ancien RT2 était branché sur le même cable, je n’avais pas de soucis de ce côté là.
Ensuite pour la perte partielle de config. Je n’ai aucun éléments complémentaires si ce n’est que ça m’est arrivé ce matin en testant justement le problèmes des tempos. Donc plusieurs ajout/modification/suppression de regles. Pas d’autres éléments. Est ce qu’il y a un rapport ou non ? Impossible à dire.
Pour le problème des tempos. Je suis quasi sur que ça vient pas de ma conf. J’ai une tempo de test utilisée dans aucun scénario. Et elle se reset dès que j’active une autre tempo. Ce point là semble donc plutôt un vrai bug mais à confirmer tout de même. Le test se fait très facilement dans l’interface sans scénarios.
1. Crer 2 tempos par exemple 5 secondes et 600 secondes (temps activation à 0 et secondes cochées)
2. Enregistrer
3. Aller sur la tempo de 600 secondes
4. Déclencher avec le bouton Démarrer le timer (de 600 secondes donc). le rond rouge passe au vert
5. Aller dans la tempo de 5 secondes
6. Lancer le timer également; Le rond passe au vert également.
7. Retourner dans la tempo 600 secondes. Elle est rouge et non verte...
Ca se vérifier encore plus facilement en ayant une page web ouverte sur chaque tempo => Lancer une tempo annule toutes les autres
@Developpers_GCE c’est un comportement normal ou tu confirme que c’est un bug ?
Tu peux réessayer la restauration, puis redémarrer l’ED3 puis fermer l’onglet et en rouvrir un autre ?
Pour les API c’est insignifiant 5s effectivement
En complément j’ai copié le lien de l’url du bouton Sauvegarder.
J’'obtient ça en curl mais ça me pârait normal car ma machine ou je curl n’est pas la meme…
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@pve01:~# curl -v -o /tmp/ed3_export.bin « http://192.168.2.7/api/system/export?AuthToken=UqgBeQAGaLrAiDV »
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0* Trying 192.168.2.7:80…
Connected to 192.168.2.7 (192.168.2.7) port 80
using HTTP/1.x
GET /api/system/export?AuthToken=UqgBeQAGaLrAiDV HTTP/1.1
Host: 192.168.2.7
User-Agent: curl/8.14.1
Accept: /
Request completely sent off
< HTTP/1.1 401 Unauthorized
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT
< Access-Control-Allow-Headers: Content-Type, Origin, X-Requested-With, Accept
< Connection: close
< Content-Type: application/json
<
{ [89 bytes data]
100 89 0 89 0 0 80324 0 --:–:-- --:–:-- --:–:-- 89000
shutting down connection #0
root@pve01:~#
Non même blocage. C’est bien pour ça que je test sur une autre machine.
Ping 1ms. RAS la dessus. J’Ai regardé sur mon switch manageable. 0 déconnexion physique du RT3.
Je recheck le ping en rentrant mais c’était ca de memoire. Par contre et j’y pense, il me semble que j’avais observé une perte de ping brève lors du lancement du telechargement de la conf. Idem je check taleur.
En revanche je vais chercher le menu config / Système puis Sauvegarder.
La fenetre windows de l’emplacement du fichier à sauvegarder s’ouvre.
Dès la fenetre ouverte (sans validation du dossier de téléchargement), le RT3 ne répond plus au ping.
Ca recommence à répondre quelques secondes à partir du moment ou on valide la fenetre Windows.
Il y a donc un aspect synchrone et donc pas bon dans la gestion du téléchargement de la configuration. La fleche rouge correspond au moment ou la fenetre windows s’ouvre.
A mon avis, la déconnection puis reconnexion doit reseter la session. Ou un truc similaire.
La connexion PHY Ethernet ne tombe pas au vu de mon switch
A noter qu’avec Opéra, je n’ai pas la fenetre de téléchargement qui s’ouvre. Il doit y avoir un dossier par défaut. En revanche, quand on click sur sauvegarder, on perd instantanément la réponse au ping pendant 5 ou 10 secondes. Ca revient ensuite tout seul et quelques secondes après j’ai l 'erreur réseau dans opéra
Comme dit plus haut, il doit y avoir une gestion synchrone de la stack IP alors qu’elle devrait plutôt être asynchrone. Y a t-il un OS ou RT OS sur le RT3 ou codé en C/C++ en dur ?
Ce qui explique aussi probablement le fait que quand je perds la com EBX, je perds également la réponse au PING
Bonjour à tous.
A noter que dans l’un de mes points, j’avais perte partielle de configuration, j’ai aussi perdu la config MQTT en plus du reste…
Apres avoir remis ma conf MQTT, je vois à nouveau mes topics.
En revanche aucunes traces des relais du X8R connecté au port EBX. (Je peux bien activer mes relais du X8R depuis le RT3)
C’est que Chrome a le même souci de rafraichissement que Firefox, comme c’est des choses qu’on avait remonté en beta-test cela sera surement contourné dans les versions suivantes
J’ai essayé de creuser pour identifier les blocages du RT3. Depuis mon denrier reboot electrique hier soir (hormis les appels API de lecture qui se font toutes les 5 secondes), je n’ai fait que manipuler des relais (via MQTT pour les 2 relais du RT3) et via API (pour les relais de mon X8R).
La à l’instant sur arrivée à expiration de ma tempo de 20 minutes programmée en scénario. Mon relais 2 du RT3 est bien passé à 0. Par contre cela a bloqué instantanément le RT3.
A voir si c’est du au bug identifié des tempos qui ne peuvent être parallelisée ou à la manipulation des relais.
Seule action possible pour récupérer mon RT3 => Disjoncteur…
Ce moteur de scénario n’est pas intuitif pour moi et il manque de possibilités. De plus il manque de la doc. Par exemple on ne sait pas ce qu’il se passe si le relais est remis à 0 via API/MQTT alors que la tempo n’est pas terminée et qu’on lance un autre relais (la tempo est elle resettée et annulée quand le relais repasse à 0, ou déclenche t-elle le scénario tout de même donc induit le passage à relais d’un autre relais si la tempo du relais initial ne se termine pas ?,…).
Idem imaginions que je veuille crééer un ensemble de regle unitaire par relais avec la meme tempo (plutôt que de créer un jeu de regle global comme j’ai fait). Les tempos seraient appelées en parallèle. Est ce que quand on appelle une tempo, c’est une instance unique de la tempo qui est crée ou la tempo est-elle globale à toutes les règles ou scénarios.
Mon seul objectif de ce(s) scénario(s) est(sont) de reproduire le TA/TB du RT2 pour l’instant.
Est ce que le moteur de scénario du RT3 est un moteur light open source (comme il en existe plusieurs) ou est ce quelque chose de propriétaire ?
le manque des étiquettes TIC en MQTT dans le topic TIC
Dans l’IHM Objet, on voit une valeur en mA pour les torres. Ca ne semble pas représenter le courant effectif (semble plutôt etre du courant apparent ?) qui passe sur le cable associé à la pince. Pourquoi ne pas afficher ici une valeur expoitable en Watt tout simplement. La majorité des personnes veulent connaitre leur puissance. Ou alors mettre les deux : Puissance en W (utilisée par la majorité des utilisateurs + Courant effectif (plutôt en A). Rajouter éventuellement la puissance apparente en VA.
D’ailleurs si la valeur affichée dans l’IHM est bien du courant apparant. L’unité n’est pas bonne, il faudrait afficher du mA Apparent plutot que mA tout court.
Test en cours pour vérifier la même problématique sur MQTT
Le rafraichissement de la puissance des torres sur MQTT est trop lent. Impossible de réguler ou de gérer du surplus solaire avec un refresh de 30 secondes ou plus.
J’ai refait des tests ce matin et cela me paraît logique : le timer n’est pas remis à 0 lors du passage du relais à 0.
Pour etre clean donc il me parait necessaire de faire une 3eme regle pour annuler la tempo quand le relais repasse à 0.
En l’état actuel, je pense qu’il va falloir faire une tempo par relais et un jeu de 3 règles pour chaque relais. Ca alourdit considérablement la gestion des TA/TB qui étaient tellement simple sur le RT2
EDIT : Simplification du post initial tout en haut
J’ai essayé de supprimer des regles de scénarios et de les modifier. Il y a un réel problème de stabilité. Créer une nouvelle regle différentes des autres (par dupliquer puis la modifier). Je modifie ma nouvelle regle j’enregistre. On se délogue et se relog. La nouvelle regle écrase l’ancienne et on se retrouve avec 2 regles identiques. J’ai supprimé ces 2 nouvelles regles. Enregistrer. Impossible d’acceder maintenant au scénario. Le logo tourne indéfiniement :
J’ai essayé de créer une nouvelle sccène avec des nouvelles regles. Bien enregistgrer. J’affiche à nouveau mes scènes dans l’onglet scénario; Je n’ai plus ma denrière scène créé, j’ai une scène qui ne correspond à rien et qui a le même nom qu’une autre scène dans laquelle il y a une regle d’une autre scène. C’est incompréhensible.
J’avais bien 5 scènes différentes avant de créer la dernière qui m’a tout écrasé.
Ou j’ai un ticket d’ouvert ou j’essaie de fair remonter les infos. Cependant j’ai fait une liste précise en haut de ce poste. @GCE peut se baser également la dessus.
pour les soucis mineurs.
Intégration du RS485/MODBUS
Blocage du software et de la réponse au ping du RT3 (le watchdog si il existe, semble ne pas fonctionner pour rebooter le produit) si on perd la communication avec les autres devices sur le bus EBX notamment sur l’activation de relais ou sur sauvegarde de la configuration dans certains cas ou sur manipulation des états des relais au bout d’un moment.. C’est particulièrement problématique si on est hors site surtout pour des fonctions qui ont des impacts importants sur des consommations donc facturation…
)
