Moi je veux un plugin IAGPT ou je n’aurai qu’a lui dire via le micro de la google home découvre tous mes périphériques, mets en place tous les scénarios et le monitoring , en cas de panne répare tout.
Voilà sans rien faire d’autre.
Oui c’est compliqué à diagnostiquer, mais ça fait déjà un moment que je remonte un soucis dans les commandes d’un virtuel qui ne se mettent pas forcément à jour alors qu’une sauvegarde du virtuelle remet à jour la commande.
Me passer des virtuelles, je saurais pas faire
Dans mon exemple, j’ai une commande qui contient les états de quelques ouvertures, quand tout est fermé, la commande est à 0, si au moins un ouvrant ouvert alors il passe a 1 et si il reste plus de 7mn alors il coupe les thermostats
Alors je pourrais passer par un scénario, avec en déclencheur chaques ouvertures si égale a 1 et dans le scénario, fait une DANS 7mn, refaire un tests des ouvertures et si au moins un ouvert couper les thermostats mais est mieux ???
Je pense que le core, et le plugin virtuel qui est officiel, doit garantir la véracité des commandes.
Pour ça, dans chaque objet, tu as l’onglet « Résumé ».
Avec les generic_type ont peu aussi faire de belles choses.
#genericType(OPENING_WINDOW,#[Tous]#)# == 1
Après je ne sais pas si les thermostats dont tu parles sont via le plugin thermostats mais dans ce dernier on trouve aussi
1 « J'aime »
Oui j’utilise les résumés pour l’ensemble des ouvertures mais pas toutes pour la coupure du chauffage, mon Jeedom n’est pas conçu en « pièces » mais en « objets »
Ça, typiquement, c’est de la « non-fiabilité » au même titre que les plugins qui ne se relancent pas tous seuls lorsque les clés USB se reconnectent.
Alors, oui, pour les clés USB qui se reconnectent pas comme il faut, je remets ici un panneau C’est par ici la solution
Combien de gens ont eu, ont et auront ce souci ? C’est dommage que la gestion des ports USB ne soit pas mieux foutue, par exemple, en utilisant directement la liste des clés présentes sur le système données par la commande ls -al /dev/serial/by-id/*
Exactement
J’avais vu passer tes soucis de rafraîchissement de commandes info. J’ai les ai aussi eu. Je dirais que le problème vient de la façon de « programmer » dans le virtuel. Mais, l’utilisateur ne sait pas ce qui est possible de ce qui n’est pas possible de faire.
Lorsqu’on veut exécuter dans l’ordre les commandes
commande_1 : C = A + B
commande_2 : D = C/2
commande_3 : E = 2*(C+D)
Et bien, cela ne fonctionne pas toujours à tous les coups, sans qu’on comprenne pourquoi. De plus, si la commande_2 est dans un virtuel différent de celui qui contient les commande_1 et commande_3, là, c’est le casse-pipe assuré !
Une solution à ce problème est de s’assurer qu’aucune commande n’utilise pas le résultat d’une autre commande du même virtuel. On peut réécrire les choses comme ceci
commande_1 : C = A + B
commande_2 : D = (A + B)/2
commande_3 : E = 3*(A + B)
C D et E sont calculés directement à partir de A et B. Ici, l’exemple est simple, mais le fait de tout réécrire complexifie les choses car il faut modifier une même formule partout où elle est utilisée.
Pour faire ceci
J’écris ça
Autre exemple qui m’avait bien « gonflé » dans les scénarios.
J’avais créé un scénario avec des variables pour un faire régulateur PID.
Et bien, à force de faire des calculs itératifs, le « machin » plantait tout seul comme un grand au bout de X heures. En effet, ce « zigoto » ne savait plus faire de calcul dès que les nombres étaient écrits par lui-même avec la notation exposant car il les considérait comme du texte et ainsi concaténait et concaténait encore et encore des chaînes de caractères au lieu de faire le calcul jusqu’à ce que Boum! Voir ici
et là
La solution était de mettre des « » ou simple quote pour le forcer à calculer. Un truc entre « », il me semblait que c’était du texte 
Oui, pour les commandes imbriquées entre virtuels je fais attention mais même au sein d’un virtuel il faut respecter l’ordre des ID dans le même virtuel
Mais bon c’est pas normal, c’est au core de gérer ça.
Je crois que tu n’imagines pas la complexité du code qu’il faudrait pour gérer ca, perso c’est tellement complexe que je ne saurais pas le faire… J’imagine même pas les risques de ralentissement de jeedom juste pour ça en fonction du calcul du chemin.
1 « J'aime »
Salut,
Tout est toujours bien étayé et démontré dans tes messages, j’adore !
Sans avoir vérifié quoi que ce soit à tes propos ni vouloir entrer dans le détail et encore moins dans un débat quelconque, juste à mon sens ça fait un peu usine à gaz quand même comme ça de loin. Perso ça ne m’étonnerait même pas que ça puisse planter de temps en temps, je m’explique :
L’idée d’utiliser une commande virtuelle pour effectuer un calcul simple est viable sans problème. Pour un enchainement de calcul c’est moins l’objectif des virtuels. En effet, il faut savoir (en reprenant ton exemple) que chaque fois que les commandes A ou B vont être mises à jour cela va entrainer la mise à jour automatique de la commande virtuelle qui fait un calcul dessus (C). Et ainsi de suite pour toute commande virtuelle qui utilise une ou plusieurs autres commandes pour faire des calculs.
En gros avec ton 1er exemple, A ou B changent de valeur, ça entraine la MAJ de C. Au changement de valeur de C, D et E sont mis à jour automatiquement dans la foulée et au changement de valeur de D, E sera encore mis à jour. Arrivé ici je vois déjà un problème potentiel pour ma part dans le calcul des commandes D et E.
Je ne sais pas si je suis bien clair dans mes explications mais à priori il parait bien plus judicieux de gérer ce cas de figure par scénario que directement via des commandes virtuelles dont les valeurs dépendent les unes des autres au même moment.
7 « J'aime »
Dans les scénarios, on revient au problème de calcul que j’évoquais plus haut
si toto = titi + tata sachant que la somme de titi et de tata vaut tutu
alors toto égale à la valeur tutu ou à la chaîne de caractère titi + tata ? 
Je ne suis pas certain que ceci soit toujours vrai. Pour la création du virtuel, il vaut mieux partir du principe que les commandes puissent se rafraîchir dans n’importe quel ordre. Ce n’est pas du code séquentiel où on puisse enchaîner les équations dans les commandes.
La on touche à une limitation du language PHP : c’est un language faiblement typé, les variables ne sont pas déclarées, ça ne lui pose donc aucun problème d’additionner des nombres et du texte, il fait juste au mieux, c’est à dire mal la plupart du temps. C’est au développeur de savoir quel type de variables il utiliser.
Mais évidemment, un utilisateur domotique ne le sait pas, on peut pas lui en vouloir 
La solution c’est simple : il suffit de réécrire jeedom en java !
1 « J'aime »
Ce sujet est passionnant. J’entends beaucoup de choses sur la fiabilité ou plutôt la non fiabilité des systèmes domotique dans mon entourage pro / perso mais aussi lors de mes lectures ici ou là.
J’aimerai vous livrer mon expérience car c’est Jeedom qui fait tourner ma maison depuis 2018 et ce en ayant eu seulement deux gros soucis( ma fautes mais c’était prévu …)
Pour commencer la base : si Jeedom doit être fiable, installons le sur du matériel fiable. J’ai commencer avec un pi2 puis rapidement pi3 jusqu’à ce que ma carte sd crève ( c’était voulu, je voulais voir combien de temps pouvait tenir un système aussi … précaire), puis sur un mini pc mais avec un espace de stockage clairement sous dimensionnée
Mon installation n’a jamais été down plus d’1h puisque ce cas de figure de panne générale avait déjà été réfléchi.
Avant et pendant l’installation j’ai mangé de la doc sur l’installation mais aussi le fonctionnement global de Jeedom.
J’ai également défini un plan d’action : qu’est-ce que je veux donner à jeedom ( ou plutôt qu’est-ce que je veux domotiser), pourquoi ? Pour quand? Et enfin si je perd Jeedom quel est l’impact
Globalement on tourne sur de la sécurité, confort, automatisation et économie d’énergie.
L’avantage de construire une maison c’est que la domotisation avant avec les chantiers.
Une fois démarré 1 etape: la sauvegarde. Dès le départ j’ai tout misé sur mon nas.
La sauvegarde sur le système en lui même me paraissait dangereux.
Étape deux par quoi je commence: je n’ai pas été original, j’avais du hue des Google home et des capteurs de feu homlive. J’ai donc commencé par des scénarios simples : notification pour le jour des poubelles, faire parler des Google pour souhaiter la bienvenue… mais aussi surveille le pont hue m’arrêter en cas de Ping down surveille ma connection internet, programmer des alertes sur les piles basses des interrupteurs. Et la plupart de ces choses là ne demandent pas de scenarii. C’est possible directement dans les paramètres des modules ou dans le menu équipement de Jeedom. Ensuite est venu du zwave je regarde donc les clés avec les meilleurs retours, les posts sur l’ancien forum de Jeedom et je me lance avec quelque modules déjà en ma possessions (capteur incendie, œil fibaro et détecteur de porte) je test quelques scénario de confort, mon mode dégradé: j’enlève les piles, je laisse la porte ouverte longtemps, je fais sonner le capteur incendie. En me documentant sur le zwave j’apprends qu’on peut aussi associer un sirène à un pasteur incendié par exemple dorectelent entre eux. Génial si Jeedom est down j’ai toujours ma siren en cas de départ de feu. Bref je fiabilise.
Au fur et à mesure que je me suis équipé, je déployait avec un seul mot d’ordre, le mode dégradé. Quel est le niveau d’acceptation de perte si Jeedom est down.
Beaucoup dutilisateurs ne rationalisent pas non plus leurs installations. Si on a déjà du zwave pourquoi rajouter du zigbee, pont hue, acquara etc. Plus on a de protocole, de pont ou de box plus on a de risque de panne. Un effort doit être aussi fait à l’achat de matériel : si le cloud tombe est ce que je suis prêt à perdre mon intégration.
Attention je ne dis pas qu’il faut se limiter à un protocole. Je dis simplement qu’un deploiement doit se faire en prenant sont temps et en terminant les choses jusqu’au bout.
Je pense aussi que quand on a le choix il faut viser le cloudless. Limitons les sources de pannes (serveur netatmo down plus de météo ou retour camera par exemple….)
Jeedom tourne chez moi depuis 2018 (quasiment le 1 jour de mon arrivée dans la maison puisque que j’ai testé la solution avant à mon appartement) et je n’ai jamais eu de soucis de fiabilité.
Ça ne veut pas dire que les soucis n’existent pas mais Jeedom demande de l’investissement oui c’est certain. Mais la marche n’est pas très haute non plus. Je pense que c’est avant tout une philosophie à avoir.
Mon voisin avait acheté une box lifedomus ( un nuc avec une distrib Linux+ soft delta dore je crois) le prix n’était pas donné. On peut s’attendre à un système clé en main… bin non. Et pourtant on ne parlait pas de DIY la. On parle bien d’une box d’un grand constructeur. Résultat il a péniblement réussi à automatiser un volet sur 8 et l’apparer a alexa avant que la Lifedomus ne soit abandonnée. Elle fonctionnent toujours mais le service autour de cette box finira aussi par s’arrêter.
Pour conclure j’ai lu que Jeedom était comparé à une voiture plus haut dans les postes et que c’est aux constructeurs de s’assurer du bon fonctionnement du véhicule.
Ce n’est pas tout à fait exacte. Si l’utilisateur souhaite ajouter des fonctions aux véhicules et qu’il le fait lui même le sans vérifier la compatibilité le constructeur n’est pas responsable.
Lorsque le niveau d’huile devient très bas le voyant s’allume mais un contrôle périodique aurait pu prévenir cette problématique. Idem pour un voyant risque cassé moteur. Au même titre que Jeedom vous alerte de façon automatique en cas de non démarrage d’un Plugin la vérification des envoies d’information, de leurs fiabilité et du bon fonctionnement des modules sont à charge de l’utilisateur comme le contrôle des pneumatiques, des états de carrosseries rétroviseurs et bon fonctionnement de vos feux et phares.
Idem pour les doc on lit les notices voir les RTA mais la doc Jeedom et les cellles des plugins renferment énormément de réponses, d’astuces et surtout de mode opératoire souvent ignorés mais qui pourtant participent à fiabiliser les installations.
3 « J'aime »
Si c’était simple on demanderait pas à l’informatique de le faire pour nous 
Faut demander de l’aide à chatgpt, c’est très a la mode en ce moment
1 « J'aime »
Déja fait il ne sait pas faire pour le coup ou son code est bogué mais c’est normal c’est un des probleme les plus complexe en informatique le calcul de chemin dans un arbres, personne n’a encore vraiment réussi a le résoudre de maniere globale.
Dans tous les cas le plugin virtuel n’a de toute facon pas était fait pour ca, il doit faire des calculs que sur des commandes non virtuel normalement, je vais voir avec jeedom sas ce qu’ils en pensent d’interdire le calcul virtuel sur des virtuels car je vois bien que ca vous pose soucis et sort comme un soucis de non fiabilité de jeedom, ce n’est pas bon pour l’image.
5 « J'aime »
Oui si le virtuel n’était pas fait pour ça, cela aurait dû être verrouillé, le faire maintenant serait une grosse régression
Oui mais vu qu’on est pas en capacité de le faire marcher et qu’on voit bien que ca a un impact negatif sur l’image de jeedom il va peut etre falloir trancher.
c’est Loic qui m’avait expliqué ca lorsque j’avais remonté des soucis aléatoires dans la mise à jour de certaines commandes imbriquées dans les virtuels, mais j’ai peut être mal compris
2 « J'aime »
le problème c’est que la plus part du temps ca marche
et si il n’est plus possible de mettre des commandes externes dans une commande d’un virtuel, que ce soit pour un calcul ou pour un test, je vois plus trop l’intérêt du plugin virtuel.
Bonjour,
Si tu pourras mettre des commandes externe venant de n’importe quel plugin mais pas du plugin virtuel.
OK, d’accord, c’est juste l’usage imbriqué de commande entre les équipements du plugin virtuel qui pose soucis ?
j’ai beaucoup utilisé ca au début de jeedom, je doublais tous les équipements et plugin avec un virtuel pour simplifier la gestion en cas de problème d’un équipement/plugin. Nous avons déjà parlé de cette pratique, que j’ai abandonné maintenant et supprimer au maximum car avec la fonctionne de copie de commande ou l’outil de remplacement, ce n’est plus nécessaire.
A suivre donc.
1 « J'aime »