Autor Thema: [obsolet - Modul ist im SVN - siehe Forum #12582] 10_KNX.pm Weiterentwicklung  (Gelesen 14579 mal)

Offline GammaTwin

  • Full Member
  • ***
  • Beiträge: 135
Antw:10_KNX.pm Weiterentwicklung
« Antwort #120 am: 20 Mai 2021, 20:03:54 »
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:
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 :)
« Letzte Änderung: 20 Mai 2021, 20:13:00 von GammaTwin »

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #121 am: 20 Mai 2021, 20:24:17 »
Wollte heute Abend testen aber dann warte ich auch noch bis das gefixed ist, sonst klappen meine DOIFs auch nicht :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #122 am: 21 Mai 2021, 09:36:04 »
Hi GammatTwin & Amenophis86,
fix ist am GIT: Version 04.62
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline GammaTwin

  • Full Member
  • ***
  • Beiträge: 135
Antw:10_KNX.pm Weiterentwicklung
« Antwort #123 am: 21 Mai 2021, 14:40:36 »
wieder eingespielt :) Fix hat funktioniert. Beobachtung läuft wieder.

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #124 am: 21 Mai 2021, 21:56:43 »
Habs auch gerade eingespielt und werde mal sehen, ob ich was finde.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #125 am: 26 Mai 2021, 14:38:32 »
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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #126 am: 26 Mai 2021, 14:52:39 »
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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline GammaTwin

  • Full Member
  • ***
  • Beiträge: 135
Antw:10_KNX.pm Weiterentwicklung
« Antwort #127 am: 28 Mai 2021, 08:20:54 »
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:
false,false: Griff unten - geschlossen
true,true: Griff seitlich - offen
true,false: Griff oben - gekippt
Im 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:
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.
#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":
#erste 90 Grad Griffdrehung
Zustand 1
offen
gekippt
Zustand 2
offen
gekippt
#zweite 90 Grad Griffdrehung
Zustand 1
Zustand 2
Das 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.

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #128 am: 28 Mai 2021, 08:46:44 »
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:       $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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #129 am: 28 Mai 2021, 08:54:36 »
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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #130 am: 28 Mai 2021, 09:18:01 »
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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #131 am: 28 Mai 2021, 09:55:42 »
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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Offline Hauswart

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 859
Antw:10_KNX.pm Weiterentwicklung
« Antwort #132 am: 28 Mai 2021, 09:58:26 »
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.
« Letzte Änderung: 28 Mai 2021, 10:09:07 von Hauswart »
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #133 am: 28 Mai 2021, 12:20:45 »
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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline GammaTwin

  • Full Member
  • ***
  • Beiträge: 135
Antw:10_KNX.pm Weiterentwicklung
« Antwort #134 am: 28 Mai 2021, 14:35:48 »
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:       $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":
#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 Telegramm
Es bleibt offen:true stehen.
« Letzte Änderung: 28 Mai 2021, 14:39:17 von GammaTwin »

 

decade-submarginal