Bonjour à tous, J’ai beau chercher, essayer, en me basant sur la page officielle HA pour les template covers, de modifier mes volets roulants, mais rien n’y fait, je n’ai pas le résultat escompté.
Mes volets fonctionnent mais en mode interrupteur (switch) Ce qui est très gênant pour la commande vocale par Google Home. Je suis obligé de dire « active le volet XXX » (qui va ouvrir le volet) ou « désactive le volet XXX » (qui va fermer le volet) car ils sont vus par Google Home (et HA) comme des interrupteurs…
Je suis sur la dernière version de HA
Core2024.1.5
Supervisor2023.12.1
Operating System11.4
Interface utilisateur20240104.0
Mes volets fonctionnent en 433 par le biais d’un RFXCom qui est bien intégré.
J’ai essayé de modifier l’entité (détectée en switch) et de la passer en « volets » pour commencer mais je n’arrive vraiment pas à maitriser les commandes à taper dans le configuration.yaml
Hello. Oui effectivement je peux modifier et faire comme tu m’as montré, mais du coup en fait j’ai 2 autres covers (grisés) qui viennent de s’ajouter en fait…
J’ai remplacé mes id des « switch » par les id des « cover », j’ai remplacé les services « switch.turn_on » par les services « open.cover_open » (même chose pour la fermeture)
Cela fonctionne, mais à l’envers d’une part (baisser pour monter et inversement)
et d’autre part cela ne recréé pas une entité visible dans Google Home.
@Superchaussette, Bonjour à toi. Je me permets de te tager ici car je pense que je pourrai y arriver à l’aide de MQTT.
J’ai lu ton post avec intérêt : Template mqtt cover et cover
Mais il me manque des détails quant à la configuration.
J’ai des appareils Zigbee et de ce fait j’ai installé Zigbee2MQTT et forcément MQTT aussi.
Peut-être serait-il plus facile que je passe par MQTT pour la configuration de mes volets ?
MQTT est « juste » une espèce de « forum » pour les objets: faire passer des messages et les réponses.
Zigbee2mqtt sert de « hub » Zigbee et permet de piloter les objets zigbee en utilisant les messages. Et HA utilise MQTT pour communiquer avec les objets.
Donc la commande switch.turn_on lancé sur HA pour un switch zigbee va envoyer sur zigbee2mqtt qui lui même va transmettre la commande et récupérer la réponse sur le protocole zigbee.
Donc il faut voir MQTT comme un outil de communication sans intelligence, et rien de plus
Dans mon contexte, j’ai « quelque chose » entre HA et les relais d’action sur les volets qui communique via MQTT: une pi avec un service python (donc un peu d’intelligence quand même), qui prend en entrée un % d’ouverture (sur le topic /command) et qui calcule le temps d’activation des relais pour l’ouverture (ou fermeture, qui est plus court) des volets. Et ce script publie en retour le pourcentage d’ouverture actuel du volet et son statut.
il y a 3 topics mqtt utilisés pour le volet: /command sur lequel HA envoie sa commande (ou un autre objet, hors HA), /state (closed/open) et /status (le %). Ainsi, HA sait toujours le statut du volet.
C’est ce que tu vois dans le yaml que je partage.
Pour l’inversion de la commande, c’est bien dans le yaml: set_position_template: "{{100 - int(position) }}"
Je me suis mal exprimé je pense.
J’ai bien compris le fonctionnement d’un broker comme mosquito.
Ce que je tentais de dire, c’est comment tu as fais l’interopérabilité entre les deux ?
En gros dans mon cas je veux faire du RFXCom to MQTT to RFXCom.
Afin d’envoyer les ordres par MQTT à mes volets.
Effectivement j’étais à côté de la plaque.
Pour du 433, j’utilise du RFlink, et j’ai trouvé ceci, qui fait comme zigbee2mqtt mais en RF:
et la version « dockerisée »:
Et je reçois sur MQTT des messages sur un topic:
exemple: "rflink/EV1527/0b46ef/R/04"
ou "rflink/NewKaku/016dd76a/R/0"
En l’occurrence des télécommandes RF433 pas chères.
Et je traite ca avec un script python directement dans HA, mais c’est faisable avec les automatismes.
Je n’ai pas cherché à faire dans l’autre sens (HA → RF), mais le sujet est traité:
Application pushes informations to MQTT broker in following format: [mqtt_prefix]/[device_type]/[device_id]/R/[parameter]
rflink/TriState/8556a8/R/1 OFF
Every change should be published to topic: [mqtt_prefix]/[device_type]/[device_id]/W/[switch_ID]
Me revoilà !
J’ai bossé la journée entière sur mon problème. En passant par Node-RED, tout en ayant désactivé l’integration de RFXCom par HA. J’ai réussi à choper mes trames radios et les injecter en MQTT vers mon RFXCom. Je suis content, sauf que je reviens au problème du départ, le cover !
Je ne maitrise pas du tout, c’est dingue, ça ne doit pas être bien compliqué pourtant…
Dans les deux cas, (RFXCom en natif ou MQTT—>RFXcom) je me retrouve systématiquement avec des switches pour que mes volets fonctionnent. Des que je veux aller plus loin pour que mes volets apparaissent comme des volets… ça ne fonctionne pas et je sèche.
Hello !
Oui tout à fait, j’ai trouvé quelque chose qui me satisfait. Sur le dashboard j’ai bien mon contrôle UP & STOP & DOWN et pour ce qui est de Google Home c’est très bien aussi puisqu’il apparaissent clairement dans les scripts. Bref, c’est parfait. Il s’agit d’un petit projet très pratique qui se nomme [cover-rf-time-based] Qui a été abandonné mais heureusement il a été copié avant par une personne très sympa du forum : @Pulpy-Luke (merci encore à toi au passage)
