Je vous propose de me faire vos retours sur la version beta du plugin marstekmqtt ici.
Merci.
NB : C’est bon, le plugin semble être accessible depuis le market en version beta
Pour vos retours, pourriez-vous svp préciser systématiquement (je sais, c’est lourd, mais ça evitera des messages inutiles ou je vous demanderai ces infos …) :
Le model de(s) batterie(s) : Venus C / Venus C 3.0 / Venus D / Venus E
Le firmware de(s) batterie(s)
Le type de connexion à internet : wifi / RJ45
Type de sonde de courant : CT-00x, Shelly Pro 3EM, …
Installation : mono/triphasé
Version du plugin : (visible sur page config)
Version de l’API : (visible sur page config)
Version Jeedom
Mettre si possible vos log (marsteqmqtt / marsteqmqtt_daemon), en mode info au minimum
Bonjour,
Bonne année et merci pour le travail du plugin.
La première batterie avait été découverte avant la mise à jour beta. Et j’avais bien pu la mettre dans la pièce voulue.
J’ai fais la maj ce matin et activé l’Api sur ma deuxième batterie, bien découverte par le plugin mais elle reste désespérément dans Aucun, impossible de l’attribuer à une pièce. Le logo d’attente jeedom fait qq aller retour au lieu de tourner.
La jeedom est en Debian 11 et Core 4.4.20.
J’ai essayé de remettre les droits sur les fichiers au cas où, mais rien n’y fait.
Bien cordialement
Bizarre … J’ai pas de code particulier associé à la modification de l’objet parent et je viens d’essayer chez moi et ça marche sans problème …
Essaye de refaire une detection complete, avec tes 2 batteires en ligne : Arrête le plugin, supprimertoutes tes batteries, relance le plugin.
Et surtout, mets moi des logs …
Bah écoute ça restera dans les mystères car je n’ai pas été là de l’après midi, je reviens j’essaie et ça marche.
On garde ça en tête si ça arrive à quelqu’un d’autre, il suffit d’attendre
Même si intellectuellement c’est frustrant.
Même problème que toi. J’avais passé le timeout à 10s, c’est mieux, mais encore beaucoup de timeout.
Je viens de passer la période de sondage à 60s, pour voir si ca s’améliore.
Oui, c’est expliqué dans les pb connus. Normalement, c’est même pire que ça : le CT est perdu (il est reinitalisé comme un CT-003) et la batterie passe en mode manuel, mais sans calendirer (i.e. elle est est attente).
Il faut alors remettre le bon CT, reconfigurer le mode voulu et réactiver l’API.
Je suis a peu près sûr que c’est le soft de la batterie qui crashe et qui redémarre …
J’ai l’impression que c’est provoqué par certaines commandes (je soupçonne celle qui récupère les valeurs de CT).
Je suis en train de les activer une à une seulement pour voir si y’en a effectivement une qui pose plus de pb que d’autres.
Je vous tiens au courant …
Justement ta préco ne serait pas d’augmenter le tempo ? Perso, je suis à 60s sur mes scripts et je n’ai jamais observé vos soucis de perte / réinit de CT. Au pire, ordre de changement de mode pas appliqué que je réapplique le coup d’après.
Je vais installer et tester ton plugin dès que je peux.
Bonjour,
J’ai essayé hier soir ce nouveau plugging sur mon installation JEEDOM:
Raspberry Pi3b avec jeedom en version 4.3.22, mais ça bloque au niveau du Démon …
Il me semble que dans l’intégration HA, la période de sondage est réglée à 60s et le timeout à 15s …
Dans l’état actuel de l’api Marstek, il est peut-être effectivement illusoire de vouloir descendre plus bas …
Même si au niveau du timeout, d’après mes essais, si la requête n’a pas été répondue au bout de 2s, elle ne le sera jamais. Du coup mettre une valeur > 2s pour le timeout n’a de sens que pour augmenter le délais min entre 2 requêtes quand l’api commence à être à la rue.
