[obsolet - Modul ist im SVN - siehe Forum #12582] 10_KNX.pm Weiterentwicklung

[GammaTwin]

Update eingespielt. Kommunikation ist diesmal möglich. Werde beobachten...


Habe wieder folgendes Problem:

Ich habe Schwierigkeiten seit dem Update. DOIF funktionieren nicht mehr, da es neues Readings gibt.

Meine typische Definition:

Code: [Auswählen]

1/1/0:dpt1.001:g1:set:nosuffix 1/2/0:dpt1.001:g2:get:nosuffix
Vor dem Update entstanden nur die Readings "g1" und "g2" (und last-sender). Jetzt entsteht auch "set-G1" und "get-G2".

Es scheint daran zu liegen, dass ich die Readings "g1" und nicht "schalten" genannt habe.

@erwin: kannst Du das nachstellen. Und wie gehen wir damit um?

 

Bin wieder zurück gegangen. Hattest Du ja schon mal gelöst

[Amenophis86]

Wollte heute Abend testen aber dann warte ich auch noch bis das gefixed ist, sonst klappen meine DOIFs auch nicht

[erwin]

Hi GammatTwin & Amenophis86,
fix ist am GIT: Version 04.62

[GammaTwin]

wieder eingespielt Fix hat funktioniert. Beobachtung läuft wieder.

[Amenophis86]

Habs auch gerade eingespielt und werde mal sehen, ob ich was finde.

[Amenophis86]

Also ich konnte bisher keine Probleme feststellen. Will die Tage nochmal autocreate wieder definieren und schauen, ob das Problem noch besteht, dass alles auf disable 1 gesetzt wird aber da brauche ich Zeit zu um den Fehler abzufangen, wenn er kommen sollte.

[erwin]

Hi,
das sind ja good news!
lasst euch ruhig Zeit mit dem Testen, ich bin die nächste nächste Woche noch verfügbar, aber vom 5.-12.6. wieder weg, und erst nachher wird's die nächsten (geplanten) changes geben.
l.g.  und danke fürs testen
erwin

[GammaTwin]

Grüße,

mir ist etwas aufgefallen. Meine Fensterzustände stimmen nicht mehr.

Kann es sein, dass Wiederholungen irgendwie ignoriert werden? In einer bestimmten Zeit?

Zu Erklärung, wie die Fensterzustände ermittelt werden. Jede Griffposition sendet 2 Zustände:

Code: [Auswählen]

false,false: Griff unten - geschlossen
true,true: Griff seitlich - offen
true,false: Griff oben - gekipptIm KNX-System erzeugt eine Logik dann die Zustände "offen: true|false", "gekippt: true|false". Geschlossen gibt es nicht als Zustand, kann aber angenommen werden, wenn "offen" und "gekippt" false sind.

In Summe senden also 4 Gruppenadressen "Zustand 1", "Zustand 2", "offen", "gekippt". Da die Logik auf jede Änderung der "Zustände" reagiert, werden bei jeder Bewegung des Griffes 6 Telegramme gesendet:

Code: [Auswählen]

Zustand 1
offen
gekippt
Zustand 2
offen
gekippt
Schließe ich das gekippte Fenster, bewege ich den Griff über offen, es werden also 12 Telegramme gesendet - in weniger als 400 ms.

Code: [Auswählen]

#erste 90 Grad Griffdrehung
Zustand 1
offen
gekippt
Zustand 2
offen
gekippt
#zweite 90 Grad Griffdrehung
Zustand 1
offen
gekippt
Zustand 2
offen
gekippt
Soweit zudem, was schon immer auf dem Bus passierte. Im FHEM werden nur die beiden ersten Telegramme pro Gruppenadressen "wahrgenommen":

Code: [Auswählen]

#erste 90 Grad Griffdrehung
Zustand 1
offen
gekippt
Zustand 2
offen
gekippt
#zweite 90 Grad Griffdrehung
Zustand 1
Zustand 2Das dritte und vierte Telegramm von "offen" und "gekippt" gibt es nicht in FHEM und diese erscheinen nicht im Log.

Das kann ich mit jedem Fenster im Haus nachstellen.

[erwin]

Hi GammaTwin,

richtig 2 gleiche KNX Telegramme (innerhalb 500ms) werden ignoriert.
Gleich heisst: GA-Adresse und value ist ident
Das ist eine Funktion in fhem.pl, die ich in KNX.pm nutze.
Die Zeit ist konfigurierbar via global Attribut dupTimeout (default 500ms) siehe: https://wiki.fhem.de/wiki/DevelopmentModuleIntro - suche nach Fingerprint

Vorschlag: kommentiere die Zeile:

Code: [Auswählen]

       $hash->{FingerprintFn}  = "KNX_FingerPrint"; aus, mach einen shutdown restart
 (sollte Zeile 288 sein)
Wenn das Problem weg ist, haben wir die Ursache gefunden....
l.g. erwin

[Amenophis86]

Ich hänge mich mal mit dran, da ich eine ähnliche Frage habe. Gibt es auch eine Begrenzung in die andere Richtung? Ich habe ein Script für meinen Müllkalender bei dem im schlechtesten Fall bis zu 12 Telegramm furch eine for-Schleife direkt nacheinander von FHEM gesendet werden. Manchmal scheinen aber nicht alle auf dem BUS durch zu gehen.

[erwin]

Hi Amenophis86,

nein die Funktion gibts nur für den Empfang vom Bus. Ursprünglich hat Rudi das für die diversen Funkprotokolle implementiert, die grundsätzlich alles mehrfach senden...
Ich habs deßhalb implemetiert, weil ich (entgegen der dringenden Empfehlung) einen KNX-Router und KNXD mit Multicast testweise aktiviert habe und damit alle Telegramme mehrfach empfangen wurden.
l.g. erwin

[Amenophis86]

Alles klar, dann werde ich da mal weiter suchen. Kann mir vorstellen, dass es einfach für den Bus zu viel ist, wenn da so viel auf einmal raus gehauen wird. Aber werde mal weiter testen.

[Hauswart]

Ich bekomme seit dem neuesten Update gestern keine Daten mehr ins FHEM, senden kann ich lustigerweise noch.


Nach Restore auf 10_KNX.pm FVERSIONE  04.43 25-02-2021 geht es wieder.

[erwin]

Hi Hauswart,

kanst du bitte das IO-Device auf verbose 5 setzen und nach Log-Mgs schauen, die mit KNX_parse... beginnen?
l.g. erwin

[GammaTwin]

Hi GammaTwin,

richtig 2 gleiche KNX Telegramme (innerhalb 500ms) werden ignoriert.
Gleich heisst: GA-Adresse und value ist ident
Das ist eine Funktion in fhem.pl, die ich in KNX.pm nutze.
Die Zeit ist konfigurierbar via global Attribut dupTimeout (default 500ms) siehe: https://wiki.fhem.de/wiki/DevelopmentModuleIntro - suche nach Fingerprint

Vorschlag: kommentiere die Zeile:

Code: [Auswählen]

       $hash->{FingerprintFn}  = "KNX_FingerPrint"; aus, mach einen shutdown restart
 (sollte Zeile 288 sein)
Wenn das Problem weg ist, haben wir die Ursache gefunden....
l.g. erwin

Mit der auskommentierten Zeile funktioniert es. Damit haben wir die Ursache.

Dies bedeutet aber, das identische Telegramme verworfen werden, auch wenn in der Zwischenzeit ein anderer Zustand der GA gesendet wird. Es wird also nicht geprüft, ob es eine Wiederholung ist. Das ist aber doch nicht in Ordnung, oder?

In meinem Fall und vereinfacht auf "offen":

Code: [Auswählen]

#erste 90 Grad Griffdrehung
offen: false (Zwischen-Status, da nur Zustand1 aktualisiert)
offen: true (korrekter Status)
#zweite 90 Grad Griffdrehung
offen: false (Zwischen-Status) - wird verworfen, da identisches Telegramm
offen: false (korrekter Status) - wird verworfen, da identisches TelegrammEs bleibt offen:true stehen.