DIY-Logikmodul - Diskussionsthread (Fragen/Beispiele/Lösungen)

[mumpf]

Hi,

als Auskopplung aus dem DIY-Thread zum Sensormodul+Firmware (https://knx-user-forum.de/forum/%C3%...dul-von-masifi) soll es hier um das Logikmodul und dessen Möglichkeiten/Funktionen gehen, idealerweise mit Beispielproblemen und deren Lösungen.

Ergänzung: Seit dem ab sofort verfügbaren Release 3.8 kann man das Logikmodul (Firmware und knxprod) für sich alleine bauen, unabhängig von allen anderen Teilapplikationen. Die derzeitige Version kann auch nur 80 Kanäle, wird aber auf 99 ausgebaut - eventuell sogar auf mehr, wenn ich mein internes Nummernsystem noch umstellen kann.

Ihr findet das Logikmodul wie üblich auf github: https://github.com/mumpf/knx-logic.

Installationsanleitung: http://github.com/mumpf/knx-logic/bl...x-dev-setup.md

Applikationsbeschreibung Logik: https://github.com/mumpf/knx-logic/b...ibung-Logik.md

Als Hardware kann man natürlich immer noch das Sensormodul (ohne Sensoren) nehmen, oder irgendein selbstgebautes Board mit SAMD21 und einer BCU. Ich habe das gemacht, da es immer wieder Anfragen gab, ob man auch das Logikmodul "standalone" nutzen kann.

--------
Ich werde hier auch immer wieder mal Sachen posten, die mir interessant erscheinen. Ihr seid auch gerne dazu eingeladen, es gleichzutun. Das erste Beispiel kommt gleich im Anschluß...

Gruß, Waldemar

[mumpf]

Mich hat nach gestern Abend folgendes Lob von jgerhart (Jens) erreicht:

Aufgrund deiner Anregungen ist mir noch eine Anwendung eingefallen, und zwar habe ich einen widerspenstigen Dimmaktor, der im Kellergang ein Licht schaltet. Ab und zu hängt der aber und lässt sich nur durch Zurücksetzen wieder zur Mitarbeit überreden. Ich werde mal versuchen, das mit deinen Logiken zu lösen.

Jens hat auch gleich eine Lösung erdacht, die ich euch nicht vorenthalten möchte:

Er überprüft, ob nach einem Einschaltbefehl das Licht wirklich angeht. Das passiert über die Helligkeitsmessung des PM, der wiederum ca. 20 Sekunden braucht, um auf Helligkeitsänderungen zu reagieren. Deswegen wird nach dem Einschalten von Licht um 30 Sekunden verzögert und dann geschaut, ob es hell geworden ist. Und falls nicht, wird zurückgesetzt.

Szenario ist folgendes:
- PM triggert über eine 1-Bit GA (GA-schalten) einen Dimmaktor (mit einer Nachlaufzeit von 3 min) - diese GA antwortet auch auf Leseanforderung
- Dimmaktor schaltet das Flurlicht ein/aus
- PM sendet bei einer Helligkeit von >10 Lux auf eine 1-Bit GA (GA-Licht_an) eine 1 und bei Unterschreitung eine 0- diese GA antwortet auch auf Leseanforderung
- es dauert ca. 20 Sekunden, bis der PM die Helligkeit nach dem Einschalten registriert hat und der Schwellwert überschritten wird. Nach dem Ausschalten des Lichts dauert es ca. 30 Sekunden
- In seltenen Fällen hängt der Dimmaktor und muss zurückgesetzt werden, damit er wieder richtig funktioniert. Das habe ich bisher immer über die ETS gemacht und würde es gerne automatisieren

Ich habe jetzt 3 Logiken verwendet:
1. Logik 2: ODER, Eingang 1 = GA-schalten (Eingang 1 wird zur Vorbelegung vom Bus gelesen), Ausgang schaltet mit 30 Sekunden zeitverzögert
2. Logik 3: UND, Eingang 1 = GA-Licht_an (Eingang 1 wird zur Vorbelegung vom Bus gelesen), Kanalausgang X = Ausgang Logik 2, Logikauswertung auch wenn noch nicht alle Werte gültig sind, Logk sendet ihren Wert weiter bei Eingangstelegramm Kanalausgang X
3. Logik 4: UND, Kanalausgang X normal aktiv Ausgang Logik 2, Kanalausgang Y invertiert aktiv Ausgang Logik 3, Logk sendet ihren Wert weiter bei Eingangstelegramm Kanalausgang Y, EINschalten wird um 1 Sekunde verzögert. Aktuell ist der Ausgang noch zum Testen auf eine 1-Bit GA gelegt, das wäre aber der Trigger zum Zurücksetzen des Dimmaktors.

Für einen Keller ist das gut geeignet, ich sehe 2 kleine Lücken drin:

1. Falls sich der Dimmer im AN-Zustand aufhängt und somit nicht das AUS-Schaltsignal reagiert, wird er nicht zurückgesetzt. Nach Jens Aussage ist das noch nie passiert.
2. Falls der Dimmaktor gesperrt werden kann, dann muss die Logik noch den Sperrzustand ausschließen, sonst würde der Aktor zurückgesetzt werden.

Ich würde übrigens auch mal versuchen, direkt auszuwerten, ob nach dem Schaltsignal (EIN oder AUS) der Status des Dimmaktors auf den entsprechenden Wert (EIN oder AUS) gegangen ist. Das könnte einem die 30 Sekunden ersparen.

Ich habe noch 4 weitere (eher allgemeine) Ansätze zum "Gerät zurücksetzen":

1. Wenn das Gerät ein "In Betrieb" Signal zyklisch sendet, dann kann man einfach ein Treppenlicht auf die doppelte Zykluszeit setzen (plus ein bisschen). Treppenlicht ist nachtriggerbar, aber nicht abschaltbar. Wenn das Treppenlicht das abfällt, sendet man ein "Gerät zurücksetzen".
2. Wenn das Gerät kein "In Betrieb" zyklisch senden kann, aber z.B. Temperaturen oder andere (Mess-)Werte zyklisch senden kann, kann man die empfangen (mit einem Intervallkonverter), damit ein Treppenlicht nachtriggern und weiter wie im Fall 1.
3. Wenn es (wie im obigen Beispiel bei einem Dimmaktor) keine zyklischen Ausgänge gibt, kann man von Logikmodul aus zyklisch "ReadRequests" senden (z.B. an den Statusausgang des Dimmkanals). Die Antwort empfängt man dann und agiert wie im Fall 1.
   Zyklisch senden kann man über eine Zeitschaltuhr im Logikmodul, derzeit aber nur jede Minute oder jede Stunde. Jede Minute kommt nicht in Frage und jede Stunde ist vielleicht zu selten.
   Es geht aber auch häufiger:
   Die Zeitschaltuhr triggert jede Stunde ein Treppenlicht, dass 59 Minuten läuft. Das Treppenlicht blinkt während der EIN-Phase im Verhältnis 5 Minuten EIN/5 Minuten AUS. Man lässt nur die EIN-Signale auf den Bus und hat ein zyklisches EIN-Signal alle 10 Minuten.
4. Eventuell kann es auch helfen, wenn man ein Gerät einfach jede Nacht einmal zurücksetzt. Ist bei einem (recht alten) PM bei mir so. Ich setze den immer um 3:30 Uhr nachts (Zeitschaltuhr, mit 3:30 vermeide ich eine mögliche Zeitumstellungsproblematik) zurück. Meistens reicht das, ich schaue noch, dass Lichtkanal und Präsenz AUS sind bzw. setze erst zurück, nachdem beide ausgegangen sind.

So, das mal als erste Ideensammlung...

Die Möglichkeit, Geräte zurückzusetzen, ist ja glaube ich wirklich ein Alleinstellungsmerkmal deiner Logiken.

Hierzu noch was aus der Praxis: Alleine die Möglichkeit, so was auf eine Taste zu legen oder aus der Visu heraus anzutriggern, anstatt in die ETS gehen zu müssen, ist ein riesiger Vorteil, auch ganz ohne Logiken und Automatisierung. So können es nämlich meine Frau oder die Kinder machen. An die ETS würden die nicht rangehen.

Gruß, Waldemar

[RolfMu]

Dann gleich mal eine Frage :-)
Ist das Logikmodul eine eigene Hardware, oder Teil des Raumsensors, oder nutzt es die gleiche Hardware mit anderer Software, oder... eine ganz andere Lösung...

So ein richtig cooles busgebundenes Logikmodul wäre mal was, da würde ich mal gleich was mit anzustellen wissen :-)

[mumpf]

Ist das Logikmodul eine eigene Hardware, oder Teil des Raumsensors

Beides. Eigentlich ist es nur eine Firmware für den SAMD21. Die zugehörige Hardware kann man bei Masifi kaufen (dann bekommt man ein Sensormodul, dass auch Logik kann) oder man bastelt sich selbst ein SAMD-Board mit KNX-Anschluß und EEPROM und flasht es nur mit meiner Sensormodul-Firmware. Dann hat man eben "nur" ein Logikmodul. Oder Du nimmst die Hardware von Masifi und verzichtest auf jegliche Sensoren, dann kannst Du die natürlich auch nur mit der Logikmodul-Firmware flashen.

Kleine Anmerkung: Wenn Du wirklich nur mein https://github.com/mumpf/knx-logic (nur die Logik-Firmware) verwenden willst, sag vorher Bescheid. Ich habe einfach schon sehr lange nicht mehr die Logik standalone getestet. Könnte sein, dass die Startup-Routine nicht mehr alles so initialisiert, wie es für den Standalone-Fall nötig ist.

Grundsätzlich hab ich das Logikmodul so aufgebaut, dass es non-blocking in jede Firmware von mir eingebaut werden kann und dann das passende Gerät auch um Logiken erweitert. Hab hier leider viel mehr Ideen als Zeit .

Gruß, Waldemar

P.S.: Mein erstes "Logikmodul" sah auch so aus:
Logikmodu-Prototyp.jpg

[EPIX]

also das Logikmodul ("Software") ist das Gleiche - egal ob auf Masifii Hardware mit/ohne Sensoren oder Standalone?

[mumpf]

Genau so ist es.

Mit der erwähnten Kleinigkeit, dass ich es einfach seit Ewigkeiten nicht mehr standalone versucht habe und somit potentiell nicht alle Initialisierungen korrekt sind. Kann man aber schnell reparieren.

Ich hab da ein Schichtenmodell:

knx-sensor - implementiert das Gateway zwischen I2c-Sensoren und knx
knx-wire - implementiert das Gateway zwischen 1-Wire und knx
knx-logic - implementiert ein Logikmodul für knx
knx-common - etwas Hardware-Abstraktion und allgemeine Implementierungen, die nichts mit knx (vor allem mit dem knx-Stack, den ich verwende) zu tun haben.

Derzeit braucht jedes weiter oben stehende Paket alle darunter, mit ein paar #ifdef ließe sich auch schnell was Richtung "nur Sensor" oder "nur Wire" machen (common brauchen die alle), aber warum sollte man ein Logikmodul weglassen, wenn man es einfach "umsonst" dazubekommen kann?

Also ja, knx-logic und knx-common alleine gehen. In der common kann man dann in einer Hardware.h festlegen, welche Pins mit Prog-Button und Prog-LED belegt sind, wo das EEPROM liegt (falls eins da ist) und was der SAVE-Eingang ist (falls man das nutzen will).

Die Hardware von Masifi deckt eben alle Features ab, die ich auch in der Logik eingebaut habe, aber es ist so geschrieben, dass es auch mit "weniger" läuft:

• Ein reiner SAMD21 mit einem KNX-UART, einem Prog-Button und einer Prog-LED ist das Minimum.
• Wenn auch noch ein EEPROM (min 2KByte) und ein SAVE-Eingang da ist + ein Elko für min. 800ms Restlaufzeit (SAVE wird z.B. vom NCN5120/NCN5130 unterstützt und wird aktiv bei Busspannungsausfall), kann man auch die Funktion nutzen, dass Werte bei Busspannungsausfall gespeichert und nach einem Neustart wieder versendet werden.
• Wenn ein BUZZER da ist, der an einem Pin hängt, kann man das Logikmodul als Akustischen Signalgeber nutzen
• Wenn eine RGB-LED mit einem PCA9632-I2C-Treiber da ist, kann man es auch als optischen Signalgeber nutzen

Falls Interesse besteht, sagt mir Bescheid, dann mache ich das knx-logik-Paket standalone lauffähig.

Derzeit schaue ich mir auch den RP2040 an (Raspberry Pi Pico), bei dem könnte man z.B. SAVE mit weniger Hardware (also ohne zusätzlichem EEPROM) realisieren, mit viel mehr Logikkanälen oder eben mit mächtigerer Logik. Aber das ist noch eine längere Geschichte...

Es gibt auch Leute in meinem Alternative Firmware-Thread, die meine Software mit eigener Hardware nutzen, notfalls da nachfragen. Ich bin nicht so Hardware-Affin, deswegen nutze ich das Modul von Matthias.

Gruß, Waldemar

[sk73]

Hallo
hier eine Aufgabe für das Logikmodul aus der Praxis,

Wie kann ich die Luftqualitäts Note mit möglichst wenig Aufwand (Logikkanälen) in Farbwerte umwandeln.
Note 1+2 -> Farbe Grün = 3
Note 3+4 -> Farbe Gelb = 5
Note 5+6 -> Farbe Rot = 2

Ziel ist die Nutzung des LED Lichtes am MDT Glastaster II Smart neben dem Jeweiligen Raum Licht als Luftampel

Mit 2 Kanälen geht es einfach
Logik a Eingang Hysterese
ein Schwelle 5 -> Sende 2
aus Schwelle 2 -> Sende 3

Logik b Eingang Wertebereich
Bereich 3-4 -> Sende 5
Sonst Sende nichts

Logik A darf nicht wiederholt senden (nur Änderungen)
Logik B darf es



Erweiterter Aufgabenumfang:
1-4 wie oben
Note 5 -> Rot =2
Note 6 -> Rot = + Schwarz = 0 im Wechsel (Blinken)

oder

1-6 wie oben aber nur bei Nacht 1-4 = Schwarz (aus)

Bin auf Vorschläge gespannt


Gruß
Stefan

[mumpf]

Hi,

mit weniger Kanälen als 2 wirst Du es nicht hinbekommen, zumindest sehe ich keine Möglichkeit. Ich hatte das aber auch nicht entwickelt, um wenige Kanäle mit viel Funktionalität zu liefern, sondern um viele Kanäle mit wenig Funktionen zu haben.

Ich würde folgendes machen (für die finale Aufgabenstellung):
1+2 => 3 (Grün) über Kanal 1
3+4 => 5 (Gelb) über Kanal 2
5 => 2 (Rot) über Kanal 3
6 => 2/0 (Rot/Schwarz) über Kanal 4 blinkend
Nacht UND 1-4 => 0 (Schwarz) über Kanal 5 (intern auch mit Kanal 1 und 2 verbinden, so dass sie diese abschalten)

Hab ich nicht getestet, aber so würde ich rangehen.

Gruß, Waldemar

[doenke]

Hallo zusammen,

ich spiele gerade damit, auf Änderung der Luftfeuchtigkeit beim Duschen zu reagieren.
So ganz komme ich damit aber noch nicht zurecht.

Die einzige Möglichkeit, die ich für mich gefunden habe ist mittels Differenzintervall den aktuellen Wert mit einem Anderen zu vergleichen.
Der Eine ist dann der Feuchtigkeitswert von vor 30 Sekunden, der andere der Aktuelle.

Wie aber komme ich an zwei Feuchtigkeitswerte von unterschiedlichen Zeiten.?

Ich hatte erst mit "Ausgang schaltet Zeitverzögert" gespielt. Das sieht aber so aus, als ob das Ein/Aus Signal zeitverzögert wird, wenn es dann wieder in einen DT9.xxx umgewandelt wird, wird der aktuell anliegende Wert genommen...
Hier bin ich in einer Sackgasse.


Eine Andere Idee ist, die Feuchtigkeit im 30 Sekunden Abstand zu lesen und die dann alternierend auf zwei GAs zu senden. Dann habe ich zwischen beiden auch immer 30 Sekunden. Das könnte ich abbilden mit einem Blinker aus dem Treppenhauslicht und zwei Kanälen mit Tor.


Irgendwie habe ich aber das Gefühl, dass das noch deutlich einfacher gehen muss. Da steige ich doch in einem Jahr nicht mehr durch, was ich mir dabei gedacht habe...


Fällt dazu jemandem was ein? Hat wer sowas schonmal gemacht?
Bin ich auf dem richtigen Weg?


Grüße,
Sönke

[mumpf]

Hi Sönke,

die aktuellen Logikkanäle sind sehr elementar, relativ flexibel pro Kanal, aber jeder Kanal ist eben nur ein einfaches UND/ODER/EXOR/TOR... Du wirst für dieses Problem mehrere Kanäle brauchen.

Ich hatte erst mit "Ausgang schaltet Zeitverzögert" gespielt. Das sieht aber so aus, als ob das Ein/Aus Signal zeitverzögert wird, wenn es dann wieder in einen DT9.xxx umgewandelt wird, wird der aktuell anliegende Wert genommen...
Hier bin ich in einer Sackgasse.

Ja, das ist so. Es wird immer der Wert gesendet, der aktuell am Eingang anliegt. Ich dachte eigentlich, ich habe das in die Doku geschrieben, hab aber die Stelle jetzt auf die Schnelle nicht gefunden . Technischer Hintergrund: Ich hab keinen Speicher frei, um mir den ursprünglichen Wert zu merken.

Ich hab ironischerweise diesen Fall bei mir noch nicht mit dem Logikmodul implementiert, da ich schon vorher was mit dem MDT Logikmodul realisiert habe. Wie das immer so ist, wenn etwas zuverlässig läuft, fasst man das nicht an. Aber ich werde es zumindest nochmal ausprobieren.

Eine Andere Idee ist, die Feuchtigkeit im 30 Sekunden Abstand zu lesen und die dann alternierend auf zwei GAs zu senden. Dann habe ich zwischen beiden auch immer 30 Sekunden. Das könnte ich abbilden mit einem Blinker aus dem Treppenhauslicht und zwei Kanälen mit Tor.

Die Idee ist gut. Ich würde es auch so angehen. Eigentlich spricht auch nichts dagegen. Ohne es ausprobiert zu haben, sollte es auch mit nur einem Tor gehen:

• Tor: Lässt alle 30 Sekunden einen Wert durch, damit ist dieser Wert maximal 30 Sekunden alt
• Differenzintervall: Aktueller Wert auf E1, der triggert die Auswertung bei Telegrammeingang (der andere Eingang nicht). E2 bekommt den Vergleichswert vom Tor.

Da Du ja einen Sprung in der Luftfeuchte feststellen willst, muss der aktuelle Wert nicht in diskreten 30 Sekunden-Schritten vorliegen. Sobald der um z.B. 2% springt, wird geduscht. Oder anders gesagt: Wenn "Duschen" wahr ist, wenn der Wert nach 30 Sekunden um 2% gestiegen ist, dann ist es auch wahr, wenn er nach 15 Sekunden um 2% gestiegen ist.

Irgendwie habe ich aber das Gefühl, dass das noch deutlich einfacher gehen muss.

Tja, selbst mit dem MDT Logikmodul, das eine andere Philosophie verfolgt und pro Kanal mächtiger ist, brauchte ich für die 30 Sekunden-Verzögerung ein Tor, das es dort so nicht gibt. Ich habe dann eine Formel "Luftfeuchte + 0" genommen, da man bei Formeln triggern kann, wann sie berechnet werden. Der Differenzvergleich ist dort ähnlich. Somit: Nein, viel einfacher geht es nicht. Zumindest fällt mir nichts ein.

Da steige ich doch in einem Jahr nicht mehr durch, was ich mir dabei gedacht habe...

Ein wichtiger Punkt ist immer die Dokumentation, ich mach das immer in den Eigenschaften->Beschreibung, für jeden Logikkanal und meist noch für die Gesamtlogik.
Logiken in KNX sind aufwändig, für komplizierte Sachen hab ich immer noch eine Logikengine. Aber ich versuche nach und nach die Sachen ins KNX zu bekommen.
Allerdings ist dann ein "normaler" Elektriker damit sicherlich überfordert, falls dieser was am Haus machen müsste.

Ich hoffe, das hilft erstmal.

Gruß, Waldemar

[doenke]

Hallo Waldemar,

besten Dank für Dein Feedback. Dann bin ich ja auf dem richtigen Weg... :-)

Ich muss zugeben, dass es einen Riesenspaß macht, zu puzzeln, wie man mit den einfachen Mitteln zu einem Ergebnis kommt. Das ist fast schon erschreckend, wie weit man so kommt. Und ja... irgendwann wird einem ob der Komplexität übel und man lässt es doch bleiben. Aber es ginge. zumindest meistens.

Deinen Tipp mit dem Beschreibungsfeld nehme ich sehr dankend entgegen. Wenn mehr als 2 oder 3 Kanäle involviert sind, bin ich bisher von der KNX Lösung wieder abgekommen und habe mich dann doch für die Logikengine entschieden. Mit etwas mehr Erläuterung könnte es aber gehen.


Ich mache die Sache mit dem Duschsensor mal fertig und teile sie dann hier.

Viele Grüße,
Sönke

[doenke]

Hallo Waldemar,

Die Sache mit der Messung im Minutenabstand funktioniert. Bis auf ein Ding:

ich verzweifel an der Differenzhysterese...
Ich habe mal ein einfaches Beispiel aufgesetzt und eine Wertetabelle gemacht:

Zwei Eingänge, beide UND-Verknüpft
Bsp1.jpg

Den ersten Eingang mit Differenzhysterese:
Bsp2.jpg
Den zweiten mit Werteintervall, so dass der immer wahr ist, ausser bei 0:
Bsp3.jpg

Hier habe ich dann Eingang 1 auf 100 gesetzt und verschiedene Werte für Eingang 2 ausprobiert:

Eingang 2	Eingang 1 - Eingang 2	Ausgang	Erwartung
0	100	Aus	Aus, wegen UND-Verknüpfung
10	90	Ein	Ein
90	10	Ein	Ein
99	1	Ein	Aus
100	0	Ein	Aus
101	-1	Aus	Aus
105	-5	Aus	Aus
200	-100	Aus	Aus

Kannst Du mir sagen, wo ich hier meinen Denkfehler habe?
Es macht auf mich den Eindruck, dass hier auf "größer als" geprüft wird?

Oder hab ich bei dem Konstrukt mit der UND Verknüpfung etwas übersehen?


Viele Grüße,

Sönke

[mumpf]

Hi,

bin derzeit unterwegs und erst ab 6.1. wieder in der Lage zu testen. Ich verwende das bisher nur mit DPT 5, da funktioniert es. Da ich schon an ein paar Stellen mit DPT 9 korrigieren musste, vermute ich auch hier das Problem. Danke für die Rückmeldung, ich melde mich kommendes Wochenende.

Gruß, Waldemar.

[mumpf]

Hi Sönke,

Fehler gefunden. Wie erwartet lag es am DPT9, da hab ich falsch gedacht. War etwas blöd... Ich mach noch ein paar weitere Tests und dann bringe ich am WE eine neue Version vom Sensormodul raus, ich will sowieso vom Beta zur Release, da kann das dann alles mit rein.

Gruß, Waldemar

[doenke]

Hi Waldemar,

Danke fürs kümmern. Ich freu mich schon drauf.

Sönke