UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[TOP TIPP] Vollautomatische 24h Jalousiesteuerung (Übersicht)

Hier stellen Foristen und Kunden Ihre EIGENEN Logikbausteine vor. Diese Logikbausteine stehen jedem im Rahmen der vom Autor eingeräumten / genannten Lizenz zur Verfügung.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

Vollautomatische 24h Jalousiesteuerung (Übersicht)

#1

Beitrag von Robert_Mini »

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.

Übersicht_Gesamt.png


Im Logik Editor sieht das wie folgt aus:
Übersicht_Gesamt_LE.png

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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von Robert_Mini am Fr Nov 01, 2019 11:10 am, insgesamt 9-mal geändert.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#2

Beitrag von StefanW »

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
Zuletzt geändert von StefanW am So Okt 27, 2019 2:38 pm, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#3

Beitrag von Robert_Mini »

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
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#4

Beitrag von Dragonos2000 »

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 :clap:
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#5

Beitrag von Robert_Mini »

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
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#6

Beitrag von Dragonos2000 »

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...
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit

Ersteller
Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#7

Beitrag von Robert_Mini »

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
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#8

Beitrag von Dragonos2000 »

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)
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
Benutzeravatar

jensgulow
Reactions:
Beiträge: 321
Registriert: Fr Apr 19, 2019 4:37 pm
Hat sich bedankt: 66 Mal
Danksagung erhalten: 134 Mal

#9

Beitrag von jensgulow »

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

Jens

_____________________________________________________________________
TWS 2600#394 , TWS 3500L#1051, VPN offen, Reboot erlaubt
Was wird genutzt? -> TWS, KNX, 1-wire, MODBUS, Http-REST-API, IFTTT, Enocean, Amazon Alexa

Dragonos2000
Reactions:
Beiträge: 2181
Registriert: So Aug 12, 2018 1:38 pm
Wohnort: Karlsruher Raum
Hat sich bedankt: 481 Mal
Danksagung erhalten: 889 Mal

#10

Beitrag von Dragonos2000 »

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"]
]
Zuletzt geändert von Dragonos2000 am Mi Okt 30, 2019 4:24 pm, insgesamt 2-mal geändert.
Lg
Jochen
____________________________________________________________
TW 2600 #188
VPN offen, Zugriff jederzeit, Experimente jederzeit, Reboot jederzeit
Antworten

Zurück zu „Zusätzliche Logikbausteine“