Je commande 17 VR/BSO grâce à vos modules X4VR. Tout marche convenablement dans l’ensemble, sauf que je souhaite domotiser les BSO avec un Rapberry pi, et je rencontre un soucis. Mes plus grands BSO mesurent environs 4m de haut, pour un temps de montée (et de descente) d’environ 95 secondes.
Je souhaite commander l’orientation des lames avec des impulsions de 300ms pour les orienter en fonction de la course du soleil.
Pour mettre en évidence le soucis je fais la boucle schématique suivante dans un programme:
Requete fermeture 100% du BSO n°X
While 1:
Requete position BSO n°X
Requete PulseUP 1x BSO n°X
pause 1 seconde
endWhile
Résultat:
les lames s’orientent vers le haut par à-coups, puis le BSO monte par à-coups (comportement attendu), mais le retour de la requête sur la position reste à 100% en permanence. Ce qui fait qu’au bout de 50 boucles environ, le BSO est ouvert à mi-course, et le module X4VR le pense fermé (100%).
Je pense comprendre le problème: si la durée de l’impulsion représente moins de 1% du temps d’ouverture totale du BSO, l’arrondi se fait à 0.
Conséquences:
à partir d’un Pulse UP impossible de refermer le BSO: il faut l’ouvrir en entier puis le refermer (manœuvre qui prends donc plus de 3 minutes après 1 pulse UP, au lieu de 300ms pour un pulse DOWN…)
du coup dans mon cas impossible de les domotiser pour ajuster leur orientation en fonction du soleil.
Le problème a déjà été évoqué sur ce forum sans qu’une solution ait été trouvée à ma connaissance. Y-a-t’il du neuf?
De mon côté, je peux contourner le problème en définissant la position fermée avec des requêtes à 99% depuis le raspberry. En revanche ça ne marche plus avec une commande par l’interrupteur mural qui fera fermer systématiquement à 100% le BSO.
J’ai aussi essayé de mettre le fine gap adjust à 0 pour faire croire au module que le BSO s’ouvrait plus vite en début de course mais sans effet.
Je ne pense pas que ce soit un pb d’arrondi. Les pulses étant fait pour l’orientation et pas le déplacement (même si au final ils le font) ne sont pas comptabilisés comme des temps de déplacement et donc le X-4VR ne le voit pas.
essayez de mettre le BSO à la position souhaitée avec un SetVR puis orientez les lames avec un SetPulseUp (ou SetPulseDown selon). Le X-4VR devrait renvoyer la bonne position.
Justement c’est là qu’il y a un problème:
1- Je mets la position du BSO à 100% (BSO fermé et lames verticales)
2- Je fais un (ou plusieurs) SetPulseUP: les lames s’horizontalisent
3- A partir de là les commandes SetPulseDOWN ne marchent plus
J’ai fait une nouvelle expérience sur un BSO dont le temps d’ouverture est de 28 secondes.
J’ai utilisé le code schématique suivant sur mon raspberry Pi:
Requete fermeture 100% du BSO n°X
print(Requete position BSO n°X)
Requête PulseUP 5x BSO n°X
Pause 5 secondes
print(Requete position BSO n°X)
Si je défini le temps d’une pulse à 270ms (<1% du temps total d’ouverture), le code affiche:
100
100
Si je défini le temps d’une pulse à 290ms (>1% du temps total d’ouverture), le code affiche:
100
95
Ce qui montre bien que le problème vient des pulses trop courtes non comptabilisées dans la mesure de l’ouverture.
Si quelqu’un a une solution à ce problème, je prends!
Oui les valeurs récupérées par les requêtes collent visuellement à l’IHM (je n’ai que les jauges, pas de valeurs numériques).
De plus la même manip avec les BP conduit à la même conséquence:
1- Fermeture du volet par 1 appui court vers le bas
2- Orientation des lames à l’horizontal par un ou des appui(s) long(s) vers le haut.
3- Ensuite impossible de baisser les lames par appui court ou appui long vers le bas.
Ceci du coup avec une durée de pulse inférieure à 1% de la durée de montée: dans mon cas 300ms Vs 95s de montée. Si je règle les pulses à plus de 950ms, tout fonctionne nickel, sauf que l’orientation des lames ne sert plus à rien avec une telle durée!
J’ai trouvé une solution!! (à un problème que je suis le seul à avoir appremment! )
Version raspberry pi:
Surveillance toutes les 5 secondes de la position des BSO concernés par ce problème par des requêtes itératives du raspberry pi sur l’IPX.
Si un BSO est détecté à 100%, requête pour l’ouvrir à 99%, puis requête pour le fermer avec autant de pulses down que nécessaire.
Ainsi le BSO est physiquement fermé avec un X4VR qui le pense à 99%.
Du coup il accepte les PulsesUP ET les PulsesDOWN, par requêtes ou avec l’interrupteur mural!
La version avec scénarios et presets sur l’IPX doit pouvoir se faire, mais plus laborieuse.
Voilà, ce petit défaut des X4VR est corrigé, mais c’est quand même une usine à gaz.
Reste à voir si ce comportement peut me gêner dans certaines situations.
Je vais me baser là dessus pour mes besoins, mais suis toujours à la recherche d’une solution plus simple.
J’espère que les développeurs de GCE passent par ici de temps en temps, histoire qu’une mise à jour logicielle du X4VR puisse être étudiée pour ce point notamment.
Et avec un peu de chance ça servira à un autre geek à ne pas perdre des heures à comprendre ce qui se passe.
)