ElabNET Technik Forum

Hallo zusammen!

Ich möchte euch in diesen und weiteren Threads eine Lösung zur Steuerung der Jalousien vorstellen. Aufgrund meiner Erfahrungen (siehe viewtopic.php?f=46&t=1389) mit dezentraler Logik auf Wetterstationen etc. habe ich nun die Steuerung komplett auf den TWS übertragen. Damit habe ich für mich eine (fast) perfekte Lösung geschaffen, die für viele andere auch funktionieren sollte.

Um eine uneingeschränkte Nutzung/Verbreitung zu ermöglichen, werden uneingeschränkte Nutzungsrechte gemäß der TOLL ("Timberwolf Open Logikblock License"), die unter https://wrgt.news/TOLL zum Download zur Verfügung steht, übertragen.


Hauptmerkmale:
- Tag, Dämmerungs- und Nachtmodus (abhängig von Helligkeits und Zeitobjekt)
- Lamellennachführung bei Sonnenschein
- Behanghöhe abhängig von Sommer/Winter, im Winter innentemperaturgeregelt
- Berücksichtigung des Türkontaktes für Offen- und Lüftungsstellung
- Beim Übergang Tag/Dämmerung/Nacht wird bei offener Tür die letzte Stellung gehalten (schützt vor Aussperrung und verhindert am Morgen ein Auffahren bei offenem Fenster, solange die Automatik noch nicht auffährt)
- Übergeornete Freigabe und Hold Funktion
- Diverse Schwell- und Verzögerungswerte (teils kombiniert), damit die Behangverstellungen minimiert werden können
- Sendet Autosperre = 0 beim Übergang zu Dämmerung (morgens und abends)

Folgende Bausteine spielen zusammen (Nummerierung wie in Skizze unten):
0) Der TWS Standard Astro-Baustein für die Berechnung von Sonnenhöhe und Sonnenrichtung (Elevation und Azimut).
1) Dämmerungsschwellwert für Beginn Lamellensteuerung und Höhesteuerung (inkl. Grenzwert für Sonnenhöhe, der Dunkelphasen untertags unterdrückt), siehe viewtopic.php?f=65&t=1567
2) Beschattung Höhe als Eingang für Beschattung Auto (berücksichtigt Sommer/Winter, Innentemperatur)
siehe viewtopic.php?f=65&t=1565
3) Beschattung Auto (berücksichtigt Helligkeit, Sonnenrichtung und Fenster/Jalousieparameter), siehe viewtopic.php?f=65&t=1566
4) Beschattung Gesamt 1-3 + weiter Parameter und liefert Höhe und Lamelle für den Jalousieaktor und Dämmerungsstatus, siehe viewtopic.php?f=65&t=1568
5) Beschattung Autosperre => schickt beim Umschalten von Nacht => Dämmerung bzw. Tag => Dämmerung ein Telegramm Autosperre = 0 an den Aktor (Automatik aktivieren). Aktor selbst ist auf 1-2 Stunden Rückkehrzeit auf Auto nach manuellem Eingriff parametriert.



Im Logik Editor sieht das wie folgt aus:

Anregungen und Fragen gerne hier in diesem Thread, die anderen Threads werden ich sperren, um spätere Ergänzungen einpflegen zu können.

lg
Robert

Hallo Robert,

ganz hervorragend, freue mich schon auf die weiteren Teile.

Für die Mitleser:

• Eine der wichtigsten strategischen Fragen in einem Smarthome ist die Frage, ob eine Funktion zentral oder dezentral zu lösen ist.
• Das KNX-System wurde vor 30 Jahren auf Basis von 8 Bit Microprozessoren erfunden, zentrale Funktionen waren - auch wegen der damaligen Verfügbarkeit und Preislage - zunächst nicht vorgesehen.
• Dadurch hat sich im Bereich das "dezentrale" stark etabliert und wird von vielen heute noch als eine wichtige Eigenschaft begrüßt.
• Im Laufe der Zeit wurde der Funktionsumfang immer mächtiger, weil jeder Produktmanager einer Firma wollte die Produkte der anderen Firmen durch eine immer umfangreichere (und damit unübersichtlichere) Applikation ausstechen.
• Dies führte im Bereich der KNX Wetterstationen zur Entwicklung sehr komplexer Beschattungssteuerungen mit zig parallel verwalteten Fassaden, Sommer, Winter, Frühjahrs, Party und sonstigen Modi mit mehreren tausend Einstellungen, die eine Wochenlange Einarbeitung benötigen.
• Dummerweise sind solche leistungsfähigen Beschattungsstationen dem Wetter komplett ausgesetzt. Es ist ansich ein Unding, solchermaßen wichtige Logik-Schaltzentralen draußen - dem Wetter ausgesetzt - anzubringen, das muss schiefgehen. Insbesondere, wenn solche Beschattungssteuerungen dann noch auf einem Mast oberhalb des Dachgiebels montiert werden sollen. Mehr kann man eine Elektronik nicht Sonne, Sturm, Hagel, Regen und Blitz ausliefern, das ist die exponierteste Stelle am Haus.
• Und jetzt nehmen wir noch den heutigen technischen Fortschritt. Nach fünf bis zehn Jahren ist die Beschattungssteuerung durch die nächste Version ersetzt, die noch viel mehr kann. Mit dem Ergebniss: Komplett andere Applikation.
• Aus beiden - Exponierte Lage und geringe Langzeitverfügbarkeit - kann man erwarten, dass solche Beschattungssteuerungen nicht nur mit großer Wahrscheinlichkeit alle 5 bis 8 Jahre ausfallen werden, sondern dann zudem womöglich kein kompatibles Modell zur Verfügung steht mit dem Ergebnis, dass man ein Viertel des KNX Projektes neu aufbauen muss - mit all den Kosten.
• ==> Deshalb meine ich, sind langzeitgemanagte zentrale Server im Keller, mit einer viel längeren Lebensdauer und auch einer Chance auf jahrzehntelange Kompatibilität, hier die deutlich bessere Lösung. Mit dem WireGate Server und dem Timberwolf Server, jeweils auf 10 bis 20 Jahre ausgelegt inkl. kompletter Datenübernahme haben wir gezeigt, dass eine jahrzehntelangelange Verfügbarkeit inkl. kompatibler Nachfolger möglich ist.
• Daher mein Rat. Viele Sensoren um das Haus verteilt (alle Himmelsrichtungen) an möglichst geschützter Position (unter dem Dachüberstand), prinzipiell leicht austauschbar, weil Temperatur, Luftfeuchte und Helligkeit ist kein großes Ding und jeder Sensor von jedem Hersteller kann hier gegen einen anderen ausgetauscht werden mit einer zentralen Steuerung die mehrere Busprotokolle beherrscht und schon liegt man strategisch über die Jahrzehnte auf einer viel sichereren Seite - als sich auf eine monströse Beschattungslösung auf dem Dach zu verlassen. Vom irren Aufwand eine solche dort vom Dach abzumontieren um diese für Firmware-Updates einzuschicken mal ganz zu schweigen....

Deshalb freut mich diese Entwicklung und dieser Artikel so sehr, weil es ein wichtiges Problem für die Kunden lösen hilft.

lg

Stefan

Du triffst es wie immer auf den Punkt.

Zu ergänzen:
- Auch die besten Wetterstationen decken nur einen Teil der Erfordernisse ab.
- Dann hat man zusätzlich ein wenig Logik da und nochmal ein paar Dinge (ZSU) auf einem RTR...
- Manche Dinge wie Offenhalten bei Dämmerung lassen sich damit fast nicht umsetzen.
- Auch Zeit-Verzögerungen sind mit Logik-Bausteinen und auch plugins schwierig umsetzbar.

lg
Robert

Hi Robert,

gute Darstellung der Funktionsblöcke- sollte ich für meinen Rolladenbaustein evtl.auch so machen.
Wie ich sehe, hast Du es auch in mehrere Bausteine aufgesplittet
Sieht gut aus

Dragonos2000 hat geschrieben: ↑Mo Okt 28, 2019 10:10 am Wie ich sehe, hast Du es auch in mehrere Bausteine aufgesplittet

Ja - ab einem gewissen Umfang ist das übersichtlicher.
Hatte am Anfang auch einen modularen Aufbau im Sinn, aber irgendwie gibt es zuviele Abhängigkeiten:

• Fassade - Innentemperatur
• Mehrere Fassaden je Raum
• Eventuell unterschiedliche Fenstergrößen je Fassade

so dass am Ende die Hauptbausteine Auto und Gesamt je Fassade und Raum benötigt.

lg
Robert

Bei mir hab' ich ja nach viel hin- und herüberlegen ja auch 2 bausteine draus gemacht (eigentlich auch noch ein dritter): Einer zum ausgeben der benötigten Behanghöhen abhängig von den Zuständen und einer, der die Zustände ansteuert. Der erwähnte Dritte verändert im Moment nur die Verzögerungszeiten abhängig Sommer/Winter, soll aber noch ein bischen Mehr Intelligenz bekommen, wenn ich Zeit habe...

Ein Hintergrund war auch die Übersichtlichkeit (Code + Frontend) im Zusammenspiel mit den vielen Parametern einer Jalousie.
Man kann zwar den Code inzwischen schön mit Kommentaren strukturieren, aber was hilft ein Baustein, der 2,5 Bildschirmseiten füllt.

Nur als Info zur Komplexität: in Summe >100 Modules und >170 Variablen in Baustein 1-3!

lg
Robert

Ja, stimmt: Die vielen Parameter/Eingänge haben mir bei meinem Baustein auch Kopfzerbrechen bereitet. Für die Kopplung der "Kopfsteuerung" mit den nachgelagerten Rolladenbausteinen hatte ich schon überlegt, ein einzelnes -nennen wir es "KO" zu benutzen, damit ich bei einem Update des Bausteins nicht unzählige Aus- und Eingänge miteinander verbinden muss. Dafür bräuchte ich aber idealer Weise ein Array of Arrays oder eine Datenklasse, die ich selbst definieren kann, weil ich dann Bool, Floats und Ints gleichzeitig in einem Datensatz übergeben würde...
@S. Kolbinger Wäre soetwas in Zukunft denkbar? (Eigene Datenstrukturen wie oben beschrieben definieren)

.... Du sprichst vom Massenmodus? Siehe hier: viewtopic.php?f=24&t=1333&p=15315&hilit ... dus#p15315

Nein, kein Massenmodus. Ich will eine eigene Datenstruktur definieren können, die aus verschiedenen Datentypen (Bool, Integer, Float,...) bestehen kann. Vereinfachtes Beispiel:

MeineDatenstruktur:{
setpoint : float,
mode: integer,
active: bool,
start: bool
}

Im Input, Output, Level und Module will ich die dann verwenden können:
"Level": [
["$test","MeineDatenstruktur",[0,0,true,false]],
["$result","bool",true]
],
"Module": [
["And",["$test.active","$test.start""],"$result"]
]