10_KNX.pm Weiterentwicklung

[Amenophis86]

Code: [Auswählen]

Unknown code C01002r0110e00, help me!C<src-addresse><r> 01 1 0e <value>

Ah das ist der Hexcode für die GA Adresse, vielen Dank

der system-weite autocreate threshold ist 3* in 60 sekunden , dass gilt für alle devices. Was richtig oder falsch ist, bin ich mir nicht sicher. Z.b. Ein ThemperaturSensor, der alle 3 Minuten sendet, würde auch mit dem default nicht angelegt werden, aber jedesmal eine "unknown..." message produzieren.

Ich verstehe. Dann muss das vermutlich wirklich jeder für sich entscheiden, ob er will, dass jedes Gerät angelegt wird (1x Nachricht in 10 Sekunden zum Beispiel) oder nur bestimmte Geräte und dann die Werte entsprechend anpassen.
Kann es sein, dass das help me auch kommt, wenn es das Device schon gibt aber auf disable 1 steht? Und ist es neu, dass neue Geräte auf disable 1 gestellt werden? Ich glaube nämlich, dass das früher nicht war mit disable und deswegen weniger help me Nachrichten gekommen sind, wenn es das Device schon gab.

[erwin]

Kann es sein, dass das help me auch kommt

das muss ich mir anschauen...

Und ist es neu, dass neue Geräte auf disable 1 gestellt werden?

Ja, das ist neu. Grund ist, das der User sowieso die def ändern muss (zumindest model)  sonst kann das device die ankommenden Nachrichten ja nicht richtig interpretieren. Und mit disable schmeisst die parse funktion gleich die ankommende message weg (=schneller).
Das mit den unknown messages, wenn das device schon exisitert, aber disabled ist, schau ich mir noch an.
PS: die "unknown code xxx, pls. help me" werden aus der fhem.pl geschickt, ausgelöst werden sie durch die 00_TUL, bzw. 00_KNXTUL Module...

[EinEinfach]

Hallo zusammen, habe heute das Update eingespielt und gleich angefangen mit DPT16.001 spielen. Gerade im Log folgendes gesehen:

Code: [Auswählen]

2021.02.24 11:42:03 1: PERL WARNING: Illegal hexadecimal digit ' ' ignored at ./FHEM/10_KNX.pm line 2082.

[erwin]

Hi EinEinFach,

Line 2082 ist bei dieser version mitten in der cmd-ref, dort kann/darf nichts exektuiert werden, kannst du bitte nochmal checken?
und: geht irgendwas nicht? Was versuchst du - was ist das ergebnis - ich brauch was zum nachstellen.
l.g. erwin

[EinEinfach]

Ich schicke einige Statis an den Glastaster 2 von MDT. Der String war "Gesperrt", wo das einmalig im Log aufgetaucht ist. Wie gesagt, das war nur einmalig da, sonst tut alles wie es soll. Ich beobachte das, sollte was neues auftauchen, versuche ich mehr Input zu liefern

Gruß

[erwin]

@EinEinfach: ok,schaun wir mal...

@All:
ich bin dabei, die nächste Version zu releasen:
u.a. wird dort ein neues Attribut eingeführt, siehe diskussion in diesem Thread zum Thema toggle-cmd.
Die neue cmd-ref:

Code: [Auswählen]

toggleSRC - lookup current value before issuing "set device <gadName> toggle" cmd.
FHEM has to retrieve a current value to make the toggle-cmd acting correctly. This attribute can be used to define the source of the current value.
Format is: <devicename>:<readingname>. If you want to use a reading from own device, you can use "$self" as devicename. Be aware that only on and off are supported as valid values when defining device:readingname.
If this attribute is not defined, the current value will be taken from owndevice:readingName-get or, if readingName-get is not defined, the value will be taken from readingName-set....sollte soweit rückwärtskompatibel sein und nun auch "spezial-fälle" abdecken.
Die Frage: der name toggleSRC gefällt mir überhaupt nicht, mir ist nur nix besseres eingefallen....
Hab ihr bessere Vorschläge für den Attribut-Namen? - noch kann ich ganz leicht ändern...
l.g. erwin

[Amenophis86]

Top, für die Einführung.

Ich schlage einfach nur KNX_toggle vor. Zum einen bin ich ein Fan davon, wenn attr die nur für ein Modul sind entsprechend mit dem Modulnamen beginnen und zum zweiten bedarf es aus meiner Sicht das Kürzel SRC nicht.

[erwin]

Hi,
"KNX_toggle" klingt logisch und plausibel...und gefällt mir wesentlich besser!
Ich lass die Version noch ein paar Tage auf meine Prod-system laufen...
Falls in den nächsten Tagen kein "genialer name" kommt, wirds KNX_toogle!
Danke erwin 

[erwin]

Hi All,
eine neue Version E04.43 ist am Git:
change History:

Code: [Auswählen]

1) fix: en-de-code dpt 6,8,13
2) fix autocreate- unknown code..
ich hab autocreateThreshold wieder aus dem Modul entfernt, nachdem das als Attribute im autocreate modul vom user selbst definiert
werden kann, und zwar auch KNX spezifisch! Z.b: "attr autocreate autocreateThreshold KNX_.*:2:10"
-übersetzt: definiere ein KNX_xxyyzzz device falls binnen 10 sekunden 2 Messages mit der gleichen GA-addr. vom Bus ankommen.
unknown codes sollten jetzt keine mehr vorkommen!
Die devices sind default disabled, es muss ein richtiger dpt-typ manuell definiert werden.
3) Set-readings / get-readings
Ich habe versucht zu trennen: die Funktion der set/get/listenonly option (verhindern von set- od. get-cmd) von der Logik wann set- / get-readings gesetzt werden.
set-readings werden NUR MEHR gesetzt, sobald ein FHEM set-cmd ausgeführt wird.
  bisher: wurde das set reading auch gesetzt, fall die "set-option" definiert war und eine Msg vom Bus kam..
  (es gab kein get-reading wenn die "set-option" definiert war)
get-readings werden für ALLE messages gesetzt, die vom Bus kommen (unabhängig von set-option).
- das kann bei unterschiedlichen Implementationen durchaus zu Unterschieden führen: (das ist zwar nicht neu, aber kann fürs debuggen nützlich sein!)
- Folgende Varianten hab ich bisher festellen können:
- a) ein FHEM-set cmd erzeugt KEIN get-reading. Das wäre der "Normalfall"
- b) ein FHEM-set cmd erzeugt EIN get-reading, zusätzlich zum set-reading.
Mögliche Ursachen:
b1) der IP- Layer echoed die gesendete FHEM-set msg. (Trifft für KNXTUL multicast zu)
b2) in der ETS (bzw. im KNX-device) ist für diese GA das Flag update/aktualisieren gesetzt.
b3) sehr alte KNXD-Versionen machen das auch auf Tunnel-connections.
Was zutrifft kann man evtl. erkennen, wenn man im event-monitor auf last-sender schaut...
- Mehrfache get-readings (für dieselbe GA) kommen vor:
a) Falls am KNX-TP1 ein resend passiert.
b) TASMOTA-KNX - schickt jede msg 3mal, falls in den KNX-definitionen im Tasmota "Communication Enhancement" eingestellt ist.
c) wenn es in einem LAN mehrere KNXD's mit "S" option bzw. KNX Router gibt, dann entstehen möglicherweise loops..
d) Falls gleichzeitig ein TUL UND ein KNXTUL Modul definiert ist! Verhalten ist nicht deterministisch, manchmal kommen die msgs über beide Interfaces, manchmal nur über eins von beiden...
Lt. KNX-specs darf es KEINE 2 Pfade zwischen 2 Geräten geben! (so hab ich es zumindest verstanden)
Falls jetzt jemand verwirrt ist, hab ich Verständnis dafür... Falls ihr die unterscheidung set-/get-reading nicht für weitere Logik braucht, empfehle ich die Verwendung der "noSuffix-option".
4) cmd-ref: umstellung von "<a name=" nach "<a id=" siehe:https://forum.fhem.de/index.php/topic,118915.msg1135123.html#msg1135123
5) Neu: Attribute KNX_toggle
ist in der cmdref im Detail beschrieben.
Das sollte für die nächste Zeit die letzte "gröbere" Änderung am Modul sein, fixes und neue Features natürlich ausgenommen.
Feedback willkommen! Bei Problemen bitte mit einem "list <device>" und evtl. Log-Auszug, falls sinnvoll.
l.g.erwin