Forum Communauté Jeedom

Bonjour Domotruc,

Je partage ton analyse, cependant, je pense que l'implémentation mqtt est dédiée à des clients qui se connectent de manière épisodique et ont donc besoin des valeurs (peu de valeurs pour chaque client) à un temps t sans besoin d'actualisation (visualisation, reporting de certaines valeurs,...) mais pas pour la gestion du CCGX qui utilise d'autres canaux dédiés.
Victron ne souhaite pas faire évoluer cela mais la poste reste ouverte puisque Venus est en open source...

Dans mon cas, je vais filtrer beaucoup plus les topics de mes clients d'autant plus que je souhaite démarrer un autre broker destiné au partage des informations spécifiques à ma domotique.
Ce broker étant hébergé sur le Nuc et, pourquoi pas, géré en liaison avec ton plugin.
As tu des préconisations?

Merci et bonne journée.

Bonsoir Gwladys,

Gwladys a écrit : ↑

23 oct. 2018, 09:44

Bonjour Domotruc,

Je partage ton analyse, cependant, je pense que l'implémentation mqtt est dédiée à des clients qui se connectent de manière épisodique et ont donc besoin des valeurs (peu de valeurs pour chaque client) à un temps t sans besoin d'actualisation (visualisation, reporting de certaines valeurs,...) mais pas pour la gestion du CCGX qui utilise d'autres canaux dédiés.
Victron ne souhaite pas faire évoluer cela mais la poste reste ouverte puisque Venus est en open source...

Dans mon cas, je vais filtrer beaucoup plus les topics de mes clients d'autant plus que je souhaite démarrer un autre broker destiné au partage des informations spécifiques à ma domotique.
Ce broker étant hébergé sur le Nuc et, pourquoi pas, géré en liaison avec ton plugin.
As tu des préconisations?

Merci et bonne journée.

JMQTT ne sait connecter qu'un seul broker. Si tu veux connecter plusieurs brokers, je pense que c'est possible avec des jeedom déportés, chacun ayant son plugin jMQTT, mais je n'ai jamais essayé. Autre solution, utiliser jMQTT et MQTT sur le même jeedom, connectant chacun son broker.

Après j'ai en tête 2 évolutions du plugin:

• Supporter plusieurs brokers

• Réécrire le démon client MQTT en python (au lieu de php aujourd'hui) et pouvoir le déporter sur une autre machine avant de répartir la charge CPU

Ça ne sera pas tout de suite car ça demande une reprise profonde du plugin...

Bonjour,

Je suis rapidement preneuse d'une solution multi broker.

Quand à la charge processeur, le pb est que nous n'avons pas forcément la possibilité de l'évaluer, sauf en lisant les commentaires sur le présent forum.

Le mqtt me plait bien dans son principe, cependant, je dois continuer à me renseigner comment fonctionne le broker, d'où mes questions sur la gestion des topics des clients par le broker.

Merci et bonne journée,

Bonjour,

Je viens de mettre à jour le plugin JMQTT sans voir de soucis de fonctionnement.

Je ne manquerais pas de vous tenir informés.

Ou en êtes vous de vos travaux sur Venus?

Bonne soirée, (au coin du feu vu le temps,...)

Bonjour,

Un grand merci à vous deux pour votre participation au post. J'ai réussi à partir de vos infos et malgré mon absence de connaissances des environnements du Pi et de Jeedom à mettre en place sans trop de difficultés une première installation.

Elle est encore loin d'être opérationnelle mais j'arrive déjà à récupérer pas mal d'infos, et à les gérer au sein de Jeedom.

Un retour d'expérience qui m’inquiète un peu. Je viens de me rendre compte que les topics intègrent l'instance de l'appareil dans leurs intitulés (N/XXXXXXXXXX/battery/258/Alarms/HighStarterVoltage). Le problème, c'est que cette instance est variable du côté de VenusGX. Elle change lorsque l'on débranche un appareil de la box ou que l'on coupe son alimentation !!! Cela risque d'être gênant sur une exploitation à long terme ...

Suite à la prochaine évolution de l'installation ...

Bon WE

Bo jour,

Bravo.

L'affectation dynamique des instances sous Venus est un élément fonctionnel dépendant de la configuration.
Il est donc nécessaire d'avoir une configuration fixe avant de développer les applicatifs de supervision.

Bon courage,

Ps: j'utilise conjointement le modbus ip et le mqtt sur Venus en fonction des informations et de leur importance dans le process ce régulation.

Pour ceux qui voudraient se lancer dans un interfaçage jeedom / victron via le plugin jMQTT, quelques vues d'écran pour exemples.

Elles ont été généré très rapidement, surtout pour apprendre la manipulation de Jeedom, voir les possibilités de calculs sur données brutes et voir la stabilité de l'ensemble. Je vous proposerai quelque chose de plus abouti ultérieurement. J'ai fais ces premiers tests sur une config (Pi3B+) + carte SD. Le colis avec un boitier "Raspberry Pi Desktop" et un SSD arrive ...

(Météo très maussade aujourd'hui donc les panneaux produisent très très peu ...)

...

Bravo Akoua, trés belle démonstration et qu'en est il de la charge de ton RPI supportant Jeedom?

Tu as de la chance d'être en monophasé car cela complexifie pas mal les graphes et la gestion de l'ensemble.

Pour ma part, mon Jeedom est abonné aux topics gérés exclusivement par CCGW en mqtt et pour le suivi temps réel, je passe en modbus sur des EM24 et autres peripheriques de mesure en sortie du PDL.

bonne journée,

Bonjour,
Jolie mise en place!!!
Par contre, jeedom lui envoie t-il des instructions?

Bonjour Gwladys,

Pour la charge du Rpi, je te dirais ça la semaine prochaine lorsque j'aurai fait l'installation proprement sur le SSD. L'installation test qui tourne actuellement n'est pas représentative, car j'ai d'autres softs qui tournent dessus pour m'aider à la compréhension de l'environnement, à la mise en place et aux paramétrages. Moi et l'environnement Linux, c'est une vielle histoire d'environ ... 2 semaines. J'ai encore besoin de béquilles ... LOL


Bonjour Vins,

Je travaille dans le sens VenusOS vers Jeedom. Rien ne repart dans l'autre sens. Quelles instructions tu vaudrais remonter vers le Venus ?

Ok.
Je voudrais savoir pour l'instant.
J'aimerais dans l'idée de modifier la puissance de tirage sur les batteries, arrêter le tirage sur les batteries sur % utiliser, déclenché la fonction absorption.
La, c'est ce que j'ai en tête.
Merci

Ces fonctions sont accessibles en modbus mais je crains que cela ne soit que partiellement possible en mqtt car ces commandes sont lourdes de conséquences sur l'installation.

Du moins pour mon installation et les régulations associées; de controle de charge, de delestage et de gestion des batteries, j'utiliserais le modbus en temps réel avec un automate.
Jeedom ou Lifedomus, sera conservé pour la supervision

Ok. Je comprendssur le principe.
Mais le ccgx reste le gestionnaire.
En mode "ess", on peut modifier ces paramètres, du moins "getpoint".
Ce qui permet de tirer ou non sur les batteries. Étant donné qu'actuellement j'ai qu'une petite installation solaire et batteries. Ce qui me permettra de tirer dessus au matin en HP.
Connais tu le "mode ESS"?
Pourquoi plutôt passer par le modbus?
Merci

Bonjour,

Je connais et utilisé ESS, mais il y a plusieurs modes en ESS et ce mode ne permet pas un pilotage pointu pour l'optimisation secteur/batteries/soutirage, d'où le pilotage temps réel en modbus.

Donc chacun choisi sa stratégie en fonction de ses besoins.

Ok.
Peux-tu me donner des informations sur l'utilisation en mode modbus, automate?
Je ne connais pas. Et je ne comprends pas la différence.
Pour moi, c'est 2 protocoles à peu près identique.

(Ce post indique mon avis et n'engage que moi)

L'automate est fait pour gérer en temps réel les événements (OS fait pour cela) avec une très grande fiabilité sans fioritures ni interface "sexy".

Ce sont donc des matériels de terrain et les Jeedom plutôt considérés comme des superviseurs charges de faire de jolies interfaces avec de multiples capteurs dont le temps de réponse peut être très long donc incompatible avec des process et de la sécurité.

C'est donc comme cela que je conçois cette installation.

Ok. Moi, c'est juste pour changer des programmes.
Exemple : en hiver, je n'ai pas assez de production donc changement de "optimisé sans batteries life" en " maintenir les batteries chargée" ou
En été, utiliser les batteries le matin.
Dans ESS, "optimisé sans batteries life" changer "grid getpoint" de 0 à XX et remettre à zéro quand % batteries descend en dessous de XX.
Voilà ce que je souhaite.
Donc ccgx reste le"maître".
Et ce n'est pas trop grave Si il y a un peu de décalage (à prendre en compte dans la programmation jeedom).
C'est logique pour toi?
C'est viable dans le temps?

Concernant ton affichage, je galère à trouver les bonnes informations dans le retour MQTT. Pourrais-tu me communiquer les commandes MQTT vers "à quoi ça correspond"?
Merci

vins a écrit : ↑

31 oct. 2018, 21:52

Concernant ton affichage, je galère à trouver les bonnes informations dans le retour MQTT. Pourrais-tu me communiquer les commandes MQTT vers "à quoi ça correspond"?
Merci

.
Bjr vinc, je pense que c'est à moi que tu t'adresse. Je te fais ça au fur et à mesure.

Pour me faciliter la vie au départ, j'ai créer des virtuels pour chaque objet Victron. J'ai mis dans ces virtuels une copie de l'ensemble des commandes détectées sur jMQTT. Ensuite, j'ai fais le ménage. C'est un peu long mais ça permet de s'y retrouver car VenusOs envoie effectivement BEAUCOUP de données.
. .
PV - Tension - #[Energie][Victron Venus][Trina 810 - Pv V]# - N/IP_du_Venus_GX/solarcharger/288/Pv/V{value}

PV - Puissance - #[Energie][Victron Venus][Trina 810 - Yield Power]# - N/IP_du_Venus_GX/solarcharger/288/Yield/Power{value}

PV - Intensité - #[Energie][Victron Venus][Trina 810 - Current]# - N/IP_du_Venus_GX/solarcharger/288/Dc/0/Current{value}

Batt. – Intensité - #[Energie][Victron Venus][solarcharger/288/Dc/Current]# - N/IP_du_Venus_GX/solarcharger/288/Dc/0/Current{value}

History J0 - #[Energie][Victron Venus][Trina 810 - History Daily]# - N/IP_du_Venus_GX/

Pour rappel, la valeur "288" correspond à l'instance de l"appareil. Valeur à modifier en fonction de l'installation.

Ok. Merci.
Si tu as d'autres commandes intéressantes, tu peux les partagé.

Akoua a écrit :

vins a écrit : ↑

31 oct. 2018, 21:52

Concernant ton affichage, je galère à trouver les bonnes informations dans le retour MQTT. Pourrais-tu me communiquer les commandes MQTT vers "à quoi ça correspond"?
Merci

.
Bjr vinc, je pense que c'est à moi que tu t'adresse. Je te fais ça au fur et à mesure.

Pour me faciliter la vie au départ, j'ai créer des virtuels pour chaque objet Victron. J'ai mis dans ces virtuels une copie de l'ensemble des commandes détectées sur jMQTT. Ensuite, j'ai fais le ménage. C'est un peu long mais ça permet de s'y retrouver car VenusOs envoie effectivement BEAUCOUP de données.
.

Vue PV.png

.
PV - Tension - #[Energie][Victron Venus][Trina 810 - Pv V]# - N/IP_du_Venus_GX/solarcharger/288/Pv/V{value}

PV - Puissance - #[Energie][Victron Venus][Trina 810 - Yield Power]# - N/IP_du_Venus_GX/solarcharger/288/Yield/Power{value}

PV - Intensité - #[Energie][Victron Venus][Trina 810 - Current]# - N/IP_du_Venus_GX/solarcharger/288/Dc/0/Current{value}

Batt. – Intensité - #[Energie][Victron Venus][solarcharger/260/Dc/Current]# - N/IP_du_Venus_GX/solarcharger/288/Dc/0/Current{value}

Pour rappel, la valeur "288" correspond à l'instance de l"appareil. Valeur à modifier en fonction de l'installation.

Ok. Merci.
Si tu as d'autres commandes intéressantes, tu peux les partagé.