Non moi aussi j’ai des nombres flottant et ça fonctionne bien. Là c’est comme si HA voyait pas la bonne valeur et donc Appdaemon le voit pas non plus. Donc CoverManager ne peut pas lancer l’action car pour lui ça correspond pas.
C’est normal. HA stocke tout en UTC et adapte ensuite l’affichage dépendant de la Timezone que tu as configuré
Je suis allé voir les Callback dans AppDaemon et j’ai bien quelque chose lié à sensor.outdoor_illuminance. Par contre, j’ai 0 dans les colonnes Fired et executed depuis le redémarrage d’AppDaemon hier après la MAJ de la config.
Le Kwargs dit ça :
{
"new": "<function CoversManager.initialize.<locals>.<lambda> at 0x7fd075c80b80>",
"old": "<function CoversManager.initialize.<locals>.<lambda> at 0x7fd075c80c20>",
"config": "dryrun=False common=CommonConfig(position=PositionConfig(opened=100, closed=0, min_ratio_change=5, min_time_change=10), opening=OpeningConfig(type='lux', time=None, locker=None), closing=ClosingConfig(type='lux', time=None, secure_dusk=False, locker=None), adaptive=AdaptiveConfig(enable=True, locker=None), manual=ManualConfig(allow=True, timer=datetime.timedelta(seconds=5400)), temperature=TemperatureConfig(indoor=TemperatureIndoorConfig(sensor='sensor.bsb_lan_temperature_thermostat_salon', setpoint=23, seasons=SeasonsConfig(spring=SeasonConfig(setpoint=None), summer=SeasonConfig(setpoint=None), autumn=SeasonConfig(setpoint=None), winter=SeasonConfig(setpoint=None))), outdoor=TemperatureOutdoorConfig(sensor='sensor.gw1100_temp', low_temperature=24, high_temperature=27)), lux=LuxConfig(sensor='sensor.outdoor_illuminance', open_lux=23, close_lux=10), locker='binary_sensor.alarm_status', seasons=None) covers=CoversName(root={'cover.volet_bureau': CoversConfig(window_heigh=210, window_azimuth=75, positional=PositionalConfig(action=True, status=True), fov=FovConfig(left=20, right=90)), 'cover.volet_cuisine': CoversConfig(window_heigh=210, window_azimuth=255, positional=PositionalConfig(action=True, status=True), fov=FovConfig(left=90, right=90)), 'cover.volet_salon': CoversConfig(window_heigh=210, window_azimuth=165, positional=PositionalConfig(action=True, status=True), fov=FovConfig(left=90, right=90))})",
"action": "open"
}
Pour revenir sur la valeur du capteur de luminance, je suis allé voir l’historique et la valeur est correcte : 304,08 lx à 17h27:45, valeur rafraîchie toutes les 2min, ce qui correspond au réglage de la station météo. Mais pourquoi le log dit que la valeur date d’1h avant ?
Oui moi aussi ca fait la même chose. Je pense donc que c’est normal
Tu as bien une autre ligne avec un "action": "close" dans le kwargs ?
Ca indique la bonne heure mais en UTC donc il faut ajouter 1h par rapport au graph.
Ce que je ne comprend pas c’est pourquoi on a pas reçu l’update.
On aurait dû avoir un log du type `… Callback triggered by state change of…``
Tu peux essayer de simuler en changeant le nombre de lux à 8 par exemple à partir des outils de développement.
Si tu as besoin de déclencher plusieurs fois, il faut d’abord repasser au dessus de 10lux et ensuite passer en dessus de 10lux car il compare la valeur précédente et actuelle.
j’ai effectivement un autre kwargs qui gère l’action close :
{
"new": "<function CoversManager.initialize.<locals>.<lambda> at 0x7fd075c81300>",
"old": "<function CoversManager.initialize.<locals>.<lambda> at 0x7fd075c813a0>",
"config": "dryrun=False common=CommonConfig(position=PositionConfig(opened=100, closed=0, min_ratio_change=5, min_time_change=10), opening=OpeningConfig(type='lux', time=None, locker=None), closing=ClosingConfig(type='lux', time=None, secure_dusk=False, locker=None), adaptive=AdaptiveConfig(enable=True, locker=None), manual=ManualConfig(allow=True, timer=datetime.timedelta(seconds=5400)), temperature=TemperatureConfig(indoor=TemperatureIndoorConfig(sensor='sensor.bsb_lan_temperature_thermostat_salon', setpoint=23, seasons=SeasonsConfig(spring=SeasonConfig(setpoint=None), summer=SeasonConfig(setpoint=None), autumn=SeasonConfig(setpoint=None), winter=SeasonConfig(setpoint=None))), outdoor=TemperatureOutdoorConfig(sensor='sensor.gw1100_temp', low_temperature=24, high_temperature=27)), lux=LuxConfig(sensor='sensor.outdoor_illuminance', open_lux=23, close_lux=10), locker='binary_sensor.alarm_status', seasons=None) covers=CoversName(root={'cover.volet_bureau': CoversConfig(window_heigh=210, window_azimuth=75, positional=PositionalConfig(action=True, status=True), fov=FovConfig(left=20, right=90)), 'cover.volet_cuisine': CoversConfig(window_heigh=210, window_azimuth=255, positional=PositionalConfig(action=True, status=True), fov=FovConfig(left=90, right=90)), 'cover.volet_salon': CoversConfig(window_heigh=210, window_azimuth=165, positional=PositionalConfig(action=True, status=True), fov=FovConfig(left=90, right=90))})",
"action": "close"
}
Je vais tester demain la manipulation de la valeur de luminosité. Est-ce qu’il est possible aussi de simplifier le fichier de configuration en laissant tomber la gestion en fonction du soleil et se focaliser sur le pilotage par luminosité ? ça fera un fichier log plus facile à analyser (pour moi en tout cas).
Tu peux en désactivant le mode adaptive.
Regarde aussi si dans appdaemon.log et error.log si tu n’as pas des erreurs liées à CoversManager
J’ai testé en forçant le capteur de luminosité à zero et ça ne déclenche aucune action sur les volets.
Le log correspondant est ici. Je n’ai pas d’erreur dans appdaemon.log et error.log.
Problème résolu avec la Beta 3. Merci à Marc pour tout le temps passé à chercher le bug !
J’ai besoin d’une confirmation vis à vis de l’aide dans le github sur un point : si je veux créer des scénario différents pour certains volets, est-ce je dois ajouter une nouvelle configuration à la suite de la première comme ci-dessous ?
CoversManager:
module: covers_manager
class: CoversManager
use_dictionary_unpacking: true
log: CoversManager
config:
[scénario 1 pour 1er groupe de volets]
CoversManager:
module: covers_manager
class: CoversManager
use_dictionary_unpacking: true
log: CoversManager
config:
[scénario 2 pour 2eme groupe de volets]
Bonjour,
Exactement.
Mais tu dois mettre un nom différent au choix compréhensible par toi
CoversManager:
module: covers_manager
class: CoversManager
use_dictionary_unpacking: true
log: CoversManager
config:
[scénario 1 pour 1er groupe de volets]
CoversManager2:
module: covers_manager
class: CoversManager
use_dictionary_unpacking: true
log: CoversManager
config:
[scénario 2 pour 2eme groupe de volets]
Hello,
Bravo beau boulot, par contre dommage qu’il soit nécéssaire de passer par AppDaemon
Pourquoi ne pas etre parti sur une intégration direct dans HA ?
Car pour le coup tout ceux qui n’ont pas d’addons sur leur HA sont grillé… (ce
qui est mon cas)
Autre point en faveur de l’intégration : c’est de supprimer toute la config YAML qui peux etre compliqué pour un non averti.
Bonjour,
Merci.
Les intégrations ont pour rôle de restituer des données prenant d’une API locale ou remote mais pas vraiment de traiter les données pour déclencher des actions. Ça s’est le rôle des automatisations HA.
J’aurais pu faire un blueprint énorme pour tout gérer mais j’ai pris le parti de coder cela avec AppDaemon me laissant plus de flexibilité.
Quand à l’installation de AppDaemon, c’est un addon aussi simple à installer qu’une intégration donc ce n’est pas vraiement un problème.
L’application CoversManager et elle aussi simple à installer dans AppDaemon puisqu’elle est disponible dans HACS où vous avez sûrement déjà installé des custom intégration.
L’installation n’est donc pas à mon sens un problème et l’utilisation de AppDaemon plutôt qu’une intégration non plus.
Celui qui n’a pas déjà AppDaemon, si il veut CoversManager, l’installera au même titre qu’il aurait installé une intégration si cela en avait était une.
Reste le sujet de la configuration, qui est en effet en YAML là où une intégration propose une configuration visuelle. Mais comme expliqué précédemment une intégration n’a pas vraiment le même rôle que celui d’une app AppDaemon (sinon AppDaemon n’aurait jamais existé). C’est plutôt comme les gens qui préfère utiliser Node-red que les automations HA.
Maintenant, il faut aussi garder à l’esprit que le YAML est une des fondations de HA, souvent utile à connaître pour pousser HA un peu plus loin, et finalement aussi simple que n’importe quoi d’autre.
Mais j’ai quand même voulu faire une documentation suffisamment complète pour faciliter cela.
L’utilisation de CoversManager n’a rien d’inaccessible bien au contraire et une fois mis en place, tu le laisseras bosser dans son coin pendant des mois sans y toucher.
Hello !
Moi j’aime bien AppDaemon !
On avait travaillé su des BP il y a plus de deux ans, une belle usine, bref ça tourne toujours. Mais cette nouvelle option me plait bien.
Par contre je ne vois nulle part la notion de position, par exemple je veux que qu’à 10:00 mon VR s’ouvre mais à la position 40 (ou %). Pareil, si ensoleillement excessif, je ne veux pas totalement fermer, et le soir en été je veux laisser entrouvert.
On peu gérer ça via une automation, mais l’intérêt serait peut être d’intégrer cette notion ? voire des custom position qui dépendraient d’un input_boolean ?
Bref, j’essaie de voir si je peux reproduire mon fonctionnement actuel et voir si c’est adaptable.
En tous ca bravo pour le taff !
Je comprends et respecte ton choix d’utiliser AppDaemon. Cependant, je suis désolé, mais ton argumentaire n’est pas bon :
C’est totalement faux.
Home Assistant prévoit explicitement que les intégrations puissent automatiser des actions, et c’est clairement mentionné et expliqué dans la documentation développeur officielle.
Tu dois connaitre AdaptiveCover ? Les intégrations thermostats ? Les intégrations « hardware » ?, etc…
Regarde sur https://www.home-assistant.io/integrations/ et sur le store HACS tu verras il y a des centaines d’intégrations qui ne fetch absolument aucune API.
Concernant le YAML, c’est vrai qu’il fait partie des fondations de HA, mais si tu suis la roadmap actuelle, tu verras que la volonté de Home Assistant est justement de réduire au maximum son utilisation. Chaque mise à jour ramène de plus en plus de configurables YAML à une interface visuelle, ce qui montre bien la direction que prend HA : simplifier l’expérience utilisateur.
Et c’est la je crois notre point de divergence, c’est que toi tu as un pensée ingénieur dev (bidouiller et le YAML c’est cool) moi j’ai plus une pensée utilisateur (le moins de configuration, le plus simple, le plus accessible à tous)
Oui j’ai fais un raccourci en parlant d’API mais je n’ai jamais vu HA valider une integration officiellement qui fait plus que de la collecte de données et l’intégrer dans des commandes. Bon après j’ai pas vu non plus toutes les integrations.
Le limiter oui mais jamais le supprimer car il permettra toujours de faire les actions avancées.
C’est un développement interne fait pour mon usage personnel. Maintenant je le met à disposition de la communauté si ca peut servir, alors oui je l’ai aussi développé avec AppDaemon qui me semblait plus simple.
Tu parles de AdaptiveCover, je l’avais testé et ne répondait pas à mes besoins c’est pour cela que j’ai fais CoversManager. Si j’avais pu m’économiser du temps de développement je l’aurais fait.
Il existe tellement d’équivalent ou même de solution qui surpasse surement mon code (mais ne répondait pas à mes besoins) que réfléchir à passer 2 à 3 fois plus de temps à faire une integration HACS pour potentiellement 0 utilisateurs qui l’utiliserait n’a en effet pas était ma préoccupation.
Maintenant si mon code peut servir à d’autres et que des bonnes idées d’amélioration peuvent m’être partagée, je le ferais avec plaisir…mais il faudra aussi à l’utilisateur prendre quelques minutes pour installer CoversManager.
Je suis actuellement en train de developper une intégration pour Diagral, là je sais que du monde est intéressé donc je le code pas que pour moi et prend en compte dans le développement initial, le moyen de rendre cela le plus accessible.
Donc ca dépend des contextes. J’ai une autre app AppDaemon pour gérer la piscine, là potentiellement je me poserais la question de la transformer en intégration vu que cela concerne plus d’utilisateurs. Je ne l’ai pas fait à l’origine car j’en avais besoin rapidement, et j’avais pas encore pris le temps de regarder le code des intégrations.
Hello,
Oui quand j’ai commencé HA je me suis beaucoup appuyé sur ton blog. Merci pour ça d’ailleurs. Et notamment cet article.
Après je l’avais trouvé très et trop complet pour mon usage. Je l’avais donc laissé un peu de coté. Maintenant en regardant un peu dans le rétro, ma roadmap pour CoversManager était bien plus petite que ce que j’en ai fait, car au fur et à mesure de l’écriture du code, je me disait que telle ou telle feature serait bien à ajouter.
Au final j’aurais peut être dû utiliser ce que tu proposais 
En effet ca n’existe pas. On ne peut pas définir une position d’ouverture (c’est 100% par défaut).
Pour l’ensoleillement excessif, le volet se ferme pas à 100% mais à la position qui permet au soleil de ne plus rentrer dans la fenêtre. Par contre il ferme à 100% si les conditions de temperatures extérieure sont remplies afin d’éviter de chauffer trop la pièce.
Et le soir en effet la fermeture est à 100%
C’est en effet une bonne idée de pouvoir définir le % à l’ouverture et à la fermeture, eventuellement par saison.
J’ajoute ça en roadmap 
: Allow to define a position for opening (morning) and closing (evening) by seasons · Issue #55 · mguyard/appdaemon-coversmanager · GitHub
Merci
Attention, si je trouve le temps d’installer CoversManager je risque de te soumettre d’autres idées…
J’ai regardé les autres possibilités (le gros BP et AdaptiveCover), alors oui l’approche peut paraitre plus simple que le Yaml, mais AppDaemon « me » parait plus simple. Je gère déjà pas mal de choses avec (ControlerX, Automoli, etc…). La prise en compte immédiate des modifications de code est un vrai bonheur. Après je comprends que ça puisse faire peur 
Salut à Tous
@Jezza j’ai eu la même interrogation que toi et évoqué avec @mguyard la complexité de sa solution dans ce post
Au final après beaucoup d’essai avec des BP, je suis tombé sur une intégration qui permet de faire ce que je souhaitais que je cite dans les dernières réponse du post en lien
Hello @Yoyouri
Effectivement, l’automatisation des volets est un sujet complexe.
Un grand merci à tous ceux qui ont développé des outils et les partage.
Cependant, à mon sens, ces outils souffrent aujourd’hui de deux défauts majeurs : la configuration et le débogage. Ces limites freinent leur adoption et restreignent leur utilisation à un public averti.
J’ai quelques idées pour repartir sur la base d’AdaptiveCover, mais je suis déjà bien occupé par le développement de deux intégrations qui me prennent beaucoup de temps.
L’idée serait de créer une nouvelle intégration avec un config flow ultra-simple, basé sur des questions que même un enfant de 10 ans pourrait comprendre :
Côté débogage, l’intégration pourrait inclure des capteurs « virtuels » qui indiquent clairement si les conditions sont remplies ou non.
Et basta ca tourne…
Après, comme toujours, tout est possible en développement… il faut juste le temps pour le faire ! 
Bonjour,
Tu dis que les configurations sont complexes, touffu et c’est vrai.
Tu souhaites faire une intégration qui change cela, parfait mais réfléchi bien avant et tu risques d’arriver comme nous.
Pour une solution complète, utilisable par le plus grand nombre, et correspondant à leur attentes, tu devras systématiquement avoir un grand nombre d’options et donc un grand nombre de paramètres.
Dans les questions d’exemple que tu listais, il te manque l’heure à laquelle la personne veut l’ouverture ? et si c’est pas l’heure mais la luminausité, à quel lux ? Même chose pour la fermeture ? Certain te dirons qu’ils veulent une option pour un décalage de quelques minutes avant ou après ce qui est configuré, d’autres te dirons que ça change selon les saisons, etc…
Nous avons tous une façon différente de vouloir gérer nos ouvrants. Et c’est ça qui rend la chose compliqué.
Si tu fais simple on te dira qu’il manque trop d’options. Si tu as ces options, d’autres te diront que c’est trop compliqué, et encore d’autres qu’ils veulent encore plus d’options.
Mais je te souhaite de réussir à faire ce que tu veux.
Bref, on commence à dévier un peu trop du sujet principal de ce thread…
Bonjour,
C’est dispo dans la v2.1.0-beta.1
CoversManager:
[...]
config:
common:
[...]
seasons: "sensor.season" <------- Requis pour gérer les saison. Permet de connaitre la saison actuelle par l'integration [Saison](https://www.home-assistant.io/integrations/season)
position:
opened: 100 <--------------- Existait déjà. C'est la position max d'ouverture qu'accepte le volet pour tout les mouvement d'ouverture
closed: 0 <--------------- Existait déjà. C'est la position max d'ouverture qu'accepte le volet pour tout les mouvement d'ouverture
opening:
type: "time"
time: "10:00:00"
position:
default: 50 <--------------- La position d'ouverture par default
seasons:
winter: 20 <--------------- La position d'ouverture en hiver qui écrase la position d'ouverture par default. On peut paramétrer toutes les saisons
closing:
type: "prefer-lux"
secure_dusk: True
position:
default: 10 <--------------- La position de fermeture par default
seasons:
summer: 50 <--------------- La position de fermeture en été qui écrase la position d'ouverture par default. On peut paramétrer toutes les saisons
[...]
A l’époque ou j’utilisait Schedy j’avais pas mal customisé pour lui faire un semblant de GUI pour les autres, donc question, peut t’on remplacer la valeur de time: 10:00:00 par un time: input_datetime: que quelqu’un d’autre pourra régler à ma place sans entrer dans le code ?
Il me semble avoir lui que tu avais qq part un binary pour interagir avec une alarme (qui pourrait être un boolean ou l’état de de alarm_control_panel). Mais j’ai un autre cas d’usage, mes enfants ne vivent pas dans la région, mais s’ils sont géolocalisés dans les 50 km je considère qu’ils sont en vacances ici, ou si un ami occupe leur chambre. Je bascule donc un boolean et le volet de leur chambre passe en gestion manuelle et ils ne se feront pas réveiller par un automatisme.
Un autre cas d’usage, dans le séjour, si je lance un film en journée ça ferme les volets de la pièce (sur la valeur d’un binary, qui pourrait donc être un template (dans mon cas je ne ferme que si c’est un film, pas si je regarde juste 10 mn les infos…) (je me sert de l’état du sub…).
Bref, tout ça pour dire que si tu veux gérer des options en fonction d’évènements out de statuts il faut que ça soit générique et multipliable, donc peut être gérer les fonctions de base sur ce principe…
Voilà, juste quelques idées…