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

[lichtimc]

OK, super, danke.
Wenn man übrigens DOIFs im Perl Modus einsetzt und die dort vorhandene Funktion fhem_set("device on g3"); verwendet, funktioniert das nicht: Die Meldung erscheint im Log, es wird aber nichts geschalten.
Vielleicht könntest du dir das noch anschauen?
Vielen Dank.

[erwin]

re: DOIF's

sorry nachdem ich doif überhaupt nicht verwende, gibts 2 Möglichkeiten:

1) versuch mal mit doif "set device g3 on"
   falls es so funktioniert,dann ist das die Lösung....
  die neue syntax wurde vorallem für scripte, notify,... eingeführt.
2) FALLS NICHT:
   setze das KNX-device auf verbose 5 und beoachte den Eventmonitor was passiert, wenn das doif auslöst.
   das ist für mich dann die Unterscheidung das richtige Kommando vom doif kommt oder nicht!
   wenn das nicht hilft, dann bitte ein list device und einen Log-Auszug hier posten.
l.g. erwin

[thorte]

Hallo zusammen,

ich habe seit dem letzten Update Probleme mit dem Statustext meiner MDT-Glastaster. Ich habe lass mir auf den Glastastern zwei Zeilen Statustext anzeigen, die ich über ein entsprechendes Device bediene:

Code Auswählen Erweitern


Internals:
   DEF        4/1/120:dpt16.000:Meldung:set:nosuffix
4/1/121:dpt16.000:Statustext1:set:nosuffix
4/1/122:dpt16.000:Statustext2:set:nosuffix
   DEVNAME    Visu.KiZ3.Info
   Eversion   E04.20 10-01-2021
   FIRSTGADNAME Meldung
   FUUID      5f5d111d-f33f-4189-41b8-ace088441a0ddee4
   GETSTRING 
   IODev      KNX
   NAME       Visu.KiZ3.Info
   NOTIFYDEV  global,TYPE=KNX
   NR         285
   NTFY_ORDER 50-Visu.KiZ3.Info
   SETSTRING  Statustext1:multiple,>CLR< Meldung:multiple,>CLR< Statustext2:multiple,>CLR<
   STATE      bbb <br/> 20.4 °C
   TYPE       KNX
   GADDETAILS:
     Meldung:
       CODE       04178
       GROUP      4/1/120
       MODEL      dpt16.000
       NO         1
       OPTION     set
       RDNAMEGET 
       RDNAMEPUT  Meldung
       RDNAMESET  Meldung
       SETLIST    :multiple,>CLR<
     Statustext1:
       CODE       04179
       GROUP      4/1/121
       MODEL      dpt16.000
       NO         2
       OPTION     set
       RDNAMEGET 
       RDNAMEPUT  Statustext1
       RDNAMESET  Statustext1
       SETLIST    :multiple,>CLR<
     Statustext2:
       CODE       0417a
       GROUP      4/1/122
       MODEL      dpt16.000
       NO         3
       OPTION     set
       RDNAMEGET 
       RDNAMEPUT  Statustext2
       RDNAMESET  Statustext2
       SETLIST    :multiple,>CLR<
   GADTABLE:
     04178      Meldung
     04179      Statustext1
     0417a      Statustext2
   Helper:
     DBLOG:
       Statustext1:
         dblog:
           TIME       1612552381.85846
           VALUE      bbb
       Statustext2:
         dblog:
           TIME       1612549390.03373
           VALUE      20.4
       last-sender:
         dblog:
           TIME       1612552381.85846
           VALUE      fhem
       state:
         dblog:
           TIME       1612552381.85846
           VALUE      bbb
   READINGS:
     2021-02-05 19:10:25   Meldung         
     2021-02-05 20:13:01   Statustext1     bbb
     2021-02-05 19:23:10   Statustext2     20.4 °C
     2021-02-05 20:13:01   last-sender     fhem
     2021-02-05 20:13:01   state           bbb
Attributes:
   IODev      KNX
   group      Visu
   room       EG_KiZ3
   stateFormat Statustext1 <br/> Statustext2
   verbose    5


Je Glastaster habe ich so zwei dpt16.000-Adressen, über die ich die beiden Zeilen befülle. Mit dem alten Modul funktioniert dies problemlos. Seit dem Update kommt irgendwie nichts mehr an. Zeitweise hatte ich den Eindruck, es funktioniert, aktuell ist es aber wieder so:
10_KNX.pm in der Version vom 10.12. --> alles geht
10_KNX.pm in der Version von 16.01. --> ich bekomme keinen Text auf die dpt16-Adressen der Glastaster geschrieben.

Verbose vom Device und vom KNX-Interface (knxd) habe ich auf 5 gesetzt, kann aber keine offensichtlichen Fehler finden:
Funktionieren 10_KNX:

Code Auswählen Erweitern


2021.02.05 20:08:40.378 5: enter set Visu.KiZ3.Info: hash: HASH(0x5609cc2acba0), attributes: Visu.KiZ3.Info, Statustext1, aaaa
2021.02.05 20:08:40.378 5: set Visu.KiZ3.Info: desired target is gad Statustext1, command: aaaa, args:
2021.02.05 20:08:40.378 5: check value: aaaa, gadName: Statustext1
2021.02.05 20:08:40.378 5: check value: aaaa, gadName: Statustext1, model: dpt16.000, pattern: (?^ix:.{1,14})
2021.02.05 20:08:40.378 5: encode value: aaaa, gadName: Statustext1
2021.02.05 20:08:40.378 5: encode model: dpt16.000, code: dpt16, value: aaaa
2021.02.05 20:08:40.378 5: encode model: dpt16.000, code: dpt16, value: aaaa, numval: aaaa, hexval: 0061616161                   
2021.02.05 20:08:40.379 5: sending Cw041790061616161                   
2021.02.05 20:08:40.380 5: set Visu.KiZ3.Info: cmd: aaaa, value: aaaa, translated: 0061616161                   
2021.02.05 20:08:40.380 5: decode value: 0061616161                    , gadName: Statustext1
2021.02.05 20:08:40.380 5: decode model: dpt16.000, code: dpt16, value: 0061616161                   
2021.02.05 20:08:40.380 5: decode model: dpt16.000, code: dpt16, value: 0061616161, numval: 0, state: aaaa
2021.02.05 20:08:40.384 5: exit set


Nicht-funktionierende 10_KNX:

Code Auswählen Erweitern


2021.02.05 20:11:34.196 5: KNX_Set -enter: Visu.KiZ3.Info, Statustext1, aaaa
2021.02.05 20:11:34.196 5: KNX_Set: set Visu.KiZ3.Info: desired target is gad: Statustext1, command: aaaa, args:
2021.02.05 20:11:34.196 5: KNX_checkAndClean -enter: value= aaaa, gadName= Statustext1
2021.02.05 20:11:34.196 5: KNX_checkAndClean -exit: value= aaaa, gadName= Statustext1, model= dpt16.000, pattern= (?^ix:.{1,14})
2021.02.05 20:11:34.197 5: KNX_encodeByDpt: Statustext1 model: dpt16.000, code: dpt16, value: aaaa
2021.02.05 20:11:34.197 5: KNX_encodeByDpt -exit: model: dpt16.000, code: dpt16, value: aaaa, numval: aaaa, hexval: 0061616161
2021.02.05 20:11:34.197 5: sending Cw041790061616161
2021.02.05 20:11:34.198 5: KNX_Set: Visu.KiZ3.Info, cmd= aaaa, value= aaaa, translated= aaaa
2021.02.05 20:11:34.203 5: KNX_Set: -exit


Hat jemand ein ähnliches Verhalten?

Gruß Thorsten

[erwin]

Hi Thorsten,

kann ich mir auf die schnelle nicht erklären, weil:
die Zeilen:

Code Auswählen Erweitern


sending Cw041790061616161 (Log ok)
...und
sending Cw041790061616161 (Log Fehler)

aus deinen Logs schauen absolut ident aus. Diese Message kommt aber schon aus dem TUL Modul (TUL_write), nachden das KNX-Modul die daten zum senden übergeben hat!
Abgesehen von den Log Meldungen, die im neuen modul etwas anders aussehen, schaut auch der Rest der beiden Logs gleich aus.
Ich gehe jetzt nicht davon aus, dass du am TUL Modul etwas geändert hast.
l.g. erwin
PS: Ich werde morgen versuchen, das nachzustellen.... Danke, daß du gleich alle relevanten infos zusammengestellt hast!

[lichtimc]

Ich hab dasselbe Problem.
Mir ist aufgefallen: Im Busmonitor schaut ein dpt16-Telegram so aus:
ASCII:test23
Von ETS gesendet:   74 65 73 74 32 33 00 00 00 00 00 00 00 00
Von FHEM gesendet: 74 65 73 74 32 33
Es werden also statt 16 nur 6 Bytes übetragen und das kommt bei den Tastern wohl nicht so gut an...
ASCII: test2345678987 funktioniert hingegen auch, wenn ich es von FHEM aus verschicke.
lg David

[erwin]

Hi all,

ja das ist eine Erklärung, ist mir auch aufgefallen, wird in der nächsten version  gefixt,
allerdings erklärt es nicht, warum es mit der alten version geht

Um das nochmal zu verifizieren (ich selbst hab kein reales dpt16-device):
Darf ich Thorsten bitten, einen 14 Char langen string von fhem an das device zu schicken - und feeback zu geben?
lg erwin

[thorte]

Hallo Erwin

kann das von David beschriebene Verhalten nachvollziehen. Ein String mit 14 Zeichen wird angezeigt, ein kürzerer String nicht.

Gruß Thorsten

[erwin]

Ok, danke dann haben wir eine Lösung!
ich sollte mich nicht so unbedingt an die standard-dokumente halten: 

To transfer strings of characters, datapoint types 16.000 and 16.001 allow sending text of up to 14 characters.

das ist zwar richtig, mehr als 14 char gehen nicht, aber weniger als 14 ? Hab ich wohl falsch interpretiert....
Die neue Version kommt Anfang nächter Woche.
l.g. erwin

[lichtimc]

Ich werde diese Log-Meldung in der nächsten version auf LogLevel 4 ändern. Damit kommt das im "normalen" Betrieb nicht mehr.

Wäre es eventuell sinnvoller, dass die Meldung nur bei beispielsweise "set device on" nicht mehr kommt, wenn man jedoch explizit "set device on g2" verwendet, man über "... alte Syntax ..." informiert wird?
Wenn bei "set device on" wirklich "set device on g1" ankommt, sollte das doch auch auf die neue Syntax "set device g1 on" geändert werden oder?

Noch ein Bug: Wenn etwas so definiert ist: 1/1/10:dpt1:switch
und ich mache ein "set device switch toggle" dann wird immer nur ausgeschalten und nicht wieder ein.

[erwin]

David,

"set device switch toggle" dann wird immer nur ausgeschalten und nicht wieder ein

.. das kommt daher, weil bisher der ist-status vom "get" - reading abgefragt wurde, und nicht vom "set"... (also g1-get,...). Ist mir nicht aufgefallen, weil ich fast alle ga's mit nosuffix codiert habe.
Ich hab kurz überlegt, ob ich auf das state reading gehen soll, aber das könnte ja auch falsch sein (stateregex, statecmd,...). Ich hab's jetzt auf das "set"-reading geändert, auch auf die Gefahr hin, dass das nicht der aktuelle status ist... sondern der zuletzt aus fhem ausgeführte cmd. (der status könnte sich ja durch ein event kommend vom knx-bus ändern...)
TOGGLE: das ist auch so ein cmd-Konstrukt aus der "alten Zeit". Für FHEMWEB braucht mans nicht, das geht mit devstateIcon bzw. cmdIcon eleganter, aber evtl für's scripten!
wg. Log-Meldung: klingt sinnvoll,  kommt jetzt immer (im Loglevel 3) wenn das letztes wort g[0-9] ist.
Danke für den Input!
l.g. erwin

[Amenophis86]

Toggle auf das Set reading zu setzen sehe ich als nicht zielführend an
Ich arbeite noch mit get und Set und würde mich ärgern, wenn es sich an set orientiert. Warum? Weil get logischer ist, dafür gibt es das Rückmeldungs KO bzw die GA. Werden bei euch alle Geräte nur über eine GA geschaltet und sonst nicht? Kann ich mir nicht vorstellen. Als Alternative könnte man mittels eins Attr den User entscheiden lassen und als Standard get lassen. Ich denke es dürfte sonst gerade bei alten Definitionen zu Problemen, kommen, wenn User sich auf einmal fragen, warum ihr Toggle nicht mehr richtig funktioniert.

[lichtimc]

Toggle auf das Set reading zu setzen sehe ich als nicht zielführend an

Geräte, die kein Rückmeldungs KO haben, würden Toggle dann gar nicht unterstützen. Edit: das hat doch gar nichts mit Rückmeldeadressen zu tun sondern nur mit der Schalt-Adresse und dazugehörigem getG1/setG1, oder?
Wenn Toggle nur auf set basiert, würde das Toggle falsch schalten, wenn das Gerät außerhalb von FHEM geschalten wird.

Am besten wäre wsl. wenn Toggle entweder get oder set nehmen würde, je nachdem welches neuer ist, oder?

[Amenophis86]

Es muss in FHEM unterschieden werden zwischen Device, welche nur eine GA haben und über diese sowohl den Status als auch die Schaltung abbilden und Device, welche mehrere GA verbinden. Allerdings ist die Frage, ob bei Variante 1 dies dann dem KNX Status entspricht. Nehmen wir die Geräte von MDT zum Beispiel, die haben oft ein eigenes KO für die Rückmeldung, welches oft auf einer eigenen GA landet. In FHEM müsste es dann entweder ein Device für Status und eins für schalten geben, oder beide GA in einem Device zusammengefasst. Andere Geräte, wie zum Beispiel die Speerfunktion eines BJ 6131/31 haben nur ein KO zum setzen und freigeben und keine Rückmeldung. Hier wäre es dann nur ein Device in FHEM.

Jetzt die Frage, was wäre die beste Lösung. Ich denke das Problem ist, dass unabhängig von Rückmeldung oder Schalten es immer sein kann, dass über eine weitere GA der Status geändert wird. Dies bekommt ein reines GA-Device in FHEM dann nicht mit, somit würde bei einem toggle nichts passieren. Daher wäre meine Empfehlung weiterhin, dass man mittels eines attr selbst einstellen kann, auf welches Reading toggle achten soll (am beste sogar mit der set magic, damit es auch aus einem anderen Device den Status holen kann) und als default weiterhin get zu lassen.

[lichtimc]

Und wenn das toggle einfach beim generellen state nachschaut? Das würde doch bei Geräten mit nur einer, als auch bei Geräten mit Schalt- und Rückmeldeadresse funktionieren, oder?
Natürlich darf man dann das Reading mittels stateCmd nicht dahingehend verändern, dass toggle nicht mehr weiß in welchem Status sich das Gerät befindet. (darf nur on/off sein)
stateRegex aber wirkt sich ja nur auf die Anzeige aus, nicht aufs Reading, oder?

[Amenophis86]

und was widerspricht in deinem Vorschlag zu state meinem attr Vorschlag, der bisher als einziger alle Möglichkeiten abdeckt? Bei deiner Variante nennst du ja selbst wieder ein Problem, wo es nicht passt.