MDT Logikmodul SCN-LOG1.02: Praktische Beispiele

[evolution]

Inzwischen denke ich einfach, dass wir über genau das selbe reden

[PhilW]

N'Abend,

nur für mein Ego , und auch wenn die Funktion für mein Vorhaben nicht richtig gewesen wäre, wäre ich doch mit meiner damaligen Frage https://knx-user-forum.de/forum/%C3%...66#post1294466 dann auf dem richtigen Weg gewesen und das hätte funktioniert, oder?

Gruss
Guido

[mumpf]

Thema: Duscherkennung über Luftfeuchte

Hi,

da mir meine Duscherkennung (also die Info "Es wird geduscht") über den Temperaturfühler an der Abwasserleitung der Dusche zu lange dauerte (Status ist erst nach 50-90 Sekunden da), habe ich mal versuchsweise das Ganze über die Luftfeuchte versucht, da mein Luftfeuchtesensor in der Nähe der Dusche ist und ich im Gruppenmonitor eine deutliche Erhöhung der Luftfeuchte beim Duschen beobachten konnte.

Idee: Ich beobachte, ob sich die Luftfeuchte innerhalb einer Minute sprunghaft um mehr als 5% nach oben verändert hat. Dazu braucht man einen Vergleicher:
DuscherkennungVergleicher.PNG
Jetzt brauche ich noch 2 Werte zum vergleichen. In meinem Falle ist Wert1 die aktuelle Luftfeuchte, Wert2 die Luftfeuchte vor einer Minute. Um jede Minute den Wert2 für eine Minute zu speichern, nehme ich den Universal-Rechner:
DuscherkennungVergleichswert.PNG
Der Addiert zum Eingang1 (aktuelle Temperatur) den Wert 0. Somit bleibt es bei der Temperatur. Der Trick hier ist, dass der Wert am Ausgang durch "Senden bei Impulseingang" und "sende alle Ausgänge bei EIN" erst dann erscheint, wenn am Impulseingang eine 1 ankommt. Und diese 1 lasse ich durch das Minutensignal des Logikmoduls erzeugen. Somit habe ich dann jede Minute einen Wert am Ausgang, den ich in der folgenden Minute mit der aktuellen Luftfeuchte vergleichen kann.

Was soll ich sagen, bisher (in den letzen 4 Tagen) hatte ich immer ein "es wird geduscht" innerhalb von 12-27 Sekunden auf dem Bus gehabt. Schlimmstenfalls kommt der Wert nach etwas mehr als einer Minute, was immer noch besser ist, als die alte Logik im Durchschnitt gebracht hat.

Hier noch die relevanten KO:
DuscherkennungParameter.PNG

Vielleicht nutzt das jemanden als Anregung,
Gruß, Waldemar

P.S.: Falls jemand eine bessere Idee hat, das zu realisieren (z.B. mit nur einer Funktion), nur her damit...

[trollvottel]

mumpf Interessanter Ansatz. Nur interessehalber: Was machst Du dann mit der Information "Es wird gerade geduscht"?

Ich habe direkt am Eingang zur Duschnische einfach einen Bewegungsmelder zur Erkennung; Nutze das bisher aber nur für Beleuchtungszwecke..

[PhilW]

Ich mache z.B. die Spiegelheizung an, damit der Spiegel nicht beschlägt. Allerdings bin ich mit der unregelmässigen Luftfeuchte und damit mit der nicht zuverlässigen Steuerung sehr unzufrieden.
Insofern, vielen Dank Waldemar, ich werde den Ansatz mit der sprunghaften Anstieg mal verfolgen.

Gruss
Guido

[mumpf]

Was machst Du dann mit der Information "Es wird gerade geduscht"?

Bei mir ist es ähnlich wie bei PhilW:

• Ich mache die Spiegelheizung an, hier allerdings auch noch in Abhängigkeit zum Taupunkt beim Duschbeginn (ist aber eine Logik in der Logikengine, nicht wirklich fürs Logikmodul geeignet)
• Ferner wird die Farbdusche (RGBW Effektbeleuchtung Dusche) eingeschaltet - das ist der Hauptgrund, warum die alte Lösung zu langsam war...
• Und der PM wird nachgetriggert, der schaut nicht in die Dusche rein (ich hatte einen, der reinschauen konnte, hat mir aber aus anderen Gründen nicht gefallen, deswegen habe ich den durch einen Temp- und Luftfeuchte-Fühler ersetzt).

Gruß, Waldemar

[mumpf]

Hi,

nachdem ich in der letzten Zeit viele der in meiner KNX-Anlage vorhandenen Logiken ausprobiert habe, muss ich mich nochmal lobend zum MDT Logikmodul äußern.

Die eigentliche logische Funktion, sei es ein Logik-Gatter, eine Wertetabelle, eine Berechnung oder eine DPT-Wandlung, ist normalerweise schnell gemacht.
Dann geht es allerdings darum, dass diese Logik produktiv funktioniert, und zwar unter möglichst vielen (idealerweise allen) unerwarteten Bedingungen. Hier sind 2 Bedingungen besonders wichtig: Nach einem Stromausfall (also die gesamte Anlage war vorher tot) und nach einer Neuprogrammierung des Logikmoduls selbst (weil man z.B. an einer anderen Logik noch „rumfeilt“). Die 3. immer wiederkehrende Bedingung, auf das neuprogrammieren irgendeines anderen KNX-Gerätes zu reagieren, bekommt übrigens keiner hin (zumindest habe ich keinen Weg gefunden, ich lasse mich aber gerne vom Gegenteil überzeugen).

Aber schon bei den ersten beiden Bedingungen trennt sich die Spreu vom Weizen, oder ins KNX übersetzt: Daran sieht man, ob die Logiken in den Geräten „nur Beigabe“ sind, oder ob man sie mit der Intention bereit stellt, auch produktiv genutzt zu werden. Einstellungen, die es erlauben, beim Neustart des Gerätes

• eine Weile zu warten, bevor die Buskommunikation beginnt (beim Logikmodul würde ich mir das für jede Funktion einzeln wünschen)
• Eingangswerte aktiv vom Bus zu lesen (anstatt z.B. den letzten Wert oder eine feste Vorbelegung zu fordern)
• mit dem Senden des Ausgangswertes zu warten, bis wirklich alle Eingänge einen Wert erhalten haben

sind hier Gold wert und ich bin sehr froh, dass man an solche Sachen beim MDT Logikmodul gedacht hat. Auch wenn es bei einigen Funktionen noch Verbesserungspotential gibt (ich habe an anderer Stelle schon passendes Feedback gegeben), muss ich sagen, dass die anderen Logiken, die nur „Beigabe“ sind, da bei weitem nicht mitkommen.

Insofern an dieser Stelle nochmal ein großes Lob von mir, ich bin sehr zufrieden mit dem, was es schon gibt und freue mich auf ein Update mit hoffentlich neuen Features bzw. korrigierten bereits bekannten Funktionen.

Gruß, Waldemar

[knxzzz]

Hi mumpf ,

wie hast du das Objekt für stopp mit reinverarbeitet?
Habe alles so nachgebaut und funktioniert auch. Nur wenn das Tor fährt kann ich nicht stoppen. :-(
Danke dir!

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

[mumpf]

Naja, ich habe Stop (also die selbe GA) auch direkt mit dem Budde-Modul verbunden. Das klappt dann. Die Logik läuft ja nur, wenn das Tor steht. Wenn es also fährt, führt der Stopp zum Stopp.

Gruß, Waldemar

[knxzzz]

Naja, ich habe Stop (also die selbe GA) auch direkt mit dem Budde-Modul verbunden. Das klappt dann. Die Logik läuft ja nur, wenn das Tor steht. Wenn es also fährt, führt der Stopp zum Stopp.

Gruß, Waldemar

Habe auch das Budde modul

Habe eine GA für auf abd und eine für stopp (egal ob 0 oder 1 kommt).
Wie genau hast du das umgesetzt? Verstehe es noch nicht wirklich. ;-)

[mumpf]

Hi,

ich dachte, es funktioniert bei Dir schon und nur Stopp geht nicht? Du brauchst folgendes:

Taster (bei mir kurz/lang, kann aber natürlich auch anders belegt werden):
KO1: zum fahren (sendet beim Tastendruck eine 1)
KO2: zum stoppen (sendet beim Tastendruck eine 1)

Logik:
KO3: Eingang Taster
KO4: Eingang Tor fährt
KO5: Eingang Tor ist unten
KO6: Ausgang Tor Richtung

Garagenaktor (z.B. Budde-Modul):
KO7: Eingang Tor fahren
KO8: Eingang Tor stoppen
KO9: Ausgang Tor fährt
KO10: Ausgang Tor ist unten

Jetzt verbindest Du:
KO1 mit KO3, KO2 mit KO8, KO4 mit KO9, KO5 mit KO10, KO6 mit KO7.

Das wars.

Gruß, Waldemar

[knxzzz]

Hi,

ich dachte, es funktioniert bei Dir schon und nur Stopp geht nicht? Du brauchst folgendes:

Taster (bei mir kurz/lang, kann aber natürlich auch anders belegt werden):
KO1: zum fahren (sendet beim Tastendruck eine 1)
KO2: zum stoppen (sendet beim Tastendruck eine 1)

Logik:
KO3: Eingang Taster
KO4: Eingang Tor fährt
KO5: Eingang Tor ist unten
KO6: Ausgang Tor Richtung

Garagenaktor (z.B. Budde-Modul):
KO7: Eingang Tor fahren
KO8: Eingang Tor stoppen
KO9: Ausgang Tor fährt
KO10: Ausgang Tor ist unten

Jetzt verbindest Du:
KO1 mit KO3, KO2 mit KO8, KO4 mit KO9, KO5 mit KO10, KO6 mit KO7.

Das wars.

Gruß, Waldemar

Ahh. Die info hat mir gefehlt.
stop auf die lange Taste zu legen.
ja, die Logik mit der Steuertabelle läuft soweit.
dachte, du kannst während der Fahrt mit einem kurzen Tastendruck (gleiche ga wie der trigger für Tor fahren) das Tor stoppen.

danke dir !

[mumpf]

Hi,

habe ich nicht ausprobiert, aber sollte auch klappen. Verbinde mal einfach KO1 mit KO8 und probier es aus. Hintergrund:

Wenn Tor steht (wo auch immer):
KO1 sendet eine 1.
Die 1 kommt beim KO8 an, da das Tor steht, macht das nichts.
Gleichzeitig kommt die 1 bei der Logik an und erzeugt einen Fahrbefehl. Da die Logik einige Zeit braucht, wird der Fahrbefehl auf jeden Fall nach dem Stopp ankommen, also sollte das Tor fahren.

Wenn Tor fährt:
KO1 sendet eine 1.
Die 1 kommt beim KO8 an, das Tor stoppt.
Gleichzeitig kommt die 1 bei der Logik an, da liegt aber noch der Status "Tor fährt" an und so geht die Logik ins leere.

Könnte klappen. Dann brauchst Du kein Stopp auf lang zu legen, könntest es aber auch lassen, als Fallback...

Gruß, Waldemar

P.S.: Das klappt aber nicht, wenn bei Dir irgendwelche Telegrammwiederholungen passieren wegen fehlenden ACKs auf dem Bus. Insofern sind solche Logiken, die sich auf Telegrammreihenfolge im Millisekundenbereich verlassen, potentiell unzuverlässig.

[lo4dro]

Kann ein "Ausgang" blinken , wenn am "Eingang" eine 1 ansteht?
Hintergrund: Ein Binärmodul wird für die Zustandsabfrage einer Heizung benutzt.
Bei einer Störung soll an einem Taster in der Wohnung eine LED Blinken.
Wenn der Brenner läuft nur leuchten.

Im Taster gibt es kein geeignetes Funktion die das erfüllen kann.

[trollvottel]

Das ginge schon. Aber das Timing wäre vom Bus abhängig, d.h. das Blinken ist "nervös", je nach Buslast oder Verzögerungen der Telegramme. Das blinkt dann ähnlich unrhythmisch wie so mancher Blinker in Autos, wo der Bordcomputer der Taktgeber sein soll, aber gleichzeitig noch andere Dinge zu tun hat.