OpenKNX-Logikmodul release

[wknx]

wknx Nochmal ne Rückfrage: Auf was läuft den das Logikmodul bei Dir? Also welches Software/Hardware-Package? Sensormodul/EnoceanGateway/Standalone?

Aktuell auf einem Sensor-Modul mit nur Beeper auf der Platine.

Habe diese Implementierung derzeit "nur" experimentell im Einsatz und will einige Funktionen dadurch abbilden die jetzt teilweise noch in OpenHab hängen. Dazu braucht es z.B. auch die Flankenerkennung. In der aktuellen Konfiguration sind es 25 Logikkanäle, davon 6 Schaltuhren die wahrscheinlich auch eher exotisch sind (jede Minute/Stunde/Tag/Woche/Monat/Jahr) und bislang nur aus Neugier angelegt wurden. Vielleicht ist das schon relativ viel? Ohne den Fix mit +1000ms würde die Verzögerung nach meinem bislang nur groben Verständnis der Implementierung vom Umfang der erforderlichen Verarbeitungsschritte abhängen.

Lokale Abweichungen im Sekundenbereich halte ich auch für unproblematisch. Der Drift ist bei mir wahrscheinlich auch nur aufgefallen, weil ich bislang nur die Uhrzeit-Datum-Kombination auf den Bus sende und niemals die reine Zeit.

[mumpf]

Hi,

ab sofort gibt es ein neues 0.12-Beta auf Github: https://github.com/OpenKNX/OAM-Logic.../tag/0.12-Beta
Die Applikationsbeschreibung ist auch aktualisiert: https://github.com/OpenKNX/OAM-Logic...ibung-Logik.md

Auszug aus dem Changelog:

• NEU: Interne Ausgänge (als Quelle für die X- und Y-Eingänge eines Logikkanals) können jetzt neben EIN- und AUS-Werten auch nur EIN- oder nur AUS-Werte weiterleiten.
• NEU: Zu den mathematischen Funktionen, die Ausgangswerte berechnen können, ist jetzt die Funktion % (Modulo), also Rest-Division, hinzugekommen.
• NEU: Neben den mathematischen Funktionen, die Ausgangswerte berechnen können, sind jetzt auch Bitoperationen hinzugekommen. Es gibt jetzt
  • & (Bit-Und),
  • | (Bit-Oder),
  • ^ (Bit-Exklusiv-Oder),
  • << (Bit-Links-Verschiebung),
  • >> (Bit-Rechts-Verschiebung)
• FIX: Bei der Einstellung "Nur bei geändertem Ergebnis, aber erstes Telegramm immer senden" wurde das zweite Telegramm auch gesendet, wenn es gleich zum unterdrückten war. Das ist jetzt korrigiert.
• Die Zeitbasis für Zeitschaltuhren ist jetzt genauer, die Zeitschaltuhren driften jetzt weniger.

Bei den internen Ausgängen (also den rein booleschen internen Verknüpfungen) hab ich eine kleine Lücke geschlossen: Man kann jetzt bestimmen, ob der Ausgang nur EIN- oder AUS-Signale weiterleitet. Und natürlich auch beide Signale, wie bisher.

Die mathematischen Funktionen sind etwas erweitert worden, vor allem die Bitfunktionen erlauben jetzt neue Funktionalitäten.

Es gab eine Lücke, wenn erste Telegramme nicht gesendet werden. Die ist jetzt auch geschlossen, danke wknx für die Meldung. Ebenso danke ich Dir für die Idee, die Zeitbasis für die Zeitschaltuhren zu verbessern.

Viel Spaß mit dem Release,
Gruß, Waldemar

[mumpf]

Ich hatte nun gerade zwischendurch die 0.10-Beta erwischt.

Noch eine Anmerkung, falls das (irgendjemandem) passiert, dass ein neues Release kein upgrade kann: Bitte meldet euch bei mir hier übers Forum. Ich achte sehr darauf, dass man bei meinen ETS-Applikationen einen upgrade machen kann und nicht nochmal alles neu parametrieren muss. Aber auch ich mache Fehler. Normalerweise kann ich sowas zeitnah korrigieren und dann geht ein Upgrade ohne Probleme.

Gruß, Waldemar

[mumpf]

könnte man das nicht auf 2 Kerne aufteuilen dann wäre das Problem gelöst....

Wenn man 2 Kerne hätte... das Logikmodul muss auch auf dem SAMD laufen können. Hier wäre der bessere Weg ganz klar, einen der internen Timer des Prozessors zu nehmen. Aber auch dafür muss man sich Zeit nehmen (die Sourcen sind verfügbar, es muss nicht immer ich sein).

Und mal ernsthaft, ich weigere mich, das als Problem zu sehen (auch wenn ich mir das grundsätzlich anschaue): Wir reden hier von Zeitschaltuhren, die Geräte im Haus steuern. Ob der Rollanden morgens um 07:05:00 oder um 07:05:01 aufgeht, ist vollkommen egal, selbst wenn es 07:06:04 werden sollte. Die alten mechanischen Zeitschaltuhren für die Steckdose hatten ein 15 Minuten-Raster...

An anderer Stelle finden man eine Zeitbasis von 1/10 Sekunden, was hier vielleicht einfach zu hohe Erwartungen weckt.

Dazu wollte ich auch was sagen: Die Zeitbasis von 1/10 Sekunden sagt nicht, dass die Uhren besonders genau laufen, sondern nur, dass man Verzögerungen bauen kann, die unter einer Sekunde ligen, was häufig hilft, wenn man Probleme mit Telegrammlaufzeiten hat.

[jeff25]

Hi Waldemar,

könnte man das nicht auf 2 Kerne aufteuilen dann wäre das Problem gelöst....

Gruß
Robert

[mumpf]

wknx Nochmal ne Rückfrage: Auf was läuft den das Logikmodul bei Dir? Also welches Software/Hardware-Package? Sensormodul/EnoceanGateway/Standalone? Auf SAMD oder RP2040?

Letztendlich finde ich 1 Sekude Verzögerung pro Minute einfach zu viel, auch wenn ich wie bereits gesagt nicht wirklich darauf geachtet habe. Selbst meine 400ms fand ich schon zu viel, aber das ist auf dem ModbusGateway (kommt bald mit Logikmodul), da ist das Modbus-Timing, was dazwischenfunkt, da muss sowieso noch was optimiert werden.

Gruß, Waldemar

[mumpf]

Freue mich auf den Fix.

Der Fix ist jetzt drin und ein erster Test sieht gut aus. Ich mach noch ein paar weitere Tests (morgen), aber es wird funktionieren.

Ich habe auch Deinen Vorschlag im Timer.cpp eingebaut und incrementiere jetzt um 1000. Das Verhalten ist wesentlich besser, auch hier danke für den Tipp. Jetzt ist die Verzögerung bei mir nur noch 40ms.
Und ja, ich könnte den Timer vom Controller nehmen, hab das bisher nicht angegangen, weil es so viele andere interessante Sachen zu entwickeln gibt. Und mit eine Sync über den Bus alle 10-15 Minuten merkt man nicht wirklich eine Verzögerung.

Danke für Deinen Input, ich sehe zu, bald ein neues Release zu machen.

Gruß, Waldemar

[wknx]

Das erste Telegramm wird unterdrückt, aber wenn das nächste Telegramm gleich ist, wird das gesendet. Das soll so nicht sein. Ich korrigier das mal.

Danke! Toll, dass du da so schnell die Ursache finden konntest :-) Freue mich auf den Fix.

Btw.: Zum Zeitverhalten habe ich nach Blick in den Code einen Verdacht: (Es fehlt mir allerdings an Erfahrung in Hardware-naher Programmierung mit C++, in sofern hoffe ich da nun kein Unsinn folgt)
Die interne Zeit-Repräsentation wird sekundenweise erhöht, diese Erhöhung erfolgt allerdings nicht im Sekundenintervall, sondern nur frühestens nach 1000ms, siehe
https://github.com/OpenKNX/OAM-Logic...er.cpp#L44,L47
Die Zeit läuft also immer etwas langsamer (mehr oder weniger) als der Zeitgeber des Systems und Du hast einen Drift der Zeit bis zum nächsten eingehenden Uhrzeit-Telegramm.
Lösungsidee: mTimeDelay nicht neu setzen, sondern um 1000ms inkrementieren; das nächste Update wird bei verzögerter Ausführung somit schon nach weniger als 1s erfolgen und selbst übersprungene Sekunden sollten nachgeholt werden. https://github.com/OpenKNX/OAM-Logic.../Timer.cpp#L46
Alternativ könnte es vielleicht auch interessant sein in Relation zum Systemtimer abzubilden?

[mumpf]

Ich hab es eben noch ausprobiert, es ist wirklich noch ein Fehler drin.

Das erste Telegramm wird unterdrückt, aber wenn das nächste Telegramm gleich ist, wird das gesendet. Das soll so nicht sein. Ich korrigier das mal.

Gruß, Waldemar

[mumpf]

Lass uns weiter über Deine Wertetabelle diskutieren, die anderen Sachen sind eher Kosmetik. Womit ich nicht sagen will, dass ich das ignoriere, nur das andere ist spannender...

Vielleicht muss ich Dein Szenario besser verstehen. 1 -> 0 und 0 -> 1 macht das Modul von alleine, wenn Du "bei geändertem Ergebnis" machst (ja, mit einem UND bzw. ODER mit einem Eingang).

Und dann Undefiniert: Das kann es nur zum Einschaltzeitpunkt geben. Und das erste Telegramm definiert den Wert. Wenn dieser Wert nicht erwünscht ist, musst Du dieses erste Telegramm unterdrücken. Deswegen ist "bei geändertem Ergebnis, aber erstes Telegramm ignorieren" genau richtig. Deine Einstellung ist also korrekt.
Die Frage ist somit, was da nicht passte. Es ist ja immer noch möglich, dass noch ein Fehler drin ist.

Gruß, Waldemar

[wknx]

heißt das, Du hattest noch keine Version vorher? Dann hoffe ich, dass Du noch nicht allzu viel in der 0.10 gemacht hast, denn leider gibt es keinen Weg von der 0.10 auf die 0.11 per Upgrade. Sorry.

Ist nicht so tragisch, ich habe das Modul sowieso noch im experimentellen Einsatz. Daraus resultieren auch meine anderen Fragen.

1.

Zeile 3: Logik auswerten "erst wenn alle Werte gültig sind"

Dann ist doch der aktuellen Wert gültig. Wie sollte ich denn mit dem vorangegangenen Wert umgehen? Der muss ja berücksichtigt werden, wenn einen Zustandsänderungen (von 0 auf 1 oder 1 auf 0) erkennen will.
Meine erste Idee war ein UND oder ODER zum durchschleifen eines einzigen Wertes mit "Trigger bei Änderungen, aber erste Ignorieren" und "Wiederholungen nicht senden". Das hatte irgendwie nicht zum Erfolg gefühlt. Was ich bislang nicht versucht hatte ist den Ausgang zum Eingang zurückzuführen. Vor diesem Szenario warnt die Applikation ja auch gutem Grund.

2. […] Es ist ein Darstellungsproblem der ETS.

Ist auch nicht so tragisch. Mir ist auch so als wäre die Reihenfolge am Anfang korrekt gewesen. Evtl. also auch abhängig von internen Datenstrukturen der ETS.

Zu 3.
Halte ich auch nicht für kritisch bzw. eher ein Thema der Dokumentation. Ich hatte mal experimentell eingestellt zu jeder Minute ein Telegramm zu senden. Das Erfolg ja auch nicht zum Minutenanfang (zumindest interpretiere ich das nun so). Vielleicht könnte man da die Dokumentation noch ergänzen mit einem Hinweis, dass das Ereignis irgendwann (?) in der gewählten Minute auftritt, sofern das dem erwarteten Verhalten entspricht. An anderer Stelle finden man eine Zeitbasis von 1/10 Sekunden, was hier vielleicht einfach zu hohe Erwartungen weckt. Harte Echtzeitbedingungen darf man sowieso nicht erwarten. Habe mich auch nicht so weit mit der Implementierung beschäftigt, dass ich einen Einblick in den zeitlichen Gesamtablauf habe. Spätestens wenn zu einem exakten Zeitpunkt eingehende Telegramme verarbeitet werden müssen würde ich denen auch eine höhere Priorität einräumen.
Bei mir sind es übrigens etwas über 61,04 Sekunden. Hab im Log allerdings auch Zeiten unter 1 Minute, bei denen ich mir nicht sicher bin ob die von ggf. als Folge der Neuprogrammierung entstanden sind. Wahrscheinlich ist das abhängig von der Nutzung der anderen Logikkanäle. Wenn ich es hilft kann ich das mal weiter analysieren. Müsste jetzt schon ein paar Tage im Buslog drin sein.

[mumpf]

Hi,

Ich hatte nun gerade zwischendurch die 0.10-Beta erwischt. Kann ich die nun einfach auf die 0.11 updaten, bzw. müsste ich dabei irgendwas besonderes beachten?

heißt das, Du hattest noch keine Version vorher? Dann hoffe ich, dass Du noch nicht allzu viel in der 0.10 gemacht hast, denn leider gibt es keinen Weg von der 0.10 auf die 0.11 per Upgrade. Sorry.
Falls Du aber eine 0.9 hattest, dann hat ja das Update von 0.9 auf 0.10 nicht geklappt, oder? Hast Du dann manuell alles übertragen? Falls Du noch ein Backup vom Projekt mit der 0.9 hast, könntest Du dort das Upgrade auf die 0.11 machen und dann das Gerät in das aktuelle Projekt kopieren. Das sollte eigentlich gehen (ohne Gewährt, so einen Fall hatte ich noch nicht).

Hintergrund: Ich mache wirklich vor jeder Version den Upgrade-Test, aber in diesem Fall hatte ich mit einer anderen Applikaiton (PM-Modul, enthält auch die Logik) getestet, die hatte zufällig auch gerade die Version 0.10 auf 0.11. Ich hatte also ein erfolgreiches Update mit einer falschen Applikation.

Zu Deinen Punkten:

1. An sich sind für Deine Fälle folgende Einstellungen vorgesehen, mich würde interessieren, ob Du das noch nicht kanntest oder warum dir diese Einstellugen nicht reichen:
   1. Zeilen 1,2,4 und 5: Logik sendet ihren Wert weiter "nur bei geändertem Ergebnis"
   2. Zeile 3: Logik auswerten "erst wenn alle Werte gültig sind"
2. Ich hatte schon mal geschaut, ich gebe die Channels in der korrekten Reihenfolge in der XML vor. Es ist ein Darstellungsproblem der ETS.
3. Ich hab eben mal geschaut, bei mir sind es 60,4 Sekunden. Ich kann nochmal schauen, ob ich irgendwo sehe, wie die 400ms Verzögerund zustande kommen, aber ich werde auf keinen Fall zusichern, dass es eine exakte Uhr ist, die im Modul läuft. Dazu gibt es viel zu viele Einflüsse, auf die ich keinen Einfluss habe. Aber die Uhr synchronisiert sich jedesmal mit der Buszeit, sobald diese auf den Bus gesendet wird und hat somit keinen nennenswerten Drift. Solltest Du Exaktheit im ms-Bereich erwarten, ist meine Uhr nicht die, die Du verwenden solltest.

Gruß, Waldemar

[wknx]

mumpf erst mal vielen Dank für die tolle Umsetzung einschließlich Setup-Prozess!

P.S.S.: Das 0.10-Beta, das kurzzeitig verfügbar war, hatte einen Copy&Paste-Fehler, der ein Upgrade in der ETS verhinderte. Das ist mit der 0.11-Beta korrigiert.

Ich hatte nun gerade zwischendurch die 0.10-Beta erwischt. Kann ich die nun einfach auf die 0.11 updaten, bzw. müsste ich dabei irgendwas besonderes beachten?
(Oder habe ich da nun großes Pech und muss die Konfiguration von Hand erneuern?)

Ist der Thread hier ansonsten auch passend für Fragen/Anmerkungen, oder sollte ich für die besser einen neuen starten? Dann würde ich die nachfolgenden Punkte in einen neuen Thread schieben:

1. Ich suche eine Möglichkeit zur Flankenerkennung bzw. Senden bei Zustandswechsel. Habe schon verschiedenes probiert, aber noch keine Lösung gefunden.
   Ziel:

   INPUT vorheriger Wert	INPUT	OUTPUT
   0	1	1
   1	0	0
   undefiniert	*	-
   0	0	-
   1	1	-

   Übersehe ich da eine ganz einfache Möglichkeit?
2. Wenn ich in der Baumansicht der ETS die Logikkanäle aufklappe, dann erscheinen diese nicht mehr in der korrekten Reihenfolge von 1 bis 99. Sondern einige an der falschen Position.
3. Wenn ich eine Zeitschaltuhr jede Stunde und jede Minute ausführen lasse, dann werden Telegramme mit 61 Sekunden Abstand ausgegeben. Vielleicht habe ich da aber auch die Funktionsweise noch nicht korrekt verstanden.

[mumpf]

Hi allerseits,

ab sofort gibt es ein neues 0.11-Beta auf Github: https://github.com/OpenKNX/OAM-Logic.../tag/0.11-Beta
Die Applikationsbeschreibung ist auch aktualisiert: https://github.com/OpenKNX/OAM-Logic...ibung-Logik.md

Auszug aus dem Changelog:

• NEU: Logikfunktion "Schalter" hinzugefügt. Siehe neues Kapitel "Schalter (RS-Flip-Flop)"
• Neues Beispiel "Einfacher Szenen-Controller" zugefügt.
• NEU: Feiertag Nationalfeiertag (AT) zugefügt (danke an mgeramb für den Code)
• NEU: Feiertag Maria Empfängnis (AT) zugefügt (danke an mgeramb für den Code)
• FIX: Typo "Fronleichnam" korrigiert
• FIX: Eingangskonverter für Einzelwerte funktioniert jetzt korrekt
• FIX: Wenn man einen (oder mehrere) Logikkanäle ausgelassen hat, konnte es passieren, dass die Logiken hinter der Lücke nicht mehr ausgeführt wurden (z.B. Kanal 1, 2, 3, 5 => 5 wird nicht mehr berechnet)

Es ist eine neue Logikfunktion "Schalter" dazugekommen. Diese funktioniert wie ein RS-Flip-Flop. Auch wenn die meisten (wenn nicht alle) Funktionen, die damit gehen, auch mit 2 dezidierten Logikkanälen realisierbar sind, lässt sich so eine Logik kompakter (und somit übersichtlicher) formulieren.

Ein erstes einfaches Beispiel, dass diese Logikfunktion nutzt, ist auch dazugekommen ("Einfacher Szenen-Controller")

Die 2 Feiertage, die sich mgeramb gewünscht hat, sind jetzt auch drin. Damit ist die maximale Anzahl von möglichen Feiertagen voll (32), wenn weitere Feiertage dazukommen sollen, muss umgebaut werden. Ich weise nochmal darauf hin, dass man für feste Feiertage (die nicht von Ostern oder vom Advent abhängen) durchaus auch eine Zeitschaltuhr verwenden kann und diese am passenden Tag schalten lassen kann.

2 Bugs und ein Typo sind jetzt auch korrigiert und wie üblich ist die ETS-Applikation Upgrade-Fähig, kann also eingespielt werden und alle Parameter und GA Zuweisungen bleiben erhalten. Das Upgrade-Verfahren ist hier erklärt: https://github.com/OpenKNX/OpenKNX/w...tuelle-Version

Ich habe im Release.zip jetzt auch eine Datei Readme-Hardware.html drin, die Links zu der Hardware enthält, auf der meine precompiled Firmware "out-of-the-box" läuft. Hier ist neben dem Sensormodul von Masifi (http://smart-mf.de) jetzt auch der PiPico-BCU-Connector von Ing-Dom dazugekommen (https://github.com/OpenKNX/OpenKNX/w...-BCU-Connector).

Ich wünsche euch viel Spass mit der Logik,
Gruß, Waldemar

P.S.: mgeramb Da Du einen Pull-Request geschickt hast, gehe ich davon aus, dass Du die Build-Umgebung aufgesetzt hast. Diese hat sich in der Zwischenzeit geändert. Ich werde baldmöglichst eine Wiki-Page machen, die das Aufsetzen beschreibt, ist leider etwas anspruchsvoller geworden. Mit der alten Umgebung wirst Du das Logikmodul nicht bauen können, da wir jetzt symlinks benutzen. Falls Du es selber versuchen willst: Git-Client mit symlinks installieren (reinstall nötig), dann Win10-Rechner in Developer-Mode versetzen und dann erst ein Pull machen. Dann läuft es wie gewohnt.

P.S.S.: Das 0.10-Beta, das kurzzeitig verfügbar war, hatte einen Copy&Paste-Fehler, der ein Upgrade in der ETS verhinderte. Das ist mit der 0.11-Beta korrigiert.

[mumpf]

Hi,

angeregt durch die Frage https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/1726538-knx-bewässerungsautomat-opensprinkler-was-sollte-so-ein-device-können?p=1794032#post1794032 habe ich zu der textuellen Antwort (dort im Thread) auch ein Beispiel gebaut und das schrittweise in der Doku aufgeführt.

Ihr findet das Beipiel hier: https://github.com/OpenKNX/OAM-Logic...n-tag-schalten.

Es zeigt, wie man etwas jeden n-ten Tag schalten kann, kann aber leicht auch für andere Zeiträume abgewandelt werd. Und ein Teilproblem ist ein Zähler, falls jemand so etwas braucht. Insgesamt ist es meiner Meinung nach ein gutes Beispiel, aus dem man lernen kann.

Gruß, Waldemar