Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Bin nun über die Timer bzgl. Einheiten gestolpert. Man findet in der Doku leider widersprüchliche Angaben: mal Minuten, mal Sekunden, mal Millisekunden. Nachdem ich mir den Code angesehen habe vermute ich daß ms richtig sind.
Vielleicht lässt sich das im Help Bereich (dort findet man z.B. 5s als Beispiel, ansonsten keine weitere Einheitsangabe) und auch im Code (dort findet man Minuten im Kommentar) korrigieren, dann müssen andere darüber nicht stolpern.
Du hast Recht, das ist nicht konsistent. Ist mir gar nicht (mehr) aufgefallen, da man im Logikeditor nie den gesamten Kommentar an den Eingängen zu Gesicht bekommt und damit gar nicht sieht, dass dort "Minuten" dahinter steht.
Ich werde das korrigieren, danke für den Hinweis.
gaert: Könnte man die Eingänge eines LBS genauso vollständig einblenden, wenn man mit der Maus drüber fährt, wie die Ausgänge?
habe seit gestern EDOMI installiert, da mich Dein Baustein hier sehr interessiert und ich ihn ausprobieren wollte. Erstmal vielen Dank für das ausführliche Werk von Dir!
Bin nun über die Timer bzgl. Einheiten gestolpert. Man findet in der Doku leider widersprüchliche Angaben: mal Minuten, mal Sekunden, mal Millisekunden. Nachdem ich mir den Code angesehen habe vermute ich daß ms richtig sind.
Vielleicht lässt sich das im Help Bereich (dort findet man z.B. 5s als Beispiel, ansonsten keine weitere Einheitsangabe) und auch im Code (dort findet man Minuten im Kommentar) korrigieren, dann müssen andere darüber nicht stolpern.
Bin nun auf morgen gespannt wie sich das Ganze an meiner ersten Testjalousie verhalten wird, das Projekt ist eben live gegangen.
Und dann kommen noch so schöne Dinge wie Temperaturprogramm (innen, aussen und auch vorhergesagte maximale Temperatur abhängig beschatten oder auch nicht), die ich noch in die Logik mit einbauen möchte. Kann man ja aber gut über die vorhandenen Eingänge mit anhängen... Oder hast Du da ggf. auch vor den Baustein zu erweitern?
soeben habe ich die Version 2.8 veröffentlicht. Posting #1 ist aktualisiert, hier nochmal die Neuerungen und Changes:
1. Schrittweite der Lamellenverstellung
Mit dem Eingang E38 kann die minimale Lamellenverstellung in % angegeben werden. Oftmals ist es der Fall, dass die Raffstore-Antriebe kleine Schritte im Prozentbereich nicht sauber anfahren können. Mit diesem Wert kann die minimale Verstellung vorgegeben werden. Dabei wird steigende oder fallende Elevation korrekt gehandhabt, so dass die Lamellen jeweils erst wieder dann verstellt werden, wenn die Sonne im weiteren Verlauf hindurch scheinen würde.
2. Minimale / Maximale Elevation
Mit den Eingängen E36/E37 kann eine minimale bzw. maximale Elevation angegeben werden. Wenn der Helligkeitsschwellwert überschritten wird, die Elevation aber kleiner als E36 bzw. grösser als E37 ist, wird nicht beschattet. Diese Funktion kann bspw. verwendet werden, wenn ein Balkon zeitweise Schatten auf ein darunter befindliches Fenster wirft. Dann braucht dort der Behang nicht herunter gefahren werden.
3. Status über Edomi-Neustart
Mit dem Ausgang A10 steht der aktuelle interne Status des Behangs zur Verfügung. Wenn es wichtig ist, dass der Behang nach einem Edomi-Neustart nicht verfahren wird, sondern in der von Edomi errechneten Position von vor dem Edomi-Neustart verbleibt, kann dieser Ausgang über ein remanentes KO mit dem Eingang E39 verbunden werden.
4. Korrektur des Handling externer Behang-Manipulation
Ich konnte nun das Verhalten genauer analysieren.
...
Nun ist es bei meinem Jalousieaktor von MDT so, dass er jeweils auf die entsprechende Höhe fährt und einen fixen Winkel, welcher in ETS konfiguriert wird, einstellt. Danach wird ein Telegramm für die absolute Höhe und den Winkel versendet. In diesem Fall 255 für die Höhe und 255 für den Winkel.
In einem zweiten Schritt stellt er die Lamellen gem. dem absoluten Winkel, welcher im zweiten Telegramm von EDOMI geschickt wurde. Dabei verändert sich auch die Höhe leicht. Anschliessend gibt's wieder 2 Telegramme. 245 für die Höhe und 51 für den Winkel.
Ich habe auch MDT-Aktoren, erst wenn der Raffstore komplett die gesendeten Höhen und Winkel angefahren hat, werden die Statuswerte gesendet, hab damit keine Probleme.
Ich kann da nichts dazu sagen, da ich einen solchen Aktor nicht habe. Wenn es aber bei Christoph funktioniert, dann solltet ihr wohl mal die Aktor-Settings miteinander abgleichen. Evtl. liegt ja hier der Unterschied.
PS: Ich wäre euch sehr verbunden, wenn ihr dazu einen separaten Thread aufmachen würdet.
Habe vorgestern Abend auch mal den Release Candidate in Betrieb genommen, konnte es gestern tagsüber aber leider nicht beobachten, da ich nicht zuhause war. Was ich aber schon mal sagen kann: nachdem ich gestern Abend heimgekommen bin, standen die Lamellen zum ersten Mal alle perfekt waagrecht auf 50% (wie konfiguriert). Bisher waren die oft leicht schief - vermutlich deswegen, weil auch bei mir die 1 - 2% Fahrbefehle zwar den Aktorstatus aber nicht den physischen Lamellenwinkel beeinflusst haben und deswegen am Abend die Werte voneinander abgewichen sind. Die Minimalverstellung steht bei mir auch auf 5%.
Die automatische Deaktivierung des LBS bei manueller Verstellung habe ich nun auch mal bei einem Raffstore implementiert. Werde weiter beobachten und berichten.
Ich habe auch MDT-Aktoren, erst wenn der Raffstore komplett die gesendeten Höhen und Winkel angefahren hat, werden die Statuswerte gesendet, hab damit keine Probleme.
Nun ist es bei meinem Jalousieaktor von MDT so, dass er jeweils auf die entsprechende Höhe fährt und einen fixen Winkel, welcher in ETS konfiguriert wird, einstellt. Danach wird ein Telegramm für die absolute Höhe und den Winkel versendet. In diesem Fall 255 für die Höhe und 255 für den Winkel.
In einem zweiten Schritt stellt er die Lamellen gem. dem absoluten Winkel, welcher im zweiten Telegramm von EDOMI geschickt wurde. Dabei verändert sich auch die Höhe leicht. Anschliessend gibt's wieder 2 Telegramme. 245 für die Höhe und 51 für den Winkel.
Der LBS deaktiviert sich jedoch immer selber, da der zuerst gesendete Winkel natürlich ausserhalb der Toleranz liegt. :-(
Ich werde nun einen Verzögerungs LBS vor die beiden Eingänge schalten und testen ob die Beschattung damit korrekt funktioniert.
Mir ist jedoch unklar ob das Verhalten des MDT Aktors aussergewöhnlich ist oder ob ich andere Aktoren auch so verhalten. Falls dieses Verhalten der Standard ist wäre es wohl sinnvoll bereits im Beschattungs-LBS eine Verzögerung einzubauen.
Stimmt, die Toleranz müsste eigentlich passen.
Jedoch deaktiviert sich der LBS immer von selber, sobald die Storen unten sind.
Ich muss das Ganze morgen noch debugen
Wenn die 5% noch im Baustein sind, dan sollte das doch passen.
So ist es. Toleranz Höhe ist +/- 10% und Toleranz Winkel ist +/- 5%.
Aber wie oben schon geschrieben, wird der Eingang zwar als % beschrieben aber als Byte behandelt. Solange das noch nicht korrigiert ist, einfach einen Bytewert einspeisen oder den %Wert mit 2.55 multiplizieren.
Ich habe festgestellt, dass bei meinem Aktor, die Toleranzen nicht immer ausreichern.
Bspw. Behang auf 100% und Winkel auf 0% führt bei mir dazu, dass der Behang schlussendlich bei 96% steht, und dies liegt ausserhalb der Toleranz.
Es wäre toll, wenn die Toleranz konfigurierbar wäre.
Da alle Eingänge auf echten %-Werten basieren, würde ich auch hier die Eingänge in % verarbeiten, also die jeweilige Division durch 2.55 entfernen. Einverstanden?
[PHP] if ($currentHeightExternalRefreshed == 1 && $currentHeightExternal <> '' && ((($currentHeightExternal / 2.55) < $minHeight) || ($currentHeightExternal / 2.55) > $maxHeight)) {
setLogicElementVar($id, 3, ($currentHeightExternal / 2.55));
...
Somit rechnest du ja 0-255 in % um, was ja bereits am Eingang anliegen sollte gem. Beschreibung.
Ist hier die Doku oder der Code nicht korrekt?
Guter Punkt! Das ist in der Tat inkonsistent. Ist mir nicht explizit aufgefallen, da ich die Funktion aktuell nicht wirklich verwende und nur in meinem Test-Setup durchgespielt habe. Danke für den Hinweis!
Da alle Eingänge auf echten %-Werten basieren, würde ich auch hier die Eingänge in % verarbeiten, also die jeweilige Division durch 2.55 entfernen. Einverstanden?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: