OpenKNX-Logikmodul release

[Alloc]

Hi, mir ist gerade aufgefallen, dass die einzelnen KO bei der Logik den Logiknamen nicht davor haben, so wie es zum Beispiel bei den PM-Kanälen ist:
image.png
Das heißt hier "muss" man eigentlich jedem Ausgang explizit einen eigenen Namen geben, damit man die Zuordnung direkt versteht, wenn man nicht immer im Kopf hat, welcher Logikkanal wofür war. Wenn hier entsprechend auch der Name des Logikkanals (und wenn nicht vergeben dann halt "Logik 1: ") davor wäre wie bei den PMs könnte das durchaus hilfreich sein.

Außerdem - und das ist dann wirklich ein Luxusproblem - wäre es glaube ich praktisch, wenn man die Ausgangs-KOs auch abschalten könnte, wenn man die Ausgabe intern in ein anderes KO schreibt. Sonst sammeln sich da in der Liste KOs die nicht verbunden sind. Und eigentlich (wenn man eben das interne Umleiten nicht hat) ergeben Logiken, deren Ergebnis nicht genutzt wird, ja recht wenig Sinn. Daher war das eben für mich kurz verwirrend, als ich da die beiden unbenutzten Ausgänge sah, weil ich dann dachte ich hätte wieder ungenutzte Kanäle nicht abgeschaltet

[mumpf]

Hi David, das ist mir am liebsten... User die ihre Probleme selber finden Gratuliere!

Gruß, Waldemar

[shortyle]

Hi zusammen,

ich hab da aktuell doch noch ein Problem mit dem Logikmodul. Es hatte bis vor kurzem auch funktioniert und ich weiß nicht was ich "verstellt" haben soll.

Worum geht es:
über 4 UND Logiken wird eine Wahrheitstabelle dargestellt, die in den Ausgängen die Tagesphase bestimmt.
gespeist werden die Logiken mit der Ausgabe einer ZSU (Normal oder Nacht) und einer Szenennummer.


Das passt soweit erstmal alles.
Wenn ich nun aber die Tagesphase anzeigen lasse, dann ist immer Tagesphase 4 obwohl diese Logik (Nummer 7) kein positives Ergebnis hat.

Im Busmonitor erscheint Folgendes:

Bildschirmfoto 2025-02-27 um 19.14.37.png

Ich habe alles schon zigmal durchgeschaut, finde den Fehler aber nicht.

edit: Problem gefunden - Die Einstellung "Logik auswerten" war falsch und hat auch bei nicht gültigen Werten ausgewertet.

[shortyle]

Das heißt aber auch, das Du über den KO Zugriff sehr wohl vom Logikmodul auf das Präsenzmodul zugreifen kannst.

das stimmt. Über einen „normalen Eingang“ kann ich auch ein „internes“ KO eines anderen Moduls aus der Applikation nutzen. Das hilft schonmal weiter

[willisurf]

Ja genau. Interne Eingänge des Logikmoduls beziehen sich nur auf das Logikmodul und sind eine andere Art der internen Verknüpfung, als der Bezug auf KOs (die Modulübergreifend im Gerät funktionieren).

Das heißt aber auch, das Du über den KO Zugriff sehr wohl vom Logikmodul auf das Präsenzmodul zugreifen kannst.

[shortyle]

Hi zusammen,
kurze Frage zum Logikmodul.
Kann ich die internen KOs vom Präsenzmodul ("Ausgang Präsenz" und "Bewegung") als interne Eingänge 3 und 4 eines Kanals verwenden?
Ich hätte vermutet, dass es geht, allerdings klappt es irgendwie nicht und auch im Diagnoseobjekt erscheint nur

A1 Bx Cx Dx Q1

.

Die Eingänge C und D sind im den internen absoluten Kanalnummern 21 und 22 ("Ausgang Präsenz" und "Bewegung") belegt.

---------------------------------
Just in dem Moment wo ich es schreiben, stelle ich fest, dass es wohl doch nicht so klappt, da damit nicht die KO Nummern gemeint sind sondern tatsächlich die (Ausgangs)Kanäle der Logiken.

Also muss ich es doch per separater GAs machen

[mxcxpx]

ich benutze die Zeitschaltuhr für die "morgens Jalousie-Auf" über 1bit telegram.

Mo-Fr 7.40 Uhr
Sa 8.30 Uhr
So+Feiertag 8.40Uhr

Leider geht Sonntags auch 8.30Uhr auf und ich verstehe nicht warum

woran könnte es liegen

(ich hatte anfangs auch die Urlaubsfunktion aktiviert aber ohne GA , da ist es dann immer um 7.40 Uhr aufgegangen.)

ich benutze die Logic im 8-Fach Schaltaktor FW0.2

[willisurf]

Ich denke, es war eher so was gemeint.

Ja Danke Waldemar, so ergibt es Sinn.

Das ist auch ein schönes Beispiel, warum es -neben dem Zugriff auf KOs- wichtig ist, die internen Verknüpfungen zu haben.

[mumpf]

da man dem telegramm nicht ansieht ob es von intern kommt oder extern, vermute ich keine extra behandlung.

Naja, wir wissen ja nicht, wie der knx-Stack vom DALI-Gateway funktioniert. Aber henfri, Du kannst es ja ausprobieren:
Setze bei dem KO, dass das Telegramm empfangen soll, nicht nur das S- sondern auch das A-Flag und mach einen ReadRequest auf die GA. Wenn das reicht, musst Du nichts mehr machen.

Gruß, Waldemar

[mumpf]

Aber ich kann einen Eingang, den ich einmal definiert habe nicht in einem zweiten Kanal verwenden (oder?).

Das hängt davon ab, wie Du Deine Logiken gestalten/strukturieren möchtest.

Aber hinter der GA/dem KO kommt ja noch so einiges, bevor es zur Logikverarbeitung kommt. Und das muss man halt zwischen den Kanälen synchron halten

Um Dein Beispiel leicht komplizierter zu machen (und so den Sinn des Vorgehens zu unterstreichen): Nehmen wir mal an, ich will für die Endlage meines Rollladens ein Bool-Trigger "Endlage" geschickt bekommen und über ein 2. KO eine Szene 5 auslösen.

2 Kanäle sind klar, die kann ich unabhängig definieren:

1. Kanal

• L: OR, 2 Eingänge, bei jedem Eingangssignal
• E1: DPT5.001, Wertintervall 0-5 (ich möchte die letzten 5% als Endlage haben)
• E2: DPT5.001, Wertintervall 95-100
• A: DPT1, EIN bei EIN, nichts bei AUS

2. Kanal

• L: OR, 2 Eingänge, bei jedem Eingangssignal
• E1: DPT5.001, Wertintervall 0-5 (ich möchte die letzten 5% als Endlage haben)
• E2: DPT5.001, Wertintervall 95-100
• A: DPT17, 5 bei EIN, nichts bei AUS

Hier hab ich das Problem, dass ich alle Eingänge aller Kanäle ändern muss, wenn ich beschließe, dass die Endlage bei 2% reicht.

Wenn ich aber folgendes mache:
1. Kanal

• L: OR, 2 Eingänge, bei jedem Eingangssignal
• E1: DPT5.001, Wertintervall 0-5 (ich möchte die letzten 5% als Endlage haben)
• E2: DPT5.001, Wertintervall 95-100
• A: DPT1, EIN bei EIN, nichts bei AUS

2. Kanal

• L: OR, ein interner Eingang, bei jedem Eingangssignal
• I1: Ausgang von Kanal 1
• A: DPT17, 5 bei EIN, nichts bei AUS

Hier nutze ich die 1. Logik und ergänze nur einen weiteren Ausgang. Das kann man auch weiter strukturieren und verteilen. Will ich z.B. den Bool zyklisch und die Szene nach 5 Sekunden haben, kann man das im ersten Beispiel über 2 Kanäle lösen, will man wiederverwendbare Teile nutzen, macht man das mit 3 Kanälen:

1. Kanal

• L: OR, 2 Eingänge, bei jedem Eingangssignal
• E1: DPT5.001, Wertintervall 0-5 (ich möchte die letzten 5% als Endlage haben)
• E2: DPT5.001, Wertintervall 95-100
• A: sendet nichts

2. Kanal

• L: OR, ein interner Eingang, bei jedem Eingangssignal
• I1: Ausgang von Kanal 1
• A: Einschaltverzögerung 5 Sekunden, DPT17, 5 bei EIN, nichts bei AUS

3. Kanal

• L: OR, ein interner Eingang, bei jedem Eingangssignal
• I1: Ausgang von Kanal 1
• A: Zyklisch senden alle 330 Sekunden, DPT1, EIN bei EIN, nichts bei AUS

und so weiter... deswegen habe ich auch relative Adressierung im Logikmodul eingeführt, so kann man Logikblöcke bauen und kopieren/verschieben, um bei Bedarf mehr Platz zu schaffen.

willisurf Ich denke, es war eher so was gemeint.

Gruß, Waldemar

[traxanos]

Hier ist ja die Frage, wie das Dali GW damit umgeht.

da man dem telegramm nicht ansieht ob es von intern kommt oder extern, vermute ich keine extra behandlung.

[henfri]

Ja, das ist schon klar. Aber hinter der GA/dem KO kommt ja noch so einiges, bevor es zur Logikverarbeitung kommt. Und das muss man halt zwischen den Kanälen synchron halten. Darum ging es mir.

[willisurf]

Aber ich kann einen Eingang, den ich einmal definiert habe nicht in einem zweiten Kanal verwenden (oder?).

Du kannst ja mit direkter KO Verknüpfung darauf zugreifen und musst die GA nur einmal verknüpfen. Wenn ich Dich richtig verstanden habe

[henfri]

Hier ist ja die Frage, wie das Dali GW damit umgeht.

[traxanos]

aber ja nicht auf seine eigene Antwort hören

eigentlich schon. der verwendete NCN gibt die Telegramme immer direkt wieder ans Gerät zurück. Wenn also auf Applikationsebene nichts "gefiltert" wird, bekommen die Gerät ihre eigenen Telegramme wieder rein.

Wie das Logikmodul das handhabt kann ich gerade nicht sagen.