Gestion de Volets roulants via module DIO 433Mhz

Mon problème

Bonjour à toutes et tous,

Je débute avec HA (venant de Jeedom) et je suis en train de réaliser les intégrations de mes équipements avant de passer à la phase gestion et automatisation.
J’ai réussi à intégrer et mettre en place mon réseau Zigbee (combee2 avec vm mosquitto et vm Zigbee2mqtt)
Je viens basculer mon rfxcom sur HA, c’est ok pour mes sondes Orégons, mais je cale avec la gestion des volets roulant (bubendorff 4 fils tant qu’à faire…)

J’utilise des modules CHACON 54754 (https://blog.domadoo.fr/guides/guide-dinstallation-du-module-volet-roulant-chacon-54754/ qui sont appairés à une télécommande Dio 4 voies (Dio 54761) afin de pouvoir piloter les volets même si l’infra domotique n’est pas dispo.

J’ai récupéré les trames de la télécommandes de jeedom (On et Off pour chaque équipement):
[2021-07-13 18:32:18][DEBUG] : {« devices »:{« 017B5D2E11 »:{« packettype »:« 0x11 »,« subtype »:« 0x00 »,« id »:« 017B5D2E »,« unitcode »:1,« cmnd »:1,« level »:100,« rssi »:7}}}
[2021-07-13 18:32:25][DEBUG] : {« devices »:{« 017B5D2E11 »:{« packettype »:« 0x11 »,« subtype »:« 0x00 »,« id »:« 017B5D2E »,« unitcode »:1,« cmnd »:0,« level »:0,« rssi »:7}}}

Volet Cuisine Up/Down
[2021-07-13 18:35:14][DEBUG] : {« devices »:{« 017B5D2E11 »:{« packettype »:« 0x11 »,« subtype »:« 0x00 »,« id »:« 017B5D2E »,« unitcode »:2,« cmnd »:1,« level »:100,« rssi »:7}}}
[2021-07-13 18:35:16][DEBUG] : {« devices »:{« 017B5D2E11 »:{« packettype »:« 0x11 »,« subtype »:« 0x00 »,« id »:« 017B5D2E »,« unitcode »:2,« cmnd »:0,« level »:0,« rssi »:7}}}

Volet BV Up/Down
[2021-07-13 18:37:40][DEBUG] : {« devices »:{« 017B5D2E11 »:{« packettype »:« 0x11 »,« subtype »:« 0x00 »,« id »:« 017B5D2E »,« unitcode »:3,« cmnd »:1,« level »:100,« rssi »:7}}}
[2021-07-13 18:37:44][DEBUG] : {« devices »:{« 017B5D2E11 »:{« packettype »:« 0x11 »,« subtype »:« 0x00 »,« id »:« 017B5D2E »,« unitcode »:3,« cmnd »:0,« level »:0,« rssi »:7}}}

Volet PF Up/Down
[2021-07-13 18:38:28][DEBUG] : {« devices »:{« 017B5D2E11 »:{« packettype »:« 0x11 »,« subtype »:« 0x00 »,« id »:« 017B5D2E »,« unitcode »:4,« cmnd »:1,« level »:100,« rssi »:7}}}
[2021-07-13 18:38:29][DEBUG] : {« devices »:{« 017B5D2E11 »:{« packettype »:« 0x11 »,« subtype »:« 0x00 »,« id »:« 017B5D2E »,« unitcode »:4,« cmnd »:0,« level »:0,« rssi »:7}}}

J’ai intégré les 4 voies de la télécommande dans HA :

Du coup, ces volets sont reconnus comme entité « switch » et pas cover…

J’ai effectué des recherches, mais je ne trouve pas comment gérer mes volets en tant que tel et pas en tant que switch.

De plus, va rester le problème de la gestion du stop de ces derniers : En effet, sous jeedom, j’avais réalisé des scripts pour les piloter car l’arrêt se fait en appuyant une seconde fois sur la commande du volet. Ex : je l’ouvre , donc, j’appuis sur ON et pour l’arrêter à l’endroit voulu, je dois appuyer sur ON. Si j’appuis sur OFF, il repart dans l’autre sens !
Pas évident à mettre en place pour moi dans l’immédiat.

Autre question : Existe t-il un script ou autre qui permet de gérer les ouvertures partielles ? En donnant par ex le temps total d’ouverture ou de fermeture (forcément différent suivant le sens) afin de calculer la bonne durée de fonctionnement pour ouvrir ou le fermer à l’endroit souhaité ?

Merci pour votre aide et vos conseils.

Ma configuration


[center]## System Health

version core-2021.7.2
installation_type Home Assistant OS
dev false
hassio true
docker true
virtualenv false
python_version 3.9.5
os_name Linux
os_version 5.10.45
arch x86_64
timezone Europe/Paris
Home Assistant Community Store
GitHub API ok
Github API Calls Remaining 5000
Installed Version 1.13.2
Stage running
Available Repositories 846
Installed Repositories 4
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 6.1
update_channel stable
supervisor_version supervisor-2021.06.8
docker_version 20.10.6
disk_total 30.8 GB
disk_used 3.4 GB
healthy true
supported true
board ova
supervisor_api ok
version_api ok
installed_addons Samba share (9.5.1), Visual Studio Code (3.5.0), zigbee2mqttassistant (0.3.157), Home Assistant Google Drive Backup (0.104.3), TasmoAdmin (0.15.0)
Lovelace
dashboards 2
resources 2
views 2
mode storage
[/center]
1 « J'aime »

Salut,

Pourquoi une VM pour chacun de ces si petits services ? Rassembler les 2 c’est plus simple et plus économique à mon avis, si on veut pas tout gérer automatiquement via HA directement

Pour les gestions des on/off/stop, regarde de ce coté…

J’avais même filé un bout de config

1 « J'aime »

Bonsoir,

Merci pour ces informations. Je vais aller regarder.

Pour les 2 VM, en fait, il s’agit d’une VM pour zigbee2mqtt (plus simple qu’un CT pour géré la clé USB avec proxmox) et Mosquitto est sur un CT.
J’ai pris pour habitude de séparer les services. C’est plus simple pour la MCO quand ça se passe mal.
Mais il est vrai que j’hésite à installer mosquitto sur la VM Zigbee2Mqtt. Mais vu que le CT n’est pas vraiment gourmand, je laisse comme ça pour l’instant.

D’après toi, je pars comme ça avec mes volets en gestions switch et pas cover ou j’essaye de trouver une solution pour les configurer comme cover afin de ne pas être ennuyé plus tard ?

J’ai un peu de mal à voir sur le long terme l’incidence (pour les automations et autres scripts) que pourrait avoir une gestion des volets en switch…

Merci en tout cas du temps pris pour me répondre. :relaxed:

Zigbee2mqtt c’est à peine plus gourmand que mosquitto… Pour ça que l’intégration container dans HA est à mon avis un bon choix (et puis niveau gestion de l’usb, j’ai pas tellement de souci, ça marche tout seul). Après chacun ses préférences.

Tu dois pouvoir gérer l’un comme l’autre, mais à mon avis les volets c’est plus adapté quand même, les notions liées au volet/cover seront à traiter à la main si tu gère de ton coté avec des switchs…
Et puis, comme 99% du boulot est déjà fait avec l’exemple de config, ça devrait pas prendre trop de temps en dehors de l’analyse et de la lecture

1 « J'aime »

Ok, merci pour ces précisions.
Il va me rester à trouver comment transformer mes volets en COVER et pas SWITCH !

Merci encore.

C’est l’intégration que @Pulpy-Luke t’a indiqué qui va te créer une entité cover.

Lance toi, tu verras :+1:

1 « J'aime »

Merci ! je n’avais pas saisie cette subtilité. Les habitudes de Jeedom sont bien encrées…
J’avais l’habitude de créer des objets virtuels à tout va et de raccrocher les divers sondes, capteurs, actionneurs, etc dessus.
C’est clairement différent maintenant :smiley:

C’est le même principe mais l’intégration personnelle (custom component) le fait pour toi…:innocent:

1 « J'aime »

Bonjour à vous,

Déjà, merci pour l’accompagnement et vos réponses.
J’ai installé le custom component via HACS :
Capture d’écran 2021-07-14 à 10.59.44

En revanche, pas d’intégration dispo via intégration/ajout d’intégration. Aucun cover dans la liste.
J’en déduis donc qu’il faut le faire à la main via du code, mais là, je sèche.
J’ai bien récupéré le bout de code (script couvertes.yaml) de Pulpy, mais je ne sais pas ou/comment l’intégrer pour créer les appareils « Cover ».

Directement via les script en Yaml ?

Désolé pour ces questions « basiques ». J’ai un peu de mal encore avec l’approche HA malgré le visionnage d’un paquet de tutos !

Bon 14 juillet à tous

L’intégration est simple :

Si tu n’as pas découpé ton fichier configuration.yaml en plusieurs morceaux, il faut coller le code à cet endroit.
Voilà un autre exemple encore plus adapté à ton cas (switch qui n’offre que 2 fonctions on/off). Si on joue avec le switch directement, ça fonctionne ainsi :

  • on => le volet monte, un deuxième on pour le stopper
  • off => le volet descend, un deuxième off pour le stopper
  • si on mélange les on et les off c’est le bazard, le moteur force car alimenté pour faire les 2 mouvements opposés
velux_suite_prop:
    name: "Velux suite"
    travelling_time_up: 23
    travelling_time_down: 23
    close_script_entity_id: script.close_velux_suite_prop
    stop_script_entity_id: script.stop_velux_suite_prop
    open_script_entity_id: script.open_velux_suite_prop
    send_stop_at_ends: True

ça c’est la création de ton volet… qui va appeller tout seul les 3 scripts pour les actions open/stop/close

Tu dois juste définir les temps de montée/descente en secondes (en fonction de comment ça fonctionne chez toi, mais c’est pas indispensable au premier abord)

script:
    open_velux_suite_prop:
    alias: Ouvre le velux de la suite
    sequence:
        - service: switch.turn_on
        data:
            entity_id: switch.velux_suite
        - service: input_text.set_value
        target:
            entity_id: input_text.velux_suite_prop_last
        data:
            value: open
    close_velux_suite_prop:
    alias: Ferme le velux de la suite
    sequence:
        - service: switch.turn_off
        data:
            entity_id: switch.velux_suite
        - service: input_text.set_value
        target:
            entity_id: input_text.velux_suite_prop_last
        data:
            value: close
    stop_velux_suite_prop:
    alias: Stoppe le velux de la suite
    sequence:
        - service: "{% if is_state('input_text.velux_suite_prop_last', 'open') %}
            script.open_velux_suite_prop
            {% elif is_state('input_text.velux_suite_prop_last', 'close') %}
            script.close_velux_suite_prop
            {% endif %}"
        - service: input_text.set_value
        target:
            entity_id: input_text.velux_suite_prop_last
        data:
            value: "{% if is_state('input_text.velux_suite_prop_last', 'open') %}
            stop_open
            {% elif is_state('input_text.velux_suite_prop_last', 'close') %}
            stop_close
            {% endif %}"

ça c’est les 3 scripts en question. Il faut que tu remplaces switch.velux_suite par le bon switch chez toi
et pour que ça marche bien il faut aussi créer l’entrée

input_text:
  velux_suite_prop_last:
    initial: ""

ça va récupérer le dernier mouvement (up/down) pour appeler le ‹ stop › qui va bien et appeler le switch dans les bonnes conditions

Forcement quand tout est correct, il faut relancer le core pour la prise en compte

2 « J'aime »

Merci @Pulpy-Luke , je vais tester ça demain.
ça me semble plus simple comme ça.

Je viens de terminer l’intégration des prises Ikéa Zigbee afin de mailler mon réseau. Dommage que les accessoires aquara Xiaomi ne respectent pas le protocole Zigbee et se cantonne au routeur sur lequel ils sont raccrochés !
J’ai des capteurs sur mes 4 volets roulants afin de savoir quand il sont complètement fermés.
ça aide pour savoir si l’ordre d’ouverture ou de fermeture est bien passé…

Salut. C’est deux fois le même exemple. Seuls les noms sont probablement plus explicites

C’est pas tellement le débat ici mais les aquara respectent la norme. Que ce ne soit pas le fonctionnement qui apporte le plus de fonctions est un autre sujet.

Dans toute la mécanique présentée ici, ça n’apportera rien de plus. Tout fonctionne sans retour d’état.

Personnellement, la seule fonction qui est meilleure sur le rfxcom côté jeedom, c’est la gestion des protocoles actifs/inactifs. Pour tout le reste, HA fonctionne mieux : J’ai jamais perdu d’ordre et il n’y a pas besoin de gérer des pauses entre les ordres au niveau des automatismes.
Pour le rflink, je ne sais pas par contre

1 « J'aime »

Merci @Pulpy-Luke !
Je viens de tester et ça fonctionne !
J’ai galéré un peu car j’avais zappé de rajouter un « - platform: cover_rf_time_based » avant ! Forcément…

Il me reste plus qu’à intégré ça dans le tableau de bord avec une jolie carte et ça sera parfait pour le premier volet. Les autres suivront, mais ça sera du copier/coller, donc, ça va pas trainer !

Merci encore. :relaxed:

1 « J'aime »

Bonne nouvelle donc !
Pour l’affichage, je suis parti là dessus :

homeassistant:
  customize_domain: #for all covers
    cover:
      assumed_state: false
      device_class: shutter
    cover_rf_time_based:
      assumed_state: false
      device_class: shutter

Et la carte custom:shutter-card

1 « J'aime »

@Pulpy-Luke, je te remercie à nouveau, c’est parfait. J’ai complètement intégré 1 volet avec la carte qui va bien !
Je vais m’occuper des 3 autres ce weekend avant de passer à la prochaine étape : Automatisation avec fermeture sur la façade ouest en cas de fort ensoleillement et chaleur, ainsi qu’une automatisation de fermeture à la tombé de la nuit, avec, si possible demande et interaction.
Je gérais ça, sous jeedom, avec télégram qui permettait de faire de l’interactif en posant une question, et en attendant une réponse avec des choix proposés : Fermeture des volets (Oui, non, redemande dans 20 minutes) et en cas de non réponse au bout de 10 minutes, le script s’arrêtait.
Pratique !

Toujours est-il, je te remercie à nouveau pour le temps que tu m’auras accordé. Je commence à y voir un peu plus clair et à comprendre le fonctionnement et les subtilités de HA.

1 « J'aime »

De rien. Si ça fonctionne et que c’est plus clair alors j’ai doublement bien dépensé mon temps. Et sans doute que ce sujet servira à d’autres à l’avenir.
Pour le reste de tes modifications, ça sera plus facile une fois que tu auras décidé du choix technique entre les automatisations natives ou nodered…
On aura sans doute l’occasion d’en rediscuter dans les prochains sujets.
Bonnes modifications

Et voilà :


Le fonctionnement est assez bluffant et assez précis. Le seul petit bémol c’est que la prise en charge du décollement du volet à l’ouverture n’est pas pris en charge.
Ex: si je mets une ouverture à 10%, ça ne va pas ouvrir le volet, juste décoller les lames vu le faible temps d’activation.
C’est du pinaillage car pas vraiment utile dans mon cas et je vais gérer avec des % un peu plus élevés pour compenser.

Pour ce qui est de l’utilisation de NodeRed ou des automatisations natives, c’est la question du moment… j’ai commencé à créer des automatisations natives et c’est assez simple et rapide.
J’ai vu quelques tutoriels YouTube sur NodeRed et c’est effectivement bien plus puissant, mais bien plus complexe à prendre en main.

Tu utilises quoi toi ?

Ah ah c’est de là qu’elle vient!

J’avais hésité à te poser la question d’où ça venait car je l’avais remarqué sur la vue que tu avais partagé. Mais vu que je suis encore loin d’avoir intégrer la fonction d’ouverture basée sur la durée (la discussion sur le retour d’état des volets) je ne l’avais pas fait. Je garde ça sous le coude :wink:

Pinaiz Larod tu as été bien plus réactif que moi… je suis en train d’essayer de faire la même chose et heureusement que Pulpy était là pour m’aider sinon je n’aurais même pas encore un volet dans HA.

Oui c’est le seul défaut. Partir de 0 vers 10% c’est pas pareil que partir de 100 vers 10%.
C’est moins visible entre 0/50/100 forcément.

Globalement c’est ce que je fais ‹ manuellement › mais ça mériterai un truc automatique pour compenser.

Vu les trucs tordus que j’avais en tête, tout en yaml c’était un peu compliqué au niveau de relecture… Nodered c’est plus simple, mais du coup j’ai beaucoup de trucs brutaux… Ça fait partie d’un travail de fond que je mène encore pour rendre ça plus simple

Clair, quand tu auras basculé ton rfxcom définivement , un coup de copié/collé et tu seras au même niveau que @larod241

Effectivement, j’avance tranquillement, mais surement et Pulpy n’y est pas étranger.
Je maitrisais plutôt bien jeedom et la migration est finalement plus facile que prévue.
Il faut, bien évidemment, s’approprier l’outil et la logique, ainsi que le vocabulaire et la logique, mais, finalement, j’ai fait, en peut de temps (merci à HACF) bien mieux que ce que j’avais sous Jeedom pour les volets par ex.

Je viens de gérer l’automatisation des ouvertures/fermetures avec offset :

Il ne me reste plus qu’à gérer la fermeture partielle des volets ouest l’après midi afin de préserver la fraicheur dans la maison.

Et ensuite… on passe à la partie chauffage !!! J’ai 2 PAC à piloter en fonction de la saison (clim / chauffage) et de la présence dans la maison ! :smiley: :smiley: