Bonjour,
Nouvelle question :
J’ai un volet appelé cover.xxxx, j’ai créé un volet virtuel avec ton appli nommé cover.xxx_timebased. Tout fonctionne parfaitement quand je commande depuis le cover,xxx_timebased.
Comment recopier ce volet virtuel avec la position du volet de base ? Le problème que j’ai est que mes volets sont commandés par HA et par l’interrupteur Tuya physique. Quand on force l’ouverture ou la fermeture via l’interrupteur, la position du volet virtuel ne change pas. ( alors quelle change dans le sensor cover.xxx de base)
Il y a pas mal d’options dans ton intégration mais elles ne paraissent pas toutes décrites
Merci d’avance
Phil
Messieurs. quelqu’un peut-il expliquer exactement comment ajouter le code yaml à l’assistant domestique. j’ai essayé plusieurs fois je n’ai pas eu l’entité .Merci d’avance
Hello
Perso j’ai
Une ligne dans configuration.yaml:
cover: !include cover.yaml
Un fichier cover.yaml dans lequel j’ai autant de blocks que de volets:
- platform: cover_rf_time_based
devices:
cover.volet_cuisine_time_based:
name: Volet cuisine time based
travelling_time_down: 8
travelling_time_up: 14
open_script_entity_id: script.ouverture_volet_cuisine
stop_script_entity_id: script.stop_volet_cuisine
close_script_entity_id: script.fermeture_volet_cuisine
send_stop_at_ends: False #optional
always_confident: False #optional
device_class: shutter #optional
# availability_template: "{{ is_state('binary_sensor.rf_bridge_status', 'on') }}" #optional'
Tu relances HA ( dans ce cas en option configuration seulement )
Et tu as ton nouveau sensor volet
Phil
Hello.
C’est tout le souci de cette integration : La gestion en parallèle des volets via les télécommandes et via Ha ne permet pas de synchroner la position.
Ce qui m’étonne cependant c’est que tu semble avoir une info de la position l’interrupteur. Du coup j’ai du mal à comprendre ce qu’apporte l’intégration par rapport au volet de base.
Accessoirement c’est pas mon integration mais un simple dépôt cloné du fait de la suppression de l’original.
J’ai pas vu notification de l’issue mais en déplacement cette semaine donc accès limité
Avec l’intégration de base, je n’ai pas la notion de position . Je peux juste faire monter, descendre, arret.
Avec ton intégration je rajoute une notion de position virtuelle liée au temps de montée et de descente.
C’est pour ça que je l’utilise ( même si je ne l’exploite pas encore )
Je pense qu’il doit y avoir moyen de récupérer l’info de montée, décente et arrêt du sensor de base pour lancer aussi la même chose sur le sensor génère par ton intégration.
Avec un automatisme peut être.
Je vais y réfléchir ….
Phil
OK c’est un peu plus clair pour moi.
En imaginant que tu arrives à voir la notion de montée/arrêt/descente sur le volet d’origine tu vas avoir quand même pas mal de contraintes.
- si tu indique une position au composant timebased, il agit sur le volet physique
… Donc là tu as une boucle d’interactions. Aujourd’hui il n’y a pas moyen de dire : affiche la position zz dans timebased sans actionner le moteur. C’est peut-être une fonction de synchro qu’il faut ajouter. - quand tu va vouloir arrêter le volet physique à mi course par exemple, tu n’aura aucun moyen simple de retrouver la position correspondante. En gros il faudrait être en mesure de dire le volet est monté pendant x secondes (comprendre tracer les événements horodatés up et stop, faire le delta) donc la position est x/temps de montée… Valeur du temps de montée qui est elle du côté timebased… Là on est presque à réécrire l’ensemble de timebased à l’extérieur… Pas simple.
À mon avis c’est quand même bien compliqué à faire
Je suis d’accord ! Mais au moins en tout ou rien ce serait pas mal
Sinon en utilisant la même commande de montée descente arrêt que le sensor volet virtuel, ça devrait compter le temps aussi bien ( enfin comme on dit ce se sera pas plus pire que moins mauvais !)
Type automatisme « si ordre x sur volet de base change, lancer ordre x sur volet virtuel »
Avec 3 automatismes et x montée, descente, arrêt je le sens bien ….
J’y réfléchis …… je reviendrai la dessus si je m’en sors
Phil
Justement ça c’est possible avec une automatisation, mais ça marchera jamais correctement en l’état, parce que tu oublie la suite.
La mécanique voulue et actuelle c’est ça
Action sur volet virtuel => (entraine) => action sur le volet de base
donc si tu ajoute une automatisation, tu aura
Action sur volet de base => (automatisation) => Action sur volet virtuel => (entraine) => action sur le volet de base
Et donc par conséquences :
Action sur volet de base => (automatisation) => Action sur volet virtuel => (entraine) => action sur le volet de base => (automatisation) => Action sur volet virtuel => (entraine) => action sur le volet de base ....
hello
je te lis apres … les grands esprits se rencontrent !
les etats de mon volet sont 1 : montée, 2: descente, 3: arret
j’ai donc fait 3 automatisations.
je joins la première:
alias: recopie ouverture volet chambre nicolas
description: ""
trigger:
- platform: state
entity_id:
- cover.volet_chambre_nicolas
attribute: raw_state
to: "1"
condition: []
action:
- service: cover.open_cover
data: {}
target:
entity_id: cover.volet_chambre_nicolas_time_based
mode: single
et cela fonctionne nickel. reste à le roder en attente des effets de bord.
ca doit pouvoir se mettre dans le code directement du programme mais c’est une autre histoire
Phil
Ou enfin là tu demandes à réouvrir un volet déjà ouvert… Moi je suis pas persuadé que ça soit acceptable pour tous les moteurs … Là à un moment donné, il « force » et c’est pas forcément bon, donc à surveiller de près et à ne pas forcément reproduire
effectivement il faut faire attention en fonction des moteurs.
Perso il y a des fins de courses qui arrêtent en haut ou en bas physiquement le moteur. donc toute nouvelle demande de remontée ouvert ou redescente fermé ne declenche rien
j’ai fait les 3 automatisations sur mes 3 volets et ca parait fonctionner dans tous les cas (physiquement avec l’inter, et autant avec le sensor de base que le virtuel. dans tous les cas, l’image de la position du volet suit
phil
prochaine étape faire fonctionner cette satanée passerelle « kit de connectivite Somfy » avec mes 2 volets IO…
Hello
J’ai du toucher a quelque chose car je peux demarrer la descente, l’arret, la montée, le pourcentage evolue correctement mais le volet ne s’arrete pas a la position voulue
J’ai voulu télécharger le dépôt, mais j’ai un message d’erreur.
Quelqu’un pourrait m’aider svp ?
Salut
C’est pas un dépot pour les addons (module complémentaire) mais un pour HACS
1 « J'aime »
Parfait, merci, c’est installé
Hello et merci ! je suis content de retrouver mon set_known_position ! 
Avec mes contacteurs de fin de course ça me permet de re synchroniser les positions malgré l’utilisation des boutons physique des volets !
Hello,
Il y a quelque chose qui m’échappe avec cette intégration. Sur Jeedom, j’utilisais le plugin volet proportionnel, celui-ci a 3 configurations :
- Temps de montée totale
- Temps de descente totale
- Temps de décollement (temps que mettent les lames pour se décoller du seuil).
Ici, il n’y a pas cette notion de « temps de décollement », ce qui a pour effet de dérégler le pourcentage lors d’une descente après ouverture ou inversement. Par exemple, mon volet met 4,5 secondes pour se décoller du seuil. Il lui faut donc 36,5 secondes au total pour s’ouvrir complètement. Ainsi, pour passer de 0 à 50% (volet complètement fermé), il lui faut 18 secondes. Cependant, pour passer de 100% à 50%, il lui faut 16 secondes (car il n’y a pas le temps de décollement). Le plugin volet proportionnel de Jeedom adapte le calcul en fonction de si le volet est déjà décollé ou non. Ici, même en mettant le Time UP à 36,5scd et le Time DOWN à durée montée - décollement (soit 32scd), le volet fini par se dérégler en passant d’un pourcentage > à un pourcentage < et inversement.
Merci d’avance 
Bonjour , j’utilise également le set_known_position et dans mes logs HA ,il est indiqué qu’avec la version 2025.9
'cover_rf_time_based' registers an entity service with a non entity service schema which will stop working in HA Core 2025.9'
il va falloir trouver une solution ,cela dépasse mes compétences.
Roberto
1 « J'aime »
Bonjour,
Nouveau venu dans HA mais avec une précédente expérience avec Fibaro 
Ma nouvelle maison est équipée en VR Solaires Profalux … donc retour d’état = nada 
Ma première intégration de mes VR s’est faite grâce à AirSend Duo : nickel 
Je souhaite perfectionner tout cela grâce à ce dépot, merci @Pulpy-Luke
Mon projet :
- Mettre un SONOFF - Capteur de porte ou fenêtre Zigbee 3.0 SNZB-04P en haut de chaque VR pour avoir une info « OPEN » SÛRE, DE RÉFÉRENCE. OK ce n’est pas du matos pour l’extérieur mais avec ces caractéristiques ça devrait le faire :
( Durée de vie de la batterie de 5 ans, Distance d’installation ≤20 mm, Modèle de batterie CR2477 (3 V), Température de fonctionnement -10°C~60°C, Humidité de travail 5 - 95 % HR, sans condensation) - Mettre un aimant néodyme sur la lame du bas du volet. (Ça devrait le faire, j’ai pratiqué cette technique avec un portail coulissant)
J’ai donc commencé à tester l’intégration sur un VR. Ça « marchotte » et j’ai trouvé ces messages en log :
2025-02-05 11:53:30.036 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'cover_rf_time_based' registers an entity service with a non entity service schema at custom_components/cover_rf_time_based/cover.py, line 157: platform.async_register_entity_service(. This will stop working in Home Assistant 2025.9, please report it to the author of the 'cover_rf_time_based' custom integration
2025-02-05 11:53:30.037 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'cover_rf_time_based' registers an entity service with a non entity service schema at custom_components/cover_rf_time_based/cover.py, line 161: platform.async_register_entity_service(. This will stop working in Home Assistant 2025.9, please report it to the author of the 'cover_rf_time_based' custom integration
Bref y disent qu’il faut en parler à @Pulpy-Luke
Merci d’avance
Bonne journée - Jean-Paul
1 « J'aime »
Salut,
Merci pour l’info.
A l’origine la réplication est faite pour que ça ne disparaisse pas, donc voir si c’est pas trop compliqué de corriger.
D’ici 2025.9 il reste encore un peu de temps.
Sinon, il faudra chercher trouver une autre solution
Accessoirement il va falloir betatester