Oui en effet j’attendais que tu arrive a sortir de la marmite
en attendant un grand merci pour ton code qui m’a prévenu de suite
Edit cela peut peut être servir:
Si vous utilisez un Shelly RGBW2 utilisé en white j’ai pu constater des changements sur les sorties durant la MAJ de celui-ci. c’est pas grave mais si vous l’utilisez pour d’autres choses cela peut être intéressant à savoir …
Au top cette astuce ! J’ai réussi à l’implémenter sur les Sehlly 1.
Question parallèle : sur un de mes 3 modules les commandes Info et Announce ne fonctionnent pas : elles ne sont pas créées automatiquement et quand je les créé moi-même elles ne remontent rien (résultat de test vide). Une idée? Je penche vers un hardware plus ancien que les 2 aures mais je ne sais pas comment le confirmer.
Je suis sur box Atlas, en v4.3.8, santé tout au green.
Merci pour ton retour.
En fait c’était mes commandes announce et info de type Info qui ne fonctionnaient pas, mais au bout d’un moment elles ont fonctionné. Bizarre…
Bon par contre j’arrive pas à faire lancer le scénario : est-ce qu’il faut bien mettre en déclencheur la commande announce de chaque relais, pour que le scénario se déclenche à chaque mise à jour de cette info ?
Mais du coup je vois pas l’intérêt de l’action Commande_announce (ou Annonce dans l’exemple de jeandhom)
La commande ‹ announce › est là pour que tu la lance à la main pour une mise ajour.
Sinon tes modules reçoivent l’information d’eux même et te préviennent.
Par contre ton scénario doit être déclenché par la commande information ‹ announce ›.
Il faut mettre le ‹ announce › de chaque équipement oui.
Ok merci en effet ça fonctionne, mon scénario se lance bien quand la commande announce est mise à jour (si je reboot le Shelly par exemple). La difficulté c’est qu’à part en rebootant elle ne se met pas à jour puisque pas de nouvelle valeur envoyée par le shelly, donc difficile de tester le scénario
Et forcément j’ai un plantage du scénario, du coup difficile de le débugger. Mais j’avance doucement grave à ton aide. Je créerai ptet un autre fil si je bloque trop, je vais pas polluer encore plus le fil de jeandhom.
Edit pour @jeandhom : le scénario me remontait une erreur (Error code : 22001 (1406). Data too long…) pour la ligne suivante :
message::add($source,$fw_ver,'Nouveau firmware disponible - Mettre à jour le firmware');
Je l’ai résolu en réduisant en gardant juste les infos essentielles :
Petit update : maintenant que tout fonctionne bien chez moi je vois qu’une nouvelle version de jmqtt va intégrer directement une fonction pour découper un Json et d’avantage de templats pour les shelly. On aura fait tout ça pour rien ?
Rien à redire, je découvre encore cet outil . Par contre je comprends pas, si le découpeur de Json (on dirait un nom de serial killer ) a toujours existé qu’est-ce qu’il y a de nouveau dans cet outil mentionné dans la nouvelle version ? Et la manip’ mentionnée dans ce fil serait donc inutile ?
Depuis la 4.2 du core (il me semble) tu peux directement tout mettre dans un payload dans commande action et extraire (depuis début 2021) le contenu d’un payload JSON à la volée.
Donc récupérer les infos et les publier pour lancer l’update en full jMQTT doit être possible (sans scénario), non ?
Le scénario ne lance pas automatiquement la mise à jour du firmware lorsqu’il détecte une nouvelle mise à jour. Il fait apparaître la commande action « MAJ Firmware » et fait disparaître la commande info « MAJ Dispo ». Je ne pense pas que cela soit possible sans scénario.
Merci pour ton retour. En effet pour la partie du scénario qui affiche les MàJ je suis d’accord qu’il faut la garder, mais notre réflexion avec @Bad portait sur la partie du script qui « découpe » la commande announce pour récupérer les termes séparés (Id, IP, fw, etc…). Il semble qu’il y ait une fonction plus simple pour découper cette chaîne.