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

Begonnen von erwin, 15 Dezember 2020, 11:45:16

Vorheriges Thema - Nächstes Thema

GammaTwin

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


Habe wieder folgendes Problem:
Zitat von: GammaTwin am 11 Februar 2021, 19:09:45
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 :)

Amenophis86

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...

erwin

Hi GammatTwin & Amenophis86,
fix ist am GIT: Version 04.62
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

GammaTwin

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

Amenophis86

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...

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.
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...

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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

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:
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.

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:       $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 Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

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.
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...

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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

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.
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...

Hauswart

#132
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.
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

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

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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

GammaTwin

#134
Zitat von: erwin 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

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.