Bon après avoir repoussé (trop?) longtemps l’échéance, je vais bien finir par devoir me lancer…
Autant la migration en V2.0 en elle même ne me fait pas trop peur
Autant j’ai de nombreuses télécommandes IKEA: E1743 (Tradfri on/off) et E2201 (Rodret on/off).
Elles sont toutes contrôlées via des blueprints me permettant (avec des helpers spécifiques) d’aller au delà des capacités initiales de chaque télécommande, notamment en étant capable de créer des doubles clics « virtuels ». Et de faire de la variation (loop) sur les appui longs… Ces blueprints sont basés sur les sensor.*_action qui vont disparaitre.
Je vais donc devoir recréer mes triggers a partir des « actions » publiées par les inter, dans mon cas:
on
off
brightness_move_down
brightness_move_down
brightness_stop
En l’état actuel de choses, sans mise à jour des templates utilisés jusque là, je perdrais donc deux fonctionnalités bien pratiques:
la possibilité de définir le « double clic » qui n’est pas pris en charge de base par ces boutons (là il faudrait s’y filer et se refaire la logique du blueprint…)
Du coup la question se pose de basculer sur Switch manager comme proposé par @KipK :
Questions:
Switch manager permet il de gérer ce type d’appui long ou de doubles appui de façon « native » pour des télécommandes qui n’en sont pas équipées initialement ?
Switch Manager utilise quelle techno entre:
device trigger
mqtt trigger
event entity (la méthode expérimentale) ?
ou alors switch manager ne continent pas « nativement » les blueprints ?
Bonjour
Je suppose que tu le sais et que ça ne te convient pas, mais au cas ou …
Les télécommandes ikea ont un paramétrage possible via zigbee2mqtt ‹ simulated_brightness ›
Perso je ne les utilise plus de cette manière, mais je suppose que ça marche toujours
Ce que j’apprécie dans ces blueprints (en particulier la suite awesome blueprint qui apparemment est en cour de mise à jour…) c’est la capacité à pouvoir utiliser les télécommande de façon « indépendante » en câblant des actions différentes sur chaque bouton / action
Par exemple suivant les cas (le pire exemple):
le 1 (on traditionnellement) va faire le toggle du sapin
le 0 (off traditionnellement) va faire le toggle de la crèche
le 1 long (luminosité +) va faire allumer tout le salon
le double 1 va allumer un lampadaire
le double 0 éteindre toutes les lumières
le 0 long éteindre tout le salon
Bon en général je reste plus simple mais j’aime bien avoir un ou deux « Easter eggs » par exemple le hold du 0 éteint quasi toujours la piece, l’étage ou la maison suivant la localisation des télécommandes (chambre / pieces à vivre…).
Ou alors le double clic qui contrôle les volets à la place de la lumière par exemple…
Sinon, si on reste dans le contrôle simple d’une seule lumière en mode on/off et variateur, autant faire du binding direct de l’ampoule IKEA sans passer par Z2M et HA… c’est au final plus simple et plus rapide…
Si ça ne marche plus, je reviendrai sur du fonctionnement plus simple, mais j’aimait bien pourvoir twister un peu mes télécommandes en rajoutant des fonctions « en plus » (en particulier les doubles clics…). Rien de critique car comme dit dans ma description, chez nous la principale interface domotique ça reste la voix avec Alexa…
Oui pour ma part j’ai revu un peu mes configs, suite à quelques questionnements quand la famille vient à la maison, j’avais le choix, un mode d’emploi à côté du bouton ou me mettre à la place de l’utilisateur, pour ma tranquillité même si ma femme à une forte capacité d’adaptation j’ai choisi l’option 2
Je tend vers la même chose, c’est pour ça que ce n’est pas critique si je perd cette capacité.
Cependant le truc que j’utilise beaucoup c’est le hold du 0, pour éteindre toutes les lumières qui s’allument automatiquement la nuit, en revenant d’un petit pipi nocturne… Celui là même ma femme l’utilise…
j’utilise beaucoup aussi, mais uniquement avec les dimmer et boutons philips hue, et là je les configure hors home assistant dans une app « hue essentials » qui se connecte directement sur l’api du pont hue, les capacités de configuration des boutons et dimmer n’ont plus de limite.
Mais il faut avoir des équipements philips hue, et l’appli est sur l’iphone.
Pas sûr pour les double click non gérés nativement. Comme tu vois dans le blueprint au dessus , il récupère la valeur du payload ( single, double, hold )
Pour info, ce sont les blueprint dédié au plugin switch manager, indépendant des blueprint HA classique ) .
A voir si ça permet de bidouiller un faux double clic, je ne me suis pas penché sur la question.
Il n’utilise pas les event et trigger HA, mon commentaire plus haut porte à confusion. C’est géré directement depuis MQTT ( Mqtt trigger ? ) Mais ca n’utilise pas les action legacy z2m ( sauf si un blueprint a décidé de le faire ) :
@BBE en lisant la doc sur le github, j’ai bien l’impression que tu peux faire tes double clics.
timestamp key
You can also access the unix timestamp that the action was executed by accessing data.button_last_state[0].timestamp, this can allow you to determine which button and what action was last executed or calculate how long ago the same button and action was excecuted by also accessing data.timestamp which is the current timestamp for the current button and action. data.timestamp - data.button_last_state[0].timestamp will give how much time has passed in seconds and milliseconds via decimal point since the button action of the first button to the current button and action (referencing the same button and action will give the last time it was executed and not the current execution).
You could use a choose sequence action that checks whether any other button is held and handle an action for that. Be creative! Keep in mind that this is less useful with press actions etc as they’re reset upon a switch reload/save where as a hold/rotate action is more useful as they’re called in an active state.
Bonjour, depuis le passage en 2.0, j’ai perdu mes sensors action de mes télécommandes (j’ai bien mis dans ma conf legacy_action_sensor: true). Et même en repassant à la version précédente de z2mqtt avec une sauvegarde je ne les récupère plus. Quelqu’un a-t-il eu ce soucis et réussi à le régler? J’ai perdu toutes les actions de mes télécommandes, c’est bien génant!
All action sensors are now disabled by default (sensor.*_action entities). It’s recommended to use the MQTT device trigger instead. In case you really need the action sensors, add the following to your configuration.yaml.
Merci pour l’aide. Malheureusement rien n’y fait, je n’avais pas vu cette restauration du backup mais j’avais modifié le fichier manuellement (ce qui devrait revenir au même à mon sens). Bref, je viens de tenter la restauration mais cela ne change rien.
edit : ça a fini par revenir en remodifiant (une fois de plus) le fichier configuration.yaml depuis le module complémentaire. Cela dit, je ne comprends toujours pas pourquoi (en règle générale) les modifications des fichiers de conf ne sont pas prises en compte en dehors des modifs via les interfaces de HA…
Merci à tous.
Pour ceux qui utiliseraient ce type de blueprint (Awesome HA blueprint)… ça bouge… le E1743 est patché, le reste va suivre (il y a un fork et ils sont en train de merger dans la branche de départ) :
Si tout marche bien je basculerai « juste » grace aux blueprints…
Bonjour et bonne année.
est-il possible de bloquer la mise à jour de zigbee2mqtt?
Ce matin, le WAF est monté d’un cran … Plus de chauffage, et bouton poussoir qui ne fonctionne plus…
Heureusement, j’ai pu restaurer avec PBS.
J’avais bien essayé de mettre les nouvelles lignes dans le config.yaml de Z2M, mais rien ne fonctionne…
Je pensais avoir désactivé les MAJ auto, mais, apparemment non.
Je pense rester en 1.42, c’est vraiment trop galère de faire la MAJ. Bizarre pour un logiciel qui se veut user friendly… (oui je sais Z2M n’est pas HA)
Merci de votre aide
Merci !!
En fait, je ne trouvais pas cette fenêtre, j’allais « tout simplement » dans Z2M… Même avec ta capture d’écran, il a fallu que je fouille dans tout HA (c’est lourd)…
Encore merci