Bonjour à tous
Je viens tout juste d’installer influxDB et Grafana et je tente d’apprivoiser ces deux outils puissants
Je suis sous les dernières version influxDB 2 et Grafana dernière version
J’ai installé le plugin InfluxDB aussi car j’ai pas réussi à pousser des commandes avec ce bloc code
// EXEMPLE D'un bloc code dans un scénario pour implémenter une table
// dans influxdb depuis jeedom (sans le plugin-influxdb)
$host = '192.168.0.158'; //c'est l'ip de la machine qui héberge influx
$base = 'jeedom'; // nom de la base (il faut qu'elle existe)
$table = 'ballon'; // nom de la table
// ID des commandes reperez les ID des commandes
// et donner un nom dans la table
$cmd = cmd::byId(72);$input1 = $cmd->execCmd();$c1='top';
$cmd = cmd::byId(71);$input2 = $cmd->execCmd();$c2='haut';
$cmd = cmd::byId(70);$input3 = $cmd->execCmd();$c3='milieuhaut';
$cmd = cmd::byId(69);$input4 = $cmd->execCmd();$c4='milieubas';
$cmd = cmd::byId(68);$input5 = $cmd->execCmd();$c5='bas';
$req='influx -database '.$base.' -host '.$host.' -execute "INSERT '.$table.' '.$c1.'='.$input1.','.$c2.'='.$input2.','.$c3.'='.$input3.','.$c4.'='.$input4.','.$c5.'='.$input5.' "' ;
$scenario->setLog('DEBUG REQUETTE : '.$req);
$output0 = shell_exec($req);
$scenario->setLog('DEBUG RETOUR : '.$output0);
Ce bloc code est peut être pour influxDB 1 ou bien j’ai fait une erreur
Est ce qu’il y a une adaptation à faire pour influx DB 2 ?
Si oui laquelle car je suis pas un as du codage du tout.
Ensuite est ce que le plugin influxDB est lent voir hyper lent à l’affichage des commandes pour vous ?
Chrono en mains j’attends plus de 5 minutes avant l’affichage des commandes de mon jeedom ! Est ça pareil chez vous ?
Merci bien de votre accompagnement
Ce code ne fonctionnera pas pour une v2.
Le plugin gère la v2.
La vitesse d’affichage dépend du nombre de commandes que vous avez et du matériel sur lequel vous exécutez jeedom.
Avec ~2500 commandes, cela prend 2s à 3s chez moi mais effectivement c’est trop « lent ».
Je devrais améliorer cette partie dans le plugin
Mais du coup, avez-vous le même problème lorsque vous allez dans la configuration de l’historique?
Bonjour @jerome6994
Pour le code dont je suis l’auteur il à été réalisé du temps de la V1
et n’a pas été réviser depuis.
Ça n’a plus d’intérêt entre le plugin-influxdb et l’intégration jeedom d’autre part …
libre a toi d’en faire une adaptation.
Bonne journée
C’est pas d’hier et la stable aussi depuis la 4.1 mais c’est hors sujet puisque la c’est tagué avec le plugin.
L’avantage du plugin c’est la liste toutes les commandes que tu peut choisir a la volée sans aller cocher chaque commandes une à une dans les équipements …
@Mips
Merci pour le retour, alors 2 à 3 secondes j’achète
Je viens de tester avec l’historique et j’ai craqué au bout de 6 minutes d’attentes !
Je ne sais pas à quoi c’est du ceci !
Côté machine je suis sur NUC i5 avec 32Go de RAM dont 8 dédié à Jeedom
@olive
Je n’ai pas pris la propriété de ton code loin de là d’ailleurs
L’intérêt que j’y voyais c’est la simplicité d’envoyer les commandes sur influxDB sans attendre les 6 minutes mini évoquées
Mais je suis bien incapable de faire l’adaptation sinon je demanderai pas de l’aide sur les deux sujets.
Mais merci du temps passé à répondre
Je vais déjà explorer le pourquoi c’est si lent qui semble être le vrai souci initial soulevé par @Mips
Ah oui… donc je pense qu’il y a plutôt un problème de ton coté.
En fait j’ai revérifié et mesurer les temps et c’est côté client (donc ton browser/ordi) le soucis, c’est la table en javascript (pour pouvoir trier et filtrer) qui prend du temps à s’initialiser.
Coté serveur (donc jeedom) ça prend 0s chez moi et jeedom est sur une vm proxmox nuc i5 avec 4go pour jeedom (et seulement 2go sur ma machine de dev mais « seulement » 1500 commandes)
C’est le même composant utilisé dans l’historique jeedom et dans ma liste de commande.
Peux-tu aller dans le résumé domotique et dire combien tu as de commandes?
En fonction, si tu en as beaucoup plus, je peux faire des tests en créant des commandes supplémentaires pour être dans les mêmes conditions
Salut Mips,
Une piste pour peut-être gagner du temps a l’affichage de la liste des commandes
Ne garder que les binaire et les numériques et ne pas mettre les strings
Tu en pense quoi ?
C’est vrai que moi je n’envoie que du numérique mais je ne sais pas si c’est le cas de tout le monde.
et s’il y a des commandes « string » mais qu’en fait c’est du numérique dedans ca va être bloquant.
Alors je cherche ce qui a généré autant de commande pour rien.
Il y a d’une part la virtualisation mais il y a surtout le zwavejs2mqtt qui pour un objet me fait 40 à 50 commandes qui ne sont pas activées mais bien présentes.
Mais de manière générale avec le plugin jmqtt on remonte bcp de commandes aucun tri n’est réalisé à contrario d’un plugin comme zigbeelinker.
Bref du ménage à faire.
Donc dans l’option de filtrage il peut y avoir aussi que les commandes actives si c’est pas déjà inclu.
Dans le résumé domotique on pourrait aussi avoir la quantité de commande et équipement sur chaque ligne de nos objectes cela permettrait de cibler plus facilement
Salut Jerome
Quand tu fait des intégrations avec jmqtt si tu met en automatique ça génére beaucoup de commandes
une fois récupéré il te faut désactivé le modes inclusion auto puis supprimer toutes les commendes dont tu ne te sert pas !
N’hésite pas si tu a beaucoup d’équipements identique à faire un template du 1er puis a l’appliqué sur les autres on gagne beaucoup de temps en ménage.
Bonne journée
Sauf que cette notion n’existe pas
Il n’y a pas de commande « active » ou « inactive ».
Par contre je suis occupé à revoir complétement la partie config, par défaut il n’affichera que les commandes sélectionnées (donc en principe très léger) et ensuite il y aura plusieurs possibilités pour sélectionner des commandes:
je laisserai un écran avec le système actuel (qui en fait est satisfaisant quand on a un nombre de commandes raisonnables)
dans ma version en dev, il y a déjà moyen de chercher des commandes une par une (même popup que partout dans jeedom)
je pensais rajouter une « navigation » par pièce, puis équipements;
et bien sur toujours la possibilité d’avoir plusieurs équipement avec des règles de push différentes par ensembles de commandes à envoyer.
ce n’est pas encore en beta, je veux finir le dernier point avant de passer en beta et puis je dois gérer la migration des équipements car la config en interne change.
Super @Mips
Je lançais des idées
Je viens de voir que le plugin suivi conso par exemple génère environ 200 commandes par équipement créé !
Avec mes panneaux solaires et quelques équipements de conso dessus j’ai pas loin de 4000 commandes rien que là !
le listener c’est un mécanisme du core.
La taille est limitée et je ne pourrai pas changer cela, créé plusieurs équipements influx et sépare les commandes que tu envoies dans chacun de ces équipements; par exemple un par plugin ou un par type de mesure ou par pièce…
Demandes-toi aussi si tu as vraiment besoin de l’info en temps réel ou si l’avoir chaque minute suffit et donc de passer en auto-actualisation.
Parce je doute que cela ait vraiment une importance de savoir cela dans des stats après 3 mois… mais à toi de voir.
Comme dit dans la doc, le temps réel va demander plus de ressources à ton jeedom (cpu surtout), c’est comme avoir 74 scénarios de plus (ou un scénario avec 74 déclencheurs )
j’aime le gout du risque 
