Vorschalt-LBS f. Beschattungssteuerung

[hx5]

Nein. Der ist eher Zufall
Ist kurz und seit 15 Jahren konnte ich mich damit (fast) überall anmelden...

[starwarsfan]

Hallo miteinander,

na? Habt ihr alle Ostereier gefunden? Achnein, hier geht's ja um etwas anderes...

Also Frage in die Runde: Gibt's noch weitere Feature- resp. Funktionalitäts-Vorschläge für den Vorschalt-LBS?

[tobo]

Das Schliessen von Rollläden bei großer Hitze oder Regen und gleichzeitig nicht geschlossenem Fenster halte ich durchaus für sinnvoll. Bei Hitze (auch wenn die Sonne nicht scheint) würde ich erwarten dass die Zirkulation der Luft zumindest verringert wird so dass die Temperatur im Raum weniger schnell ansteigt.

[hartwigm]

Ich präferiere einen Raumkontrollerbaustein.

Da gehört für mich noch dazu

a.) Anwesenheit
b.) Blendschutz
c.) Status der Heizung (Heizen/kühlen)

usecase
keine Anwesenheit und Heizmodus wäre für mich keine Beschattung um die kostenlose Wärme zu gewinnen

d.) Ventilposition Heizventil
e.) Reduzierung Heizventil bei Sonne um x%

[Teutone]

Ich würde gern noch die Parameter etwas erweitern.

• Behanghöhe bei Fenster geschlossen(Beschattung Ja)
• Lamellenwinkel bei Fenster geschlossen(Beschattung Ja)
• Behanghöhe bei Fenster offen(Beschattung Ja)
• Lamellenwinkel bei Fenster offen(Beschattung Ja)

• Behanghöhe bei Fenster geschlossen (Beschattung Nein)
• Lamellenwinkel bei Fenster geschlossen(Beschattung Nein)
• Behanghöhe bei Fenster offen(Beschattung Nein)
• Lamellenwinkel bei Fenster offen(Beschattung Nein)

Anwendungsfall wie folgt. Schiebtür und Raffstore (2700mm hoch), die Raffstores sind ganz oben, ich öffne die Tür und die Position der Sperre vom LBS 145 wird angefahren. Das ist nicht erwünscht, wenn keine Beschattung notwendig ist. Ist die Beschattung notwendig, so brauche ich nur ca. 1900mm zum durchlaufen. Somit wäre es dann sinnvoll mit Postion 20% zu verschatten.

Viele Grüße
Nico

[hx5]

Anwendungsfall wie folgt. Schiebtür und Raffstore (2700mm hoch), die Raffstores sind ganz oben, ich öffne die Tür und die Position der Sperre vom LBS 145 wird angefahren. Das ist nicht erwünscht, wenn keine Beschattung notwendig ist..

Ich habe sowas jetzt mit dieser Logik erschlagen:

2017-04-18 15_52_41-EDOMI · Administration.png

Kurz zusammen gefasst macht diese folgendes:
Ich gebe einen Mindestwert bei offenen Fenstern an (hier 85%). Nun wird geprüft ob der aktuelle IST oder die folgenden SOLL-Werte der Automatiken (Beschattung, ZUS....) höher sind. Wenn dem so ist wird auf den Vorgabewert reduziert wenn nicht werden die Werte an den Aktor weiter gegeben. Beim schließen der Fenster wird dann der letzte SOLL-Wert über den LBS 19000394 an den Aktor geschickt.

Klarer Vorteil: Ich brauche mir nicht alle möglichen Szenarien für die Fenster überlegen und sämtliche Automatiken können auch bei offen Fenstern laufen.

[starwarsfan]

Hallo Hartwig

Ich präferiere einen Raumkontrollerbaustein.

Da gehört für mich noch dazu

a.) Anwesenheit
b.) Blendschutz
c.) Status der Heizung (Heizen/kühlen)

usecase
keine Anwesenheit und Heizmodus wäre für mich keine Beschattung um die kostenlose Wärme zu gewinnen

d.) Ventilposition Heizventil
e.) Reduzierung Heizventil bei Sonne um x%

Ähm, ja schön. Und was soll das sein? Aus den paar Worten da oben kann ich mir nichts nehmen. Was willst Du mit welchen Eingängen unter welchen Bedingungen abbildern?

[hx5]

Generell würde ich gerne mal folgendes einwerfen:

Meine persönliche Meinung ist, dass man eher mehrer Vor- und Nachschalt-LBS entwickeln sollte als zu versuchen eine eierlegende Wollmilchsau zu konstruieren. Meiner Meinung nach macht auch der Beschattungs LBS schon mehr als er sollte (die Beschattung steuern).

Dadurch wird die Fehlersuche, vor allem bei aktualisierten Bausteinen immer schwieriger und auch die Entwicklung. Neueinsteiger werden von Bausteinen mit mehreren Dutzend Eingängen auch eher abgeschreckt. Und weil jeder seine eigenen Vorlieben und Ausgangslagen hat wird man auch nie alle glücklich machen können.

Wenn man mehrer kleine LBS hätte wäre man viel flexibler und jeder könnte sich nach und nach seine Steuerung erweitern/anpassen.

Was man beispielsweise gut trennen kann ist:

• Beschattung
• Sperren
• Dämmerung
• Fenster
• Temperatur

Die meisten anderen Funktionen kann man dann sicher recht einfach mit den EDOMI-eigenen Bausteinen realisieren...

[starwarsfan]

Meine persönliche Meinung ist, dass man eher mehrer Vor- und Nachschalt-LBS entwickeln sollte als zu versuchen eine eierlegende Wollmilchsau zu konstruieren. Meiner Meinung nach macht auch der Beschattungs LBS schon mehr als er sollte (die Beschattung steuern).

FullAck, da bin ich ganz bei Dir! Deswegen will ich hier auch erstmal die Ideen sammeln und dann schauen, wie sich das umsetzen lässt.

[baumhaus123]

Generell würde ich gerne mal folgendes einwerfen:

Meine persönliche Meinung ist, dass man eher mehrer Vor- und Nachschalt-LBS entwickeln sollte als zu versuchen eine eierlegende Wollmilchsau zu konstruieren. Meiner Meinung nach macht auch der Beschattungs LBS schon mehr als er sollte (die Beschattung steuern).

Dadurch wird die Fehlersuche, vor allem bei aktualisierten Bausteinen immer schwieriger und auch die Entwicklung. Neueinsteiger werden von Bausteinen mit mehreren Dutzend Eingängen auch eher abgeschreckt. Und weil jeder seine eigenen Vorlieben und Ausgangslagen hat wird man auch nie alle glücklich machen können.

Wenn man mehrer kleine LBS hätte wäre man viel flexibler und jeder könnte sich nach und nach seine Steuerung erweitern/anpassen.

Was man beispielsweise gut trennen kann ist:

• Beschattung
• Sperren
• Dämmerung
• Fenster
• Temperatur

Die meisten anderen Funktionen kann man dann sicher recht einfach mit den EDOMI-eigenen Bausteinen realisieren...

FullAck! Ich bin auch der Meinung, dass mehrere kleine sinnvoller wären. Z.B. einen, der anhand der Innen/Außen Temp ermittelt, ob denn eine Verschattung angezeigt wäre (Überhitzschutz <-> Heizungsunterstützung). Sollte das mit irgendwelchen Anwesenheiten/geöffneten Schiebetüren oder Ähnlichem in Konkurrenz stehen, so muss man das eben über eine eigene Logik abbilden, was einem hier wichtiger ist. Hier hat einfach jeder andere Anforderungen, die ein LBS nie alle vernünftig (und wartbar) abbilden kann.
Der Beschattungsbaustein bietet schon so viele tolle Möglichkeiten, dass das eigentlich alles mit Boardmitteln machbar sein sollte (De-/Aktivierung, Sperre, Konfiguration sämtlicher Schwellwerte und Winkel, Offsets, oder auch die Ausgänge, die einem eigentlich alles wichtige zum LBS-Zustand liefern.

JM2C

[MrIcemanLE]

Ich kann baumhaus123 und hx5 nur zustimmen. Vielleicht wäre ein Thread hilfreich in dem wir Logik-Strukturen untereinander Teilen. Zunächst mit Bildchen, später dann auch als Datei die über die Import-Funktion in Edomi eingelesen wird. So kann jeder, auch ohne Programmierkenntnisse die Logik an seine Bedürfnisse anpassen.

Edit: Zugegeben ... Die Berechnung von Lamellenwinkeln aus dem Sonnenstand will keiner mit den Grundrechen- und Logikbausteinen stricken ;-)

[rdeckard]

Ich bin eigentlich auch dafür, dass man lieber modular die Logiken auf verschiedene Bausteine (oder Edomi-Logiken) aufteilt. Dies hilft der Wartung, Fehlersuche und der Flexibilität.
Die Schnittstellen müssen natürlich ebenfalls flexibel definiert sein.

Es wird wohl immer Diskussionen geben, welche Funktionalität intern oder extern ausgewertet werden sollte.

Mir ist z.B. in den letzten Tagen aufgefallen, dass ich bisschen Mühe mit der Definierung eines richtigen Helligkeitsschwellwerts habe. In der Theorie ist es so schön logisch. Ist es genügend hell, scheint die Sonne und die Jalousien müssen runter. Nur scheint mir dieses "genügend hell" irgendwie nicht so eindeutig zu sein. Bin ich unter 50'000 Lux, so kann es schon bei einem bewölkten, aber hellen Himmel auslösen (dünne Wolkendecke). Subjektiv würde ich in diesem Fall die Jalousien nie von Hand runterlassen und somit habe ich dann das Gefühl, die Steuerung ist nicht "smart" genug. Setze ich den Schwellwert höher, dann kann es sein, dass ich am Vormittag oder späten Nachmittag von der Sonne geblendet werde, weil die Jalousien bereits wieder hochgehen oder noch nicht ausgelöst haben.
Lux heisst also nicht unbedingt, wie "stark" die Sonne scheint, sondern nur, wieviel Helligkeit vorhanden ist. Wie man das lösen kann, weiss ich nicht. (Ausser man verwendet mehr Lux-Sensoren).
Auch die Helligkeitswerte für die Dämmerungsschaltung sind für mich nicht so richtig zu fassen. Am Abend möchte ich die Jalousien erst runterfahren, wenn es wirklich fast schon stockdunkel ist. (Im Moment gehen sie mir schon fast zu früh runter)
Setze ich den Lux-Wert aber zu tief, dann gehen sie am Morgen natürlich schon beim ersten Lichtstrahl rauf. Aber gerade am Morgen fände ich es besser, wenn es lieber noch etwas heller werden muss, bevor sie raufgehen. Kurz gesagt: Subjektiv würde ich zwei verschiedene Lux-Grenzwerte benötigen. Einen für den Abend und einen für den Morgen.
Jetzt könnte man natürlich sagen, dies sollte am besten im Beschattungs-LBS mit einem zusätzlichen Wert definiert werden und gut ist. Oder würde man das lieber in einen externen Baustein ausgliedern? Wie definiert man am besten "Morgen" und "Abend"? Einfach mit einer ZSU? Im Winter wird es schneller dunkel als im Sommer, wo es eher langsam geschieht. Das spielt hier sicher auch eine Rolle.

Zusammengefasst kann ich für mich sagen, dass eine automatische Beschattung viel komplexer ist, als ich mir das vorher gedacht habe. Zumindest, wenn sie einigermassen "intelligent" sein sollte (und dazu gehören halt die vielen Spezialitäten, die jeder bei sich hat). Manchen reichen Basisfunktionen und geben sich damit zufrieden, andere wollen es so smart wie möglich umgesetzt haben. Wir haben hier ja den Vorteil, dass wir nicht auf die Funktionen eines Herstellers abhängig sind, sondern fast alles mit mehr oder weniger Aufwand umsetzen können.
Und genau dies sollte man halt bei diesem modularen Konzept immer im Kopf behalten.
Und nicht vergessen, dass nicht jeder mit den Edomi-Logiken so perfekt umgehen kann, dass er seine Wünsche easy umsetzen kann. Auch wenn es technisch gehen würde. Die Userfreundlichkeit sollte man nicht ganz aus den Augen verlieren. Ein LBS hat ja eigentlich den Sinn, dass sich jemand im Detail mit dem Thema auseinandergesetzt hat und andere davon profitieren können, dass sie den Baustein nur noch anwenden können, ohne alles zu verstehen oder sich selber damit im Detail zu befassen. Wenn alles in zuviele Bausteine ausgelagert wird, wird es für viele Anwender, die nicht so technisch versiert sind, irgendwann zu kompliziert.
Die Cracks (Baustein-Entwickler) sagen schnell mal: "Mach das doch mit einer vorgeschalteten Logik." Aber wie man dass dann macht, überfordert dann viele und es wird halt gar nicht umgesetzt. (Wie ich bei meiner Sperre für die Sitzplatztür selber erfahren musste)

[starwarsfan]

N'abend miteinander

Ich bin eigentlich auch dafür, dass man lieber modular die Logiken auf verschiedene Bausteine (oder Edomi-Logiken) aufteilt. Dies hilft der Wartung, Fehlersuche und der Flexibilität.

Genau so ist es.

Die Schnittstellen müssen natürlich ebenfalls flexibel definiert sein.

Hier wird es schon spannend. Am Beschattungs-LBS sieht man ja sehr schön, wohin Flexibilität hinsichtlich der Anzahl der Parameter führt. Ich hätte mir zu Beginn der Entwicklung auch nicht träumen lassen, mit welcher Anzahl an Konfigurationsmöglichkeiten der Baustein nun aufwartet.

Es wird wohl immer Diskussionen geben, welche Funktionalität intern oder extern ausgewertet werden sollte.

Richtig, das liegt in der Natur der Sache.

Zusammengefasst kann ich für mich sagen, dass eine automatische Beschattung viel komplexer ist, als ich mir das vorher gedacht habe.

Yeah, willkommen im Club!

Zumindest, wenn sie einigermassen "intelligent" sein sollte (und dazu gehören halt die vielen Spezialitäten, die jeder bei sich hat).

Und genau deshalb habe ich soweit wie möglich darauf geachtet, den Baustein einerseits möglichst generisch zu halten, so dass man ihn über die verschiedenen Eingänge an die eigenen Gegebenheiten und Anforderungen anpassen kann und andererseits auf die Kernfunktionalität der Steuerung des Behangs zu beschränken.

Unterm Strich ist das ein rechter Spagat (gewesen). Ich hatte mir auch die mögliche Aufteilung von Beschattung und Dämmerung in separate Bausteine angeschaut, das dann aber schnell wieder verworfen. Beide Fälle haben Gemeinsamkeiten, welche sich gegenseitig beeinflussen können und mit dem allgemeinen Overhead war es dann besser, beides in einem Baustein unterzubringen.

Manchen reichen Basisfunktionen und geben sich damit zufrieden, andere wollen es so smart wie möglich umgesetzt haben.

Und genau aus letzterem heraus ist der Baustein entstanden...

Wenn alles in zuviele Bausteine ausgelagert wird, wird es für viele Anwender, die nicht so technisch versiert sind, irgendwann zu kompliziert.
Die Cracks (Baustein-Entwickler) sagen schnell mal: "Mach das doch mit einer vorgeschalteten Logik." Aber wie man dass dann macht, überfordert dann viele und es wird halt gar nicht umgesetzt. (Wie ich bei meiner Sperre für die Sitzplatztür selber erfahren musste)

Ja und nein. Die Kunst ist eben, den gesunden Mittelweg zu finden resp. sich auf die Kernaufgabe eines Bausteines zu beschränken. Man kann endlos Aufwand in einen LBS stecken, um genau ein Problem zu lösen. Damit wird dann aber vermutlich auch nur einer glücklich. Oder aber man steckt noch viel mehr als endlos Aufwand in den LBS, um alle möglichen Fälle irgendwie zu erfassen und zu behandeln. Damit wird dann aber auch nur eine sehr kleine Anzahl von Anwendern glücklich, da der LBS für den Rest einfach zu komplex/umfangreich ist.

Ich denke mal, ich werde einige Versuche mit kleineren Einzelbausteinen machen. Nach dem was sich hier so herauskristallisiert, scheint das der effizienteste Weg zu sein.

[baumhaus123]

Ich versuche mal, konkret ein Szenario zu artikulieren:
Ich bräuchte einen Baustein, der mir ermittelt, ob eine Beschattung durchgeführt werden soll, oder nicht. Das boolsche Ergebnis dieses Bausteins würde ich dann an den Eingang E40 hängen, welcher die Beschattung steuert.

Der Baustein sollte die Innen-Ist-Temperatur, die eingestellte Soll-Temperatur, eventuell einen Eingang für Heizmodus und einen Eingang für maximale Raumtemperatur besitzen. Steht das Zimmer auf Heizmodus und ist die Ist-Temp < Soll-Temp, so sollte die Beschattung deaktiviert werden und die solaren Gewinne eingefangen werden, bis die maximale Raumtemperatur erreicht wurde. Befindet sich das Zimmer aber nicht im Heizmodus, so sollte die Beschattung greifen, obwohl die Ist-Temp womöglich unter der Soll-Temp ist, weil die Kühle im Zimmer im Sommer ja erstrebenswert ist.

Das ist jetzt mal nur grob gebrainstormed und euch fällt sicher noch etliches dazu ein. Für mich umreißt es zumindest mal die Steuerung ob Beschattung ja/nein indiziert ist. Sonderlocken wie "eigentlich solare Gewinne, aber aufgrund Anwesenheit dennoch Beschattung" würde ich dann mit einer eigenen Logik erstellen.

Was mit ihr dazu?

[hx5]

Hallo Zusammen,

hier mal meine Gedanken zur Steuerung:
2017-04-20 17_29_48-Organigramm Rollos.ods _ 2 - OpenOffice Calc.png


Die Idee ist, dass Beschattung-,Temperatur-, Dämmerungssteuerung durch den nachgeschaltete Sperre überwacht werden. Die Sperre könnte so zum steuern der Prioritäten dienen und evtl. den Gesamtstatus ausgeben. Dahinter kommt nur noch die Fenster- und Türsteuerung weil man, meiner Meinung nach, keine komplette Sperre braucht sondern wie in meinem Beitrag weiter oben schon beschreiben nur eine Überwachung einer Minimalöffnung.

Den Beschattungsbaustein hab ich hier mal klein gehalten (obwohl er natürlich großartig ist) und für Jalousien braucht man selbstverständlich jeweils zwei Ein- und Ausgänge. Ich denke aber so ist es erstmal übersichtlicher.

Anbei habe ich das mal als OpenDocument angehängt (.pdf muss weg, kann dann auch mit Excel bearbeitet werden....).
Organigramm Rollos.ods.pdf