Retour d'état interrupteurs volets roulants Tuya + Positionnement

Oui mais ça va rendre le truc plus compliqué :
Tu peux essayer de faire dans le volet 2 :

       open_switch_entity_id: cover.bureau
       close_switch_entity_id: cover.bureau

Mais à mon avis ça passe pas…
L’autre solution c’est de passer par l’intégration un peu différente pour la création du volet 2 :

ça permet de lancer des scripts (au moment du open/close/stop). Du coup tu peux faire un script qui fait le open sur le volet 1, etc. C’est un empilement plus complexe par contre

Je comprends.
Avant d’essayer, j’ai trouvé ça :
Là mon cover.bureau de localtuya est fermé et j’ai trouvé une option timer dans l’intégration tuya qui fonctionne :

Si je l’ouvre :

Une fois complètement ouvert (après le timer déféini) :

Il a bien changé de position. Par contre son état reste inconnu alors que sur cette carte on voit bien qu’on ne peut pas le monter mais seulement le descendre.
Je suis sur qu’il y a un truc à creuser de ce côté non ?

image

Pour info je n’ai joué qu’avec le store du bureau sur l’intégration localtuya

Sur l’intégration tuya je suis un peu sec, je l’ai pas. Donc pas moyen de te dire…
Par contre, si tu veux avoir les % d’ouverture, tu ne vas pas avoir des millions de solutions , il y a toutes les chances qu’il faille utiliser l’une des deux intégrations time based du sujet

La première chose serait d’avoir des retours d’état du moins de les simuler.
Je pense qu’avec MQTT on peut le faire mais je n’arrive pas à envoyer la valeur modifiée à HA…
et avec ta première solution ça ne fonctionne pas tu avais raison.
Faut faire le script mais je ne sais pas faire….

hummm… pas certain, en tout cas, j’en ai pas besoin avec ces deux solutions chez moi

ça s’apprends c’est comme le reste
Par exemple j’ai partagé un des miens

J’ai bien vu ton script mais je ne le comprends pas…

Tu pourrais me l’expliquer ou me donner un exemple avec mes entités stp ?

Allez le prochain coup, c’est toi qui fait le boulot

input_text:
  retour_etat_fictif_2:
    initial: ""

cover:
  - platform: cover_rf_time_based
    devices:
      bureau_2:
        name: "bureau_2"
        travelling_time_up: 18
        travelling_time_down: 15
        close_script_entity_id: script.close_bureau
        stop_script_entity_id: script.stop_bureau
        open_script_entity_id: script.open_bureau
        send_stop_at_ends: True

script:
  open_bureau:
    alias: "Open volet du bureau"
    sequence:
    - service: cover.open_cover
      data:
      entity_id: cover.bureau
    - service: input_text.set_value
      target:
      entity_id: input_text.retour_etat_fictif_2
      data:
      value: open
  close_bureau:
    alias: "Close volet du bureau"
    sequence:
    - service: cover.close_cover
      data:
      entity_id: cover.bureau
    - service: input_text.set_value
      target:
      entity_id: input_text.retour_etat_fictif_2
      data:
      value: close
  stop_bureau:
    alias: "Stop volet du bureau"
    sequence:
    - service: cover.stop_cover
      data:
      entity_id: cover.bureau

à voir s’il faut

    send_stop_at_ends: True

ou

    send_stop_at_ends: False

Je te remercie.
Plusieurs questions pour comprendre

Au début tu déclares ton input.text
Pourquoi mettre les doubles quotes sans rien dedans ?
Quelle est la différence entre les plateformes cover_rf_time_based et cover_time_based ?
Le send_stop_at_ends sert à envoyer un stop ou non à la fin du script c’est ça ?

Et le input_text.set_value sert à modifier l’état du volet roulant ? Mais le fictif ou le réel ?

Le mot clé initial veut dire qu’à la création, on y associe la valeur qui suit le mot clé. Donc comme pour le moment le volet2 n’a jamais fonctionné, je met vide (On peut mettre n’importe quoi en principe) : "".
Quand le volet aura bougé, ça prendra la valeur open ou close et ça ne sera plus jamais vide.
Mais dans ton cas, ce input_text est juste bon pour l’exercice, ça sert strictement à rien pour le fonctionnement du volet

Ce sont deux implémentations différentes : cover_rf_time_based c’est cover_time_based avec l’appel de scripts à la place d’activation de switchs
Forcement il faut installer celle que l’on utilise

C’est ça. Sur mes volets Somfy, j’en ai pas besoin, quand ils arrivent en bout de course, ils s’arrêtent tout seuls, et stop est une commande à part entière. Sur mes velux, il n’y a pas de stop proprement dit, il faut doubler la commande open/open et close/close. Dans le code initial, je me servais de l’input_text pour retrouver si je devais faire un 2ème open ou un 2ème close dans le script du stop

Comme son nom l’indique … fictif… c’est juste une info, dans un coin, toute seule, c’est même pas un cover

Ok.
Merci pour les explications. Je teste ça demain matin et je te ferai un retour.
Mille merci !!!

Yahou ça marche trop bien !!!
Encore merci !!!
J’avais même pas vu que tu pouvais faire les scripts en GUI… je suis un boulet !

Merci pour ta patience et ta réactivité !

@++++

1 « J'aime »

Super !
Tu es lancé donc :wink:

1 « J'aime »

Oui je suis lancé.
J’ai fait toutes les modifications pour mes volets roulants.

J’ai pu réaliser quelques tests et ça fonctionne bien.

Cependant je suis face à un nouveau problème. Je sais pas si ça peut se résoudre :

Lorsque j’appuie sur mon cover.bureau2 avec le bouton close, tout se comporte normalement et quand il se met en stop, le statut du cover.bureau change lui aussi tout seul (ça c’est cool !)

A l’inverse si j’appuie ensuite sur le bouton open du cover.bureau (soit sur HA soit directement sur l’interrupteur) ça ne change pas le statut du cover.bureau2…

Y’a-t-il un moyen de régler ce problème ?

Du coup l’idée serait que le cover.bureau2 soit toujours aligné au statut du cover.bureau
Tu vois le truc ?

Ouverture avec le bouton physique de l’interrupteur :

@Pulpy-Luke

Ben je crois avoir trouvé :

J’ai fait une automation et ça a l’air de fonctionner :

alias: Ouverture bureau 2
description: ''
trigger:
  - platform: device
    device_id: 626c8500d6c5b77cd95a6b308e9c489a
    domain: cover
    entity_id: cover.bureau
    type: opening
condition: []
action:
  - service: cover.open_cover
    target:
      entity_id: cover.bureau_2
mode: single

Par contre c’est le stop que j’arrive pas à régler…

La question c’est pourquoi vouloir les 2 ? Bureau2 ajoute des fonctions à Bureau et conserve toutes les fonctions d’origine, donc je vois pas l’intérêt de se servir de Bureau directement.
si c’est juste pour le nommage, tu change bureau en bureau-tuya puis bureau2 en bureau et voilà

Le bureau 2 me sert pour avoir l’état ouvert ou fermé
le bureau me sert si j’appuie sur l’interrupteur physique

faut juste que je trouve pour le stop…

Mais sur lovelace je laisserai bureau 2

Et du coup, quand l’info ne sera pas transmise correctement comme là tu fera comment ?

Bref, si tu veux vraiment faire ça, tu va devoir t’assurer d’éviter des soucis de bouclage :
Bureau2 mets à jour la position de Bureau (comme dans mon exemple) mais la position de Bureau sert aussi à mettre à jour Bureau2 (via ton automatisation)…

Personnellement les télécommandes servent de déco et en cas de panne de la domotique. Le reste du temps, c’est via la tablette murale, via le téléphone ou les commandes vocales, y compris vocal depuis le teléphone… Tous le monde à la maison s’est pris au jeu

Mais le coup des automations open et close ça fonctionne vraiment bien.
C’est juste le stop que j’arrive pas à gérer.

Et es enfants ne se servent pas toujours des télécommandes et ils n’ont pas de tel…

ça viendra ! Avec l’âge, ils vont préférer rester assis dans la canap’ plutôt de que de se lever :sweat_smile:

Il faut que regarder sur quel trigger tu peux te baser… Le principe reste le même.

Ben c’est le problème c’est que je trouve pas le bon trigger…