i-magin Posté(e) le 4 décembre 2016 Signaler Posté(e) le 4 décembre 2016 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
i-magin Posté(e) le 18 août 2017 Auteur Signaler Posté(e) le 18 août 2017 (modifié) 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" 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é le 18 août 2017 par i-magin
Domomat Posté(e) le 18 août 2017 Signaler Posté(e) le 18 août 2017 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... 1
pepite Posté(e) le 18 août 2017 Signaler Posté(e) le 18 août 2017 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
i-magin Posté(e) le 18 août 2017 Auteur Signaler Posté(e) le 18 août 2017 (modifié) 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 Modifié le 18 août 2017 par i-magin
pepite Posté(e) le 18 août 2017 Signaler Posté(e) le 18 août 2017 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. 1
pepite Posté(e) le 18 août 2017 Signaler Posté(e) le 18 août 2017 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 ;-)
Domomat Posté(e) le 18 août 2017 Signaler Posté(e) le 18 août 2017 (modifié) 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é le 18 août 2017 par Domomat
Did Posté(e) le 2 janvier 2019 Signaler Posté(e) le 2 janvier 2019 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.
i-magin Posté(e) le 3 janvier 2019 Auteur Signaler Posté(e) le 3 janvier 2019 (modifié) Bonjour @Did On peut toujours activer-désactiver un agenda Un extrait de mon utilisation du plugin "mode" : Voici également un extrait de l'un de mes scénarios : 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 ... Et bonne année à tous ! Modifié le 3 janvier 2019 par i-magin 1
Did Posté(e) le 3 janvier 2019 Signaler Posté(e) le 3 janvier 2019 C'est bon, merci @i-magin, ça re-fonctionne avec équipement (je n'ai que celui-là). Bonne année!
Did Posté(e) le 3 janvier 2019 Signaler Posté(e) le 3 janvier 2019 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é.
i-magin Posté(e) le 3 janvier 2019 Auteur Signaler Posté(e) le 3 janvier 2019 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
Invité chris6783 Posté(e) le 3 janvier 2019 Signaler Posté(e) le 3 janvier 2019 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
Did Posté(e) le 3 janvier 2019 Signaler Posté(e) le 3 janvier 2019 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: - Ouverture des volets au printemps et en été sauf les weekends et jours fériés 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.
Invité chris6783 Posté(e) le 3 janvier 2019 Signaler Posté(e) le 3 janvier 2019 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 //
Did Posté(e) le 3 janvier 2019 Signaler Posté(e) le 3 janvier 2019 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?
Invité chris6783 Posté(e) le 3 janvier 2019 Signaler Posté(e) le 3 janvier 2019 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
Did Posté(e) le 6 janvier 2019 Signaler Posté(e) le 6 janvier 2019 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?
Invité chris6783 Posté(e) le 8 janvier 2019 Signaler Posté(e) le 8 janvier 2019 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
Did Posté(e) le 8 janvier 2019 Signaler Posté(e) le 8 janvier 2019 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?
Did Posté(e) le 14 janvier 2019 Signaler Posté(e) le 14 janvier 2019 Bon je patauge avec la réactivation de scénario dans un mode (ouverture volet auto) selon l'état d'un autre mode (saison).
Messages recommandés