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

Offline lichtimc

  • Full Member
  • ***
  • Beiträge: 109
    • davitech.casa
Antw:10_KNX.pm Weiterentwicklung
« Antwort #30 am: 04 Februar 2021, 09:36:08 »
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.

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #31 am: 04 Februar 2021, 10:56:22 »
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
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 thorte

  • New Member
  • *
  • Beiträge: 36
Antw:10_KNX.pm Weiterentwicklung
« Antwort #32 am: 05 Februar 2021, 20:26:22 »
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:
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:
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:
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

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #33 am: 05 Februar 2021, 22:21:51 »
Hi Thorsten,

kann ich mir auf die schnelle nicht erklären, weil:
die Zeilen:
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!
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 lichtimc

  • Full Member
  • ***
  • Beiträge: 109
    • davitech.casa
Antw:10_KNX.pm Weiterentwicklung
« Antwort #34 am: 06 Februar 2021, 01:09:43 »
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
« Letzte Änderung: 06 Februar 2021, 01:11:18 von lichtimc »

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #35 am: 06 Februar 2021, 10:29:39 »
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
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 thorte

  • New Member
  • *
  • Beiträge: 36
Antw:10_KNX.pm Weiterentwicklung
« Antwort #36 am: 06 Februar 2021, 11:18:44 »
Hallo Erwin

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

Gruß Thorsten

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #37 am: 06 Februar 2021, 11:32:57 »
Ok, danke dann haben wir eine Lösung!
ich sollte mich nicht so unbedingt an die standard-dokumente halten:  ;D
Zitat
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
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 lichtimc

  • Full Member
  • ***
  • Beiträge: 109
    • davitech.casa
Antw:10_KNX.pm Weiterentwicklung
« Antwort #38 am: 07 Februar 2021, 01:16:08 »
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.
« Letzte Änderung: 07 Februar 2021, 02:38:16 von lichtimc »

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #39 am: 07 Februar 2021, 06:38:58 »
David,
Zitat
"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
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: 2927
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #40 am: 07 Februar 2021, 12:35:14 »
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.
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 lichtimc

  • Full Member
  • ***
  • Beiträge: 109
    • davitech.casa
Antw:10_KNX.pm Weiterentwicklung
« Antwort #41 am: 07 Februar 2021, 12:38:57 »
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?
« Letzte Änderung: 07 Februar 2021, 12:45:42 von lichtimc »

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2927
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #42 am: 07 Februar 2021, 13:35:25 »
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.
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 lichtimc

  • Full Member
  • ***
  • Beiträge: 109
    • davitech.casa
Antw:10_KNX.pm Weiterentwicklung
« Antwort #43 am: 07 Februar 2021, 13:57:12 »
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?
« Letzte Änderung: 07 Februar 2021, 13:59:42 von lichtimc »

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2927
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #44 am: 07 Februar 2021, 14:40:28 »
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.
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...