Ok, merci pour ces précisions.
Il va me rester à trouver comment transformer mes volets en COVER et pas SWITCH !
Merci encore.
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
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
C’est le même principe mais l’intégration personnelle (custom component) le fait pour toi…
Bonjour à vous,
Déjà, merci pour l’accompagnement et vos réponses.
J’ai installé le custom component via HACS :
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 stopperoff
=> le volet descend, un deuxième off
pour le stopperon
et les off
c’est le bazard, le moteur force car alimenté pour faire les 2 mouvements opposésvelux_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
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
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.
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
@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.
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à :
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
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 !
Bonjour Iarod241
je suis dans le cas de 3 volet DIO reconnus comme switch.
Et je bute toujours sur la manière pour les transformer en cover avec 3 commandes ouvrir, fermer, stopper.
j’ai d’autre volets avec des commandes Legrand Netatmo, des lumières avec des Shelly , du Hue aussi, des commandes Google et Alexa excellentes, bref tout va bien sauf ce RF433 !!
cela fait une semaine que je teste avec différentes config YAML et scripts et rien ne fonctionne. Je te sollicite pour m’aiguiller. Merci par avance.
je précise que j’ai intégré « platform: cover rf time based » correctement…
SAlut.
Partage ton code, sinon difficile de dire ce qui ne va pas
Bonjour Pulpy,
je fonctionne avec un module RFXcom
type: entities
entities: