Fiabilité de jeedom?

Bonjourn

Le vous représente combien d’utilisateur ?

Donc on ne pourrait pas utiliser les commandes d’un virtuel dans autre. Sacrée régression …

Un gros warning sur la page de l’équipement serait moins douloureux :wink:

Le vous je sais pas moins de 10 utilisateurs je dirais mais vu que ca sort dans un sujet sur la fiabilité de jeedom qui est critique pour moi j’essaye d’améliorer les choses.

Une grosse régression oui après ca n’aurait jamais du etre possible, il n’a pas du tout était fait pour ca le plugin.

Bonjour,
Pour éviter un gros boulot, un message d’avertissement pourrait déjà suffire.
Je pense que vous avez déjà plein de jolies choses à faire.

Les virtuels permettent de faire des choses bizarres ? Il est possible de tenter de planter un clou avec un smartphone. Après, ce n’est pas la meilleure façon de s’en servir et tant pis pour l’utilisateur qui tente des trucs improbables. Le message indiquerait déjà ce qu’il ne faut pas faire.

J’adore l’analogie :rofl: du coup, faudrait ne pas autoriser les clous ou les smartphones.
Il ne faut pas restreindre les fonctionnalités de ce plugin qui fait un boulot incroyable parceque certains veulent tout gérer dans ce plugin. on en revient aux échanges (de même type) d’il y a 2 ou 3ans, d’utilisateurs qui doublonnaient tous leurs équipements dans le plugin virtual par souci de maintenabilité future.
Il ne faut pas brider cet outil parce que certains lui en demandent trop, comme on interdit pas les smartphones parce que certains font des selfies au bord des falaises

… Et l’objet initial de ce sujet n’était même pas les virtuels

EDIT : peut-être juste compléter cette alerte dans la doc

IMPORTANT

Il ne faut pas abuser des virtuels car ils entrainent une surconsommation générale (cpu/mémoire/swap/disque), des temps de latence plus longs, une usure de la carte SD, etc… Il ne faut donc EN AUCUN CAS dupliquer (tous) les équipements en virtuel sans absolue nécessité !
`

Les virtuels ne sont pas des commandes qui permettent de faire des calculs complexes ou recursifs (entre virtuels), il convient, dans ce cas de privilégier l’usage des scenarios avec une mise à jour des virtuels avec les données déjà calculées.

Les virtuels sont des outils à utiliser avec parcimonie uniquement lorsque cela s’avère nécessaire.

Norbert

1 « J'aime »

J’ai pensé aussi au problème des chiens séchés au micro-ondes.
Il y a eu la doc mise à jour pour prévenir que ça n’était pas sain.
Après, il n’y a pas eu de détecteur de vie dans le four pour éviter à tout prix les andouilles.

En tout cas, Jeedom est fiable selon moi.
Vu tout ce qu’on lui met dans la tête, avec l’historique et les protocoles en tout genre.

Évidemment, un pont fermé comme Philips Hue qui ne prend pas les marques non validées et qui proposent des petites routines, ça parait plus fiable. Mais tellement limité que ça dépanne Mme Michu.
Ou un Jeedom qui tourne sur une carte SD depuis un moment, il aura forcément un problème, voir des lenteurs si c’est un view Raspi surchargé.

La page Santé est un vrai plus, qui permet de voir rapidement ce qui va ou non.
J’aime aussi les astuces/tuto du genre analyser les archives. On a vite fait de tout historiser et d’oublier ensuite les purges.

Peut-être améliorer à temps perdu un Advisor dans Jeedom ?
Mais bon, Il me semble qu’il y a déjà pas mal de sujets en court…

Bonjour,

Si on devait rependre la question d’origine et les publications de l’auteur d’origine, vous devez tous avoir remarqué que le problème n’était pas la fiabilité de Jeedom !
- Mais surtout le manque de lecture des documentations et du savoir-faire de l’utilisateur (ne pas se voiler la face pour dire les choses clairement).

C’est même souvent le problème commun avec tous les messages de ce type.

Je ne trouve pas correct de dire que la course à pieds c’est nulle sous prétexte que je ne tiens pas plus de 500m.

Simon, ceux qui on des iPhones peuvent tester s’il est possible de planter des clous avec ? Je ne suis pas certain qu’Apple l’autorise. -----》[ ]

2 « J'aime »

Si c’est un i-nail à 50 € ça devrait être autorisé :joy:

Bonjour, je sais que c’est pas le sujet du post, mais c’est pour essayer de comprendre

quelle est la différence entre :

  • une commande d’un virtuel qui appelle une commande d’un équipement provenant d’un autre plugin
  • une commande d’un virtuel qui appelle une commande d’un autre virtuel
  • une commande d’un virtuel qui appelle une autre commande de ce même virtuel

ce sont ces 2 derniers points qui semblent ne pas être « propre », c’est bien ca ?

1 « J'aime »

Bonjour,
Tu as le risque de faire une boucle et d’avoir des soucis lors des mises à jour de valeur on juste :

  • le cas de la boucle est évident : commande A qui utilise B, B utilise C et C utilise A => ca plante en pouvant emmener la db avec
  • lors de la mise à jour par cron il traite dans l’ordre des IDs, si A a besoin de B et que B est après A ben ca marche pas. Il va mettre à jour A puis B et donc A aura la valeur calculé depuis l’ancien B
  • ya aussi le cas ou A a besoin de B et C et que B et C se base sur D, lors de la mise à jour de D, B et C vont se mettre à jour et ca va déclencher une double mise à jour de A, dans ce cas impossible de prédire si A aura ou non la bonne valeur

Et la c’est que les cas simple mais il y a des cas beaucoup plus complexe.

1 « J'aime »

ok, je comprends
la boucle, on a une alerte je crois, il suffit d’y faire attention.
pour l’ordre de MAJ des ID, tu m’avais transmit l’information, j’y fait donc attention dans les commandes dans un même virtuel.
Je vais faire une passe pour limiter ces imbrications

Mais c’est vrais que j’ai pris l’habitude pour faciliter la gestion de certaines parties, de regrouper dans un virtuel, des commandes qui pointent vers des équipements, puis au sein dece même virtuel, de faire des commandes de contrôles, d’affichages ou d’alertes, qui elles appellent, non plus les commandes des différents équipements mais les commandes de son propre virtuel. C’est pratique et plus facile à maintenir :slight_smile:

merci Loïc, bon long we :slight_smile:

si je comprend, certains dont moi se plaignent d’un core qui n’assiste pas assez l’utilisateur sur les plantages ou dysfonctionnement pour arriver au fait qu’il va falloir se méfier parce qu’un changement va influer sur le fonctionnement actuel …

c’est une punition parce qu’on s’est plain ??? Mdr

1 « J'aime »

Non au contraire on vous écoute et on réagit en conséquence

Bonjour,
Je dirai plutôt que le titre et le 1er sujet mettait en doute la fiabilité de Jeedom.
Et que l’idéal aurait été de créer un sujet par problème constaté pour trouver la cause, voir une solution.
Il y a « se plaindre », et « demander de l’aide » : ce n’est pas le même état d’esprit.

Après, la réponse de Loïc pour gérer un truc non essentiel (selon moi) m’a attristé car il y a plein de chantiers plus intéressants pour améliorer Jeedom, plutôt que de devoir mettre des barrières partout.

Ta proposition d’aider l’utilisateur est très bien.
La page santé est déjà un 1er pas.
La page de paramétrage avec les commandes linux essentielles aussi est un 2nd pas bien utile.
Pour aider à diagnostiquer Jeedom, cela n’est pas obligé d’être fait dans le Core, un plugin tiers peut aussi arriver à faire quelque chose.
En attendant, il faut lire les tutoriels.

3 « J'aime »

on dit qu’on veut être aidé par le core pour le diag et surtout la « réparation » éventuelle de trucs qui déconnent sans avoir besoin d’être expert.

a la place, on trouve un truc anormal mais qui marche pour certains. On veut le modifier pour revenir a un fonctionnement normal : rien a voir avec le sujet.
Qui plus est, si c’est comme pour la répétition de valeurs ou chacun va devoir repasser sur des fonctions qui marchent … c’est contre productif !
je souhaite, dans mes doléances, passer moins de temps a régler des pb plus ou moins récurrents et du coup va falloir que je vérifie mes virtuels … = punition ! lol

je réitère : Jeedom demande beaucoup de surveillance et je pense que le core pourrait détecter et réparer plus de choses seul grâce a votre matière grise bien plus performante que la mienne en ce domaine (et je ne parle pas de la patience …)! (démon en vert mais arrêté, équipement qui ne remonte plus de valeurs et surement d’autres)

1 « J'aime »

Bonjour,
Et tu penses que le core ne surveille rien ? Tu imagines pas tous ce qu’il fait et tous ce qu’il repare automatiquement sans que le tu vois… Ce qu’il ne fait pas c’est que c’est pas possible de le faire de maniere 100% sur, je pourrais effectivement prendre ton jeedom faire des trucs qui repare tout automatiquement chez toi par contre ces trucs vont casser le jeedom chez d’autre… Si encore on avait que les box jeedom on pourrait mais la on a des milliers de hardware different avec chacun leur particularité c’est compliqué a gerer. Crois moi dès que je peux automatiser je le fais mais faut pas que ca casse le jeedom d’un autre donc tout n’est pas automatisable meme si vu de ta fenetre ca semble « simple ».

1 « J'aime »

je n’ai pas dis que c’était simple, je dis que vous êtes oh combien plus capables que moi.

je pense que si chaque commande pouvait être configurée de façon a remonter un pb si elles n’ont pas reçu d’info 1 fois par an, par minute ou par mois de telle a telle heure par exemple serait une grande avancée sans que l’utilisateur ne passe par scénario ou autre surveillance a mettre en place.
Ex : avec le type ou autre combo, si on déclare une remontée d’info solaire, on sait qu’il n’y aura rien de telle heure a telle heure etc… que si c’est une mesure de température, on doit avoir une donnée toutes les 5 min, etc, etc … tout ca déconnectable pour les gens qui veulent le faire eux même mais au moins, a la première install, ca marche ou ca crie si pb

il est compliqué pour un type comme moi de deviner les problèmes qui peuvent survenir, je sais aussi qu’il est impossible d’être exhaustif mais vous (dev et autres spécialistes) en savez tout de même plus et ce savoir n’est pas forcément a notre disposition sauf a poser des question une fois que le problème est arrivé sans qu’on ne l’ai vu …

Jeedom est super mais super chronophage aussi, que ce soit en résolution de pb ou en création des scénarios plus ou moins alambiqué pour éviter le soucis qu’on a eu.

Là dedans, je ne parle nullement de software pur mais juste de friendly. Si je « branche » une sonde de température et qu’elle ne dit rien, il y a un soucis. Pour le moment, si je ne surveille pas, je ne le sais pas, c’est dommage de ne pas avoir d’alerte « intégrée ».

2 « J'aime »

Bonjour
Mais c’est déjà possible dans la configuration avancé de l’équipement tu peux mettre des alertes si l’équipement n’a pas communiqué depuis x minutes

1 « J'aime »

C’est typiquement Français ça… On râle pour quelque chose (si c’est justifié normal, pas de débat), mais si la correction nous embête ou nous donne du boulot on se plaint.

Certains d’entre vous soulèvent un cas où il y a des couacs. Ok. @Loic explique que cela n’aurait jamais dû être autoriser pour x raison.
Il est à mon sens tout à fait normal qu’il veuille y mettre un verrou.
Ce n’est pas parce que cela fonctionne dans 99% des cas qu’il faut le laisser ainsi.

Vu que certains aiment les analogies, ce n’est pas parce qu’une voiture fonctionne bien dans 99% qu’il ne faut pas corriger des bugs dans un programme qui pourrait être mortel juste parce que l’on ne veut pas perdre son temps à aller au garage.

Surtout qu’il y a d’autres moyen de faire ce qui n’est pas censé être fait dans un virtuel.

A noter également que je ne critique pas la critique. Je suis moi-même dans la critique de temps en temps et je suis également agacé de certains bugs car oui il en existe (j’ai toujours un post ouvert depuis un an où je présente même comment reproduire le bug qui n’est pas corrigé et qui a mené à des longs posts de discussions avec Loic… Après, ce n’est pas un bug vital non plus).

C’est bien de vouloir mettre un verrou sur quelque chose même si cela vient un peu tard.
Encore mieux si la correction est annoncée quelques temps à l’avance pour laisser tout le monde corriger le tir sur leur Jeedom.

Je pense que 95% de ce qui est demandé existe, juste que beaucoup ne savent pas, ne lisent pas les docs ou ne cherchent pas … pour un équipement qui ne répond plus, il y a une alerte pour ca :


et possibilité de recevoir des notifs :

Et tout est dispo dans la page analyse/equipement (batterie/non communication)
Pour un démon qui crash ou des pbs systeme, il y a la page santé.
Et puis, il y a toujours les logs qui sont souvent une mine d’information (associé à internet)

Et puis il y a la qualité de ce qu’on achète par rapport à la fiabilité souhaitée (on n’achete pas un jean sur Shein en souhaitant qu’il dure comme un levi’s !) et la complexité de ce qu’on souhaite faire par rapport à ces compétences, vouloir domotiser intégralement une maison sans un minimum de compétences en électricité ou en informatique me semble une utopie … il faut avoir la volonté d’apprendre, et beaucoup ne l’ont pas et s’attendent à trouver du click-n-play)

Norbert

2 « J'aime »