comme cela ne fonctionnait pas déjà par mqttexplorer, je réessaye plusieurs configurations, je reviens ici si j’y arrive
1 « J'aime »
Je pense que le plugin ne le permet pas tout simplement ou il y a une astuce mais rien trouvé dans community, j’ai créé un post quand meme
Ok… Je n’ai rien trouvé non plus de mon côté.
J’essaie de voir s’il y a moyen de modifier le code source pour qu’il intègre l’interprétation d’une publication sous la forme ‹ topic racine ›/‹ topic ›/‹ commande › (comme pour publier les infos de puissance par exemple en provenance de mon Shelly pro 50 EM, et qui ne pose aucun problème du coup), et pas juste ‹ topic racine ›/‹ commande ›.
1 « J'aime »
Salut @Francky62 ,
Bon, j’ai trouvé un palliatif qui fonctionne en modifiant un peu le code source de Solar_Router.
Le principe est de faire en sorte que Solar_Router interprète bien les ordres MQTT envoyés sur le topic racine + un topic de publication qui soit non vide.
Voici ce qu’il faut faire (code source Solar_Router v9.01) :
Dans le fichier MQTT.ino (tout se passe dans ce fichier), la première modification est à faire en ligne 55 :
if (subMQTT == 1) {
for (int i = 0; i < NbActions; i++) {
if (LesActions[i].Actif > 0) {
char TopicAct[50];
//sprintf(TopicAct, "%s", LesActions[i].Titre.c_str());
sprintf(TopicAct, "%s", "routeur/SSR1");
clientMQTT.subscribe(TopicAct);
}
}
Commenter la ligne 55, la remplacer par l’instruction :
sprintf(TopicAct, « %s », « routeur/SSR1 »);
Où « routeur » et « SSR1 » seront les topics racine et de publication paramétrés du côté de Jeedom et de l’interface http de Solar_routeur.
La seconde modification du code source se situe aux lignes 108 à 115 du même fichier :
if (String(topic) == "routeur/SSR1") { // Activation des relais SSR sur le topic SSR1
if (subMQTT == 1) {
for (int i = 0; i < NbActions; i++) {
if (LesActions[i].Actif > 0 && String("routeur/SSR1") == String(topic)) { // original : if (LesActions[i].Actif > 0 && LesActions[i].Titre == String(topic)) {
LesActions[i].tOnOff=ValJson("tOnOff", message);
LesActions[i].Prioritaire();
}
}
}
On ajoute un test sur le topic « routeur/SSR1 » (ou « topic racine/topic de publication » choisi),
Puis un second pour exécuter l’action à proprement parler.
Du coup, ca fonctionne parfaitement bien à partir de Jeedom ou MQTT Explorer maintenant 
…
Bon, ca reste très basique et rudimentaire (codé en « dur »). Il y a certainement moyen de faire bien mieux que ça, en particulier en intégrant le topic de publication choisi pour l’activation des relais/triacs via l’interface HTML par exemple… Mais tant que ça ne reste qu’une rustine pour dépanner…
Attention également qu’à chaque mise à jour du logiciel Solar_Router, il faudra réappliquer ces modifications ! Et ce tant que notre ami André, qui a mis au point ce routeur solaire, n’aura pas pris en compte ces modifications dans son code source ‹ officiel › (je me charge de lui envoyer un petit msg en ce sens…).
Voilà, ca devrait faire l’affaire et je vais pouvoir me consacrer à l’étape de la réalisation concrète…
1 « J'aime »
Bien vu pour une solution provisoire 
Par contre, il faudrait en trouver une durable car pas sur que dans 6 mois, je m’en souvienne 
Salut,
Oui, cela ne reste qu’un patch, l’idée est bien d’intégrer durablement dans les prochaines versions un moyen de le rendre compatible sans modifs avec MQTT Manager.
J’ai vu que jMQTT pouvait à priori envoyer des commandes MQTT sur un topic racine sans passer par un topic de publication… Mais bon, j’ai pas envie de tout casser pour changer au profit de jMQTT, car hormis ce petit souci, mes équipements wifi/Zigbee fonctionnent tous très bien.
Et comme je le disais, de toutes façons je ne suis pas sûr que la norme ISO du protocole MQTT autorise une publication de commande directement sur le topic racine (si quelqu’un peut d’ailleurs confirmer ce point ce serait sympa, car si j’ai récupéré la norme ISO/IEC 20922:2016, il y a 80 pages à se coltiner 
…).
Et dans ce cas, c’est donc au programme tiers de s’y conformer…
Bon, la solution a finalement été trouvée par André (voir son post ici).
Il suffit de simplement renommer le triac ou le relais avec ‹ topic de publication ›/‹ nom de l’équipement ›
Comme par exemple :
Et ça marche !
Donc pas besoin de patch, c’était plutôt simple… 
1 « J'aime »
Parfait , merci de ton aide
Cela fonctionne aussi pour moi
Tuto mis a jour pour la creation d’un scenario avec la configuration du foçage déja (en cours)
Maj du bon fonctionnement
1 « J'aime »
Super merci fonctionne aussi pour moi,
je viens de la faire marcher aussi avec JMQTT.
le paramétrage du topic dans ESP32
le paramétrage des actions dans esp32
le paramétrage dans JMQTT
voila si ça peut aider …
Nickel…
Juste une petit question pour confirmer : avec jMQTT, ça ne fonctionne pas avec un topic de publication vide ? J’ai eu d’autres infos par ailleurs comme quoi à priori jMQTT était plus permissif sur ce point…
Merci !
Non, ça fonctionne très bien. Je viens de faire les tests, si c’est de ça que tu parles.
Cordialement,
Ok, Merci !
Hello,
Petite mise en place d’un ssd1306 sur le routeur connecté sur Enphase envoy 
2 « J'aime »
Bonjour à tous,
Je rejoins l’équipe des Enphase et F1ATB par contre j’ai un souci à comprendre comment coupler au mieux la partie domotique avec la partie pure F1ATB.
André, de F1ATB, à un routeur qui est en charge de collecter les infos et d’autres pour la gestion fine de l’alimentation des charges résistives en fct du surplus. (D’ailleurs le routeur peut être le même).
Dans notre cas, on a toutes les données de Envoy dans Jeedom (et certainement avec du MQTT) et du coup je me dis que l’on n’a pas besoin du 1er routeur. Mes CEs mono sont déjà domotisés avec un sonoff et un contacteur de puissance, et du coup je me posais la question de pourquoi ne pas insérer le routeur F1ATB en parallèle de celui ci comme cela je peux soit piloter comme je faisais le CE en pleine puissance en zigbee par le sonoff soit profter en parallèle du surplus grace au routeur F1ATB.
Est ce possible de faire cela? du coup on a aucun cable à tirer en plus et on a la modularité de la pleine charge pour l’hiver indépendamment si il y a surplus et on optimise pendant l’été le surplus dans les CEs.
Je ne sais pas si je suis clair et si cela a du sens du coup (car parfois on fait des choses trop compliquées pour pas grand chose lol)
XabiX
Bonjour,
Si je comprends bien, et si je reformule la question, l’idée est donc de disposer en parallèle des Sonoff qui gèrent les chauffe-eau, le routeur solaire tout en profitant, dans la partie ‹ mesure ›, des données reçues de l’Envoy ?
Si c’est bien de ça qu’il s’agit, la réponse est oui. C’est même ce qu’Alain préconise sur son site vis à vis d’un contacteur jour/nuit (ici), qui reprend le même principe.
Perso j’ai mis le routeur en série (la partie mesure est assurée par un Shelly PRO EM50 en MQTT), après mon contacteur J/N (piloté par Jeedom), pour des raisons de simplicité de câblage (le routeur est directement posé à proximité du chauffe-eau), et aussi parce que le routeur peut-être lui aussi piloté également par Jeedom en mode ON/OFF/AUTO. Ce qui permet donc toutes les combinaisons possibles…
Bonjour,
Du coup tu laisses ton J/N en mode forcé « ON »
Oui, c’est ça. Je laisse le routeur gérer tout seul (il est conçu pour ça) en minimisant les interventions côté jeedom qui reste en backup.
Et du coup, j’ai toujours une solution de secours en cas de panne d’un côté ou de l’autre. Il faut juste que je réfléchisse maintenant pour automatiser la bascule dans ce cas…
Du coup, tu as laissé le contacteur Jour/Nuit en mode toujours ON (ce qui équivaut pour moi aujourd’hui à mon Sonoff mais que j’active en ON que 1h30 par jour sans gestion des surplus pour l’instant) et ensuite tu as mis en série le routeur F1ATB qui est du coup le seul en charge à l’heure actuelle de gérer en été de router le surplus et en hiver de faire le role de contacteur pour chauffer à minima ton eau sans vraiment avoir de surplus.
Est ce correct de dire qu’en parallèle cela offre plus de fléxibilité qu’en mode série?
Si je mettais le sonoff en amont alors je me demande qu’elle serait sa valeure ajoutée car effectivement on peut passer et se contenter du routeur qui fait exactement la même chose et en mieux (et de manière autonome).
J’imagine que ce 3e cas n’a pas d’interêt?
Pour l’instant mon Sonoff est en amont de la carte ACI et de la résistance du CE. Est ce que cela pose pb si je fais de même, si je pars en mode parallèle avec le routeur aussi en amont de la carte ACI? ou il faut mettre absolution le routeur après la carte ACI?
Merci bcp
Oui, c’est en effet le mieux je pense de d’avoir un mode de fonctionnement en OU logique (//), plutôt qu’en ET (série). Cela permet aussi de gérer très simplement les modes dégradés en cas de détection d’avarie sur l’un ou l’autre des dispositifs et d’y pallier en conséquence.
Je ne l’ai pas fait de mon côté (pour l’instant…) car cela aurait grandement complexifié l’installation au niveau de mon tableau électrique en ce qui me concerne (éloignement, place limitée, chauffe du relais à gérer, etc…). Je garde quand même la possibilité de gérer l’ensemble si nécessaire via Jeedom.
Non, en effet. Je ne vois pas vraiment ce que ca change…
1 « J'aime »
A quoi sert cette carte ACI, et qu’est-ce que c’est ?