Salut,
Je n’utilise pas ton apps et je n’ai surement pas tout compris mais j’ai quand même l’impression que ça (re)fait beaucoup de choses déjà plus ou moins existantes avec automatisations natives et/ou les blueprints d’automatisations. Voire des choses issues du lab HA.
- la notion de salle existe déjà nativement
- la recherche par ID/zone/type
- les nouveaux déclencheurs
- des outils de détections d’incohérence
La notion d’abstraction est intéressante, mais à titre personnel en changeant de matériel, simplement en renommant l’entité, je conserver les automatisations à jour et fonctionnelles.
Ce genre de dev « souffre » de biais:
- un besoin ultra-spécifique qui est difficile à généraliser
- une n-ième façon de traiter un besoin (en plus des automatisation, nodered etc)
- une doc qui doit tout expliquer (j’ai lu le github, tes 2 sujets, regardé la vidéo et j’ai pas vu l’ombre d’une automatisation au sens HA, au mieux j’ai vu une carte)
- un ratio temps de config/compréhension par rapport au temps passé à corriger à la main pas toujours évident
Donc pour un utilisateur lambda (ce que je ne suis sans doute au sens premier) c’est tout sauf facile à prendre en main. Il y a déjà trop de choses à apprendre pour s’éviter d’en ajouter une de plus.
Et si je compare par rapport à l’expérience vécue avec mon générateur des effets météo en CSS, personnellement j’ai pris le partie de garder l’idée mais de tout refaire en mode carte classique, l’adhésion des utilisateurs est beaucoup plus facile, mais ça reste vachement technique.
Donc sans forcément connaitre l’objectif que tu te fixes, j’aurais tendance à dire : comment faire pareil mais en plus simple (du point de vue utilisateur) et moins spécifique (du point de vue dev) c’est ça qui à mon avis dois guider tes prochaines évolutions