OpenKNX-Logikmodul release

[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

[Marmin]

Danke für die Info würde die vorcompilierte nehmen habe dir auch eine pn geschrieben

Gruß
Marco

[mumpf]

Hi,

esp32 wird nicht funktionieren, zumindest nicht "out-of-the-box", wenn Du Dich mit PlatformIO auskennst, könntest Du es hinbekommen. Ich kann auch bei Problemen helfen, aber es ist nicht meine Zielplattform, deswegen hab ich das da nie realisiert.

PICO läuft grundsätzlich, da die Siemens BCU auch nur ein UART ist, sollte das kein Problem sein. Nano-BCU hat den Vorteil, dass sie den SAVE-Ausgang rausführt und so auch speichern von KO-Werten beim Stromausfall erlaubt.

Willst Du die Firmware selber bauen oder die vorcompilierte nehmen? Für die vorcompilierte musst Du bestimmte pins anschließen:

#define PROG_LED_PIN 16
#define PROG_LED_PIN_ACTIVE_ON HIGH
#define PROG_BUTTON_PIN 17
#define PROG_BUTTON_PIN_INTERRUPT_ON FALLING
#define INFO_LED_PIN 10
#define INFO_LED_PIN_ACTIVE_ON HIGH
#define KNX_UART_TX_PIN 12
#define KNX_UART_RX_PIN 13
#define SAVE_INTERRUPT_PIN 15

Die Info-LED brauchst Du nicht zwingend, die hab ich primär zum Debugging verwendet.

Ich persönlich würde zu PICO+Nano-BCU raten.

Gruß, Waldemar

[Marmin]

Guten Tag,
Bin neu in der openknx Welt und wollte fragen ob ich das logikmodule auch mit ein pico und einen siemens bcu oder esp32 + siemens bcu betreiben kann ,oder ist es besser ihn mit dem pico +platine+nano bcu zu verwenden?

[mgeramb]

Hallo Michael,

ich verstehe jetzt, was Du meinst: In der Kanalansicht (Channels) siehst Du die KO 5 und 6 nicht. Das habe ich bei mir auch. War so nicht beabsichtigt, aber da muss ich echt mal schauen, warum die ETS6 das so macht. Wenn Du aber auf Kommunikationsobjekte gehst, wie willisurf, dann wirst Du die KO sehen.

Wie arbeitest Du, wenn Du nicht die Ansicht Kommunikationsobjekte verwendest?

Sorry, sorry, ich bin einfach nur blind, bzw. habe ich nicht zu weit gescrollt. Alles bestens. Von der Benutzerführung wäre allerdings trotzdem zu überlegen, die Feiertage aus dem Logikbereich raus auf Root zu schieben. Denke das kommt eher von dem Teil, dass die Logik früher Teil des Sensors war, da hat das Sinn ergeben, wenn man aber nur das Logikmodul installiert, ist das nicht ganz logisch, weiß aber nicht ob das soweit trennbar wäre, dass es als Teil des Sensors sich anders darstellt.

Liebe Grüße, Michael

[mumpf]

Hallo Michael,

ich verstehe jetzt, was Du meinst: In der Kanalansicht (Channels) siehst Du die KO 5 und 6 nicht. Das habe ich bei mir auch. War so nicht beabsichtigt, aber da muss ich echt mal schauen, warum die ETS6 das so macht. Wenn Du aber auf Kommunikationsobjekte gehst, wie willisurf, dann wirst Du die KO sehen.

Wie arbeitest Du, wenn Du nicht die Ansicht Kommunikationsobjekte verwendest?

Gruß, Waldemar