Wanneer ik via de Signum (Velbus app op gsm) een zonnewering naar x% stuur, dan gaat de screen naar x%
So far so good.
Wanneer ik dan de screen naar 100% stuur, dan gaat hij niet volledig open ! !
Hoe weet ik dat?
Wel, héél eenvoudig, twee keer drukken, héél kort na elkaar op de drukknop van glaspaneel die de screen ook controleerd. Bij de eerste druk, heel kort, ietsje naar beneden en bij de tweede druk naar boven en die tijd duurt veel langer dan het eventjes naar benden gaan. Dus de screen was niet volledig ingedrukken door het Signum bevel “100%”.
Hopelijk was deze uitleg duidelijk… …
Dus: Hoe komt het dat via de Signum de screen niet volledig indraait bij commando 100% ??
Als de screen/rolluik bijvoorbeeld 40 seconden nodig heeft om volledig naar boven te gaan, dan moet de tijd in Velbus op meer dan 40 seconden ingesteld zijn.
Als deze tijd in Velbus minder dan 40 seconden is ingesteld, zal de screen niet volledig naar boven gaan.
Deze waarde moet dus altijd iets hoger zijn dan de werkelijke tijd die de rolluik nodig heeft om volledig naar boven te gaan.
Zo heb ik begrepen wat je bedoelt. Ik hoop dat mijn antwoord je probleem kan oplossen.
Dank u wel voor de reactie.
Die tijd heb ik inderdaad ingesteld op basis van de looptijd van de screens.
Maar de vraag is nu natuurlijk: Hoe stel je die tijd CORRECT in ??
Is het inderdaad ietsje meer dan de échte looptijd om zeker te zijn dat ze via drukknoppen altijd volledig in of volledig uit staan.
Maar hoe bepaalt de module dan de nodige looptijd wanneer hij commando “30%” krijgt vanuit de Signum ???
Procent van wat trouwens?
Ik ga ervan uit dat het is van deze ingegeven looptijd want de module kent (denk ik) geen andere inputs.
Wil dat dus zeggen dat wanneer je een screen hebt met een werkelijke looptijd van 30 seconden hebt en je geeft 33 seconden in in VelbusLink, dan moet je met de app 27,27% ingeven om de screen op 30% te hebben?
want:
a) 30% van 30 seconden looptijd is 9 seconden
b) 9 seconden zijn 27,27% van de 33 seconden in VelbusLink
Gisteren nog iets anders vastgesteld:
a) 2 gelijke screens naast elkaar
b) gelijke tijd ingesteld in VelbusLink
c) beiden naar 30% via Signum
Guess what, ze staan verre van gelijk
Scheelt zeker zo’n 10 cm
Dan beiden terug naar 100% via de Signum, beiden zijn niet volledig in en hebben dezelde positie fout als dat ze bij 30% hadden.
Dan met de glaspanelen beide screens open laten gaan en ze gingen dan wel volledig open.
Dus ja, een woordje uitleg over die “%” sturing zou zeker welkom zijn.
Alvast bedankt hiervoor
Alain
Bijna 2 jaar geleden heb ik een project gedaan met 14 rolluiken. Ik heb de tijd van elk rolluik zelf gemeten en deze tijden in de programmatie ingegeven.
Normaal is er in elke slaapkamer maar 1 rolluik of screen. Bij de rolluiken in de woonkamer is het belangrijk dat ze op hetzelfde moment starten en stoppen.
Er waren 3 rolluiken in de woonkamer die op hetzelfde niveau moesten stoppen. Ik had geluk dat ik deze 3 rolluiken op bijna dezelfde hoogte kon laten stoppen want die 3 zelfde hoogte meeting was
Lutron producten enkel in UK, France, Italië en Spanje
Daarbij komt nog de vraag HOE die motoren worden aangestuurd. Zal 110% zeker niet gaan met een VMB2BLE-10 want die heeft geen encoder ingang. Stel je gebruikt de Lutron driver, hoe moet de VMB2BLE-10 dan zeggen dat die naar positie 30% moet ofwel x pulsen verdraaien?
Maar alvast bedankt voor de link naar de Engelse discussie op het forum.
Een mens voelt zich al vééééél minder alleen.
Kan/mag ik een suggestie tot verbetering aanbrengen ?
Via de historiek in HA ben ik er achter gekomen dat het procentueel aansturen van zonnewering (verder zw) gebaseerd is op de ingegeven looptijd in VelbusLink.
Een zw met een looptijd van 30s loopt bij een instelling van “15% open” een tijd van 25,5s.
Hoe nauwkeurig en met welke resolutie meet de module die tijd?
Aan de niet gelijke positie bij een gelijke vraag van 15% van twee naast elkaar geplaatste zw, zou ik durven zeggen seconde.
Voorstel 1: resolutie tijdmeting naar 0,1 seconde brengen
Voorstel 2: looptijd van een zw/gordijn/… … laten bepalen door module ipv dat de gebruiker iets moet instellen in VelbusLink
Ik ben ervan overtuigd dat beide voorstellen een significante verbetering is in positie bepaling door de VMB2BLE-10 modules.
Desalniettemin heb ik nog wat zitten pingelen met de “Total timeout” parameter van de module. Alhoewel dat dit 100% gelijke screens zijn heb ik de ene op 18 en de andere op 17 seconden moeten zetten om het kleinst mogelijke verschil te hebben bij positie 15% open. Mocht ik kunnen instellen op 0.1 seconde zou het wel goed / perfect te krijgen zijn.
Lijkt misschoen overbodig maar twee gelijke screens aan de voorkant van een huis die niet gelijk staan is niet echt mooi.
Je analyse klopt. De VMB2BLE werkt voor de positiebepaling volledig tijdsgebaseerd. De module kent dus niet de werkelijke positie van het screen, maar vertaalt de ingestelde looptijd naar 0–100%.
Als een screen bijvoorbeeld 20 seconden nodig heeft om volledig uit te rollen, dan komt 50% overeen met ongeveer 10 seconden looptijd. De resolutie van de VMB2BLE is daarbij 1 seconde.
In de praktijk kunnen twee identieke screens na verloop van tijd (of zelf vers uit de doos) toch iets verschillend lopen. Een motor of mechaniek (vooral de zijrails) kunnen wat stugger worden, waardoor de looptijd licht wijzigt. Het is daarom normaal dat je de timing wat moet bijregelen na verloop van jaren.
Veel moderne motoren hebben bovendien zelf een einddetectie, bijvoorbeeld op basis van vermogen of interne eindschakelaars. Je mag de VMB2BLE dan nog iets langer aansturen; de motor stopt zelf zodra de eindpositie bereikt is.
Wil je een exacte referentie bovenaan en onderaan, dan kan je ook met sensoren werken. De tussenposities blijven echter altijd tijdsgebaseerd.
Voor meerdere screens naast elkaar kan je dit ook praktisch oplossen met een scene. Een scene “50%” hoeft niet noodzakelijk elk screen letterlijk op 50% te zetten. Als ze bijvoorbeeld visueel beter uitlijnen met het ene screen op 49% en het andere op 51%, kan je dat gewoon zo opslaan in de scene.
Je voorstel om de tijdsresolutie fijner te maken begrijpen we zeker. Dat zou een fijnere afregeling mogelijk maken, maar het basisprincipe blijft tijdsgebaseerd en mechanische verschillen tussen motoren blijven dus mogelijk.
Dank u wel voor uw antwoord.
Absoluut mee eens dat geen twee motoren dezelfde snelheid draaien tenzij ze gesyncroniseerd zijn dmv bv encoders en servodrives, maar dat is een ander verhaal.
Wat u voorstelt met die scene is eigenlijk hetzelfde als wat ik gedaan heb met andere looptijd voor identieke screens maar een beetje anders
Echter 1% of 1sec resolutie is niet genoeg.
Ik hoor of lees wel of er ooit een betere resolutie mogelijk is in de toekomst.
!
