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.
so, ihr habt es nicht anders gewollt! Version 0.1 ist online.
Nach doch recht aufwändigem StepByStep-AuskommentierenUndEdomiNeuStarten habe ich den Fehler gefunden. Interessanterweise bestand dieser auch schon im ursprünglichen Beschattungsbaustein und ist somit auch dort schon korrigiert.
Der Text im ersten Posting ist noch nicht komplett angepasst, dafür bin ich jetzt zu müde. Kommt also noch. Also immer her mit dem Feedback und viel Spass beim testen des Bausteins.
hier ein kurzer Zwischenstand. Es wird leider noch etwas dauern bis zum ersten Release, da ich am Baustein irgendetwas gröberes kaputt gemacht habe.
Wenn ich ihn in Edomi aktiviere, schmiert die Logikengine komplett ab und Edomi startet neu. Somit ergibt das einen Endlos-Loop und ich habe bis jetzt noch nicht herausgefunden, woran das liegt. Selbst wenn ich den Code des aktivierten LBS in der Entwicklungsumgebung öffne, wird mir keinerlei Problem angezeigt. Ich hatte einen solchen Effekt schonmal mit falschen Funktionsnamen und mehrfacher Verwendung des LBS, das ist hier aber nicht der Fall, da alle Funktionsnamen korrekt modifiziert wurden und der Baustein in meiner Dev-Umgebung auch nur ein einziges Mal verwendet wird. Sehr seltsam.
Da mit dem LBS "Beschattungssteuerung-NG" meine Raffstoren jetzt einwandfrei laufen (Kompliment an starwarsfan !!!), habe ich begonnen an den ersten beiden Fenstern mit Rollos eben diesen LBS ein zu setzen (halt ohne die Winkelpositionen). Bevor ich jetzt weitermache, meine Eingangs gestellte Frage
starwarsfan
Ich hätte auch noch ein Featurewunsch wenn möglich.
In einem anderen Rollladen LBS gibt es die Funktion per Flag nur noch größere Werte auszugeben und kleinere zu ignorieren.
Sprich wenn ich am frühen Abend die Funktion aktiviere gehen die Rollladen nur noch abwärts aber alle Höhenänderungen < Ist werden verworfen.
Der Usecase bei mir währe:
1. Rollladen im Flur wird während wenn die Kinderschlafen (Mittags und abends) in Stellung 80% gefahren damit es nicht zu hell ist. Wenn jetzt tagsüber die Beschattung aktiviert war fährt abends der Rollladen eventuell wieder hoch weil keine Sonne mehr da ist nur um kurz später wieder runter zu fahren.
2. Ähnliches Szenario wenn Sonnenuntergang ist und wir die Rollläden zwecks Blendschutz runterfahren (über die Beschattungsfunktion), dann geht die Sonne unter es ist aber noch zu hell für Dämmerung. Also gehen die Rollläden hoch nur um kurze Zeit später dann wieder komplett zu zu fahren was eigendlich unnötig ist...
Man könnte das jetzt extern abfangen aber dann deaktiviert sich eventuell der LBS ständig weil Ist und Soll Position zu weit auseinander sind.
super Sache der Rolladenbaustein, da könnte ich schwach werden. Meine Beschattungssteuerung ist bisher sehr einfach gestrickt.
Was ich bei bisherigen Bausteinen vermisse ist die Gruppensteuerung.
Heisst: Soll ein einzelner Rollo, zusammen mit allen anderen Rollos, in der Dämmerung schliessen oder am Morgen auffahren, getrennt für runter und rauf. In der Visu kann ich das - für jedes Fenster extra - einstellen.
Beispiel: Jemand im Haus will einen bestimmten Rollo nicht in der Automatik (2 Lux runter, 80 Lux rauf) haben, dann geht er zur Visu und nimmt den Rollo raus. Dann ist manuell angesagt, nur Dinge wie Regenautomatik oder Wind laufen noch.
Die Gruppensteuerung kann auch per Taster ausgelöst werden, dann fahren alle in der Gruppe rauf oder runter.
Das sieht so aus: 2017-06-29 14_37_40-EDOMI · Administration.png
es ist gar nicht so trivial die alle so zu steuern das Sie sich nicht gegenseitig "übersteuern".
Genau das ist der springende Punkt. Damit habe ich ganz an Anhang bereits ausführlich experimentiert und mich schlussendlich dagegen entschieden. Das ganze funktioniert dann am reibungslosesten, wenn der Baustein die volle Kontrolle über den Behang hat.
Sobald es darum geht, das irgendwie zwischen mehreren Bausteinen zu synchronisieren, wird's hässlich. Zumal die Interaktion und jeweiligen Sonderfälle auch bei jedem anders sind.
Wozu? Das macht in meinen Augen keinen Sinn und nur damit Logikseiten übersichtlich aussehen einen weiteren Baustein zu pflegen, dafür ist mir die Zeit dann doch zu schade.
Der Baustein wird weitestgehend mit dem 19000145er identisch sein, da die grundsätzliche Status-Logik die gleiche ist. Nur werden sämtliche Winkelein- und -ausgänge entfallen und dafür die Sonderfälle wie Schlitzposition etc. gehandhabt werden können. Die Funktionalität welche man nicht braucht, wird nicht verwendet resp. einfach deaktiviert. Damit hat man sogar für später aufkommende Wünsche schon alles vorbereitet, also wenn bspw. auf einmal doch die Dämmerungshandhabung gebraucht wird.
Also Dämmerung im gleichen Baustein währe schon wichtig...
Ich habe im moment ein Konstrukt aus mehreren Bausteinen pro Fenster (auch wegen meines "Reflexionen" Problems) und es ist gar nicht so trivial die alle so zu steuern das Sie sich nicht gegenseitig "übersteuern".
Was für mich wichtig währe ist eine minimale Behangverstellung wie es jetzt bei der Winkelverstellung möglich ist.
Bei mir bewegen sich mit dem 145er nämlich öfters mal die Rollläden um nur wenige cm so das es eigendlich nur "laut knallt" (Motor fährt an und stopped gleich wieder).
Wenn der LBS dann noch den Neutralstatus hat und der bei Triggern auf E1/E2 weitergegeben wird bin ich fast wunschlos glücklich!
Nur eine Anregung
Die derzeit möglichen 69 Eingänge des NG könnten so manchen Neuling abschrecken und mir z.B. würde die reine Beschattungssteuerung vollkommen ausreichen.
Das debugging wird ja für dich auch nicht unbedingt leichter mit so vielen Möglichkeiten. Also könnte man vielleicht die Gelegenheit nutzen um den Baustein aufzusplitten...
Wäre toll wenn Du da gleich eine Light-Version (alternativ?) bauen könntest, also ein Baustein der wirklich nur die Beschattung regelt.
Würde meine Logikseite deutlich übersichtlicher machen....
Wozu? Das macht in meinen Augen keinen Sinn und nur damit Logikseiten übersichtlich aussehen einen weiteren Baustein zu pflegen, dafür ist mir die Zeit dann doch zu schade.
Der Baustein wird weitestgehend mit dem 19000145er identisch sein, da die grundsätzliche Status-Logik die gleiche ist. Nur werden sämtliche Winkelein- und -ausgänge entfallen und dafür die Sonderfälle wie Schlitzposition etc. gehandhabt werden können. Die Funktionalität welche man nicht braucht, wird nicht verwendet resp. einfach deaktiviert. Damit hat man sogar für später aufkommende Wünsche schon alles vorbereitet, also wenn bspw. auf einmal doch die Dämmerungshandhabung gebraucht wird.
Welche Funktionalität könnte denn Eurer Meinung nach entfallen bzw was sind denn "die sinnvollen" Grundfunktionen für einen solchen Baustein?
Würde mich dem Test auch anschließen wollen.
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: