@AlexTrovato on peut en parler ici en français car j’ai l’impression qu’on ne se comprend pas en anglais là bas
En fait le problème c’est de stocker l’information sur les capacités du volet roulant.
Imaginons 3 marques de volets hypothétique :
La première est contrôlée par une télécommande avec 3 boutons: ouvrir les volets à 100%, ouvrir à 50%, et ouvrir à 0% (position fermé)
La deuxième est contrôlée par une télécommande avec un bouton up et un bouton down.
La troisième est contrôlée par une télécommande avec 5 boutons: 0%, 25%, 50%, 75%, 100%
Question:
Comment modéliser ça dans Gladys ?
Quand je dis « ça », c’est pas le résultat final, oui le résultat final ça peut-être un integer de 0 à 100 qui correspond au pourcentage d’ouverture du volet, je parle de l’information qui va dire « ce volet roulant à ce fonctionnement »
Parce que dans l’UI, chaque volet aura un type de bouton différent, mais il faut bien qu’il y a quelques part en DB cette information
Une possibilité que je vois, c’est de faire au cas par cas, on créé des couples category/type pour chaque type de volets. Je pense que c’est la solution la plus proche de la philosophie de Gladys 4
Mais il y a peut-être d’autre façon de faire, et surtout à voir comment cette question pourrait s’appliquer à d’autres problématiques.
J’espère que tu vois ce que je veux dire Bonne idée en tout cas de regarder comment font les autres !
Ok je comprends mieux.
En premier jet, je dirais avoir un device category par “systeme de volet”. Mais ça risque un peu lourd.
En pensant bien que cela concernera plusieurs type de device.
Sinon un système de “param / options” sur le device feature.
Du coup un volet roulant aurait un seul device_feature ? et ce device_feature aurait la category + type correspondant à son usage, et on stockerait dans le state un integer de 0 à 100 correspondant au niveau du volet ? ça peut le faire.
C’est vrai que c’est peut-être un peu lourd, mais je préfère cette approche initial tant qu’on a pas trop d’expérience avec les volets roulants, plutôt que de commencer avec le l’ultra modulaire sans comprendre et faire n’importe quoi
Je préfère aller de l’ultra spécifique vers le généraliste plutôt que l’inverse.
Une question qui me vient à l’esprit, c’est comment du coup expliquer dans l’UI dans le service MQTT à quoi correspond chaque feature ? vu qu’on display que le nom, il faut que dans le nom ça soit assez explicite pour qu’on explique « alors cette feature correspond au volet 0, 50, 100% » ^^ une idée ?
Salut,
En effet, c’est souvent comme ça, avec une phase d’apprentissage.
Le problème avec çe principe, c’est que les temps de montée/descente ne sont pas forcément les mêmes.
La descente est plus rapide que la montée car la masse du VR l’entraîne à la descente.
Cependant, ça se joue à pas grand chose.
Dans Domoticz il y a un paramètre Motor Operation Time
C’est ce que j’ai chez moi et c’est ce qui est le plus rependu du point de vu interrupteur manuel (modèles d’interrupteurs).
Par ailleurs, il existe des modèles d’interrupteurs connectés (4e gen+) qui gèrent le pourcentage d’ouverture à partir d’une temporisation.
L’idée est de renseigner les temps de montée/descente et ensuite on peut, en fonction de ces temps et du sens de la commande, ouvrir/fermer partiellement le volet.
Dans l’application, on a 2 types de commandes (up/stop/down et slider):
j’ai développé un petit montage ESP8266 pour gérer les volets roulants avec un inter 3 positions ou via Gladys. Au départ j’initialise les temps de monté et descente. J’envoie à chaque changement d’état du volet la position en %.( sur mon montage c’est inversé 100% c’est fermé - 0% ouvert)
Je pense que ce n’est pas à Gladys de calculer la position du volet mais à l’inter de renvoyer la position
Exemple:
je demande via Gladys d’ouvrir le volet à 25% mais je décide, vu l’ensoleillement, à l’aide de l’inter mural de l’arrêter à 50%.
Je presse le bouton stop.
Le temps que Gladys reçoive l’information de l’arrêt, le calcul de Gladys sera erroné.
Il y aura un décalage entre la position réelle et la position estimé par Gladys.
Depuis 9 mois le sujet n’a pas bougé, vous êtes toujours à la recherche d’une solution ?
Chez jeedom c’est simple Up/Stop/Down, le pourcentage ça ne fonctionne pas bien donc pas intégré de base ! en effet le pourcentage est calculé en fonction du temp que le volet mettra à parcourir un point à l’autre … sauf que tout les volets sont différent même si utilisé avec le même moteur.
J’ai peut être pas compris sur quoi cette fonction est bloqué ?
Juste une question de temps je pense, de mon côté sur les 9 derniers mois je me suis concentré sur les fonctionnalités les plus demandées (multi-utilisateurs, multi-dashboard, scènes, zones, présence, intégration Google Home, enfin tous les devs de cette année 2021 quoi ), comme cette fonctionnalité n’avait que 2 votes elle était nécessairement moins prioritaire
Après je suis toujours ouvert au débat si quelqu’un veut reprendre une réflexion/un développement.
Je te conseille plusieurs vidéos que j’ai fais à ce sujet:
La présentation technique de Gladys 4:
Un live coding la semaine dernière:
ça peut te donner une idée du projet
Après, le mieux ça reste de se lancer une instance en locale, tu as tout le front dans le dossier « front », et tout le back dans le dossier « server » (C’est du Node.js)
Rien de bien compliqué, et je suis toujours là pour donner un coup de main si tu as du mal !
Pour ceux sans retour, il faudrait pouvoir paramétrer dans Gladys :
un temps max de descente totale
un temps max de descente partielle (quand on voit les tirets)
un temps max de montée totale
un temps à 50% de la montée partielle
un temps max de montée partielle(quand on voit les tirets)
un temps à 50% de la descente partielle
Au niveau algo cela donnerait :
Ouvrir à 100% = tps max montée totale + 2s(à ajuster) puis reinit position à 100%
Fermer à 100% = tps max descente totale + 2s(à ajuster) puis reinit position à 0%
En partant d’une ouverture ou d’une fermeture totale on a toujours une position réinitialisée exacte
Après si on veut une ouverture à X% c’est temps à 50% + ou - (temps à 50%/50) * la position à atteindre en % on obtient une position approximative qui devrait être assez fiable non ?
Bonjour ici,
on sait si le sujet avance ? s’il est en cours de traitement par quelqu’un ?
Je vois avec le service z2m que la demande s’intensifie, avec des modèles avec OPEN/STOP/CLOSE (3 actions).
@AlexTrovato Personne ne travaille sur ce sujet à ma connaissance.
A mon avis, on perd rien à se lancer dans un développement pour déjà un type de volet roulant (Open/Stop/Close par exemple oui), pas la peine de vouloir tout faire, c’est déjà cool d’avoir un type.
Bonne idée en tout cas de regarder comment font les autres !
