OpenKNX-Logikmodul release

[thilog]

Wenn man Szenen lesbar haben will, muss man immer aufpassen. Wenn die alle auf die gleiche GA senden sollen, dann kann man bei einem der KO das S-Flag setzen und bei den anderen das L-Flag entfernen, und schon hat man nur einen, der antwortet.

Ich hab geschaut, dass die Schaltuhren disjunkte Schaltzeiträume auf EIN haben und nur bei EIN auf den Bus schreiben. Das scheint auch bei GroupReadRequsts zu funktionieren.

[thilog]

Ich versuch mal das einzukreisen:
Wenn Du die Einstellung "Urlaub wie Sonntag behandeln" entfernst, wirst Du (hoffentlich) das gewünschte Ergebnis erhalten. Oder Du wartest einfach, bis die nächste Schaltzeit erreicht ist.

Danke, das hatte ich überlesen. Hab die Urlaubsregelung erst einmal rausgenommen - damit bekomme ich gerade in einer Phase häufiger Änderungen zuverlässig einen Zustand auf den Bus bekommen.

Noch eine blöde Frage: Ich würde gerne ein externes potenzialfreies Klingelrelais via GPIO auf den Bus bringen. Ich vermute, dazu muss ich Code schreiben. Hast du (oder ein anderer Wissender ;-) ) einen Tipp, ob es dazu schon ein Beispiel oder ähnlichen Code gibt, von dem ich mich inspirieren lassen kann?

[mumpf]

Wenn man Szenen lesbar haben will, muss man immer aufpassen. Wenn die alle auf die gleiche GA senden sollen, dann kann man bei einem der KO das S-Flag setzen und bei den anderen das L-Flag entfernen, und schon hat man nur einen, der antwortet.

Gruß, Waldemar

[traxanos]

Ja, ist prima so. Mach ich auch. Man könnte natürlich auch bei AUS noch was senden lassen und so vielleicht eine Zeitschaltuhr sparen.

Dann läufst du aber Gefahr, falls du die Szene per LESEN Abfragen möchtest, das du verschiedene Antworten bekommst. Oder du musst darauf achten das kein Lesen möglich ist und das Flag entfernen.

[mumpf]

Ich versuch mal das einzukreisen:

Code:

#define SCHEDULE_MAX_CALLBACKS 10
Bedeutet das, dass ich nur maximal 10 Zeitschaltuhren definieren darf oder hab ich die Abstraktion noch nicht ganz verstanden? ;-)

Das ist intern und für callbacks von Hardware (üblicherweise Sensoren) zu unserem Hardwarelayer verantwortlich und hab nichts mit dem Logikmodul zu tun.
Jeder Kanal kann eine Zeitschaltuhr sein.

Ist die Definition eines dreiphasigen Tagesverlaufs über drei disjunkte Zeitschaltuhren korrekt oder hat sich der Autor das anders gedacht? ;-)

Ja, ist prima so. Mach ich auch. Man könnte natürlich auch bei AUS noch was senden lassen und so vielleicht eine Zeitschaltuhr sparen. Aber grundsätzlich sollte man Zeitschaltuhren so verwenden können, wie man Lust dazu hat.

auch ein Read-Request auf der GA wird nicht beantwortet.

Das ist insofern korrekt, als dass das Logikmodul intern 3 Zustände verwaltet: true, false und init. Uns solange etwas auf init steht, hat es KEINEN Wert. Und das heißt für ein KO, KEINE Antwort beim lesen.

Sende ich "l10" an das Debug-KO erhalte ich als Ergebnis "Ax Bx Cx Dx Qx".

Da muss ich gestehen, dass ich bei den Zeitschaltuhren nicht sicher bin, ob ich diese Debug-Info versorge. Ich hab die sehr viel beim Debugging von "normalen" Logiken verwendet, aber bei den Zeitschaltuhren fürchte ich ist da nichts programmiert. Aber es ist eine gute Anregung, da was zu machen. Bin sehr für Hilfe zur Selbsthilfe, sorry dass ich da noch nichts habe.

Ideen? Was mache ich falsch?

Ich gehe davon aus, dass Du gleich nach dem Neustart erwartest, dass die Tagesphase gesendet wird, wegen "Bei Neustart letzte Schaltzeit nachholen".
Du hast aber auch Urlaubsbehandlung aktiviert. In der Anleitung steht (https://github.com/OpenKNX/OAM-Logic...zeit-nachholen):

Achtung: Zeitschaltuhren, die Urlaubstage berücksichtigen, können bei der Nachberechnung der Zeitschaltpunkte nicht mit einbezogen werden, da die Information "Urlaubstag" per KO von extern dem Modul über den Bus gemeldet wird und somit nicht für die (historische) Nachberechnung zur Verfügung steht. Somit werden bei der Nachberechnung alle Zeitschaltuhren mit einer anderen Angabe als "Urlaub nicht beachten" ignoriert.

Wenn Du die Einstellung "Urlaub wie Sonntag behandeln" entfernst, wirst Du (hoffentlich) das gewünschte Ergebnis erhalten. Oder Du wartest einfach, bis die nächste Schaltzeit erreicht ist.

Gruß, Waldemar

[thilog]

Ich sehe gerade im Quellcode des Moduls:

#define SCHEDULE_MAX_CALLBACKS 10​

Bedeutet das, dass ich nur maximal 10 Zeitschaltuhren definieren darf oder hab ich die Abstraktion noch nicht ganz verstanden? ;-)

[thilog]

Nö, das ist ein Bug. Korrektur hilft aber nicht. Aktuell sollte die Tagesphase "Abend" sein, Parametrierung wie folgt:

image.png

Ausgang (bis auf EIN = Szene 2) identisch mit "Tag".

Verdrahtung der KO auch unverfänglich:

image.png
Zustand auch hier "Ax Bx Cx Dx Qx".

Edit: Ist die Definition eines dreiphasigen Tagesverlaufs über drei disjunkte Zeitschaltuhren korrekt oder hat sich der Autor das anders gedacht? ;-)

[willisurf]

Ist beim Ausschalten in Zeile 8 Sonnenaufgang richtig?

[thilog]

Uhrzeit und Datum sind verknüpft, reagieren auf ReadRequest und werden auch nach dem Start eingelesen?

Ja, wenn ich "t" an das Debug-KO sende, bekomme ich auch den aktuellen Timestamp zurück. Sollte also im Logikmodul ankommen.

[willisurf]

Uhrzeit und Datum sind verknüpft, reagieren auf ReadRequest und werden auch nach dem Start eingelesen?

[thilog]

Moin,

erstmal danke für das Logikmodul. Ich habe es gestern auf Basis des OpenKNX PiPico-BCU-Connector mit VPM-Modul in Betrieb genommen. An einer Stelle hänge ich jedoch: Ich würde gerne eine Tagesphase generieren, um sie u.a. im VPM zu nutzen. Vorgesehen sind drei Szenen: Tag (Szene 1), Abend (Szene 2) und Nacht (Szene 3). Idee war, dafür drei Zeitschaltuhren zu verwenden, je eine pro Tagesphase. Bei EIN sendet sie die passende Szene, bei AUS passiert nichts. Hier ein Auszug aus der Parametrierung:


image.png

image.png

image.png

Dummerweise kann ich nicht feststellen, dass das KO gesendet wird, auch ein Read-Request auf der GA wird nicht beantwortet.

Sende ich "l10" an das Debug-KO erhalte ich als Ergebnis "Ax Bx Cx Dx Qx".

Ideen? Was mache ich falsch?

Danke & viele Grüße
Thilo

[mumpf]

Hi, ab sofort gibt es eine neue Version 0.12.3 mit reinen Bugfixes:

• FIX: Treppenlicht konnte erst über KNX wieder abgeschaltet werden, sobald das Logikmodul länger lief als die eingestellte Treppenlichtzeit.
• FIX: "Einschaltverzögerung -> beim 2. EIN sofort schalten" wurde auch erst geschaltet, wenn das Logikmodul länger lief als die eingestellte Verzögerungszeit.
• FIX: "Ausschaltverzögerung -> beim 2. AUS sofort schalten" wurde auch erst geschaltet, wenn das Logikmodul länger lief als die eingestellte Verzögerungszeit.
• FIX: Konvertierung von DPT 9 nach DPT != 9 war um Faktor 10 zu groß. 9.0 wurde auf 90 Konvertiert statt auf 9.

Es ist ein reines Firmware-Update, die ETS-Applikation muss nicht akualisiert werden.

Download-Links wie immer in ersten Beitrag in diesem Thread.

Gruß, Waldemar

[EPIX]

Danke für die Rückmeldung - ich dachte mir schon, dass es aufwändig ist....

Lösbar wäre es eventuell wenn man den Schaltuhren-Teil in ein eigenes Modul auslagert - also ein Standalone-Schaltuhr-Modul, da wäre dann das Platzproblem gelöst.

Von "außen" müsste man halt die gewünschte Zeit als Zeit-DP10 an das jeweilige KO senden, das Verhalten definiert (Ein, AUs, Szene,...) definiert man über die ETS und braucht zur Laufzeit ja nicht geändert werden.

Mir gefällt euer Ansatz der getrennten Geräte auf einer "Einheits-Platform" sehr gut und ich würde bei Gelegenheit gerne noch ein paar bestückte Sensormodule beziehen. Für das feine Löten sehe ich mittlerweile einfach nicht mehr gut genug
(...aber das ist eine andere Geschichte)
Aber wie eingangs geschrieben: es war nur eine Anregung...

[mumpf]

Tja... einerseits nicht abwegig, andererseits leider kein "easy win". Die Logik kann noch kein DPT10 und DPT11 verarbeiten und ich wüsste nicht, wie man menschenwürdig die Schaltzeiten adressiert und neue Schaltzeiten vergibt. Ich hab pro Kanal nur 2 Eingänge und leider kaum noch Platz in den Paramtern.
Ich sag mal so: Es kommt auf jeden Fall in die Sammlung meiner Sachen für die Zukunft und ich schaue mit bei der nächsten intenen Feature-Runde für die Logik (etwas im Januar) an, was man mit dem Logikmodul noch reißen kann. Ansonsten wird es irgendwann eines geben, dass nur auf dem RP2040 läuft, da hab ich dann mehr Speicher und mehr freiheiten, aber da reden wir von >2 Jahren!

Da man viele Schaltkanäle hat, kann man derzeit natürlich mehrere Zeitschaltuhren definieren und passend zur externen Situation über eine Logik nur die Schaltuhr zum Eingang durchschalten, die man gerade haben möchte. Das erlaubt zumindest einige Freiheitsgrade...

Gruß, Waldemar

[EPIX]

eine Anregung für das Logikmodul:
es wäre natürlich seeehr bequem, wenn man die Schaltzeiten im Betrieb ändern könnte ohne jedes Mal die ETS zu starten...
Dazu wäre ein KO für jede aktive Schaltuhr notwendig wo man die Schaltzeiten abfragen / setzen kann.


Alternativ könnte man über die Debug-KO die Schaltzeiten ändern.

Ich habe natürlich keine Ahnung wie aufwändig die Umsetzung ist, bzw ob das Ganze in die Grundidee des Logikmoduls passt - ist nur ein Gedanke...