ElabNET Technik Forum

Piranha hat geschrieben: ↑Di Mai 11, 2021 7:14 pm Mich würde auch interessieren ob sich die Logiken 1-4 oder zumindest 2-4 in einem Baustein kombinieren lassen?

Ja die Logiken 2-4 lassen sich kombinieren, ist aber einiges an Aufwand.
Man muss vorher den Code mal "verstehen", sodass man weiß, was wo wann gemacht wird.
Dann müssen die einzelnen Ein- und Ausgänge der Logiken stattdessen mit internen Merkern verbunden werden.
Dann ist aufzupassen, wenn gleiche Variablennamen in unterschiedlichen Logiken vorher verwendet wurden, dass diese dann umbenannt werden müssen, usw.

Würde ich nicht empfehlen!
Erstens wird das sowohl vom Code als auch Logik-Zelle sehr unübersichtlich.
Zusätzlich bietet die aktuelle Lösung die Möglichkeit, an den Eingängen statt Parametern auch Objekte anzuhängen. Diese können wiederum von der Visu oder einer weiteren Logik kommen.
Ich denke da zb an Helligkeitsgrenzen und Verzögerungszeiten getrennt für Sommer/Winter, etc.

Und bez. Anzahl an Logiken: ab einem gewissen Grad muss man eben auf die Filternöglichkeiten und Tags zurückgreifen.

Lg
Robert

Also bei mir funktionierts einwandfrei.
Habe all jenigen Eingänge, die ich mit Objekten verbinden möchte oder von extern ändern möchte, als Eingänge gelassen. Dadurch hab ich alle Möglichkeiten offen. Die einzelnen Logiken davor aber teilweise komplett überarbeitet und für mich nicht notwendige Funktionen gelöscht und dafür andere hinzugefügt.
Durch neue Aufteilung des Codes in Gruppen bleibt die Übersicht im Sourcecode auch erhalten.
Aber wie schon geschrieben, es ist einiges an Arbeit und man sollte wissen was man tut.

Der Grund für mich war einfach, dass eine Funktion bei mir ein Baustein sein soll.

Hallo Wolfgang,

wäre es für Dich in Ordnung den Code hier zu sharen?

Noch eine Frage, wie löst ihr das Problem, dass beim Editieren der Logiken die letzten Ein- und Ausgangswerte nicht mehr stimmen (auf Standard zurückgesetzt werden). Dies führt dann ja dazu, dass die Jalousie ggf. ungewollt Auf oder Zu fährt bzw. der Zustand unter Umständen erst wieder zum nächsten Triggerzeitpunkt passt.

Korrigiert mich wenn ich es falsch sehe, aber die Persistenz hilft hier nicht weiter, sondern nur beim Reboot oder Stromausfall, oder?

Danke Euch

Grüße
Alex

Hallo Leute,

ich will mich endlich mal an das Thema Beschattungssteuerung setzen. Das lief früher via OpenHab aber seitdem dort die Zeiten umgestellt wurden fand ich nicht die (eigene) Zeit um mir da alle Änderungen anzueignen und die Logiken zu ändern. Außerdem will ich eh weg von OpenHab und mehr mit dem Timberwolf machen


Einige Bausteine (Beschattung) sind ja schon von Haus aus auf dem Timberwolf.

Was ich vermisse:
-> Eingebaute Hilfe, um Ein- und Ausgänge zu beschreiben
>>> Hier im Forum gefunden
-> Infos zu den DPT-Datentypen
>>> Ich sehe in der Logikengine (offenbar?!) nicht, welchen DPT die jeweiligen Ein- und Ausgänge der Logiken haben. Das muss ich aber ja wiederum - wenns nicht intern verschaltet wird - via ETS am Timberwolf Server parametrieren und entspr. zu GAs verbinden.
Wo gibts die Infos zu den DPTs (zb. für Sonnenhöhe, Schwellwerte Sonnenstand etc)

Die Logik braucht die DPT nicht, der Verknüpfungsassistent konvertiert das was möglich ist intern von allein. Es ist dann eher wieder nur interessant, das der Output der Logik an ein KNX-KO geht. Dieses musst aber eher danach auslegen was der KNX Aktor usw. als DPT für diese Information erwarten. Der Verknüpfungsassistent den Du ja nutzt wenn Du dem Logikausgang mit einem KNX KO verbindest konvertiert das wieder. Damit bleibt der DPT eine reine KNX information. Ich lege meine KNX-KO für den TWS an weil ich den Gegenpart im KNX kenne, nicht weil ich etwas im TWS irgendwo (Logik / MQTT) produziere.

Hallo Daniel,

der Timberwolf Server ist keine reine KNX-Maschine und damit ist die Logik auch keine reine KNX-Logik.

Im Timberwolf Server kommunizieren die jeweiligen Subsysteme mit den dazugehörigen Protokollen in der Weise, wie es für diese Protokolle vorgesehen ist. D.h. die Kodierung der Daten im Protokoll erfolgt spezifisch für dieses Protokoll.

Die Subsysteme bereiten nun die Werte für den zentralen Verteiler ("Dispatcher") auf und stellen die Werte der korrespondierenden Objekte in - derzeit - vier Datentypen zur Verfügung:

- Binär
- 32 Bit Ganzzahl
- 32 Bit Fließkomma
- Text

Zudem wird noch eine Einheit für jedes Objekt gespeichert.

Damit ist eine Wandlung von allem zu jedem möglich (übrigens ohne über die Logik zu gehen). D.h. ein KNX-GA kann damit mit einem Modbus-Gerät verbunden werden - ohne die Logik zu bemühen.

Beim Verknüpfen wird dabei auch noch geprüft, ob eine Auto-Konvertierung möglich ist, damit lässt sich ein 32 Bit Float auch mit 1 Bit Binär verbinden (wobei dann 31 Bits an Informationen verloren gehen, aber machbar ist es).

Auch die Logiken bieten - Ergänzend zur Autokonvertierung - eine Anpassung der Eingangswerte zur Verfügung.

Im Grunde ist die Sache also gar nicht so kompliziert. Einfach ein KNX Objekt im Timberwolf Server anlegen, dass dem DPT der GA entspricht, die damit verknüpft wird und dann kann man das in der Logik eben als Binärwert, Zahlenwert oder Text nutzen.

Was derzeit noch fehlt sind interne Repräsentationen von Zeitpunkten (Datum / Zeit) sowie Farbenmischungen. Daran wird gearbeitet.


lg

Stefan

Hallo Robert,

kannst du mir bitte kurz helfen. Ich möchte den Ausgang "$Hoehe_Pos_Ein_D" und "$Hoehe_Pos_Ein_Tuer_F" mit dem Baustein Limiter begrenzen. Wenn ich die beiden Variablen begrenze, läuft leider die Logik nicht mehr richtig. Bei Tag false kommt nicht mehr die 100 %.
Ideal wäre wenn min und max vom Limiter als Variabeln über den Eingang belegbar sind. Da es schwierig ist, deine Gedankengänge in dieser Custom Logik nachzuvollziehen, könntest du diese Ergänzung zur Verfügung stellen?
Danke
Enrico