Salut
Tu as eu de la chance de trouver une passerelle et neuve en plus 
J’ai remarque le même problème que toi dans les scénarios, si on lance plusieurs trames en même temps, elles semblent bien lancé par Jeedom mais pas répercuter par la passerelle.
Chez moi, j’ai mis 2 secondes entre chaque action.
1 « J'aime »
Salut à tous,
Comme vous, j’ai rencontré le même souci en créant des scénarios Jeedom comportant plusieurs commandes. Dans un premier temps, j’ai opté pour la même bidouille: rajouter un délai entre chaque action, mais ça ne réglait qu’une partie du problème, puisque l’intégration Homebridge était aussi touchée (en demandant à Siri d’allumer ou d’éteindre la lumière dans une zone contenant plusieurs éclairages, j’avais à tous les coups un ou plusieurs modules IOBL qui n’avaient pas reçu la demande).
J’ai d’abord pensé à un souci côté Boxio (qui aurait pu écrire les commandes vers le flux de sortie du port série de la passerelle en « parallèle ») mais j’ai observé le même comportement sous Windows. En fait, le problème est bien lié à la passerelle: dès qu’on commence à lui envoyer plusieurs messages dans un trop court laps de temps, elle les refuse purement et simplement en retournant une réponse NACK.
Résultat des courses, j’ai fini par modifier le daemon Python de Boxio pour ajouter un délai de 0.55 seconde après chaque commande en sortie. Si la manip’ vous intéresse, c’est assez simple: il suffit de rajouter time.sleep(0.55) juste après serial_param.port.write( message) dans boxiocmd.py: https://github.com/apages2/pluginjeedom-boxio/blob/master/ressources/boxiocmd/boxiocmd.py#L315. Perso, j’ai opté pour 0.55 secondes, qui semple être un bon compromis entre fiabilité et rapidité.
Dans l’idéal, il faudrait aller un peu plus loin que cette petite bidouille: il faudrait après chaque commande en sortie récupérer la réponse de la passerelle (soit ACK, soit NACK) et réémettre la même commande en cas de refus, avant même de passer à la commande suivante. Avec une boucle faisant plusieurs tentatives avec à chaque fois un délai d’attente plus grand, on serait sûr que la commande soit bien partie.
@BobRazowski félicitations pour avoir mis la main sur la précieuse passerelle ! Pas de doute, ça donne vraiment une seconde jeunesse à IOBL.
Au fait, pour ceux qui utilisent le gestionnaire 03809 et s’étonnent de n’avoir que des graphiques aux courbes plates, j’ai posté l’explication (et la solution) sur GitHub: https://github.com/apages2/pluginjeedom-boxio/issues/14#issuecomment-580788153
Merci Kevin, je vais regarder ça le plus tôt possible.
Ta manip est vraiment bien.
Quelque part c’est un peu un retour d’état pour savoir si la commande est bien passée et donc si l’équipement est bien dans la position voulue ?
En as-tu parlé à Apages qui pourrait mettre à jour le plugin ?
C’est toujours un plaisir de pouvoir aider 
Oui pour la première partie, mais pas forcément pour la seconde: la passerelle nous informe bien sur le fait que la commande ait été émise, mais on n’a pas la garantie que le module concerné ait bien reçu l’info (par exemple, s’il y a un parasitage important causé par un éclairage à ballast électronique ou une alimentation à découpage branchés au même moment sur un circuit proche de l’interface ou du module).
Pour être 100% sûr que la cible a atteint l’état demandé, il faut aller lui demander directement (de mémoire, ça s’appelle une UNIT DESCRIPTION REQUEST). Dans ce cas, le module en question retourne une trame Nitoo qui est convertie en OpenWebNet par l’interface USB et qui permet d’en extraire l’état réel.
Pour le coup, avoir une commande « interroger équipement » sur chaque module Boxio serait une super amélioration (pas forcément « visible » par défaut côté Jeedom, histoire de pas rajouter un bouton sur le dashboard pour ceux qui n’en voudraient pas). Cette commande existe déjà sur le gestionnaire d’énergie 03809 pour l’interroger sur les index HP/HC et sur l’état de la sortie « eau chaude sanitaire » donc j’imagine qu’une partie de la logique du traitement du statut existe déjà.
J’ai envoyé un mail à Michel et Aurélien pour les remercier pour leur fantastique travail il y a une dizaine de jours, mais Aurélien ne m’a pas encore répondu. J’ai aussi envoyé une pull request sur GitHub pour régler le souci des graphiques du gestionnaire d’énergie, mais pas de retour là non plus. Evidemment, si j’ai de ses nouvelles, je ne manquerai pas de lui en parler
@apages2 si tu nous lis… encore merci !
Edit: après vérification, c’est bien une UNIT DESCRIPTION REQUEST. Je viens d’essayer avec un interrupteur ref. 67201 (mais je mettrais ma main à couper que ça fonctionne exactement de la même façon avec les modèles doubles ou à voyant). Pour ça, il faut envoyer une trame *#1000*ID*55## et en retour, on récupère une trame de la forme *#1000*0#ID*55*129*STATUS## avec STATUS=0 quand l’interrupteur est à l’état OFF et STATUS=128 quand il est à l’état ON.
Bonjour
Je lie toujours les postes Lié à mes plugins mais je n’ai malheureusement pas beaucoup de temps à consacrer en ce moment à mes plugins jeedom, j’en suis désolé
Effectivement la requête 55 est normalement valable pour tous les équipements seul l’unit change en fonction du module à interroger
Pour ma part j’avais rajouté quelque’ une de ces commandes dans les templates et pour les commandes vraiment importante pour moi, j’avais créé des scénarios qui était déclenché par la commande en question, qui attendais quelques seconde (variables en fonction du module, par exemple 3 secondes pour un inter, et 30s pour un volet) et ensuite exécuté la commande 55 pour s’assurer que l’action avait bien été faite
Comme explique auparavant, j’avais en tête une évolution du plugin car le protocole comprend l’acquittement d’une commande, en natif mais je n’ai pas encore eu le temps de m’y pencher
Merci à Kévin pour ces PR, dès que j’ai quelque minutes je les regardes et les merges à mon plugin
Bye
1 « J'aime »
Merci pour toutes ces infos
Pour la passerelle le gars qui me l’a vendu a récupéré un stock de matos neuf legrand et il semblerait qu’il en ait d’autre 
Merci Apages et Kevin
On a hâte de profiter de cette nouvelle version
@Kevin, pour les graphiques avec le gestionnaire 03809, ta méthode marche super, merci
Saurais-tu comment je peux injecter dans Jeedom des données de relevés de ce gestionnaire que j’avais auparavant avec le Boxio de Michel ?
J’ai les relevés sur un tableur depuis plusieurs années…
Au niveau de la tempo à insérer entre 2 actions, comment faire pour modifier le fichier dans Jeedom.
Encore merci pour ton aide et ton soutien.
@apages2 je le redis ici: tu n’as absolument pas à t’excuser 
@BobRazowski haha, ça c’est un vrai coup de chance !
@Fidjial je ne suis pas hyper familier avec les fonctions avancées de Jeedom, mais je ne suis pas sûr qu’il existe un moyen « simple » d’importer des données.
Perso, j’avais des problèmes avec les index HP et HC, qui affichaient des valeurs très étranges: en fait, il y avait à chaque fois un offset par rapport à la valeur affichée sur le compteur (par exemple, pour la valeur HP, il y avait environ 65000 kWh de trop par rapport à la vraie valeur…). Quand je me suis rendu compte que Jeedom permettait de personnaliser la formule de calcul utilisée, j’ai aussi voulu corriger les anciennes valeurs dans l’historique de Jeedom.
Pour ça, j’ai opté pour la méthode bourrin: créer une sauvegarde, la télécharger sur mon PC, l’ouvrir avec 7-Zip, en extraire le script de recréation de la base de données (DB_backup.sql) et le modifier à la main pour corriger les valeurs (stockées dans les tables history et historyArc). C’est pas super compliqué puisqu’il n’y a que 3 colonnes: l’identifiant de l’info, la date de la valeur et la valeur en elle-même. Une fois fait, j’ai renvoyé la sauvegarde sur Jeedom et lancé une récupération. Bourrin, mais rapide et efficace 
Une méthode moins bourrin consisterait sans doute à récupérer les identifiants de la base de données MariaDB utilisée par Jeedom et à s’y connecter avec un explorateur ou avec une appli créée pour rajouter des données de manière automatique. Mais ça prendrait sûrement un peu plus de temps
Le plus simple, c’est sûrement avec un client SSH: tu ouvres une session, tu navigues vers le répertoire qui contient le fichier (cd /var/www/html/plugins/boxio/ressources/boxiocmd) et tu le modifies avec l’éditeur nano en faisant sudo nano boxiocmd.py). Sinon, tu peux aussi utiliser un client SFTP et aller chercher le fichier et le modifier sur ton PC avant de le renvoyer.
A noter: dès que tu feras une MAJ de Boxio, ta modification sera automatiquement écrasée. Il faudra la remettre en place en suivant la même manip’.
Bonsoir Kevin
Merci pour toutes tes précisions
J’ai bien réussi à injecter la ligne * time.sleep(0.75)* en ssh. J’ai supprimer toutes les tempo de 2 secondes dans les scénarios, je vais voir si tout se déclenche correctement maintenant.
Pour l’historique, j’ai utiliser ta méthode bourrin :
-dézipper une sauvegarde,
-ouvert la base DB_backup.sql
-repérer historyArc et injecter mon historique formaté sur 3 colonnes (461,‹ 2017-12-31 12:01:01 ›,‹ 55696 ›),
-recompresser .tar.gz
- restauré avec cette sauvegarde
- redémarré Jeedom
Mais rien de visible dans l’historique de jeedom !
Quand je regarde View data table, il n’y a pas de données…
J’ai loupé quelque chose ? ou faut-il attendre un peu que Jeedom fasse une opération ?
Merci pour ton aide et bonne soirée
Non, tu sembles avoir tout fait dans l’ordre. Perso, j’avais pas eu d’attente après la restauration.
Si tu lances une nouvelle sauvegarde, tu vois les valeurs que tu as ajoutées à la main dans le fichier .sql?
1 « J'aime »
j’ai lancé une sauvegarde et effectivement les valeurs que j’avais ajouté n’y sont pas !!!
Par contre la taille de la sauvegarde a été multipliée par 3.
je re tente…restauration et sauvegarde…
taille 780Mo au lieu de 128Mo
je vois un dossier Users qui apparaît en plus et les données sont dedans, bizarre.
J’ai l’impression que quand on injecte une sauvegarde.gz pour la restaurer, jeedom la place dans un dossier Users et lorsqu’on fait une sauvegarde à la suite, cette sauvegarde.gz est présent : ce qui augmente d’autant plus la taille de la sauvegarde…
Mais toujours pas d’historique, je vais continuer à chercher ce qui ne passe pas
Tu es sûr que ce n’est pas toi qui as ajouté par accident ce dossier quand tu as « remis » le fichier .sql dans le fichier de sauvegarde ? Au lieu de le remettre à la bonne place, peut-être a-t-il été mis dans un autre dossier ? (plutôt qu’à la racine)
Quand je télécharge la sauvegarde sur mon bureau, après je fait une extraction.
J’ai donc un dossier backup_jeedom_date_heure.
A l’intérieur je modifie le fichier DB_backup.sql
Je rajoute mes données d’historique et j’enregistre
Ensuite je compresse ce dossier backup_jeedom_date_heure en .tar.gz
Dans jeedom je fais Envoyer cette sauvegarde et je lance la Restauration
Je rame un peu à comprendre ce protocole. Je vous admire de piger le protocole avec si peu d’infos en entrée !
J’ai un module RF 88210 (interscénario automatique radio étanche de son petit nom) qui communique avec mon installation via une interface radio 03606.
C’est un détecteur de mouvement qui déclenche tout seul les équipement qui lui sont raccordé pour une durée fixée en dur sur le module.
Je ne sais pas comment créer ce module à partir de rien sachant que dans média j’ai une dropdown vide, donc pas moyen de sélectionner RF.
Pas de détection auto des modules RF, d’ailleurs dans les logs je ne vois passer aucune trame venant de ce produit (je suis même pas sur de regarder ou il faut pour faire du spy sur les trames (lol).
Mon idée étant d’avoir un retour de l’état du bouzin pour que la détection de mouvement puisse me servir à déclencher d’autre produits.
Le produit ne crachant par lui-même pas de trames, je ne vois pas comment chopper un statut pour qu’il soi à jour…
Je suis donc complètement pommé et je ne sais pas par quel bout attraper le truc 
Si vous avez des idées pour moi je suis preneur 
@Fidjial ton histoire fait vraiment penser à un problème d’emplacement. Peut-être que quelques captures montrant la hiérarchie des fichiers/dossiers de ton fichier de sauvegardes permettraient d’y voir plus clair ?
Je rame un peu à comprendre ce protocole. Je vous admire de piger le protocole avec si peu d’infos en entrée !
@BobRazowski la spécification de l’interface aide un peu, mais le code source de Boxio est une vraie mine d’or pour appréhender le protocole plus clairement (lequel est, outre l’absence de sécurité, assez complet).
Perso, je n’ai pas cette référence, mais je serais surpris si ce détecteur ne fonctionnait pas comme l’interrupteur automatique Céliane référence 67215, qui, en cas de détection, déclenche un scénario ACTION FOR TIME dont la trame contient la durée réglée sur le détecteur (durée au bout de laquelle les récepteurs sont invités à s’éteindre d’eux-mêmes, sans trame supplémentaire).
Tu devrais pouvoir voir les trames passer en passant le niveau de log à « debug » dans la configuration de Boxio.
C’est la que le bas blesse… aucune trame venant de la RF visible dans le debug. J’ai des télécommandes 88205 aussi et rien de rien dans les trames vues par la passerelle
J’ai plusieurs de ces télécommandes donc j’ai pu essayer de mon côté, et j’ai bien une trame correspondant à un scénario de type ACTION dans les logs: *25*11*0#[ID]#1##.
Tu n’aurais pas un souci de parasitage entre l’interface USB et la passerelle RF/CPL ?
La passerelle RF/CPL est loin de mon tableau ou est mon jeedom, cependant il y a un 3600 juste à côté que la passerelle voit très bien.
Le module 3606 est apparu dans ton installation ou tu l’a créé à la main ? (ou il est pas défini du tout).
En la créant à la main, elle me cause quand je lui demande sa description …
`[2020-02-16 22:14:22][DEBUG] : Jeeboxio_Equipement : Array ( [trame] => #10006008465*51## [format] => DIMENSION_REQUEST [mode] => UNICAST [media] => CPL [type] => CONFIGURATION [value] => [dimension] => DEVICE_DESCRIPTION_REQUEST [param] => [id] => 375529 [unit] => 1 [date] => 2020-02-16 22:14:22 )
[2020-02-16 22:14:22][DEBUG] : Jeeboxio_DIMENSION_REQUEST avec Parametres, mise a jour des statuts
[2020-02-16 22:14:22][DEBUG] : statusid : status1 ref legrand/sous device: 036061/ date : 1581887662 unit status : 1 unit_code : type : INTERFACE
[2020-02-16 22:14:22][DEBUG] : Jeeboxio_Equipement : Array ( [trame] => *#*1## [format] => ACK [mode] => UNKNOWN [media] => UNKNOWN [type] => UNKNOWN [value] => [dimension] => [param] => [id] => [unit] => [date] => 2020-02-16 22:14:22 )
[2020-02-16 22:14:22][DEBUG] : Jeeboxio_Trame non interprétée`
Nope, perso, je l’ai pas ajoutée dans Jeedom (je crois qu’il existe un template, mais pas trop sûr de ce à quoi ça peut bien servir).
Essaie de temporairement rapprocher l’interface, ne serait-ce que pour tester