MDT Logikmodul SCN-LOG1.02: Praktische Beispiele

[mumpf]

Hi,

wie das immer so ist, wenn man ein neues Spielzeug hat: Ich habe rumprobiert und bei dem Modul Sachen festgestellt, die zu kritischen Fragen meinerseits im Forum geführt haben. Es gibt ja selten Threads, die die positiven Seiten hervorheben, aber ich finde, das MDT Logikmodul ist es Wert, einen solchen Thread zu haben.

Ich wollte in loser Folge hier Beispiele Posten, die eher nicht triviale Möglichkeiten der Funktionen zeigen und fange mal mit der Szenensteuerung / Steuertabelle an - eine der Funktionen, die ich wirklich super finde und die mich zum Kauf verleitet hat.

Beispiel hier: Garagentorsteuerung über eine "Toggle"-GA. Wenn also das Tor zu ist und eine 1 empfangen wird, geht das Tor auf. Wenn es auf ist und eine 1 empfangen wird, geht es zu. Wenn eine 1 empfangen wird und das Tor fährt, wird es gestoppt.

Jeder, der das jetzt liest, wird sagen, dass man das doch einfach mit jedem Taster über 1-Tasten-Bedienung hin bekommt. Das Problem da ist aber, dass so ein Garagentor manchmal einfach nicht fahren will, weil es blockiert ist oder eine Katze durch die Lichtschranke läuft oder oder oder... Und mich hat es schon immer gestört, dass ich dann 2x drücken muss, wenn irgendein "Störfall" das Fahren verhindert hat. Ziel ist es also, die Fahrtrichtung, in die man fahren will, erst beim Tastendruck zu ermitteln und zu senden. Mit einfachen Logikgattern gar nicht so einfach zu realisieren, mit der Steuertabelle ein Klacks...

Voraussetzung beim Garagentor:

• KO zum Fahren: 0-hoch, 1-runter.
• KO zum Stoppen: 0 oder 1 stoppt.
• KO mit dem Motorstatus: 0-steht, 1-fährt.
• KO mit dem Torstatus "Ist zu": 0-offen, 1-ist zu.

Dann noch ein Taster (oder bei mir der Fingerprint), der bei Betätigung eine 1 sendet.

Die Wertetabelle sieht dann so aus
GarageToggle1.PNG :
GarageToggle2.PNG

Was passiert hier? Erstmal definiert man die 3 Eingänge "Taster" (der immer eine 1 liefert), "Tor unten" und "Motor fährt", die man später mit den entsprechenden GA verbindet.

Und dann schreibt man einfach die Bedingungen hin, bei denen was passieren soll.
Bedingung 1: 110xxxx sagt, dass Taster = 1 UND Tor unten = 1 UND Motor fährt = 0 sein muss (oder natürlichsprachlich: Wenn die Taste gedrückt wurde und das Tor unten ist und es nicht fährt), dann sende den Wert 0 (was Tor hochfahren bedeutet).
Bedingung 2: 100xxxx sagt, dass Taster = 1 UND Tor unten = 0 UND Motor fährt = 0 sein muss (oder natürlichsprachlich: Wenn die Taste gedrückt wurde und das Tor nicht unten ist und es nicht fährt), dann sende den Wert 1 (was Tor runterfahren bedeutet).

Das war's! Ich bin immer noch begeistert, wie simpel das ist! Im Gegensatz zu normalen Logiken muss man sich nicht darum kümmern, was passiert, wenn das Tor fährt seinen Zustand ändert (also es losfährt) oder Tor unten von 1 auf 0 geht (also das Tor nicht mehr unten ist). Keine Seiteneffekte, keine komplizierten UND/ODER/NICHT-Ketten.

Da man aber möchte, dass mit jedem Tastendruck (also jeder 1 auf dem Taster-Eingang) auch wirklich die Steuertabelle ausgewertet wird, muss man noch bei Sendebedingung auf "bei Eingangstelegramm" und "Sende bei Eingangstelegramm auf" "Eingang 1" setzen.

Als Abfallprodukt bekommt man noch die Stop-Funktion quasi umsonst. Aber da das nicht am Logikmodul liegt, gehört das nicht wirklich hierher...

Jetzt noch bei den Kommunikationsobjekten die GA verbinden und das wars!

Vielleicht hilft es jemanden, der auch verschiedene Sachen über eine GA steuern will...

Gruß, Waldemar

[trollvottel]

Da fühle ich mich gleich motiviert, meine "Waschmaschine fertig!"-Lösung zu präsentieren! Das Ganze basiert auf dem MDT AMS, SCN-LOG und geht auf die MDT Glas-LED-Anzeige. Dabei werden gleich alle möglichen Zustände einer einzigen LED "WaMa" belegt:

* Grün: WaMa hat Strom
* Rot: WaMa hat kein Strom
* Blau blinkend: WaMa läuft
* Rot aufblitzend: WaMa fertig

In meinem Fall ist es ein BOSCH Waschtrockner, aber die eingestellten Schwellwerte dürften vmtl. auch auf normale Waschmaschinen passen. Ansonsten dort ggfs. anpassen. Dazu einfach schauen wieviel Strom das Gerät zieht, wenn ein Waschprogramm gewählt, aber noch nicht gestartet wurde.

Schaltaktor mit Strommessung:
KOs AKS.PNG
Parameter AKS.PNG
Logikmodul:
KOs LOG.PNG
Parameter LOG 1.PNG
Parameter LOG 2.PNG
LED-Anzeige:
KOs GLED.PNG
Parameter GLED.PNG

Einziger Wermutstropfen bisher: Die LED zeigt auch "WaMa fertig", wenn via Wählschalter ein Programm ausgewählt, aber noch nicht der Startknopf gedrückt wurde. Das lässt sich mit noch mehr Logik aber sicher auch lösen, vielleicht hat jemand eine fixe Idee?

[MrData]

Hallo Trollvottel,

WaMa läuft müsste auch aus einer Logik (Universallogik) kommen und nicht vom Schaltaktor (es darf nur die erste Lastüberschreitung ausgewertet werden), in der Art: WaMa läuft ist dann: WaMa läuft = Nein UND Lastüberschreitung = JA
WaMa läuft müsste dann noch über einen Inverter (das Logikmodul hat in einem Block jeweils einen Vierfachinverter) geschickt werden, _nur_ das JA wird in NEIN gewandelt und in WaMa fertig geschrieben.

WaMa fertig wäre dann = WaMa läuft = JA UND Lastunterschreitung = JA ... WaMa fertig geht auch über einen Inverter, das Nein wird in WaMa läuft geschrieben.

Das Ganze kann man noch mit einer Taste zur Quittierung von WaMa fertig ergänzen bzw. über den PM beim Betreten des Raums (nur in Nebenräumen sinnvoll) wird WaMa fertig wieder auf Nein gesetzt (auch wieder über Universallogik)

Bei mir habe das Ganze noch wie folgt "getuned": neben der WaMa ist ein Taster zum Freigeben der WaMa. Der Schaltaktor mit Strommessung ist auf Treppenlicht parametrisiert ohne manuelles Abschalten, aber mit Nachtriggern, Tl =20 min. Ein kurzer Tastendruck schaltet den Aktor ein, Lastüberschreitung des Aktors triggert das Treppenlicht nach. Die WaMa ist fertig, wenn das Treppenlicht wieder aus geht (über die obere Logik wird verhintert, dass WaMa fertig angezeigt wird, obwohl die Maschine nicht gelaufen ist, zb wenn man zufällig an den Schalter kommt). Über den langen Tastendruck kann die Led für WaMa fertig dann wieder abgeschaltet werden.

Für den Geschirrspüler ist das auch so umgesetzt .... Was besonders bei kleinen Kindern sehr sinnvoll ist wenn diesen Spüler aufklappen und auf die Tasten drücken wollen ;-)

[trollvottel]

Das Ganze kann man noch mit einer Taste zur Quittierung von WaMa fertig ergänzen bzw. über den PM beim Betreten des Raums (nur in Nebenräumen sinnvoll) wird WaMa fertig wieder auf Nein gesetzt (auch wieder über Universallogik)

Sowas wollten wir bei uns nicht haben, weil unsmart. Ich will die Smarthome-Technik nicht babysitten müssen, damit sie funktioniert. Genau so wie oben geschildert funktioniert es für uns, ganz ohne PM (Der weiß doch garnicht, ob ich die Wäsche rausgeholt habe!) oder gar Taster; Der "Wasch-Workflow" an sich ist völlig unangetastet.

Der noch falsche Zustand "WaMa fertig" wenn Programm gewählt, Start noch nicht gedrückt besteht normalerweise nur wenige Sekunden und habe ich erstmal vernachlässigt. Ich werde das aber nachreichen, zum damaligen Zeitpunkt waren alle Logikblöcke belegt inzwischen habe ich da aufgrund Optimierungen wieder welche frei und kann das machen.

Was ich noch geplant habe ist eine Stromunterbrechung kurz nach Programmstart und automatisch verzögertes Wiedereinschalten zur PV-Eigenverbrauchsoptimierung. Später mal.

[mumpf]

Funktion: Wert empfangen und zyklisch senden

Hi,

da ich viel mit Status-KO arbeite, wollte ich eigentlich einen empfangenen Status auf einer bestimmten GA auf einer anderen GA zyklisch senden. Ich war zuerst enttäuscht, dass das mit dem Logikmodul nicht geht. Doch es gibt ja verschiedene Wege zum Ziel:

• Mit dem Universal-Rechner kann man das ganz komfortabel für die DPT, die der Universalrechner unterstützt, lösen. Einfach als Rechnung "Eingang1" + 0 einstellen und dann den Ausgang zyklisch senden lassen.
• Natürlich kann man auch von der selben GA lesen, wie die auf die man schreibt. Damit kann man mit dem Universalrechner die Funktion "Wert empfangen und zyklisch senden" auch realisieren.
• Vorteil: Weil es 2 Rechenblöcke im Universalrechner gibt, kann man hierüber Funktionen sparen.

Wollte das mal als Tipp loswerden.

Gruß, Waldemar

[trollvottel]

Danke für den Tipp! Doch für was nutzt/brauchst Du das?

[mumpf]

Hi,

das ist schwerer zu sagen... ich bin auf dem Trip, das Startup-Verhalten des Busses und aller Geräte (ohne Logikengine) auf einen verlässlichen Stand zu heben, möglichst ohne Seiteneffekte. Anders gesagt: Nach einem Stromausfall/Busreset möchte ich zuverlässige Funktion aller KNX-Komponenten, selbst wenn die Logikengine nicht mehr läuft. Auslöser war, dass im Urlaub nach einem Stromausfall die Logikengine nicht hochkam und dann vor allem einige die Heizung betreffenden Steuerungen gar nicht mehr funktionierten und dadurch das Haus im Anwesenheitsmodus und die Heizung im Sommermodus gelandet ist, obwohl es vorher im Abwesend/Winter war. Das hätte die Logikengine natürlich korrigiert, wenn es da nicht den Hänger beim Booten gegeben hätte . Deswegen habe ich mir das Logikmodul gekauft. Ich wollte, dass ich ein KNX-Gerät habe, dass mir Zustände auch über den Stromausfall hinweg speichern kann (Funktion: Wert speichern und nach Reset senden - leider hat diese Funktion einen unschönen Nebeneffekt, aber das hatte ich ja schon im Forum beschrieben und da hoffe ich noch auf eine Korrektur von MDT).

Den Gesamtzustand speichere ich über einen Byte-Wert, diesen Wert teile ich in eine Szene und 3 Bits auf, 2 davon schalten Betriebsmodi um und ein Bit ist eine Sperre. Klappt auch super.

Dann ist mir aufgefallen, dass bei einer Neuprogrammierung der Geräte, die von diesen 3 Bits beeinflusst werden, diese Betriebsmodi/Sperren auch verloren gehen. Und bei Neustart nicht abgefragt werden. Nicht super kritisch, aber wenn ich diese 3 Bits zyklisch sende (nicht sehr häufig -> stündlich), dann habe ich schneller eine Art "Selbstreperatur", als wenn ich bis zum nächsten Moduswechsel warte. Deswegen brauchte ich was, um von einer GA zu lesen (der Byte-Wert, der auch gespeichert wird) und zyklisch auf eine andere GA zu senden. Hinter dieser GA steckt dann ein Formatumwandler Byte->8x1Bit, so dass ich dann effektiv die 3 Bits zyklisch gesendet bekomme, obwohl ich nur 1 Byte zyklisch sende.

Langer Rede kurzer Sinn: Der globale Hauszustand (Anwesend/Abwesend, Urlaub, Sommer, Winter, Übergangszeit) und die abgeleiteten Modi für Heizung, Klimaanlage, Zirkulationspumpe, elt. Zusatzheizung im Bad werden jetzt auch ohne Logikengine korrekt nach einem Busausfall wiederhergestellt. Und als netter Nebeneffekt auch zeitnah nach einer Umprogrammierung.

Mit etwas nachdenken habe ich von zuerst 20 Funktionen das Ganze auf 12 Funktionen reduzieren können, indem ich teilweise solche Tricks wie oben beschrieben genutzt habe und vor allen, indem ich statt einzelne Bits zu speichern mit einem Bytewert gearbeitet habe, dass ich anschließend als Bitvektor auswerte.

Mal schauen, was ich jetzt noch mit den anderen 12 Funktionen anfangen kann...

Gruß, Waldemar

[STSC]

Das ganze müsstest bitte nochmals etwas genauer beschreiben.
Um 3 Objekte über Reset zu retten, hätte ich jetzt verwendet:
1x Wert speichern und nach Reset senden
1x Formatwandler 8 x 1Bit => 1Byte

Dann gibt es aber das Problem wenn das Logikmodul neu parametriert wird.
Wie hast du dann die "Selbstreperatur" mit dem zyklisch Senden gebaut?

[hjk]

Für 3 Objekte brauchst du 3 Funktionen, speichern und nach Reset senden.
Oder 3 Bits wandeln in Byte => als Byte speichern => nach Reset in Bits umwandeln. Das sind ebenfalls 3 funktionen und macht bei 3 Objekten keinen Sinn.

[mumpf]

Hi,

Das sind ebenfalls 3 funktionen und macht bei 3 Objekten keinen Sinn.

da stimme ich Dir zu, aber bei meinem Ansatz bin ich auch nicht schlechter -> und für jedes weitere Bit bin ich im Plus! Außerdem ist da noch das zyklische Senden, für das ich sonst auch noch 3 Funktionen bräuchte...
Faktisch bin ich bereits jetzt im Plus, weil es mir hier um Robustheit geht (nach Stromausfall Grundfunktionen bereit stellen). Insofern nutze ich auf der KNX-Seite nur "als Byte speichern" => "nach Reset in Bits umwandeln". Der Teil "Bits wandeln in Byte" wird von der Logikengine gemacht (derzeit).

Aber mir ging es gar nicht darum, wie ich das verwende. Sehen wir das mal abstrakter: Mit 3 Funktionen kann man auch 8 1-Bit-Objekte speichern und nach Reset wieder senden. Und das ist sicherlich besser als das mit 8 Funktionen zu lösen .

Um 3 Objekte über Reset zu retten, hätte ich jetzt verwendet:
1x Wert speichern und nach Reset senden
1x Formatwandler 8 x 1Bit => 1Byte

Wie hjk schon schrieb, für 3 Objekte über Reset zu retten macht das noch keinen Sinn, ab 4 erst. Und das mit "Selbstreperatur" war wahrscheinlich anders gemeint, als Du es verstanden hast.

Erstmal Logikmodul:

Dann gibt es aber das Problem wenn das Logikmodul neu parametriert wird.

Das Logikmodul speichert die Werte erst beim Stromausfall und nicht beim neu parametrieren. Da habe ich aber (glücklicherweise) einen Workaround gefunden. Vor dem neu programmieren des Logikmoduls dieses einfach in der ETS über "Gerät zurücksetzen" eben zurücksetzen. Dann speichert es nämlich die Werte auch. Wenn man also nur die Werte beim neu programmieren retten möchte, ist kein zyklisches Senden nötig. Hierzu hat hjk bereits geschrieben, dass MDT zwar an dem grundsätzlichen Verhalten nichts ändern kann (speichern erst beim Stromausfall), aber dass sie schauen wollen, ob man nicht das Senden eines falschen Wertes nach dem programmieren verhindern kann.

"Selbstreperatur":
Das hier ist keine allgemeine Empfehlung, hatte ich nur geschrieben, weil ich von trollvottel gefragt wurde, wofür ich das nutze. 3 der Bits, die unbedingt nach einem Neustart wieder gesetzt werden sollen, führen zu Modusumschaltungen, die richtig langfristig sind: Sperre der elektrischen Zusatzheizung im Sommer, Heiz- bzw. Kühlmodus der Klimaanlage, Sperren der Heizung (ist nicht die gleiche Sperre wie Zusatzheizung). Die Bits werden selten im Jahr geändert und somit auch selten gesendet. Wenn ich im Laufe des Jahres die Geräte programmiere, die von diesen Bits beeinflusst werden, dann gehen deren Werte verloren. Deswegen lasse ich mir diese 3 Bits zyklisch senden und kann mir sicher sein, dass nach spätestens 1 Stunde der Zustand wiederhergestellt ist. Das habe ich "Selbstreperatur" genannt und es hat nichts mit dem Problem der Neuprogrammierung des Logikmoduls zu tun.

Ich hoffe, das ist jetzt klarer geworden.
Gruß, Waldemar

[STSC]

Hi,
"Selbstreperatur":
Das hier ist keine allgemeine Empfehlung, hatte ich nur geschrieben, weil ich von trollvottel gefragt wurde, wofür ich das nutze. 3 der Bits, die unbedingt nach einem Neustart wieder gesetzt werden sollen, führen zu Modusumschaltungen, die richtig langfristig sind: Sperre der elektrischen Zusatzheizung im Sommer, Heiz- bzw. Kühlmodus der Klimaanlage, Sperren der Heizung (ist nicht die gleiche Sperre wie Zusatzheizung). Die Bits werden selten im Jahr geändert und somit auch selten gesendet. Wenn ich im Laufe des Jahres die Geräte programmiere, die von diesen Bits beeinflusst werden, dann gehen deren Werte verloren. Deswegen lasse ich mir diese 3 Bits zyklisch senden und kann mir sicher sein, dass nach spätestens 1 Stunde der Zustand wiederhergestellt ist. Das habe ich "Selbstreperatur" genannt und es hat nichts mit dem Problem der Neuprogrammierung des Logikmoduls zu tun.

Das heißt dann bräuchte man noch zusätzlich die Funktion "Zyklisch senden/abfragen". Dann wäre man praktisch bei 4 Funktionen.

[mumpf]

Genau. Im Extremfall könnte man mit 11 Funktionen 32 Bit speichern und nach Reset wieder senden, und mit 2 weiteren Funktionen diese auch zyklisch senden lassen (habe ich aber nicht ausprobiert). Werde ich vielleicht mal testen, bevor ich meine restlichen Funktionen aufbrauche. Mal schauen... wobei ich das nicht brauchen werde.

Wofür willst Du das denn nutzen?

Gruß, Waldemar

[trollvottel]

Da würde man sich eigentlich lieber eine dafür dedizierte Logikfunktion wünschen, sodass nicht das halbe Modul damit beansprucht wird.

Sowas wie "Multi-Status-Merker" oder so. Statt 8 Funktionsblöcke wäre das dann einer mit 8 KOs. Da hätte ich dann auch Anwendung für, so "langfristige" Statusbits habe ich natürlich auch im Haus an manchen Stellen.

[mumpf]

Hi,

die dezidierte Funktion ist eben "Speichern und nach Reset senden", bei der kannst Du den zu speichernden DPT aussuchen. Wenn der 1-Bit ist, dann bräuchtest Du pro Bit eine Funktion. Ich wollte nur aufzeigen, dass man bis zu 32 Bit relativ einfach mit immerhin weniger als der Hälfte der verfügbaren Funktionen zeigt.

Aber ich stimme Dir zu, es wäre wünschenswert, eine Funktionserweiterung einzubauen, bei der man z.B. auch 8x1-Bit als zu speichernder Datentyp wählen kann (mehr wird nicht gehen, da jede Funktion nur 10 KO hat). Das muss aber MDT wissen, hängt auch davon ab, wie viele Kunden so etwas wollen.

Gruß, Waldemar

[STSC]

Was auch noch ein Problem werden könnte, dass nach dem Reset "Zyklisch senden/abfragen" erst mal Müll auf den Bus sendet bis die Funktion "Wert speichern und nach Reset senden" kommt.