Zigbee2mqtt passage en version 2.0.0

Coté mqtt c’est toujours dans un topic action, mais c’est basé sur des events.

Si la télecommande est déjà gérée par switch manager, tu n’a qu’a ajouter une nouvelle telco et faire l’auto detection.

Sinon tu crées des blueprints ( dans le dossier /homeassistant/blueprints/switch_manager

Comme celui là par ex:

name: TuYa 1 Gang Remote
service: Zigbee2MQTT
event_type: mqtt
mqtt_topic_format: zigbee2mqtt/+/action
buttons:
  - actions:
      - title: press
        conditions:
          - key: payload
            value: single
      - title: press 2x
        conditions:
          - key: payload
            value: double
      - title: hold
        conditions:
          - key: payload
            value: hold

Passe en PM sinon, on est un peu hors sujet là.

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:

  • le rebouclage pour par exemple baisser la luminosité « tant que » je reste appuyé sur le bouton (solution donnée là par @Jeffodilo : Zigbee2mqtt passage en version 2.0.0 - #94 par Jeffodilo)
  • 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

En effet ! Mais merci de la précision…

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 :wink:

2 « J'aime »

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…
:rofl:

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 ) :

1 « J'aime »

@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.

1 « J'aime »

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!

1 « J'aime »

Regarde, cette partie
Zigbee2MQTT 2.0.0 breaking changes · Koenkk/zigbee2mqtt · Discussion #24198

il y a entre autre :

  • 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.

homeassistant: legacy_action_sensor: true

Salut,

Avec la version, la valeur doit être false, les anciennes actions n’existent plus… Les automatisations sont donc à adapter.

Ce que je ne comprends pas, c’est que même en revenant en v 1.42 je ne récupère pas mes sensors…


il faut restauraer le configuration.yaml qui a été backup.
le backup_v1

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.

C’est l’inverse, il faut modifier le configuration.yaml et non par le UI. Redémarrer Z2M, pour la prise en compte après.

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…

Affaire à suivre…

3 « J'aime »

Bonjour et bonne année. :grinning:
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… :weary:
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 :+1:

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 :+1: