OpenKNX-Logikmodul release

[mumpf]

Lexxs und willisurf: Hatte die Frage gar nicht gesehen... ist schon irre, was ihr da rausholt. Ist sicherlich keine triviale Logik.
willisurf: Eine gute Idee, von meinem Zähler auszugehen.
Lexxs: Es ist immer etwas schwierig, sich in eine fremde Logik einzudenken, aber soweit ich das verstanden habe, schaltest Du direkt Dein Gerät direkt über die 3/0/10 EIN. Diese GA schaltet dann auch die ganze Zähllogik ein. Der Vergleicher, der auf > 10s prüft, wird aber nur vom Zähler getriggert, der nächste Zählimpuls führt also erst zum Vergleich und zur Generierung des AUS-Signals.

Bei der Konstellation KANN die Logik nichts machen: Das EIN auf der 3/0/10 führt immer zum Einschalten vom Gerät, da ist die Logik ja gar nicht beteiligt.
Und dass das AUS erst nach ca. 1s kommt, liegt daran, dass erst beim nächsten Erhöhen des Zählers überhaupt vergleichen wird.

Was musst Du machen:

• Die Logik muss auf jeden Fall selbst das Gerät EIN- und AUSschalten. Dein EIN-Signal von Außen muss also auf einer anderen GA liegen als die Schalt-GA des Geräts. Nur dann kann die Logik entscheiden, dass kein EIN-Signal generiert wird.
• Du musst den Vergleicher auf so bauen, dass er zusätzlich zum Zählwert auch vom EIN-Signal getriggert wird. Dann kann er sofort vergleichen und abhängig vom Zähler ein EIN- oder ein AUS-Signal generieren.

Und noch ein paar Kleinigkeiten, die mir aufgefallen sind:

• Zähler sollte ganzzahlig sein, nicht DPT9. Die werden spätestens oberhalb von 2047 ungenau. Ich würde auf DPT7 (geht bis 65535) oder - falls es wirklich groß wird - auf DPT12 gehen.
• Eigentlich sollten weniger Logikkanäle gehen. Ich bin im Urlaub und kann das nicht ausprobieren, aber folgende Idee hätte ich:
  • Erste Optimierung: Kanal 21 ist nicht nötig. Kanal 22 kann im EIN-Fall zyklisch im 1s-Takt senden.
  • Bei Kanal 23 fehlen mir die KO-Zuordnungen, aber für mich sieht das überflüssig aus, falls wirklich am Eingang 1 und Ausgang die GA 3/0/10 anliegt. Ist sogar eher gefährlich, weil es eine Rückkopplung ist.
  • Kanal 24 ist ok so
  • Kanal 25 verstehe ich nicht, warum E1 vom Bus lesen soll, da der Zählerwert ja vom Logikmodul verwaltet wird.
  • Kanal 25 sollte nicht nur ein EIN, sondern auch ein AUS generieren.
  • Kanal 25 sollte ein TOR sein, bei dem das TOR durch das externe Einschaltsignal des Gerätes geschaltet wird.
    • Kommt von extern ein EIN, wird das TOR geöffnet und sendet sein Eingangssignal auf den Ausgang.
    • Das Eingangssignal ist EIN, wenn Zähler <= 10 (so musst Du Einang 1 parametrisieren), dann wird auch EINgeschaltet.
    • Ist der Zähler > 10, ist das Eingangssignal 0, es wird AUSgeschaltet.
    • Schaltet man extern AUS, wird das TOR geschlossen und schickt ein AUS auf den Ausgang.

Am Ende hast Du die ganze Logik mit 3 Logikkanälen gelöst (22, 24 und 25). Finde ich für einen Betriebszeitzähler gar nicht mal so schlecht. Vor allem, weil ich an so einen Fall gar nicht gedacht habe .

Gruß, Waldemar

[willisurf]

Lexxs einfach nur ein Beispiel und etwas Reserve. Du kann auch 11 oder 13 versuchen.

[Lexxs]

willisurf Wie genau kommst du auf 15 x 0,1s ? Also wieso 15 und nicht z.B. 10 x 0,1s?

EDIT:
Leider funktioniert die EINschaltverzögerung nicht. Es wird dennoch ca eine weitere Sekunde EINgeschaltet.

[willisurf]

Ohne das ich mir die Logik angeschaut habe, das lässt sich wahrscheinlich vermeiden, wenn Du beim Ausgangskanal eine Einschaltverzögerung von z.B. 1,5s (15 x 0,1s) einstellst.

[Lexxs]

Hallo alle zusammen,

also mein Vorhaben aus Post #222 hat an sich auf anhieb wie es willisurf aus Post #223 es beschrieben hat funktioniert.
Jedoch habe ich eine Sache die ich meines Wissens nur mit einem Zusätzlichen Logikkanal umsetzen lässt, was ich jedoch vermeiden möchte.

Folgende Problematik besteht:

Wenn die maximale EINschaltzeit (für derzeitige Testzwecke 10 Sek. eingestellt) erreicht ist und ich dennoch danach erneut ein EIN-Schaltbefehl für z.B. eine Pumpe geben, wird diese leider erneut für ca. 0,5 - 1 Sekunde EINgeschaltet, siehe dazu Bild "Gruppenmonitor". Dies ist selbstverständlich nicht zugelassen und sollte nicht passieren.

Eventuell befindet sich ein Fehler in den Einstellungen des Logikmoduls... oder muss wirklich ein zusätzlicher Logikkanal aktiviert werden um dort eine Sperre zu verknüpfen die wiederum zusammen mit einem GESAMT-UND zusammen verknüpft ist, damit kein EINschaltbefehl durch kommt?

[Lexxs]

Vielen Dank für den Input willisurf das klingt schon sehr nach der Lösung. Ich werde es austesten.

P.S.: Frohes neues Jahr euch allen!

[mumpf]

der dann bei einzelnen manuell eingeschalteten Lampen dies auch mitbekommt und entsprechend dann die Lampen irgendwann ausschaltet (Wohn-Essbereich AUS).

Hmmm, ich bin mir nicht sicher, was Du wirklich willst, aber vielleicht brauchst Du auch gar kein ODER. Du willst doch Deinen Halbautomaten nur mit jedem manuellen Schaltsignal triggern, oder? Damit die Nachlaufzeit erneut anläuft. Geht es um ein normales Treppenlicht oder einen PM?
Wenn es um ein normales Treppenlicht geht, kannst Du das mit einem einzigen Logikkanal meines Logikmoduls machen, egal wie viele Lichtquellen dran sind.

Beschreib einfach Dein gesamtes Problemszenario, ohne schon eine Lösung vorwegzunehmen, dann kann Dir besser helfen.

Gruß, Waldemar

[willisurf]

Ja genau, für 8 Eingänge eines ODER sind es vier Kanäle, die ja je 2 Eingänge für KOs haben.
Die notwendigen Verknüpfungen sind dann über die internen Eingänge (je Kanal ebenfalls zwei) möglich.

Klingt kompliziert, ist aber schnell zusammengeklickt und Kanäle gibt es ja genug.

[c4orbi]

Ich möchte mit dem Logikmodul gern einige Status Rückmeldungen von den Aktoren im Wohn-/Essbereich verodern und das Ergebnis auf einen Halbautomat geben, der dann bei einzelnen manuell eingeschalteten Lampen dies auch mitbekommt und entsprechend dann die Lampen irgendwann ausschaltet (Wohn-Essbereich AUS).

So wie ich das sehe, muss ich z.B. bei 8 Logikeingängen entsprechend viele ODER Glieder kombinieren/kaskadieren oder gibt es eine komfortablere Möglichkeit?

[willisurf]

Mit den Logiken geht eigentlich nahezu alles, das hier ist schon hohe Schule.

In Stichworten, es soll ja noch etwas zum Knobeln und testen übrig bleiben:
Doku ist sicherlich auch hilfreich.

Grundlage könnte der Zählerbaustein sein, der hier beschrieben ist. .
Dann auf Minutenbasis. Minutentakt über ZSU generiert und am besten nur intern verknüpft. Zähler zählt nur, wenn Pumpe eingeschaltet ist (TOR). Siehe auch hier
Rücksetzen dann zu einer wählbaren Zeit einmal täglich über die Zeitschaltuhr
Ein Vergleicher sperrt bei Zählerstand größer 60 ein TOR, das bei geschlossenem Tor ein Aus sendet, ansonsten das Schaltsignal durchlässt (sendet das Eingangssignal)

[Lexxs]

Hallo alle zusammen und frohe Weihnachten an euch!

Ich wollte hier mal nachfragen ob jemand wüsste ob es möglich wäre mit einem oder mehreren Logikkanäle folgendes zu realisieren...

Gerne würde ich eine maximale EIN-Schaltzeit pro Tag realisieren.
D.h. eine Pumpe darf z.B. am Tag maximal 1 Stunde laufen. Sie kann somit so oft EIN- und AUS-geschaltet werden solange die Pumpe die gesamt EIN-Schaltzeit nicht über eine Stunde hinaus geht. Andernfalls wird die Pumpe nach der einen Stunde abgeschaltet und kann erst am nächsten Tag wieder eingeschaltet werden.


Gruß Lex

[shortyle]

Ja genau…es lag an den fehlenden nachholen der schaltzeiten nach Neustart. Jetzt aktuell läuft „Nacht“ (Szene 4). so wie es sein soll.

nochmal aller besten Dank für die Unterstützung. Ihr seid coole Dudes

[mumpf]

Heißt das, es geht jetzt? Würde mich freuen.

Gruß, Waldemar

[shortyle]

Super vielen Dank. So langsam kommt da doch Licht ins Dunkel.

[mumpf]

Hi David,

ich hab mal nachgeschaut. Die Version 1.11. vom VPM hat schon das Logikmodul 1.5.1, in den ist das Problem mit den Zeiten gefixed.

Aber ist es korrekt mit den DPT Szenen für die Verwendung im VPM?

Ja, das ist korrekt. Deswegen gibt es ja die DPT: Wenn sender und Empfänger den gleichen DPT haben, dann verstehen sie sich.

Müsste dann jetzt aber nicht L02 einen plausiblen Status ausgeben?

Ja... wenn Du auch bei dieser Zeitschaltuhr "Den letzten Schaltpunkt berechnen" angekreuzt hättest . So wie es jetzt ist, wird morgen einfach bei Sonnenaufgang+1h die Zeitschaltuhr senden.

Und ich muss mich korrigieren: Mach die AUS-Zeiten wieder rein. Da das getrennte Zeitschaltuhren sind, würdest Du sonst beim Neustart um z.B. 23 Uhr nacheinander folgendes gesendet bekommen:

• Szene1: Es ist ja nach Sonnenaufgang-30min (ZS1 ist aktiv)
• Szene2: Es ist ja nach Sonnenaufgang+1h (ZS2 ist aktiv)
• Szene3: Es ist ja nach Sonnenuntergang-30min (ZS3 ist aktiv)
• Szene4: Es ist ja nach 22 Uhr

Wenn Du die Endzeiten auf AUS setzt, wir das nicht mehr passieren. Summa Summarum hat alles funktioniert, nur der Startzustand war nicht korrekt definiert (wegen fehlendem "Den letzten Schaltpunkt berechnen" bei ZS2-4. Morgen hättest Du die richtigen Tagesphasen auf dem Bus gehabt.

Und das ist auch ein Beispiel, warum es wichtig ist, immer alle Parameter mitzuschicken. Du hattest exemplarisch ZS1 mitgeschickt, da war das ""Den letzten Schaltpunkt berechnen" angekreuzt, ich ging natürlich davon aus, dass es auf allen anderen auch der Fall ist. Und auch wenn Du Fehler beschreibst, schreibst Du ja immer nur das, was Du MEINST gemacht zu haben, aber nicht das, was wirklich gemacht wurde . Ich wollte das nur hier erwähnen, weil es ganz gut zeigt, wie sehr kleine Details zu einer Verhaltensänderung führen können.

Und für alle, die das mitlesen und denken "Mensch, das ist ja kompliziert": Viele Applikationen erlauben es gar nicht, das Startverhalten zu beeinflussen und es exakt so einzustellen, wie man es will. Wenn es dann nicht passt, muss man nach einem Neustart immer warten, bis sich das Haus "einschwingt". Das ist dann eben nur SCHEINBAR einfacher.

Gruß, Waldemar