Bonjour,
C’est nickel, j’ai pigé les condition s que je peux faire pour les vacances.
Est-ce qu’il y a un moyen de personnaliser les couleurs des différents états . Que l’on peut choisir soit même les couleurs ?
Merci
Non c’est pas dans les choses prévues : la couleur se base sur la valeur/unité (un vrai savant calcul) pour avoir la même chose entre les cartes par ex : toutes affichent confort en vert par exemple, et 17°C en jaune. Et il n’y a jamais autre chose en vert ou jaune
Donc ça m’ennuie de faire autre chose
Merci pour ta réponse je comprend. J’aime beaucoup l’affichage de cette carte qui est parlant pour un planning j’ai pu rajouter un petit switch sur la carte pour passer au mode vacances, nickel
Disons que j’ai eco en vert fluo et confort en vert un peu plus foncé.
Du coup est-ce que je peux afficher sur le planning par exemple à la place de Eco 16° C mais que la valeur que je veux faire passer a vtherm soit eco (pour le preset). et si cela marche est-ce j’aurais une différence de couleur entre eco qui est à 16 et confort qui est a 17 pour ce radiateur ? et les autres radiateur la différence sera eco 17 et confort 20°. En fait je mettais trompé dans l’orthographe pour vtherm j’avais mis des majuscule et là les couleur sont complétement différente. violet bleu et turquoise. C’est deja un peu plus contrasté.
Afficher une chose et en envoyer une autre c’est fonctionnellement impossible dans la carte. La carte affiche la valeur de l’entité shedule_state et c’est shedule_state qui est utilisé pour piloter ton vtherm.
Après si tu passes par une automatisation, tu peux triturer schedule_state s’il est utilisé comme trigger et envoyé tout ou une partie de sa valeur, mais c’est pas simple.
En relisant, tes remarques, est-ce plus un souci de contraste, que de choix de la couleur ? Tu peux partager ce que ça donne, histoire de me rendre compte ?
J’ai peut-être une ou deux idées en stock mais pour l’instant c’est plutôt la capacité à modifier la carte dans l’immédiat qui pose un souci.
Juste c’est pas des reproches car c’est top comme intégration et le boulot en terme de developpement est enorme Comme je suis pas assez calé pour développé ça je pose des questions. tu as fais le choix d’un calcul pour les couleur et est-ce plus diffcile de laisser le choix au gens de choisir leur couleur. Mais en l’état c’est tout a fait lisible.
Merci. Effectivement ça demande un peu de temps de dev
Surtout qu’il a fallut commencer par coder ce que fait maintenant schedule_state en natif : générer des plannings exploitables.
Le choix du calcul de la couleur automatique était important pour moi, je suis le 1er demandeur de cette carte. Je n’avais absolument aucune envie définir à la main, une liste de couleurs pour tous les états de mes cartes, sans doublons, sans mettre un gros vert et un gros rose etc.
J’avais fait le recensement, j’en avais plus de 30 du coup, j’ai passé du temps sur le code…
Par contre, j’ai depuis refait 2 ou 3 autres trucs sur la carte météo, et je pense que je peux récupérer une partie de ce que j’ai dev : une mécanisme de surcharge d’une valeur/unité et un système partagé entre toutes les cartes. Du coup, les bénéfices seraient doubles : on pourrait imaginer forcer « 17°C » avec sa valeur de couleur perso. Et laisser la carte générer les autres… Evidement, on pourrait définir plusieurs valeurs forcées.
Là je pourrais pas t’aider sur le code, j’ai de trop vieilles notions de codages qui ne sont plus d’actualité. Faudrait que je me remette un peu dedans pour HA mais pas à ce niveau là.
Petite question, sur l’affichage de la carte, la positon des plages est un calcul entre le temps et une échelle. Cette question car j’ai constaté un décalage dans mes plages en affichages. Exemple, le soir à 22h je change de preset et le dessin de la plage commence entre 2 traits. Je pense que c’est une décalage se créé sur la fin de journée, au début pas de soucis; Je te met une image en dessous, mais effectivement j’ai conscience de chipoter, mais ce n’est pas une critique negative.Et merci de ton écoute.
Merci pour ce retour. Oui j’ai vu aussi ce genre de défauts aussi. De ce que j’ai compris, c’est surtout du à une erreur de calcul sur le texte à tronquer : fro... versus fr.. en fonction de la taille de la police etc, c’est pas toujours pareil. Et le créneau (le bloc de couleur) s’adapte ensuite au plus strict. Quand il y a de la place, en principe pas d’ano. Et ça décale d’autant le eco au dessus/comfort en bas.
Je me note de vérifier si je peux faire un peu mieux et de regarder s’il n’y a pas en plus lien avec le début/fin de journée
Et est-ce que cela a une incidence du fait que ma plage eco ou confort finisse a 22:00 et frost commence à 22:00 ou faut-il finir eco et confort à 21:59 et frost à 22:00 ?
Non, c’est juste un défaut visuel => représentation de la réalité un peu faussée.
ça n’a absolument aucun impact sur le fonctionnent de l’entité.
Concernant la config, les bornes fonctionnent ainsi : début inclu, fin exclue. En notation mathématique : [D,F[. Du coup, si tu mets 21:59 sur la fin de eco et 22:00 sur le début de frost, tu vas avoir 1 minute avec la valeur par défaut, car cet intervalle n’est pas considéré comme surchargé.
Et en plus (j’ai pas fait l’essai) je pense que ça ne changera pas le défaut d’affichage.
Bonjour @Pulpy-Luke j’ai toujours un radiateur qui fonctionne via ta carte schedule-state et je n’ai pas fait évoluer les autres.
Là je crois avoir une bonne raison de faire évoluer maintenant car je voudrais créer 2 plannings différents pour certaines pièces selon que j’ai du monde ou pas.
Mais, rappelle moi, les plannings je les définit ou, dans le code yaml de la carte ? ou via des scheduler classique comme je fais maintenant ?
En plus la carte scheduler cklassique semble avoir un pb car quen je veux entre un planning avec action « définir le réglage tepérature » la fenetre de sélections de l’entité se cache et il est impossible de faire le choix, ça ressemble à un bug…
Donc ça semble être le bon moment de tout mettre sur scheduler_state…
Okkk, oui, entre temps j’ai revisité ma config et je commençais à retrouver ça… en plus j’avais toujours le scheduler sur cette vanne qui était resté actif en parallèle du planning yaml du schedule_state, comment ça réagis dans ce cas ? les deux agissent ?
Et j’ai déjà du demander, mais n’est il pas possible de récupérer le planning venant de la carte scheduler ? histoire de garder l’interface visuelle pour créer ces plannings ? ou trop compliqué ?
Les 2 agissent, s’il font la même choses pas trop graves, mais dans le cas contraire, c’est le dernier à faire modif qui gagne, donc à éviter.
Même si le nom ressemble, l’organisation et l’objectif des 2 sont très différents :
Schedule_state gère un état d’une entité, en yaml seulement. Il se suffit à lui-même et ma carte ne fait que visualiser le planning. L’entité sert à HA globalement, et est donc exploitée par exemple dans une automatisation de ton choix pour piloter ton radiateur.
Scheduler ne fait rien tout seul, il lui faut la carte associée pour faire la config. Il agit directement sur les entités (action type switch.xxx etc) car il dipose d’un mini moteur d’automatisation. Le stockage de la config est quelque part dans HA (et pas en yaml)
Du coup même avec beaucoup de temps et de volonté, c’est pas jouable de récupérer une config
Ok vu, et scheduler désactivé sur cette vanne. j’avais dû le réactiver en ne pensant plus à schedule_state… j’espère que je vais y arriver à combiner tout ça, le mieux c’est que je bascule tout vers schedule_state pour ne plus risquer de m’embrouiller…
Et j’ai le code suivant pour la vanne sous schedule_state avec 2 conditions simples, tout ou rien en gros, mais là je voudrais créer un 2ème planning complet avec plages horaires si une boolean est activée, en gros maison partiellement occupée = 1 série de plages avec leurs temp cible, maison entièrement occupée = 1 autre série de plages avec leur cible, et toujours dans tous les cas les conditions absent = frost et fenetre ouverte dans cette pièce = frost.
J’ai deux boolean, un pour absent global, un pour maison partiellement occupée ou totalement occupée.
Si tu veux bien m’indiquer le principe yaml pour ça, après je repasserai toutes mes vanne selon ce principe.
Question : comment gérer un boost temporaire sur une vanne ?
Et comment travailler non pas sur le preset du Vtherm mais le le degré d’ouvertuire de la vanne ? par exemple forcer 100% sur une ou plusieurs vannes ?
Pour le boost je dirais de faire un truc valable avec un unique critère une condition. La condition c’est un timer de xx min qui doit être à l’état running (de mémoire). Tu place ça plutôt dans le bas de la liste pour que ça surcharge le planning normal. Du coup, tu peux déclencher ça n’importe quand, et pas plus long que la valeur du timer.
Quant au pilotage en % attention c’est pas de la régulation…mais si avoir une valeur numérique suffit, adapte ton state avec une valeur de 0 à 100
