[Firmware] OpenKNX-Logikmodul release

[mumpf]

Ab sofort ist die Produktinfo für das Logikmodul in unserem Wiki verfügbar: https://github.com/OpenKNX/OpenKNX/w...nfo-Logikmodul

Im 2. Post werde ich weiterhin die jeweiligen Releases ankündigen.

-------------------------------------------------------------

Bisherige Information für das Logikmodul:

Als erste OpenKNX-Firmware möchte ich hiermit das Logikmodul freigeben. Es ist der offizielle Nachfolger des bereits früher veröffentlichten Logikmoduls, beschrieben hier: https://knx-user-forum.de/forum/%C3%...-l%C3%B6sungen.

Da OpenKNX eine Art Neustart ist, ist die neue Firmware und ETS-Applikation nicht mehr kompatibel zu den alten Versionen. Wenn man also diese Firmware + ETS-Applikation nutzen will, muss man alles komplett neu Parametrisieren.

Es gibt 99 Logikkanäle mit folgenden - beriets bekannten - Features:

• Logikfunktionen mit bis zu 2 Eingängen
  • UND
  • ODER
  • EXOR
  • TOR/Sperre
  • Zeitschaltuhr
  • NEU: Schalter

• Einstellbare Ausgangstrigger
  • Bei Wertänderung am Ausgang
  • Bei jedem Eingangstelegramm
  • Nur beim Eingangstelegramm am Eingang 1 oder am Eingang 2
• Mehrere Kanäle können zu größeren Logikblöcken zusammengefasst werden
• Eingänge unterstützen DPT 1, 2, 5, 5.001, 6, 7, 8, 9, 17
• Ausgänge unterstützen zusätzlich den DPT 16
• Konvertierung zwischen Ein- und Ausgangs-DPT
• Alle Ein- und Ausgänge können ihre Werte invertieren
• Eingänge können aktiv Werte lesen
  • beim Startup
  • Zyklisch mit einstellbarer Zeit
  • Zyklisch bis die erste Antwort kommt
• Wiederholfilter: Wenn mehrfach EIN- oder AUS-Telegramme hintereinander kommen, kann man
  • Alle Wiederholungen durchlassen
  • Nur EIN-Wiederholungen durchlassen, AUS nur einmal
  • Nur AUS-Wiederholungen durchlassen, EIN nur einmal
  • EIN- und AUS-Telegramm nur einmal durchlassen
• Zeitglieder am Ausgang
  • Treppenlicht mit Verlängerung und vorzeitigem Ausschalten (einstellbar)
  • Einschaltverzögerung mit einstellbarer Aktion bei vorzeitigem AUS/wiederholtem EIN
  • Ausschaltverzögerung mit einstellbarer Aktion bei vorzeitigem EIN/wiederholtem AUS
  • Blinken mit wählbarem Puls-Pausen-Verhältnis
• Zyklisch senden getrennt einstellbar für EIN- und AUS-Telegramm
• Ausgangsfilter: nur EIN-, nur AUS oder beides durchlassen
• Ausgangskonverter
  • Für EIN oder AUS wird der Wert eines anderen DPT gesendet
  • Für EIN oder AUS wird der Wert eines Eingangs gesendet
  • Für EIN oder AUS kann das Ergebnis einer Formel verwendet werden
  • Man kann sogar eigene Funktionen in die Firmware einbauen
• Sonderfunktionen
  • Die Funktion "Gerät zurücksetzen" (sonst nur über die ETS machbar)
  • Akustische Signalisierung über einen Buzzer
  • Optische Signalisierung mittels einer RGB-LED
• Zeitschaltuhren
  • Als Jahresschaltuhr mit 4 oder als Tages/Wochenschaltuhr mit 8 Schaltzeiten
  • Mehrere Zeitschaltuhren können verbunden werden und so mehr als 4 bzw. 8 Schaltzeiten realisiert werden
  • Feiertage berücksichtigen (oder ignorieren)
  • Urlaub berücksichtigen (oder ignorieren)
  • Tag/Monat berücksichtigen (bei Jahresschaltuhren)
  • Wochentag/Stunde/Minute berücksichtigen (bei allen Schaltuhren)
  • Sonnenstandsbezogene Schaltzeiten:
    • Sonnenauf-/-untergang +/- Stunden/Minuten
    • Sonnenauf-/-untergang, aber frühstens/spätestens um ...
  • Jede Stunde zu bestimmten Minuten schalten
  • Jeder Schaltvorgang kann dann wie bei jedem Logikkanal auch alle Ausgangsfunktionen haben
  • Beim Neustart des Logikmoduls den zeitlich letzten Schaltzeitpunkt berechnen und erneut ausgeben

Neu/geändert gibt es folgende Features:

• Ein Eingang kann jetzt intern (ohne externe GA) mit jedem KO des Moduls verbunden werden.
  • Das erlaubt große Logiken ohne den Bus Zwischenergebnissen "vollzumüllen"
  • Da jedes KO geht, kann beim Sensormodul z.B. direkt ein Sensorausgang verbunden werden und mit Logiken versehen werden.
• Ein Toreingang kann auch ein Impulseingang sein (reagiert nur auf 1, wobei Tor geöffnet und sofort geschlossen wird)
  • Erlaubt diskret getaktete Werte auf den Bus zu senden
  • Kann zur Synchronisation von Werten genutzt werden
• Die Applikation ist optisch überarbeitet und übersichtlicher
• Speichern von Werten über einen Stromausfall hinweg wird auch ohne EEPROM unterstützt*)
• Senden von gespeicherten Werten nach einem Neustart

*) Wichtig: In der 0.7-Beta ist dies noch nicht freigeschaltet, die gibt es erst zur 1.0

Bei so wenigen neuen Features: Warum sollte man umsteigen? Um es mal klar zu sagen: Wer mit der bisherigen Logik zufrieden ist, sollte nicht umsteigen. Und derzeit wird das Logikmodul standalone auch kaum verwendet.

Es ist aber viel unter der Haube passiert:

• Der KNX-Stack ist aktualisiert, hat eine viel bessere Kommunikationsschnittstelle zu KNX-TP und ist auch für KNX-RF, KNX-IP und KNX-Secure vorbereitet.
• Es wird jetzt neben dem SAMD-Prozessor auch der RP2040-Prozessor unterstützt, das erlaubt günstigere und leistungsfähigere Hardware in Zukunft.
• Es wird nun geprüft, ob Firmware und ETS-Applikation zusammen passen, das verhindert Bedienungsfehler.
• Es gibt jetzt eine stark vereinfachte Auslieferung, alles durch Skripte unterstützt und mit wenigen Clicks zu erreichen. Keine Entwicklungsumgebung mehr nötig.

Dieses Logikmodul ist in weiteren OpenKNX-Firmware-Paketen enthalten, so dass es auch technisch notwendig ist, dass das Logikmodul released wird. Dieser Thread ist unter anderem auch dafür gedacht, Fragen zu Stellen und Probleme bzw. Features zu diskuttieren.

Das aktuellste Installationspaket: https://github.com/OpenKNX/OAM-LogicModule/releases

Die Applikationsbeschreibung ist hier: https://github.com/OpenKNX/OAM-Logic...ibung-Logik.md

Gruß, Waldemar

[mumpf]

12.12.2024: Neues Release 3.5.2 ist seit heute verfügbar. Bitte macht ein Update, falls ihr die 3.4 nutzt. Details sind hier beschrieben.

02.12.2024: Neues Release 3.4 ist seit heute verfügbar. Die Details sind hier beschrieben.

25.07.2024: Kleiner Bugfix 3.3.1 seit heute verfügbar. Siehe Anmerkung im Post https://knx-user-forum.de/forum/proj...16#post1968916.

10.07.2024: Das Release 3.3 ist verfügbar. Details siehe im Post https://knx-user-forum.de/forum/proj...50#post1965850. Da Wiki mit der Produktinfo ist auch aktualisiert: https://github.com/OpenKNX/OpenKNX/w...nfo-Logikmodul

04.02.2024: Ich habe noch einen Fehler bei den Zeitschaltuhren korrigiert, der sich äußerst selten bei Logikmodul (als Einzelgerät) auswirkt, aber zusammen mit weiteres Modulen zum tragen kommt. Das Release-3.1.4 ist somit eher optional zu sehen.

25.01.24: Das Release-3.1.3 ist verfügbar, Wiki ist aktualisiert: https://github.com/OpenKNX/OpenKNX/w...nfo-Logikmodul. Es gibt jetzt auch eine Version für reine IP-Geräte, die noch Beta-Status hat (weil der IP-Stack Beta ist, nicht das Logikmodul).
Es gibt beim Upgrade von 1.5.3 mögliche Inkompatibilitäten:

• Nach einem Update müssen alle Zeitschaltuhren, deren Schaltzeiten durch "Sonnenauf-/-untergang plus/minus Zeitversatz" definiert sind, neu definiert werden! Der Stunden-Zeitversatz geht durch das Update verloren und steht auf 0 Stunden.
• Falls das Update nicht klappt (also beim Update ein Fehler kommt) bitte hier im Thread melden. Ich weiß wie das zu beheben ist, aber es ist ein äußerst seltener Fall und zu umständlich, das hier zu beschreiben.

05.09.23: Das Release-1.5.3 ist verfügbar, beschrieben im Wiki: https://github.com/OpenKNX/OpenKNX/w...nfo-Logikmodul
Anmerkung zu diesem Release: Es gab zwar nicht sehr viele neue Features, aber einige Änderungen am KNX-Stack, die für eine deutlich stabilere Funktion sorgen, speziell bei Telegramm-Bursts, also kurzfristig hohen Buslasten.

23.12.22: Ab sofort ist die 1.0-Release verfügbar, wie hier (https://knx-user-forum.de/forum/proj...08#post1829508) beschrieben.

09.11.22: Ab sofort ist die 0.12.3-Beta verfügbar, wie hier (https://knx-user-forum.de/forum/proj...35#post1815435) beschrieben.

06.10.22: Jetzt ist die 0.12-Beta verfügbar: https://knx-user-forum.de/forum/proj...03#post1803803

26.09.22: Ab sofort ist die 0.11-Beta verfügbar, wie hier (https://knx-user-forum.de/forum/proj...55#post1800255) beschrieben.

[GeminiServer]

Hallo Waldemar,
klasse Arbeit und Hut ab! Super Dokumentation. Wirklich vorbildlich. Da hast du aber die Messlatte recht hochgelegt. 👍

Habe es gerade ausgeheckt und "versucht" & gebaut.

Erste kleine Feedbacks: Platformio.ini musste ich bezüglich der dependency libs (Knx, OGM-Common, -SensorDevices, -LogicModule) noch anpassen. Windows sollte es, glaube ich, auch so bauen. Die initialSetup.bat kannst du, glaube ich, verwerfen. Scripts etc. müssen noch Plattform unabhängig bzw. OS-Spezifisch strukturiert werden. Ich bin ja auf dem Mac unterwegs. Sollte aber auch auf Linux baubar gemacht werden. Ggf. mach ich mal meine Anpassungen fertig und erstelle ein pull-request. Bei knxprod-build werden wir wohl um ETS und Windows nicht drum rumkommen.

Nochmal. Top! Freue mich schon damit rum zu spielen.

VG,
Erkan

[mumpf]

Hi Erkan,

danke für die Blumen... aber leider ist gleich was schief gegangen. Ich habe soeben noch schnell eine v0.8-beta nachgeschoben, leider nochmal inkompatibel. Insofern solltest Du mit der was machen .

Zu Deinen restlichen Anmerkungen sage ich heute Abend noch was, jetzt ist erstmal Family dran.

Gruß, Waldemar

[mumpf]

Hi Erkan,

noch zu Deinen Anmerkungen...

Sollte aber auch auf Linux baubar gemacht werden. Ggf. mach ich mal meine Anpassungen fertig und erstelle ein pull-request

Erstmal allgemein: PR ist immer gut, wir können gerne daran arbeiten, dass es auf mehreren Plattformen compilierbar ist, allerdings wegen

Bei knxprod-build werden wir wohl um ETS und Windows nicht drum rumkommen.

ist die Plattformunabhängigkeit nicht im Focus meines Interesses. Ich habe schon viele verschiedene Hardware-Versionen zu testen, auch noch verschiedene Plattformen zu Bauen zu unterstützen kann ich nicht leisten. Aber ich werde mich da auch nicht quer stellen, wenn das jemand anderes (z.B. Du ) erreichen will.

Die initialSetup.bat kannst du, glaube ich, verwerfen.

Ich liefere immer meinen aktuellen Entwicklungsstand aus, auch mit eventuellen Versuchen, die nicht erfolgreich bzw. nicht beendet sind. Das ist so ein Fall. Derzeit hab ich nur das Setup-Dokument https://github.com/OpenKNX/OAM-Logic...O-dev-setup.md und nichts weiter automatisiert. Vielleicht mach ich mal auch hierfür ein Script, ist aber dadurch, dass man jetzt per Script Firmware aktualisieren kann, nicht mehr im Focus.

Platformio.ini musste ich bezüglich der dependency libs (Knx, OGM-Common, -SensorDevices, -LogicModule) noch anpassen. Windows sollte es, glaube ich, auch so bauen.

Würde mich interessieren, wo.

Ansonsten viel Spaß damit und Frag einfach, wenn was nicht klar ist.

Gruß, Waldemar

[bazhuyu]

Installed successfully, great project!

[mumpf]

Hi allerseits,

nur als Vorwarnung: Mir ist leider aufgefallen, dass ich bei der 0.8-Beta noch ein Naming-Problem in der ETS-Applikation habe. Leider wird damit die nächste Version nochmal inkompatibel zur vorherigen werden. Seht es bitte als "Anlaufschwierigkeiten", ich bin stark daran interessiert, Versionen kompatibel zu halten, alleine schon um selber nicht immer alles neu parametrisieren zu müssen .

Gruß, Waldemar

[mumpf]

Noch ne Ergänzung:

Die derzeit vorcompilierte Pico-Firmware-Version nutzt folgende Pins:

#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 KNX_UART_TX_PIN 12
#define KNX_UART_RX_PIN 13
#define SAVE_INTERRUPT_PIN 15

Nur falls das jemand direkt mit einem Pico ausprobieren will und nicht alles selber bauen will. Da es aber noch keine von uns unterstützte Pico-Hardware gibt, kann es durchaus sein, dass sich die Pinbelegung für den Pico in der vorcompilierten Firmware in Zukunft nochmal ändert.

Gruß, Waldemar

[mumpf]

Und noch ein Tipp, falls jemand mal ohne Prog-Button und Prog-LED was ausprobieren möchte (eine BCU an Pin 12/13 braucht man auf jeden Fall:

• Pico mit BCU verbinden.
• Pico mit Firmware per USB flashen
• Mit der ETS schauen, ob am Bus ein Gerät mit der PA 15.15.255 ist
• Jetzt in der ETS auf das Logikmodul gehen und Programmieren->Überschreibe physikalische Adresse wählen, dann 15.15.255 eintragen.
• Dann normal die Applikation programmieren

Dann hat man quasi die Minimalkonfiguration... Funktioniert aus, man hat ohne Prog-LED aber nie ein optisches Feedback, ob noch alles läuft.

Gruß, Waldemar

[GeminiServer]

Hallo Waldemar,

Zitat von GeminiServer Beitrag anzeigen
Platformio.ini musste ich bezüglich der dependency libs (Knx, OGM-Common, -SensorDevices, -LogicModule) noch anpassen. Windows sollte es, glaube ich, auch so bauen.



Würde mich interessieren, wo.

Ich habe heute mal ruhige 2 Stunden gefunden:
Habe die Platformio.ini mal etwas erweitert und umstrukturiert.

• Änderungen sind in meinem fork zu finden: https://github.com/GeminiServer/OAM-LogicModule (Platformio.ini)

Wichtig für mich war, dass es unter MacOS funktioniert. Windows sowie Linux muss noch getestet werden. PowerShell Skripte - sollten imho in Python geschrieben/portiert werden, dadurch erreichen wir mehr OS Plattform Unabhängigkeit. Ich habe erst einmal nur gebaut. Die Release Builds wurden von mir noch nicht getestet.

Eine weitere Sache noch: Unglücklich ist, dass die Pins im OGM-SensorDevices definiert werden. Was zwar ok ist, wir sollten aber die Möglichkeit bieten, lokale pins-defines zu erlauben und zu nutzen. Bin jetzt nicht tiefer in den Code gegangen und bin mir nicht sicher, was noch alles von SensorDevices genutzt wird. Musste das Projekt ebenfalls Forken und meine eigenen pins definieren.

VG,
Erkan

[abeggled]

PowerShell Skripte - sollten imho in Python geschrieben/portiert werden, dadurch erreichen wir mehr OS Plattform Unabhängigkeit.

Wieso? Powershell gibt es sowohl für MacOS wie für Linux.

[GeminiServer]

Wieso? Powershell gibt es sowohl für MacOS wie für Linux.

Wenn es geht noch besser. Hab damit kein Problem. Hatte bisher wenig mit ps gemacht.

[mumpf]

Hi Erkan,

hab mir mal Deine pio.ini angeschaut. Da gibt es einige Missverständnisse, die kann ich für meine Entwicklung so nicht nehmen, meine Projekte funktionieren so nicht. Das kannst Du am Logikmodul alleine nicht sehen und die anderen sind noch nicht draußen, insofern kann ich das verstehen, wie Du drauf kommst.

Ich kann mir aber durchaus vorstellen, noch eine weitere pio.ini.enduser oder so mit auszuliefern, die dann für Leute gedacht ist, die nicht an den Projekt entwickeln, sondern einfach mal nachbauen, z.B. mit anderen Pinbelegungen. Ich werde noch auf Deine Sachen im Detail eingehen und gerne mit Dir das Setup diskutieren, dafür mach ich aber noch einen eigenen Thread auf - aber erst ab Montag, ich hab am WE eine Familienfeier...

Aber 2 Punkte noch:

PowerShell Skripte - sollten imho in Python geschrieben/portiert werden,

Die ps-Scripte sind nicht für PIO nötig, das sind welche, die ausgeliefert werden, damit sich der Enduser eine knxprod bauen und die Firmware flashen kann. Und da Python nicht auf jedem Windows-Rechner verfügbar ist, fällt das aus. Und da man für den Vorgang sowieso Windows braucht, sehe ich hier wie gesagt keine Notwendigkeit, was umzustellen.

Unglücklich ist, dass die Pins im OGM-SensorDevices definiert werden.

Das sind Boarddefinitionen für von uns unterstützte Hardware. Deswegen ist das in einem Projekt, dass von vielen Projekten referenziert wird. Aber Du hast Recht, ich werde ein BOARD_ENDUSER einführen, dann wird am alle Definitionen in der pio.ini machen können.

Gruß, Waldemar

[mgeramb]

Hallo Waldemar,

ich habe ein kleines Problem mit dem Applikationsprogramm, die KO4-6 für Urlaubs- und Feiertagsinfos werden mir nicht angezeigt. Internen scheinen die KO zu existieren, über die Schaltuhr in der Logik konnte ich den Wert sichtbar machen. Ist das ein bekannter Fehler?

Liebe Grüße, Michael
LogikAppProgram.png

[mumpf]

Hi,

danke für die Meldung. Ich schau mal nach, aber mir ist kein Problem bekannt. Was meinst Du genau mit

über die Schaltuhr in der Logik konnte ich den Wert sichtbar machen. Ist das ein bekannter Fehler?

Was genau hast Du sichtbar machen können bzw. was hast Du dafür machen müssen? Und reden wir hier von ETS5 oder ETS6?

Gruß, Waldemar