OpenKNX-Logikmodul release

[Amenophis]

Hallo mumpf Waldemar,

ich hatte heute die Idee etwas an meiner Heizungssteuerung mit Logiken zu arbeiten. Dabei habe ich festgestellt, dass das Logikmodul kein HVAC (DPT 20) kann, um direkt den Modus zu ändern. Ist zukünftig etwas in der Richtung geplant?
Kann es vermutlich über mein MDT Modul abdecken aber das hat keine Zeitverzögerung, warum ich eigentlich eins meiner Sensormodule nutzen wollte. Man kann halt nicht alles haben

Edit:
Sehe gerade, dass auch ein Workaround über Szenen geht.

[EPIX]

Danke! und schon funktionier's....

@Waldemar: Eingang2 war aber inaktiv, daher dachte ich, es wird nur E1 ausgewertet...

[mumpf]

EPIX: Du hast eine interessante Kombi gewählt, mit Eingang 2 statt Eingang 1 hätte es wahrscheinlich klappen können - ist aber nichts, was ich vorschlagen würde.

Erstmal zum Hintergrund: Ein TOR kann man sich wirklich wie ein Gartentor vorstellen. Solange es zu ist, geht keiner durch. Solange es offen ist, kann man sowohl rein wie auch raus. Auf KNX-Telegramme übertragen: Solange es offen ist, könenn sowohl EIN- wie auch AUS-Telegramme durch. Allerdings erlaubt das TOR, sowohl beim schließen wie auch beim öffnen noch von sich aus ein Telegramm zu senden. Du lässt jetzt interessanterweise beim schließen ein EIN und beim öffnen ein AUS senden. Gleichzeitig hast Du Eingang 2 gar nicht belegt, lässt das TOR somit immer zu... Warum sendet das Tor dann immer wieder ein EIN?

Gehen wir das mal schrittweise durch, wir sind ja in KNX und das ist Telegrammgetrieben:

1. Modul wird gestartet
2. Eingang 1 wird mit AUS (0) vorbelegt und es wird ein ReadRequest gesendet.
3. Die 0 vom Eingang 1 geht an die Logik, die von jedem Eingangstelegramm getriggert werden soll.
4. Jetzt wird die Logik ausgewertet: Eingang 2 ist AUS (weil nicht belegt), das TOR wird also geschlossen.
5. Ein schließen vom Tor soll ein EIN senden.
6. Das EIN geht geht zu den Ausgangskonvertern, die aber nichts machen und einfach ein AUS über das KO auf den Bus senden.
7. Jetzt geht die Antwort vom ReadRequest ein, nehmen wir mal die obigen 40°C an.
8. Der Eingangskonverter verwandelt das in ein AUS-Signal (das nur 0-35°C im Wertintervall liegen)
9. Das AUS geht an die Logik, die von jedem Eingangstelegramm getriggert werden soll.
10. Logikauswertung: Eingang 2 ist AUS (weil nicht belegt), das TOR wird also geschlossen.
11. Ein schließen vom Tor soll ein EIN senden.
12. Das EIN wird zum Ausgangs-KO geschickt.
13. Jetzt geht das Telegramm mit 10°C ein.
14. Der Eingangskonverter wird daraus ein EIN machen (0-35°C => EIN)
15. Das EIN geht an die Logik.
16. Logikauswertung: Eingang 2 ist AUS (weil nicht belegt), das TOR wird also geschlossen.
17. Ein schließen vom Tor soll ein EIN senden.
18. Das EIN wird zum Ausgangs-KO geschickt.
19. usw...

Solange das TOR zu ist, kann vom Eingang kommen was will, es kommt nicht durch das Tor. Da Du aber die Logik jedes Eingangstelegramm auswerten lässt, wird diese immer das Tor schließen. Und da beim Schließen immer ein EIN gesendet werden soll, kommt Dein Ergebnis raus.

Besser:

• Logik: ODER mit einem Eingang, bei jedem Eingangstelegramm,
• Eingang 1: Wertintervall und Lesen bis erstes Telegramm eintrifft wie gehabt, Eingang nicht vorbelegen.
• Ausgang sendet EIN bei AUS und umgekehrt (invertiert also)

Was passiert jetzt:

1. Modul wird gestartet
2. Eingang 1 wird nicht vorbelegt und es wird ein ReadRequest gesendet.
3. Die Logik wird nicht getriggert, da nichts vorbelegt wurde.
4. Jetzt geht die Antwort vom ReadRequest ein, nehmen wir mal die obigen 40°C an.
5. Der Eingangskonverter verwandelt das in ein AUS-Signal (das nur 0-35°C im Wertintervall liegen)
6. Das AUS geht an die Logik, die von jedem Eingangstelegramm getriggert werden soll.
7. Logikauswertung ODER: Eingang 1 ist AUS, kein Eingang 2 => AUS an den Ausgang schicken
8. Der Ausgangskonverter macht aus dem AUS eine EIN
9. Das EIN wird zum Ausgangs-KO geschickt.
10. Jetzt geht das Telegramm mit 10°C ein.
11. Der Eingangskonverter wird daraus ein EIN machen (0-35°C => EIN)
12. Das EIN geht an die Logik.
13. Logikauswertung ODER: Eingang 1 ist EIN, kein Eingang 2 => EIN an den Ausgang schicken
14. Der Ausgangskonverter macht aus dem EIN ein AUS
15. Das AUS wird zum Ausgangs-KO geschickt.
16. usw...

Derzeit bekommst Du mit jedem Eingangstelegramm (also jedem Senden der Temperatur) auch ein Telegramm am Ausgang. Wenn Du die Logik auf "bei Änderung" stellst, wirst Du nur Änderungen auf den Bus gesendet bekommen.

Ich hoffe, das hilft Dir und anderen ein besseres Verständnis zu entwickeln, wie detailliert der Signalverlauf bei meinem Logikmodul beeinflusst werden kann.

Gruß, Waldemar

[willisurf]

TOR ist dafür die falsche Logikoperation.

Du musst ein ODER bzw. UND (ist bei einem Kanal egal) benutzen und kannst dann über den Eingangskomperator festlegen welche Werte als 1 oder 0 bewertet werden.

[EPIX]

Guten Morgen,

irgendwie habe ich einen Denkfehler:

ich möchte, wenn eine Temperatur <35° ist, ein EIN auf den Bus senden, andernfalls ein AUS.

Die Temperatur wird zyklisch gesendet...

Meine Einstellungen sind:


Logik_Allgemein.jpg
Logik_Eingang.jpg
Logik_Ausgang.jpg

aber es wird immer eine 1 gesendet, egal wie hoch die Temperatur ist....

Logik_Bus.jpg wo liegt denn mein Denkfehler?

LG aus Salzburg/Österreich
Erich

[zenvy]

So wie ich das verstanden habe, hältst Du im Union DPT-Abhängig einen Float oder einen Int vor. Jetzt ärgere ich mich, dass ich nicht selber drauf kam...
Ich muss das nochmal checken bei Konvertierungen (z.B. DPT9 auf DPT5), aber das war vorher potentiell auch fehlerbehaftet.

Genau, das ist die Idee. Man könnte das union auch so bauen, das die anderen DPTs ihren Datentyp behalten statt nach int32_t gecastet zu werden. Oder halt noch andere weirde DPTs einbauen.

Danke erstmal für die Idee. Ich komme allerdings erst kommende Woche dazu, hier was zu machen. Brauchst Du noch Hilfe beim Bauen, damit Du bei Dir die Sachen schon mal einbauen kannst? Sorry dass es derzeit Chaotisch ist, aber ich baue derzeit mehrere Projekte um, deswegen dauert das...

Bauen läuft alles mit bisschen gefrickel.

Ich hab allerdings evlt noch einen Bug gefunden

Ich möchte min(A, B, C, D) machen, d.h. ich nehme mir drei Kanäle und mache im ersten min(A, B), im zweiten min(C, D) und im dritten min(Kanal 1, Kanal 2).
Dazu hatte ich die "Kanalausgang X/Y" Funktion benutzt. Leider liefert der Kanal dann immer 0 zurück obwohl die beiden Einzelkanäle ordentlich ihr Minimum berechnen. Ich dachte erst, mein Patch hat das kaputt gemacht aber auch mit der 1.4 Release FW aus der zip ist das Kaputt.

Mit viel Code lesen scheint mir das auch gar nicht so zu gehen und ich vermute mal hier wird nicht der End-Wert des Ausgangs sondern der End-Wert der Logikengine (die nur bool macht) verknüpft. Ich schätze hier muss ich zwei GAs nutzen um den berechneten Wert ordentlich zu transportieren oder?

Edit: ich, ähm, hab das mal gebaut ist wahrscheinlich nicht schön und müsste angepasst werden bevor man das merged.

Edit: Und nen Tag später merke ich, dass das gar nicht notwendig gewesen wäre wenn ich "normale" Eingänge mit "benutze vorhandene KO" gemacht hätte, oh well.

[mumpf]

Aber würde das dann nicht dazu führen das der FlipFlop immer direkt zurückgesetzt wird, weil die Tür ist ja initial geschlossen (also FALS

Naja, wenn Du das Logikmodul neu startest und die Tür zu ist, würdest Du die Info am Ausgang bekommen, dass die Tür zu ist, also ist der Briefkasten "geleert" (wenn Du den Eingang bei Neustart liest). Aber das ist ja auch nicht falsch, oder? Wobei ich hier gar nicht den letzten Zustand lesen würde, das ist nicht erforderlich.

Und sonst ist es doch prima, wenn erst mit dem Schließen erst das "geleert" kommt, oder? Bei der derzeitigen Einstellung könnte sonst folgendes passieren:

• Durch die Klappe wurde "Post" gemeldet.
• Du machst die Tür auf -> "geleert" kommt
• Während die Tür auf ist, kommst Du gegen die Klappe -> "Post" wird gemeldet
• Jetzt machst Du die Klappe zu -> nix passiert, die Meldung "Post" ist immer noch da.
• Du meldest hier im Forum, dass das RS-FlipFlop nicht funktioniert .

Gruß, Waldemar

[willisurf]

Wie gesagt, versuche mal mit Test GAs und Beoachten der Reaktion im Gruppenmonitor der Sache auf die Spur zu kommen. Das kann auch Freude machen, wenn es am Ende funktioniert.

[exxtreme]

Ehrlich gesagt, ich bin ratlos.

Genau so geht es mir auch.

Kann ein anderes Gerät mit dem Logikmodul "reden"?

Das werde ich nochmal probieren.

P.S.: Ich würde übrigens den Reset vom RS-Flipflop erst beim schließen der Tür triggern (also Eingang 2 negieren).

Aber würde das dann nicht dazu führen das der FlipFlop immer direkt zurückgesetzt wird, weil die Tür ist ja initial geschlossen (also FALSE)?

P.P.S.: Ansonsten ist das RS-FlipFlop für genau diese Art von Anwendung gedacht, also genau richtig eingesetzt.

Danke, ich hab mich auch echt über diese Funktion gefreut, da alle anderen Logikbausteine die ich habe, diese Funktion nicht anbieten.

[mumpf]

Ehrlich gesagt, ich bin ratlos.

Denn sobald das gilt:

Wenn ich die Werte über die ETS setze reagiert das Logikmodul wie erwartet.

kann ich nichts mehr machen... Die Kommunikation auf dem Bus ist genormt. Und es ist Broadcasting. Wenn also Werte von einem empfangen werden können (ETS), können sie von allen empfangen werden.
Das einzige, was dazwischen liegen kann ist ein Filter, üblicherweise sind das LK. Deswegen nochmal die Frage: Kein LK zwischen Tastsensor und Logikmodul?
Wobei die Tatsache, dass Du die Telegramme vom Tasterinterface in der ETS siehst und von der ETS aus erfolgreich Telegramme senden kannst gegen einen LK spricht.

Kann ein anderes Gerät mit dem Logikmodul "reden"?

Gruß, Waldemar

P.S.: Ich würde übrigens den Reset vom RS-Flipflop erst beim schließen der Tür triggern (also Eingang 2 negieren).

P.P.S.: Ansonsten ist das RS-FlipFlop für genau diese Art von Anwendung gedacht, also genau richtig eingesetzt.

[willisurf]

Soweit ich das beurteilen kann, kommen die Werte an.

Dann müsstest Du eigentlich mit dem Gruppenmonitor und ein paar Tests des Logikkanals herausfinden können, wo es hakt.

Ich nehme für so etwas immer gern ein paar Test GAs und EasyKNX, das ist handlicher als der Gruppenmonitor (der aber auch funktioniert). Wenn die Test GA aus einem sonst unbenutztem Bereich stammen (z.B. Hauptgruppe 31) kannst Du gut filtern.

[exxtreme]

Kommen denn wirklich Werte vom Tasterinterface? Briefkasten hört sich so an, als ob da ein LK (wegen Außenlinie) dazwischen ist.

Soweit ich das beurteilen kann, kommen die Werte an. Ich kann sie auch im Gruppenmonitor sehen. Es handelt sich um zwei Reed-Kontakte im Briefkasten, das Tasterinterface dazu sitzt allerdings im Gebäude, daher ist das keine getrennte Außenline.

Und noch was: Du lässt Die Logik "Bei jedem Eingangstelegramm" reagieren, oder? Und "auch wenn noch nicht alle Werte bekannt sind"?

Stimmt, dazu habe ich kein Screenshot gesendet, es ist aber genau so konfiguriert wie du es gesagt hast:

image.png

[mumpf]

Kann mir jemand auf die Sprünge helfen?

Kommen denn wirklich Werte vom Tasterinterface? Briefkasten hört sich so an, als ob da ein LK (wegen Außenlinie) dazwischen ist.

Und noch was: Du lässt Die Logik "Bei jedem Eingangstelegramm" reagieren, oder? Und "auch wenn noch nicht alle Werte bekannt sind"?
Das sehe ich in Deinem obigen Screenshot nicht...

Gruß, Waldemar

[mumpf]

OK, danke.

So wie ich das verstanden habe, hältst Du im Union DPT-Abhängig einen Float oder einen Int vor. Jetzt ärgere ich mich, dass ich nicht selber drauf kam...
Ich muss das nochmal checken bei Konvertierungen (z.B. DPT9 auf DPT5), aber das war vorher potentiell auch fehlerbehaftet.

Danke erstmal für die Idee. Ich komme allerdings erst kommende Woche dazu, hier was zu machen. Brauchst Du noch Hilfe beim Bauen, damit Du bei Dir die Sachen schon mal einbauen kannst? Sorry dass es derzeit Chaotisch ist, aber ich baue derzeit mehrere Projekte um, deswegen dauert das...

Gruß, Waldemar

[zenvy]

Ich hab dir hier mal einen proof of concept hingelegt.

Wenn ich das Big VPM+LOG damit baue dann rechnet er korrekt. Ich habe allerdings noch nicht getestet ob die anderen DPTs alle noch gehen. Und ob DPT Mischungen korrekt sind.

In processConvertInput ist ein TODO drin welches du schneller lösen kannst als ich. Es ist auch etwas unflexibel wenn jetzt noch mehr DPTs dazu kommen sollen aber das wars vorher ja auch.

Am besten wäre natürlich ein struct statt einer union (dann weiß der uValue selber welcher DPT er ist) aber dann müsste man dynamisch Speicher allozieren oder weit genug oben im Stack 3-4 uValues vorhalten und mit runtergeben damit die gefüllt werden was auch hässlich ist.