OpenKNX-Logikmodul release

[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

[shortyle]

Szenen 1-4 werden auf dem Bus als 0-3 übertragen.

oh man...stimmt ja. Aber ist es korrekt mit den DPT Szenen für die Verwendung im VPM?

Hier mal die Statusausgaben der 4 Logiken ganz aktuell (die ZSU 2-4 scheinen also nicht zu laufen)

L01 = Ax B1 Cx Dx Q1
L02 = Ax Bx Cx Dx Qx
L03 = Ax Bx Cx Dx Qx
L04 = Ax Bx Cx Dx Qx


Die Schaltzeiten sind wiefolgt definiert

L01 jeder - Sonnenaufgang minus Zeitversatz 00h 30m Ein
L02 jeder - Sonnenaufgang plus Zeitversatz 01h 00m Ein
L03 jeder - Sonnenuntergang minus Zeitversatz 00h 30m Ein
L04 jeder - Sonnenuntergang: Spätestens 22h 00m Ein

edit:// Hier sehe ich gerade selber das sich L03 und L04 beißen...da muss ich nochmal ran

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

Und hier noch die Geräteinfo
Bildschirmfoto 2023-10-20 um 09.32.36.png


Zum Schluss nochmal die Parameter der Tagesphase die jetzt eigentlich gültig sein müsste L02
Bildschirmfoto 2023-10-20 um 09.36.31.png Bildschirmfoto 2023-10-20 um 09.36.51.png Bildschirmfoto 2023-10-20 um 09.37.08.png

[mumpf]

Szenen 1-4 werden auf dem Bus als 0-3 übertragen.

[mumpf]

Hi David,

Ich traue mich ja schon gar nicht mehr zu fragen

Ich möchte betonen, dass man hier immer fragen darf. Ich kann manchmal nicht sofort antworten, netterweise macht auch willisurf mit beim Beantworten der Fragen. Es ist ja auch ein komplexes stück Software, dass wir da haben - das bringt die Flexibilität mit sich.

Was ich aus Deinem - wirklich ausfühlichen (DANKE) - Protokoll lese:

• Die eine Zeitschaltuhr, die wir sehen, ist vernünftig definiert, wie willisurf schon sagte, die AUS-Zeiten sind nicht nötig
• Du hast auch "Den letzten Schaltpunkt nachholen" angehakt, auch prima, dann hast Du nach dem Neustart immer eine passende Tagesphase, allerdings nur, wenn die Zeitintervalle der 4 Zeitschaltuhren keine Lücken haben! Hier vermute ich ein mögliches Problem (also eine Lücke)
• Der Status für L1 ergibt ein Q0, diese Zeitschaltuhr wurde ausgeführt (hier wurde eine Zeit getroffen), das Ergebnis ist 0, also war die Zeit später as "Sonnenaufgang + 1h". Die Zeitschaltuhr hat dann eine 0 gesendet, der Ausgang sendet kein AUS.
• Keine der anderen Zeitschaltuhren war bisher aktiv (Qx).
• Somit ist das Ergebnis richtig, da ein AUS nicht gesendet wird.

Ich würde jetzt sagen, dass Du die Zeitintervalle nicht korrekt definiert hast... AUSSER Du verwendet nicht die neuste Version des Logikmoduls. Ich hatte vor nicht allzu langer Zeit einen Bug bei der Berechnung vom Zeitversatz.

Schick mir mal die Geräteinfo für das Gerät, auf dem das Logikmodul läuft. Ich schaue dann, ob in der Version die Korrektur des Logikmoduls schon drin ist.

Gruß, Waldemar

[shortyle]

Hab die Flags jetzt mal entsprechend angepasst.
Bildschirmfoto 2023-10-20 um 08.58.27.png

Komisch ist jetzt, dass er als Ergebnis "0" liefert. Wobei ich "0" ja nie definiert habe in den 4 Logiken sondern nur 1-4.
Bildschirmfoto 2023-10-20 um 09.11.31.png

Bei R07:42 und S18:08 sollte er ja als Wert 2 ausgeben.
Kann es an den DPT liegen, im Busmonitor gibt er es als DPT5.005 aus. In den Einstellungen hatte ich es ja als Ausgabe mit 17.001 definiert?!

Eine normale ZSU funktioniert. gerade getestet.

[willisurf]

Datum und Uhrzeit sind verknüpft und werden bei Diagnose mit "t" korrekt zurückgespielt.

Gut. Funktioniert denn eine ganz normale Zeitschaltuhr mal probeweise auf einem Kanal?

Das mit den AUS Zeiten hatte ich auch nur eingerichtet weil es ohne diese auch nicht funktioniert hat.

Das ist merkwürdig und sollte so nicht sein.

Bei den Flags stehe ich ein wenig auf dem Schlauch. Also nur bei Kanal 1 (von den besagten 4) die Flags K, L, S, Ü setzen und bei den anderen 3 nur K und Ü?

Ja genau. Sinn der Einstellung ist, das Du bei einem ReadRequest auf der mit 4 KOs verknüpften GA eine eindeutige Rückmeldung bekommst, auch wenn der 2., 3. oder 4. Kanal zuletzt aktiv war.