Aller au contenu
i-magin

Problèmes dans l'utilisation de Jeedom

Recommended Posts

Ce soir, j'ai voulu vérifier la "configuration avancée" d'une commande d'un équipement/module (c'est à cet endroit que l'on gère entre autre le paramètre "Gestion de la répétition des valeurs")

 

Et surprise, l’affichage était en vrac (avec Chrome) !

Après vérification avec Firefox : pas de souci

 

J'ai pu voir qu'un topic a été ouvert sur le forum Jeedom et que le problème est intervenu suite à la maj de Chrome en V55

Sur le GitHub on peut voir un "commit" intitulé "Bugfix for chrome 55"

Le problème est donc en cours de résolution

 

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

J'ai constaté un bug sur la remontée batterie de modules RFxcom

J'utilise des sondes de type "Oregon" pour la température et l'humidité

La remontée des infos sur la batterie de ce type de sonde étant aléatoire, j'avais coché le paramètre "ne pas vérifier la batterie"

J'obtiens tout de même un message Jeedom du type "Le module rfxcom a moins de 0% de batterie"

 

J'ai pu voir qu'un topic avait été ouvert sur le forum Jeedom

Au passage, je vous rapporte le commentaire "très sympa" de l'utilisateur

Citation

Ce n'est en rien bloquant mais c'est pénible d'avoir ce genre de notif pour rien

 

Il faut savoir que les messages d'erreurs ne sont affichés qu'une fois dans la liste prévue à cet effet

Par conséquent, si l'on a choisi de router le message par mail, on ne l'obtient qu'une fois

... sauf à supprimer le message et si le problème n'est pas réglé un nouveau message apparaîtra

Et bien je trouve que "c'est pénible d'avoir ce genre de commentaire d'utilisateur pour rien" :rolleyes:

De plus, il avoue :

Citation

Non j'ai hésité mais je n'ai pas ouvert de ticket officiel, si tu peux le faire ca serait cool

 

Bref, réponse a été donnée au ticket ouvert par un autre utilisateur de Jeedom : le problème a été identifié et il sera corrigé dans une prochaine version

 

A propos de prochaine version, celle du Core serait la 3.1

J'ai bien l'impression qu'il y aura encore des ajouts pour la gestion du design (la doc sortira à ce moment là)

Et il me semble bien qu'une timeline officielle va apparaître également

 

Modifié par i-magin

Partager ce message


Lien à poster
Partager sur d’autres sites

Exact mais, ce sera à configurer pour chaque commande (toujours dans la philosophie de Jeedom : souple, puissant mais super long à configurer aux petits oignons)

le Change Log : 

https://github.com/jeedom/core/blob/25a786c2e67f196ee6204f927a493515300384c2/doc/fr_FR/changelog.asciidoc

 Et la liste à l'instant :

Changelog

3.1

Correction de bugs

Optimisation globale de Jeedom (sur le chargement des classes de plugins, temps presque divisé par 3)

Support de Debian 9

Mode onepage (changement de page sans recharger toute la page, juste la partie qui change)

Ajout d’une option pour masquer les objets sur le dashboard mais qui permet de toujours les avoir dans la liste

Un double clic sur un noeud sur le graphique de lien (sauf pour les variables) amène sur sa page de configuration

Possibilitée de mettre le texte à gauche/droit/au centre sur les designs pour les élements de type texte/vue/design

Ajout des résumés d’objets sur la dashboard (liste des objets à gauche)

Ajout des interactions de type "previens moi si"

Revue de la page d’acceuil des scénarios

Ajout d’un historique de commandes pour les commandes SQL ou système dans l’interface de Jeedom

Possibilité d’avoir les graphiques d’historique des commandes en mobile (par appui long sur la commande)

Ajout de l’avancement de l’update de l’application mobile

Reprise en cas d’erreur de mise à jour de l’application mobile

Suppression des scénarios "simples" (redondant avec la configuration avancée des commandes)

Ajout de hachurage sur les graphs pour distinguer les jours

Refonte de la page des interactions

Refonte de la page profils

Refonte de la page d’administration

Compression des widgets (gain d’environ 18%)

Ajout d’une "santé" sur les objets

Correction de bug sur le niveau de batterie des équipements

Ajout de méthode dans le core pour la gestion des commandes mortes (doit être ensuite implementé dans le plugin)

Possibilité d’historiser des commandes de type texte

Sur la page historique vous pouvez maintenant faire un graphique d’un calcul

Ajout d’un gestion de formule de calcul pour les historique

Remise à jour de toute la documentation :

Toute les docs ont été revue

Suppression des images pour faciliter la mise à jour et le multilingue

Plus de choix possible sur le reglage des tailles de zone dans les vues

Possibilité de choisir la couleur du texte du résumé d’objet

Ajout d’une action remove_inat dans les scénarios permettant d’annuler toutes les programmations des bloc DANS/A

Possibilité dans les designs pour les widgets au survol de choisir la position du widget

Ajout d’un parametre reply_cmd sur les interactions pour spécifier l’id de la commande à utiliser pour répondre

Ajout d’une timeline sur la page historique (attention doit etre activé sur chaque commande et/ou scénario que vous voulez voir apparaitre)

Possibilité de vider les evenements de la timeline

Possibilité de vider les IPs bannies

Par contre pas de date de sortie annoncée, cela peut sortir à la rentrée comme l'année prochaine...

 

  • Upvote 1

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a une heure, Domomat a dit :

Support de Debian 9

 

J'aime bien le changelog.Bon c'est vrai que si ca pouvait etre supporté sans avoir à passer de lignes de commandes ce serait bien ;-).

 

@Domomat@i-magin,,

HS/ Pendant que je vous tiens, j'ai recu mon dash hier soir, et 'ai joue avec un virtuel qui allume une lampe incluse dans HC2.c'est OK pour le ON, pas pour le OFF.

 

Explicaion, je teste la valeur de l'etat avec le retour json qui est true ou false

j'ai fait

 -- si etat == "false" alors ALLUME (commande ON du virtuel) : OK

Si j'eteins, l'etat ne se met pas à jour, comment le forcer depuis le virtuel ?

 

Pardon

/FIn HS

Partager ce message


Lien à poster
Partager sur d’autres sites

Pour ce qui concerne le support de Debian 9 :

- c'est une bonne nouvelle que la team Jeedom veille à la compatibilité avec les nouvelles versions de Debian

- il n'y aura surtout pas urgence à passer en version 9

Je crains fort que certains vont se précipiter (et de plus sur des solutions DIY).... pour finir par pleurer sur les forums

 

Alors oui, pour toutes les installations hors box Jeedom, il faudra passer quelques lignes de commandes

Le plus propre étant de faire une fresh install ?

 

Et en espérant que personne n'oubliera les sauvegardes externes 

 

Depuis que j'utilise des boutons NIU j'ai laissé tomber les DASH

Je trouvais la latence trop importante

Et je ne les ai utilisé qu'avec des scénarios et non des virtuels

 

Sinon, regarde dans l'équipement Dash la commande Button 

Dans configuration commande, tout en bas au niveau de "autres" tu dois passer "Gestion de la répétition des valeurs" à "toujours répéter" 

 

Edit : si ton bouton fonctionne bien pour éteindre et allumer, tu as bien positionné le paramètre... mais c'est un peu compliqué vos solutions de bouton sous Jeedom qui actionnent des lampes sous Fibaro :2:

 

Modifié par i-magin

Partager ce message


Lien à poster
Partager sur d’autres sites

je regarderai ce soir ;-) cette commande.

C'est ok pour allumer ;-) en testant l'etat ;-)

 

pas le meme prix : 4.99 contre 29 ;-)

 

Pas tant que ca, juste que ca permet de garder HC2 en maitre et Jeedom esclave.

  • Upvote 1

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 24 minutes, i-magin a dit :

Je crains fort que certains vont se précipiter (et de plus sur des solutions DIY).... pour finir par pleurer sur les forums

 

ben quand tu le fais en DIY, c'est bien de mettre la 9 ;-)

Partager ce message


Lien à poster
Partager sur d’autres sites

L'OS n'est pas du ressort de Jeedom SAS en mode DIY. ils veillent juste à une compatibilité avec la dernière version de Debian mais il y a toujours une compatibilité avec au moins la version précédente.

Par contre il est toujours conseillé d'attendre le support de la version par Jeedom avant de changer si on ne sait pas le gérer soit même.

Certains utilisateurs avancés sont déjà en Debian 9 mais ils ont fait eux même les modifications nécessaires au bon fonctionnement de Jeedom ( passage à MariaDb par exemple) avec cette version.

 

@pepite pour ton virtuel, as-tu regardé du coté du Toggle (/plugins/virtual/doc/fr_FR/index.html#_interrupteur_de_type_toggle) ?

Modifié par Domomat

Partager ce message


Lien à poster
Partager sur d’autres sites

 Bonjour et bonne année,

J'ai une question concernant le plugin Mode, je ne me souviens plus (ou je ne retrouve pas) si on peut activer ou désactiver un agenda.

Il me semblait que je l'utilisais sur la Jeedom Smart en test mais les lignes d'action d'entrée ont été remplacées par un #xxx# depuis une mise à jour du plugin.

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour @Did

 

On peut toujours activer-désactiver un agenda

 

Un extrait de mon utilisation du plugin "mode" :

mode désactiver.PNG

 

Voici également un extrait de l'un de mes scénarios :

Désactivation agenda.PNG

 

Tu remarqueras que dans le 1er exemple (plugin "mode") j'utilise le terme "equipment" et dans le 2ème (scénario) "equipement"

Début 2018, suite à une modification il fallait utiliser "equipment" avec le plugin mode et je crois bien avec les scénarios

 

Je viens de tester mon plugin "mode" et mon scénario : mon agenda est bien désactivé

Je te laisse tester "equipment " et "equipement" (merci de nous faire un retour)... il se peut que les 2 solutions "equipment " et "equipement" aient été conservées pour les scénarios pour éviter la reprise de ceux-ci

 

J'ajoute un scénario qui permet de savoir si un agenda est actif et de renvoyer l'information dans un popup

Test agenda chauffage.PNG

 

... Et bonne année à tous !

Modifié par i-magin
  • Upvote 1

Partager ce message


Lien à poster
Partager sur d’autres sites

 C'est bon, merci @i-magin, ça re-fonctionne avec équipement (je n'ai que celui-là). :13:

Bonne année!

 

Partager ce message


Lien à poster
Partager sur d’autres sites

 Par contre, je patauge encore avec les conditions sur des scénarios:

Ouverture des volets en automne et hiver sauf les weekends et jours fériés

(#[Evènements][Infos du jour][Saison]# != "Spring" OU #[Evènements][Infos du jour][Saison]# != "Summer") ET #[Evènements][Infos du jour][Férié]# != 1 OU #[Evènements][Infos du jour][Weekend]# != 1 

et Ouverture des volets au printemps et en été sauf les weekends et jours fériés

(#[Evènements][Infos du jour][Saison]# != "Fall" OU #[Evènements][Infos du jour][Saison]# != "Winter") ET #[Evènements][Infos du jour][Férié]# != 1 OU #[Evènements][Infos du jour][Weekend]# != 1 

les deux me donnent "true" mais j'ai tellement permuté les "ET" et les "OU" que je suis paumé.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Mes connaissances en programmation sont bien trop anciennes pour réagir immédiatement à ta question, mais je pense que tu dois avoir un problème de parenthèses...

 

Cela dit, je ne sais pas comment tu obtiens les lignes de codes de ton scénario que tu as collées ci-dessus ?

Si tu ne peux pas effectuer des copies d'écran de ton scénario, tu peux utiliser la touche "exporter" pour avoir une représentation lisible de ton scénario

 

NB Je constate que tu préfères utiliser la condition "différent de" que "égal à"... çà n'a pas d'importance et chacun sa logique

Partager ce message


Lien à poster
Partager sur d’autres sites

Hello @Did

 

L’utilisation systématique de la négation est préférée par certains mais C piégeux. 

 

Tes tests sur les saisons ne peuvent que remonter true car [Saison] est forcément diffèrent de l'une des valeurs

 

Pour tester si automne ou hivers en passent par les égalités C plus ‘logique’

(#[Evènements][Infos du jour][Saison]# == "Fall" OU #[Evènements][Infos du jour][Saison]# == "Winter")

 

Et comme toutes tes conditions doivent se vérifier il faut laisser des ET de partout

 

Pour ton premier test essaye avec ça :

 

(#[Evènements][Infos du jour][Saison]# == "Fall" OU #[Evènements][Infos du jour][Saison]# == "Winter") ET #[Evènements][Infos du jour][Férié]# != 1 ET #[Evènements][Infos du jour][Weekend]# != 1

 

Partager ce message


Lien à poster
Partager sur d’autres sites

 Merci @chris6783, l'idéal serait comme la fonction DST de GEA pour différencier les deux périodes.

Voici des copies d'écran de ces deux scènes:

- Ouverture des volets en automne et hiver sauf les weekends et jours fériés:

Capture1.PNG.396cc3cfda691e2cf78bb83cd15424a0.PNG

 

Capture2.PNG.d3cb07acee59082d806c77c1833cd3cf.PNG

 

- Ouverture des volets au printemps et en été sauf les weekends et jours fériés

Capture3.PNG.9d29ecaa90d3a9282a6ff3e465efad04.PNG

Capture4.PNG.52b3c37d14a18dd6a80eec6a3f2e77e6.PNG

 

J'ai essayé aussi [Saison]# != "Spring" ou [Saison]# == "Spring" pour comparer et je n'ai pas vu de différences, peut-être des problèmes de parenthèses.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

attention tu declenches le scenario sur les changements de saison et ferie et WE. Tes volets vont monter au milieu de la nuit lorsque ces valeurs sont calculees et qu'on sort d'un WE ou d'un ferie.

il ne devrait y avoir qu'une programmation horaire, Pour la logique cf mon message du dessus, on a repondu en //

Partager ce message


Lien à poster
Partager sur d’autres sites

 Avec:

(#[Evènements][Infos du jour][Saison]# == "Spring" OU #[Evènements][Infos du jour][Saison]# == "Summer") ET #[Evènements][Infos du jour][Férié]# != 1 ET #[Evènements][Infos du jour][Weekend]# != 1

J'ai enfin un false.

Il ne faudrait donc pas mettre tous ces déclencheurs dans les modes du scénario?

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Cool pour le false.

Non tu n'as pas besoin de déclencher au changement de saison par exemple ou alors il faudra revérifier qu'il est bien 8h15 pour ne pas ouvrir les volets à 2h de mat lorsque la saison est recalculée. Les déclencheurs sont les éléments qui vont lancer le scenario au changement ou à l'heure dite. Pour toi saison et WE et férie sont juste des conditions à vérifier et pas des  déclencheurs.

Avant je déclenchais comme toi a une heure dite et ensuite j’ai ajouté toujours plus de conditions avec des mode réception de la maison qui bloquent la fermeture, le lever du soleil...

Les blocs de condition devenaient complexes et surtout répétés une peu partout dans tous les scenarios.

Maintenant je n’ai plus qu’un scenario qui vérifie les conditions et qui programme les ouvertures/fermeture de façon quotidienne en planifiant les scenarios d’ouverture et fermeture avec des lancements des autres scenarios via une action À ‘une certaine heure’ -> lance scenario ferme les volets

Comme ça en regardant un seul scenario je retrouve toute la logique de gestion des ouvertures/fermeture. Les scenarios ouverture/fermeture qui enchainent les commandes monter/baisser n’ont plus aucun déclencheur mais obéissent à une programmation centralisée

Partager ce message


Lien à poster
Partager sur d’autres sites

 Mais bon, le "true" ne marche pas quand même. Je tente de m'y prendre autrement:

Un scénario pour chaque horaire, activés ou pas par un mode saison (été et hiver) et déclenché lui, par un agenda avec en évènement, deux dates aux changements d'heure.

Mais je découvre un nouveau soucis: J'ai aussi un mode ouverture auto des volets qui, si je bascule sur non, désactive les scènes concernant l'ouverture des volets, et enfin le problème quand je repasse sur oui ne vas pas pouvoir activer la seule scène de 8h15 en hiver ou 7h en été.

Je patauge donc de nouveau, une variable peut-être?

 

Partager ce message


Lien à poster
Partager sur d’autres sites

je  vois pas trop le probleme de true, tu peux donner plus de details ?

 

Pour la variable C pas forcement utile tu as deja la saison en variable. tu peux peut-etre faire un scenario central qui programme ton scenario d'ouverture avec une action "A" dont l'heure change en fonction de la saison.

Si tu as des modes qui doivent bloquer les ouvertures tu peux laisser ces controles dans les scenarios d'ouverture.  Comme ca si le central programme une ouverture mais qu'elle doit etre interdite pour x raison ce controle sera fait juste au moment d'ouvrir

 

pour les scenarios quotidiens j'evite de jouer avec activer/desactiver car je trouve que ca genere trop de cas particuliers et devient difficile a garder sous controle

Partager ce message


Lien à poster
Partager sur d’autres sites

 J'ai refait comme ceci, ça fonctionne:

Le 06/01/2019 à 21:00, Did a dit :

Un scénario pour chaque horaire, activés ou pas par un mode saison (été et hiver) et déclenché lui, par un agenda avec en évènement, deux dates aux changements d'heure.

Mais comme j'ai aussi un mode ouverture auto des volets qui, si je bascule sur non, désactive les scènes concernant l'ouverture des volets, et quand je repasse sur oui ne vas pas pouvoir activer la seule scène de 8h15 en hiver ou 7h en été, il me ré-activera les deux, peut-être qu'avec une condition du mode saison?

Partager ce message


Lien à poster
Partager sur d’autres sites

 Bon je patauge avec la réactivation de scénario dans un mode (ouverture volet auto) selon l'état d'un autre mode (saison).

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant

×