Hallo,
ich habe eine Installation mit unidirektionalen Eltako-Aktoren (im Wesentlichen FSA12 für Lampen und FSB12 für Jalousien). In der aktuell im "Produktiveinsatz" befindlichen BSC-Software kann ich bei den unidirektionalen FSB12-Aktoren die Position der Jalousien bestimmen, unabhängig davon, ob ich die Jalousien über die Software oder über die physischen Schalter bediene. Trotz Recherchen im Forum und im Wiki habe ich keine Möglichkeit gefunden, das mit der aktuellen FHEM-Version umzusetzen.
In FHEM habe ich einen physischen Schalter für die Jalousie als Sensor für den Aktor wie folgt definiert:
define OG_Bad_Jalousie EnOcean 00123456
attr OG_Bad_Jalousie IODev TCM310_0
attr OG_Bad_Jalousie manufID 00D
attr OG_Bad_Jalousie room OG_Bad
attr OG_Bad_Jalousie shutTime 45
attr OG_Bad_Jalousie shutTimeCloses 50
attr OG_Bad_Jalousie stateFormat position
attr OG_Bad_Jalousie subType manufProfile
Obwohl die Daten des Sensors (d.h. des physischen Schalters) im Log korrekt erfasst werden, zeigen die Readings "state" und und "endPosition" immer "not_reached" und das Reading "position" immer 100 an. Einigen Einträgen in Foren zu diesem Thema entnehme ich, dass man das mit dem notify-Befehl korrigieren kann, allerdings nur in der Weise, dass die Position entweder 0 oder 100 ist.
Ich überlege nun, ob resp. wie man die tatsächliche Position der Jalousie mit FHEM ermitteln, d.h. berechnen kann (bei den FSB12-Aktoren gibt es ja leider keinen Rückkanal). Ich habe einige Programmiererfahrung, aber leider nicht mit Perl und schon gar nicht mit FHEM. Bevor ich mich an dieses "Projekt" mache, hätte ich gerne eine Rückmeldung der erfahrenen Nutzer / Entwickler, ob das im gegebenen Rahmen überhaupt möglich (und ggf. schon einmal versucht) ist. Meine Idee ist, dass jeder Tastendruck einen Timer auslöst, der während der shutTime periodisch die Position aktualisiert. In diesem Zeitraum müsste die Software natürlich auf neue Tastendruck-Ereignisse reagieren, d.h. wenn ich die Jalousie aus dem geöffneten Zustand mit "down" herunterfahre und nach 20% der shutTime erneut "down" drücke, sollte der Positionswert 20 sein. Bei weiteren Tastendrücken müsste die Position ausgehend von der letzten Position entsprechend aktualisiert werden.
Ist das grundsätzlich möglich?
Vielen Dank und viele Grüße
1. Wie die BSC-Software die Position ohne Quittungstelegramme korrekt berechnen soll, kann ich mir nicht vorstellen! Kann mir das mal jemand im Einzelnen beschreiben?
2. Ich würde die Rollos mit dem Befehl "position" fahren.
3. Vielleicht hilft schon (teilweise) der Standardtyp: Fhem mit "update" aktualisieren.
Hallo,
vielen Dank für die schnelle Antwort.
Ad 3) Ich aktualisiere regelmäßig und habe bereits die aktuelle Version (10_EnOcean.pm 6891 vom 5.11.2014).
Ad 2) Die Installation ist seit über 2,5 Jahren im Einsatz. In der Praxis werden bei uns (4-köpfige Familie) die Jalousien in mehr als 95% der Fälle durch physische Schalter gesteuert (außer bei Abwesenheit).
Ad 1) Da die BSC-Software als kommerzielles Produkt keine Open-Source-Lösung ist, kann ich natürlich nur Vermutungen über die Implementierung anstellen. Bei allen unidirektionalen Aktoren kann man sich natürlich grundsätzlich nie sicher sein, ob der "berechnete" state mit dem tatsächlichen übereinstimmt. Aber unter der Annahme, dass alle Signale korrekt empfangen werden, dürfte die Umsetzung prinzipiell nicht so schwierig sein. Ich versuche das mal an einem einfachen Beispiel zu skizzieren (bei unterstellter shutTime von 60 Sekunden):
position = 20
Tastendruck closes um 16:00:20
Tastendruck closes um 16:00:35 => Verändere position um (15 / shutTime) auf 45 (neue Position)
Tastendruck opens um 16:05:00 => Verändere position auf 0 (falls innerhalb von shutTime kein weiterer Tastendruck erfolgt)
Für die Verarbeitung benötigt man Zugriff auf die jeweils letzten beiden Kommandos ($LASTCMD ?) mit Zeitstempel (natürlich auch von anderen mit dem Aktor-Kanal verbundenen Schaltern). Außerdem muss nach einem Tastendruck für die Dauer der shutTime eine Verarbeitung in der Weise erfolgen, dass auf neue Tastendruck-Ereignisse reagiert wird und andernfalls die Position auf 0 oder 100 gesetzt wird. Geht das mit einem Timer?
Vielen Dank und viele Grüße
Grundsätzlich könnte es schon gelingen, für den Befehl stop eine Berechnung der Position auf Basis der Laufzeit vorzunehmen. Allerdings muss das Profil drei verschiedene Aktoren bedienen:
- ohne Quittungstelegramme
- mit grundlegenden Rückmeldungen closed, open und undefiniert
- zusätzlich mit Rückmeldung der zurückgelegten Laufzeit
Wenn jetzt noch die Schätzwerte auf Basis der Laufzeit dazukommen, macht die Sache nicht gerade übersichtlicher.
Weiterhin könnte man grundsätzlich den Aktor mit in Fhem eingelernten Sensoren (Tastern) verknüpfen und auf entsprechende Datentelegramme reagieren. Hier hat man aber wieder das Problem, dass diese Taster unterschiedlich als Richtungstaster oder Universaltaster im Aktor angelernt sein können. Man muss also zusätzlich noch zuverlässig ermitteln, welche Richtung tatsächlich gefahren wird.
Dann muss man nun berücksichtigen, dass die Position nur recht ungenau berechnet werden kann, z. B. wegen der Anlaufzeit der Motoren.
Letztlich gibt es noch Aktoren (FSB61), die einen lokalen Steuerangang haben. Wenn diese Aktoren kein Quittungstelegramm senden, hat man gar keine Chance.
Alles in Allem scheint es mir nicht sinnvoll, das Profil, das unterschiedliche Aktortypen abdeckt, noch komplexer zu machen, als es ohnehin schon ist. Das Ergebnis wird m. E. trotz allem Aufwands nicht wirklich zufriedenstellend sein.
Ich stimme zu, dass es wenig sinnvoll erscheint, das bestehende Profil zu erweitern. Ich dachte eher daran, (zunächst) ein eigenes Profil für den FSB12 anzulegen. Ich würde anbieten, mich in Perl und FHEM einzuarbeiten, einen Vorschlag zu entwickeln, intern zu testen und dann zur Diskussion zu stellen. Anschließend könnte dann geprüft werden, ob sich das Profil sinnvoll mit anderen konsolidieren ließe.
Gibt es dedizierte Dokumente für Entwickler? Oder ist die commandref.html (in Verbindung mit einer guten Perl-Dokumentation) ausreichend?
Auf die Funktionalität möchte ich nicht verzichten. Wir haben zehn FSB12-Aktoren für 18 Jalousien im Einsatz, viele davon stehen regelmäßig in Zwischenstellungen (insbesondere im Sommer für die Verschattung). Eine Umrüstung auf FSB14-Aktoren ist mir aktuell zu früh und zu teuer.
Hier wird niemand daran gehindert, sich einzuarbeiten und gute neue Lösungen einzubringen. Viel Erfolg. Als Informationsquelle gibt's das Programm einschl. commandref, das Forum und das Wiki.
Hallo zusammen,
ich habe die erste Stufe meines Projekts abgeschlossen und möchte allen Interessierten meine Umsetzung zur Verfügung stellen. An Feedback und Verbesserungsvorschlägen bin ich natürlich sehr interessiert. Die Funktionsfähigkeit ist systembedingt bei unidirektionalen Aktoren nicht so zuverlässig wie bei bidirektionalen Aktoren, da es sich nur um berechnete Werte handelt. Insbesondere bei kurz aufeinanderfolgenden Tastendrücken "verschluckt" sich das Programm gerne und zeigt einen falschen Zustand an. Wenn die Jalousien "out of sync" sind, hilft es zumeist, die Jalousien vollständig zu öffnen oder zu schließen und neu anzufangen.
Die Lösung habe ich für meine Installation getestet, die unidirektionale FSB12-Aktoren zur Jalousiensteuerung verwendet. Als Aktoren werden Richtungstaster (zumeist als Doppelwippen) verwendet. Ziel der ersten Stufe ist es gewesen, zunächst nur die Position und Zustände auszulesen. In einem zweiten Schritt möchte ich die physischen Schalter mit den virtuellen FHEM-Schaltern kombinieren.
Insgesamt besteht die aktuelle Umsetzung aus den folgenden Komponenten:
1) Hilfsfunktion "UpdatePosition", die ich in die Datei 99_myUtils.pm ausgelagert und diesem Eintrag angehängt habe. Diese Funktion ist das Kernstück, da sie aus den Readings und Attributen die Position der Jalousie berechnet.
2) Für die Schalter (nachfolgend am Beispiel einer Doppelwippe) wird pro Kanal das Attribut shutTime benötigt (also z.B. shutTimeA und shutTimeB).
3) Das Reading runtime misst die Zeit in (ganzen) Sekunden seit dem letzten Tastendruck.
4) Über notify wird die Hilfsfunktion UpdatePosition aufgerufen, wenn eine Taste gedrückt wird.
5) Schließlich wird noch eine Zeitschaltung benötigt, um die Jalousien in den "Endzustand" (open oder closed) zu versetzen, falls während der Gesamtlaufzeit kein Schalter mehr gedrückt wird. Ich habe das über ein DOIF realisiert. Als Verzögerung (wait) muss jeweils die Laufzeit der Jalousien angegeben werden.
Zusammengefasst sieht das am Beispiel einer Doppelwippe so aus:
define OG_AZ_Jalousien EnOcean 012345678
attr OG_AZ_Jalousien IODev TCM310_0
attr OG_AZ_Jalousien eventMap A0:opens AI:closes B0:opens BI:closes
attr OG_AZ_Jalousien manufID 00D
attr OG_AZ_Jalousien room OG_AZ
attr OG_AZ_Jalousien shutTimeA 60
attr OG_AZ_Jalousien shutTimeB 40
attr OG_AZ_Jalousien subType switch
attr OG_AZ_Jalousien userReadings runtimeA:channelA difference { time_str2num(ReadingsTimestamp("OG_AZ_Jalousien", "channelA",0));; }, \
runtimeB:channelB difference { time_str2num(ReadingsTimestamp("OG_AZ_Jalousien", "channelB",0));; }
define OG_AZ_Jalousien_UpdatePosA notify (OG_AZ_Jalousien:channelA.*) { UpdatePosition($NAME, $EVENT, "A");; }
define OG_AZ_Jalousien_UpdatePosB notify (OG_AZ_Jalousien:channelB.*) { UpdatePosition($NAME, $EVENT, "B");; }
define OG_AZ_Jalousien_SyncA DOIF ([OG_AZ_Jalousien:stateFSB12A] eq "opens") (setreading OG_AZ_Jalousien positionA 0, setreading OG_AZ_Jalousien stateFSB12A open) \
DOELSEIF ([OG_AZ_Jalousien:stateFSB12A] eq "closes") (setreading OG_AZ_Jalousien positionA 100, setreading OG_AZ_Jalousien stateFSB12A closed)
attr OG_AZ_Jalousien_SyncA do always
attr OG_AZ_Jalousien_SyncA wait 60:60
define OG_AZ_Jalousien_SyncB DOIF ([OG_AZ_Jalousien:stateFSB12B] eq "opens") (setreading OG_AZ_Jalousien positionB 0, setreading OG_AZ_Jalousien stateFSB12B open) \
DOELSEIF ([OG_AZ_Jalousien:stateFSB12B] eq "closes") (setreading OG_AZ_Jalousien positionB 100, setreading OG_AZ_Jalousien stateFSB12B closed)
attr OG_AZ_Jalousien_SyncB do always
attr OG_AZ_Jalousien_SyncB wait 40:40
Die BSC Software GFVS berechnet das nur über die Zeit, auch bei der Serie 14. Woher soll auch ein FSB14 wissen wo der Rolladen ist, da der Motor keine Position sendet?
Deswegen ist es ja auch wichtig, in der GFVS Software, die Rolläden mit der Zeit "einzulernen"
Hallo thghh,
stimmt, darüber habe ich noch nicht nachgedacht, weil ich keine Aktoren der 14er-Reihe im Einsatz habe. Es ist ein guter Grund mehr, die Umrüstung aufzuschieben ...
Hallo,
ich habe nun auch die zweite (und letzte) Stufe meines Projekts beendet und die physischen Schalter mit den virtuellen FHEM-Schaltern kombiniert.
Die virtuellen FHEM-Schalter habe ich gemäß den sehr guten Anleitungen im Wiki (http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Teach-In_als_Gateway.2FPC-Steuerung (http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Teach-In_als_Gateway.2FPC-Steuerung) und http://www.fhemwiki.de/wiki/EnOcean-FSB12-RS485-Bus-Schaltaktor-2-Kanal-Beschattungselemente-Rollladen (http://www.fhemwiki.de/wiki/EnOcean-FSB12-RS485-Bus-Schaltaktor-2-Kanal-Beschattungselemente-Rollladen)) in die FSB12-Aktoren eingelernt.
Die Synchronisation der Stati (Positionen) habe ich einfach über ein wechselseitiges notify gelöst (http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Physischer_EnOcean-_und_virtueller_Fhem-Schalter_zu_einem_Device_zusammenfassen (http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Physischer_EnOcean-_und_virtueller_Fhem-Schalter_zu_einem_Device_zusammenfassen)). Ich habe ebenfalls damit experimentiert, die beiden zu einer structure zusammenzufassen, bin damit aber nicht sehr erfolgreich gewesen (bei Lichtschaltern funktioniert das hingegen gut).
Zusammengefasst sieht die vollständige Lösung damit wie folgt aus:
#Physischer Schalter (Doppelwippe mit Richtungstastern)
define OG_AZ_Jalousien EnOcean xxxxxxxx
attr OG_AZ_Jalousien IODev TCM310_0
attr OG_AZ_Jalousien eventMap A0:opens AI:closes B0:opens BI:closes
attr OG_AZ_Jalousien manufID 00D
attr OG_AZ_Jalousien room OG_AZ
attr OG_AZ_Jalousien shutTimeA 60
attr OG_AZ_Jalousien shutTimeB 40
attr OG_AZ_Jalousien subType switch
attr OG_AZ_Jalousien userReadings runtimeA:channelA difference { time_str2num(ReadingsTimestamp("OG_AZ_Jalousien", "channelA",0));; }, \
runtimeB:channelB difference { time_str2num(ReadingsTimestamp("OG_AZ_Jalousien", "channelB",0));; }
define OG_AZ_Jalousien_UpdatePosA notify (OG_AZ_Jalousien:channelA.*) { UpdatePosition($NAME, $EVENT, "A");; }
define OG_AZ_Jalousien_UpdatePosB notify (OG_AZ_Jalousien:channelB.*) { UpdatePosition($NAME, $EVENT, "B");; }
define OG_AZ_Jalousien_SyncA DOIF ([OG_AZ_Jalousien:stateFSB12A] eq "opens") (setreading OG_AZ_Jalousien positionA 0, setreading OG_AZ_Jalousien stateFSB12A open) \
DOELSEIF ([OG_AZ_Jalousien:stateFSB12A] eq "closes") (setreading OG_AZ_Jalousien positionA 100, setreading OG_AZ_Jalousien stateFSB12A closed)
attr OG_AZ_Jalousien_SyncA do always
attr OG_AZ_Jalousien_SyncA wait 60:60
define OG_AZ_Jalousien_SyncB DOIF ([OG_AZ_Jalousien:stateFSB12B] eq "opens") (setreading OG_AZ_Jalousien positionB 0, setreading OG_AZ_Jalousien stateFSB12B open) \
DOELSEIF ([OG_AZ_Jalousien:stateFSB12B] eq "closes") (setreading OG_AZ_Jalousien positionB 100, setreading OG_AZ_Jalousien stateFSB12B closed)
attr OG_AZ_Jalousien_SyncB do always
attr OG_AZ_Jalousien_SyncB wait 40:40
# Die nachfolgenden beiden Zeilen synchronisieren die Positionen mit den beiden virtuellen FHEM-Schaltern
define OG_AZ_Jalousien_SyncPosA notify (OG_AZ_Jalousien:positionA.*) setreading OG_AZ_Jalousie_Ost_TCM position $EVTPART1
define OG_AZ_Jalousien_SyncPosB notify (OG_AZ_Jalousien:positionB.*) setreading OG_AZ_Jalousie_Nord_TCM position $EVTPART1
#Virtueller FHEM-Schalter
define OG_AZ_Jalousie_Nord_TCM EnOcean xxxxxxxx
attr OG_AZ_Jalousie_Nord_TCM IODev TCM310_0
attr OG_AZ_Jalousie_Nord_TCM manufID 00D
attr OG_AZ_Jalousie_Nord_TCM model FSB12
attr OG_AZ_Jalousie_Nord_TCM room OG_AZ
attr OG_AZ_Jalousie_Nord_TCM shutTime 40
attr OG_AZ_Jalousie_Nord_TCM shutTimeCloses 45
attr OG_AZ_Jalousie_Nord_TCM stateFormat {sprintf("%.2f",ReadingsVal("OG_AZ_Jalousie_Nord_TCM","position",0))}
attr OG_AZ_Jalousie_Nord_TCM subType manufProfile
attr OG_AZ_Jalousie_Nord_TCM webCmd position
# Die nachfolgende Zeile synchronisiert die Position mit dem physischen Schalter
define OG_AZ_Jalousie_Nord_TCM_SyncPos notify (OG_AZ_Jalousie_Nord_TCM:position.*) setreading OG_AZ_Jalousien positionB $EVTPART1
Falls zwei physische Schalter und ein virtueller FHEM-Schalter zu einer Dreiergruppe zusammengefasst werden müssen, funktioniert das mit einer notify-Kette, z.B. indem der physische Schalter A mit dem physischen Schalter B synchronisiert, der physische Schalter B mit dem virtuellen FHEM-Schalter synchronisiert und der virtuelle FHEM-Schalter wiederum mit dem physischen Schalter A synchronisiert (die Hilfsvariable stateFSB12 wird nicht synchronisiert, weil sie für die Steuerung im Frontend nicht relevant ist).
Hallo,
das ist eine schöne Erweiterung, um die Rollo-Zustände auch sauber darzustellen. Jetzt kann ich ja evtl. doch irgendwann mein GVFS ablösen :)
Allerdings habe ich ein kleines Problem. Die shutTimeA und shutTimeB bei dem physischen Schalter werden nicht gezogen (bzw. die fliegen vorher raus wg. "unknown attribute", es gibt beim EnOcean Schalter scheinbar nur eine shutTime, nicht aber shutTimeA/B ...) ...
Mache ich was falsch? Du definierst die shutTime ja auch noch bei den virtuellen Schaltern, das wird aber nicht im UpdatePosition ausgewertet. Daher geht er bei mir immer von 60s shutTime aus und das passt natürlich nicht.
Danke!
Schöne Grüße,
Jogi
Hattest Du hierfür Änderungen in der 10_EnOcean.pm vorgenommen?
Zitat2) Für die Schalter (nachfolgend am Beispiel einer Doppelwippe) wird pro Kanal das Attribut shutTime benötigt (also z.B. shutTimeA und shutTimeB).
Danke und schöne Grüße,
Jochen
Hallo Zusammen,
eigentlich mag ich keine Eigengespräche, aber nun gut ... ich habs selbst rausgefunden. In der 99_myUtils.pm war ein Fehler. Und zwar wurde dort die runTime mit der shutTime per 'lt' verglichen und nicht per '<' ... daher waren meine Laufzeiten von 2-9 Sekunden, die ich zum Testen verwendet habe, immer gt meine shutTime (von 15) ...
Also es läuft bei mir, allerdings mit kleinen Änderungen:
- in der Definition vom physikalischen Schalter habe ich shutTimeA und shutTimeB über ein userattr hinzugefügt:
attr EG_AZ userattr shutTimeA shutTimeB
attr EG_AZ shutTimeA 17
attr EG_AZ shutTimeB 17
- in der 99_myUtils.pm habe ich die oben erwähnte Änderung vorgenommen:
< if ($myStateFSB12 eq $myCurrentStateFSB12 && $myRuntime lt $myShutTime) {$myStateFSB12 = "stopped"}
---
> if ($myStateFSB12 eq $myCurrentStateFSB12 && $myRuntime < $myShutTime) {$myStateFSB12 = "stopped"}
Damit läuft es jetzt bei mir "fast" synchron zum GFVS ...
Danke und schöne Grüße,
Jogi
Hallo,
ich nutze die Funktionen von CountAlmasy mit der Modifikation von SpaceMan seit einem Jahr ohne Probleme für die Positionsbestimmung der Rolläden mit FSB12. Jetzt habe ich mal wieder ein FHEM Update eingespielt und stelle danach fest, dass nach dem Betätigen des Tasters (1. Tastendruck zum starten und 2. Tastendruck um den Rollo anzuhalten) zunächst die Position korrekt berechnet und angezeigt wird, dann aber nach Ablauf des Timers die Position immer auf open oder closed gesetzt wird. Das sollte doch eigentlich nur erfolgen wenn der 2. Tastendruck ausbleibt und das Rollo in Endposition fährt. Hat jemand das gleiche Problem bzw. eine Idee woran das liegen könnte?
Viele Grüße,
Oli
Hi,
FHEM hat bei mir bisher GVFS noch nicht abgelöst, daher ist es mir wohl bisher nicht aufgefallen ... ich vermute, daß es irgendwas mit Änderungen im DOIF Modul zu tun hat ...
Bisher sah der Code ja so aus:
([Phys_EG_AZ:stateFSB12A] eq "opens") (setreading Phys_EG_AZ positionA 0, setreading Phys_EG_AZ stateFSB12A open)
DOELSEIF ([Phys_EG_AZ:stateFSB12A] eq "closes") (setreading Phys_EG_AZ positionA 100, setreading Phys_EG_AZ stateFSB12A closed)
Seltsamerweise triggert der trotzdem, auch wenn Phys_EG_AZ:stateFSB12A den Wert "stopped" hat ... habe mir testweise damit geholfen, folgende Zeile an den Block anzuhängen:
DOELSEIF ([Phys_EG_AZ:stateFSB12A] eq "stopped")
Ich denke, das sollte man kontrollieren, ob es wirklich am DOIF liegt ... habe da vorher nie so tief reingeschaut ...
Hi,
die Anpassung des DOIF hat funktioniert (warum auch immer das vorher mal funktioniert hat), allerdings habe ich dann festgestellt dass das triggern des userReadings runtime ebenfalls nicht mehr funktioniert. Nach ein Änderung des Moduls im April muss nun ein .* hinter das reading/trigger. Damit funktioniert die Positionserkennung dann wieder wie gewohnt...
attr HSw_Arbeitszimmer userReadings runtimeB:channelB.* difference { time_str2num(ReadingsTimestamp("HSw_Arbeitszimmer", "channelB",0));; }
Viele Grüße,
Oli
Hallo zusammen,
tolle Erweiterung.
Ich habe bisher testweise 2 Rollos einer Doppelwippe mit Positionserkennung umgesetzt. Das funktioniert soweit sehr gut. Ich habe aber beobachtet, das wenn ich an der Doppelwippe den Rollo bis in oberste Position fahren lasse, das diese Position vom virtuellen FHEM-Schalter nicht aktualisiert wird. Liegt es am notify des Hardwareschalters
define EnO_switch_XXXXXXX_SyncPosA notify (EnO_switch_XXXXXXX:positionA.*) setreading eg_kue_Rollo position $EVTPART1
oder muß ich an einer andere Stelle suchen?
Ergänzung: nachdem ich diese Stelle neu definiert hatte, scheint es nun zu funktionieren
define OG_AZ_Jalousien_SyncA DOIF ([OG_AZ_Jalousien:stateFSB12A] eq "opens") (setreading OG_AZ_Jalousien positionA 0, setreading OG_AZ_Jalousien stateFSB12A open) \
DOELSEIF ([OG_AZ_Jalousien:stateFSB12A] eq "closes") (setreading OG_AZ_Jalousien positionA 100, setreading OG_AZ_Jalousien stateFSB12A closed)
attr OG_AZ_Jalousien_SyncA do always
attr OG_AZ_Jalousien_SyncA wait 60:60
define OG_AZ_Jalousien_SyncB DOIF ([OG_AZ_Jalousien:stateFSB12B] eq "opens") (setreading OG_AZ_Jalousien positionB 0, setreading OG_AZ_Jalousien stateFSB12B open) \
DOELSEIF ([OG_AZ_Jalousien:stateFSB12B] eq "closes") (setreading OG_AZ_Jalousien positionB 100, setreading OG_AZ_Jalousien stateFSB12B closed)
attr OG_AZ_Jalousien_SyncB do always
attr OG_AZ_Jalousien_SyncB wait 40:40
Allerdings wird die Position im Webfrontend die Position 0 zeitverzögert angezeigt. Kann das jemand bestätigen?
Vielen Dank für die Hilfe.
Gruß Ingo
Hi Ingo,
die Zeitverzögerung kommt daher, dass nach einem einzigen Tastendruck ein Timer abläuft, der dann nach Ablauf (wenn die Taste kein weiteres Mal gedrückt wurde) die Position entweder auf 0 oder 100 setzt (DOIF ... wait 40:40). Die Zeit für den Timer sollte größer als die Zeit sein die der Rolladen benötigt um komplett herunter zu fahren. Wird in der Zwischenzeit ein weiters Mal auf die Taste gedrückt (und der Rollo somit mittendrin angehalten) wird die Laufzeit sofort ermittelt und die Position entsprechend berechnet.
Viele Grüße,
Oli
Hi Oli,
Danke für die Erläuterung
Gruß