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

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 568
Antw:10_KNX.pm Weiterentwicklung
« Antwort #90 am: 12 April 2021, 09:16:30 »
Hi xps!

Ich hab dein device bei mir nachgebaut und gegen den ETS-Monitor getestet, ich kann in deinem list keinen Fehler erkennen! Gibts im Log Fehlermeldungen?
Das mit dem disable versteh ich nicht, das ist ein Attribut, dass es in (fast) allen devices gibt, falls das bei dir nicht verfügbar ist, dann hast du ein grundsätzliches Problem!

Einige Anmerkungen hab ich schon, deine Definition erscheint mir zu kompliziert:
Wenn du die Einheiten in den readings nicht haben willst (diese Annahme entnehme ich deinen Userreadings) dann definiere doch: 9/0/41:dpt9:TemperaturOutside:listenonly:nosuffix statt 9/0/41:dpt9.001:TemperaturOutside
und 9/0/46:dpt1.000:Heizen statt 9/0/46:dpt1.011:Heizen und 9/0/47:dpt1.000:Warmwasser statt 9/0/47:dpt1.011:Warmwasser, usw.

Auf diese Weise kannst du ALLE userreadings eliminieren! Und auch das stateFormat vereinfachen (und falls gewünscht die Einheiten dort hinzufügen).
schau dir bitte auch noch die cmd-ref zu den optionen set/get/listenonly/nosuffix an, evtl. ist da auch was brauchbares für dich dabei.
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 xps

  • New Member
  • *
  • Beiträge: 8
Antw:10_KNX.pm Weiterentwicklung
« Antwort #91 am: 12 April 2021, 09:27:09 »
Hallo Erwin,

danke für deine Antwort.
Ich habe extra eine "frische" Instanz auf einem zweiten Server aufgebaut um zu sehen ob es etwas mit meiner Instanz zu tun hat.
Auch auf dieser habe ich das Problem sobald ich das erste mal für Warmwasser ein "get" anfrage.

Das Device lässt sich dann auch nicht mehr enablen.

Generell sehe ich das disable attribut schon und verwende es auch vereinzelt - jedoch ist es bei dem automatisch deaktivierten Device nicht sichtbar.  :-\

Mein Log zeigt folgendes im Verbose 5:
2021.04.12 09:24:15 5 : sending Cr0902f
2021.04.12 09:24:15 5 : SimpleRead msg.type: reply, msg.src: 0100b, msg.dst: 0902f
2021.04.12 09:24:15 5 : SimpleRead data: 00
2021.04.12 09:24:15 4 : KNXD01: C0100bp0902f00
2021.04.12 09:24:15 5 : KNXD01: dispatch C0100bp0902f00
2021.04.12 09:24:15 5 : KNX_Parse -enter: IO-name: KNXD01, dest: 0902f, msg: C0100bp0902f00
2021.04.12 09:24:15 5 : KNX_parse -exit
2021-04-12 09:24:15 KNX KNX_Heizung5 Warmwasser-get: inactive
2021-04-12 09:24:15 KNX KNX_Heizung5 last-sender: 1.0.11
2021-04-12 09:24:15 KNX KNX_Heizung5 inactive

Internals:
   CFGFN     
   DEF        9/0/47:dpt1.011:Warmwasser
   DEVNAME    KNX_Heizung5
   FIRSTGADNAME Warmwasser
   FUUID      6073f59a-f33f-ac85-5b7c-97fcdab4a818b842
   FVERSIONE  04.43 25-02-2021
   GETSTRING  Warmwasser:noArg
   IODev      KNXD01
   KNXD01_MSGCNT 1
   KNXD01_RAWMSG C0100bp0902f00
   KNXD01_TIME 2021-04-12 09:24:15
   LASTInputDev KNXD01
   MSGCNT     1
   NAME       KNX_Heizung5
   NOTIFYDEV  global,TYPE=KNX
   NR         429
   NTFY_ORDER 50-KNX_Heizung5
   SETSTRING  Warmwasser:inactive,active
   STATE      inactive
   TYPE       KNX
   GADDETAILS:
     Warmwasser:
       CODE       0902f
       GROUP      9/0/47
       MODEL      dpt1.011
       NO         1
       OPTION     
       RDNAMEGET  Warmwasser-get
       RDNAMEPUT  Warmwasser-put
       RDNAMESET  Warmwasser-set
       SETLIST    :inactive,active
   GADTABLE:
     0902f      Warmwasser
   READINGS:
     2021-04-12 09:24:15   Warmwasser-get  inactive
     2021-04-12 09:24:15   last-sender     1.0.11
     2021-04-12 09:24:15   state           inactive
Attributes:
   IODev      KNXD01
   room       30_KNX

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 568
Antw:10_KNX.pm Weiterentwicklung
« Antwort #92 am: 12 April 2021, 10:39:15 »
Hi xps,

ok: du machst ein get auf Warmwasser - und zurück kommt "inactive" (von einem sender 1.0.11)
Das ist alles ok! das device wird nicht deaktiviert! das ist ein wert wie jeder andere - siehe cmd-ref- dpt1.011
versuch bitte mal das device auf dpt1.000 zu ändern, dann kommt sicher 0 zurück. (bzw 1 wenn WW an ist)
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 xps

  • New Member
  • *
  • Beiträge: 8
Antw:10_KNX.pm Weiterentwicklung
« Antwort #93 am: 12 April 2021, 11:09:48 »
Hi Erwin,

vermutlich hab ich mich falsch ausgedrückt.
Zuerst kommt das inactive - danach kommt dein "KNX_Get device: KNX_Heizung5 is disabled" in einem Popup.
Die Meldung bekomme ich erst wieder weg sobald ich das Device lösche und neu anlege - dann habe ich genau wieder das gleiche Problem.

Dein Tipp mit dpt1.000 hat geklappt, sobald ich das Device auf dpt1.000 abändere taucht das Problem übrigens nicht mehr auf.
Jedoch ist lt. ETS die Rückgabe dpt1.011 und hat auch im alten KNX Modul bisher funktioniert.

LG xps
« Letzte Änderung: 12 April 2021, 11:13:05 von xps »

Online Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #94 am: 12 April 2021, 11:23:45 »
xps, du verstehst das falsch. "inactive" ist der Wert, welcher von deinem Aktor gesendet wird. dpt1.011 sendet active oder inactive als WERT zurück. Das ist nur eine andere Bezeichnung für on off / 1 0 oder was auch immer. Die DPT1 heißt, dass es zwei Werte gibt. Im Standard 0 und 1. Mittels der Zahlen nach dem Punkt änderst du die Werte für 0 und 1 in Strings um. Bei dpt1.011 also in inactive und active. Damit funktioniert es genau so, wie es soll. Wenn die Pumpe an ist, müsste als ein active als Rückmeldung kommen. Haste das mal versucht?

Edit:
Oder nimm mal eine Lampe und ändere dort auf dpt1.011 und schau mal was passiert. Dann bekommst du genau das gleiche, wie bei der Pumpe raus. active für Lampe an und inactive für Lampe aus.
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 xps

  • New Member
  • *
  • Beiträge: 8
Antw:10_KNX.pm Weiterentwicklung
« Antwort #95 am: 12 April 2021, 11:28:13 »
Das Inactive der Rückgabewert ist, ist mir absolut klar.
Ich bekomme jedoch von FHEM die Rückmeldung dass das Device disabled ist nachdem ein response angekommen ist (sobald dpt1.011 hinterlegt ist).

Screenshot anbei.

LG xps

Online Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #96 am: 12 April 2021, 11:30:34 »
auch ein setreading KNX_Heizung disable 0 brachte keinen Erfolg.

mach mal attr <device> disable 0 und nicht mit setreading ändern. Disable ist ein attr und kein reading.
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 xps

  • New Member
  • *
  • Beiträge: 8
Antw:10_KNX.pm Weiterentwicklung
« Antwort #97 am: 12 April 2021, 11:33:20 »
Hab ich schon zuvor probiert - das attribut ist gar nicht gesetzt.

Internals:
   CFGFN     
   DEF        9/0/47:dpt1.011:Warmwasser
   DEVNAME    KNX_Heizung5
   FIRSTGADNAME Warmwasser
   FUUID      60740ec6-f33f-ac85-7fe6-c07ec3e7848327ca
   FVERSIONE  04.43 25-02-2021
   GETSTRING  Warmwasser:noArg
   IODev      KNXD01
   KNXD01_MSGCNT 5
   KNXD01_RAWMSG C0100bp0902f00
   KNXD01_TIME 2021-04-12 11:25:05
   LASTInputDev KNXD01
   MSGCNT     5
   NAME       KNX_Heizung5
   NOTIFYDEV  global,TYPE=KNX
   NR         448
   NTFY_ORDER 50-KNX_Heizung5
   SETSTRING  Warmwasser:inactive,active
   STATE      inactive
   TYPE       KNX
   GADDETAILS:
     Warmwasser:
       CODE       0902f
       GROUP      9/0/47
       MODEL      dpt1.011
       NO         1
       OPTION     
       RDNAMEGET  Warmwasser-get
       RDNAMEPUT  Warmwasser-put
       RDNAMESET  Warmwasser-set
       SETLIST    :inactive,active
   GADTABLE:
     0902f      Warmwasser
   READINGS:
     2021-04-12 11:25:05   Warmwasser-get  inactive
     2021-04-12 11:25:05   last-sender     1.0.11
     2021-04-12 11:25:05   state           inactive
Attributes:
   IODev      KNXD01
   room       30_KNX

Internals:
   CFGFN     
   DEF        9/0/47:dpt1.011:Warmwasser
   DEVNAME    KNX_Heizung5
   FIRSTGADNAME Warmwasser
   FUUID      60740ec6-f33f-ac85-7fe6-c07ec3e7848327ca
   FVERSIONE  04.43 25-02-2021
   GETSTRING  Warmwasser:noArg
   IODev      KNXD01
   KNXD01_MSGCNT 5
   KNXD01_RAWMSG C0100bp0902f00
   KNXD01_TIME 2021-04-12 11:25:05
   LASTInputDev KNXD01
   MSGCNT     5
   NAME       KNX_Heizung5
   NOTIFYDEV  global,TYPE=KNX
   NR         448
   NTFY_ORDER 50-KNX_Heizung5
   SETSTRING  Warmwasser:inactive,active
   STATE      inactive
   TYPE       KNX
   GADDETAILS:
     Warmwasser:
       CODE       0902f
       GROUP      9/0/47
       MODEL      dpt1.011
       NO         1
       OPTION     
       RDNAMEGET  Warmwasser-get
       RDNAMEPUT  Warmwasser-put
       RDNAMESET  Warmwasser-set
       SETLIST    :inactive,active
   GADTABLE:
     0902f      Warmwasser
   READINGS:
     2021-04-12 11:25:05   Warmwasser-get  inactive
     2021-04-12 11:25:05   last-sender     1.0.11
     2021-04-12 11:25:05   state           inactive
Attributes:
   IODev      KNXD01
   disable    0
   room       30_KNX

Die Meldung dass das Device disabled sei kommt nach wie vor.

LG xps

Edit: Dabei macht es auch keinen Unterschied ob die Produktions-Instanz oder eine ganz frische FHEM Instanz auf einem anderen Server.

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 568
Antw:10_KNX.pm Weiterentwicklung
« Antwort #98 am: 12 April 2021, 12:10:27 »
Hi
ok, jetzt hab ichs!

das Problem ist: ich hab in der get routine eine abfrage eingebaut: return "KNX_Get device: $name is disabled" if (IsDisabled($name));wobei IsDisabled eine standard funktion in fhem ist.
Die reagiert aber in deinem Fall auf state = inactive (was durch deine definition dpt1.011) gesetzt wird.
ich muss mir was überlegen für die nächste version.....

Abhilfe: definiert dpt1.000 für die beiden Werte.
Die subcodes xxx aus dpt1.xxx  sind völlig gleichgültig wie das in der ETS definiert ist, die definieren nur wie das reading in fhem ausschaut! (Skalierung und Units) t

Danke, wieder ein Problem 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 xps

  • New Member
  • *
  • Beiträge: 8
Antw:10_KNX.pm Weiterentwicklung
« Antwort #99 am: 12 April 2021, 12:34:19 »
Hi,
nichts zu danken, danke für deinen superschnellen Support!

Liebe Grüße
xps

« Letzte Änderung: 12 April 2021, 12:37:47 von xps »

Online erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 568
Antw:10_KNX.pm Weiterentwicklung
« Antwort #100 am: 19 April 2021, 11:02:01 »
Hi All,
Das nächste Update: 20210419 Version E04.52
Ich hab zwar beim letzten update versprochen, dass keine gröberen updates in nächster Zeit kommen werden,
aber der Lockdown...
- im Detail:
    - change: own package: FHEM::KNX
      replaced ok-dialog on get-cmd by "err-msg"
      replace eval by AnalyzePerlCommand
      docu correction
      fixed KNX_replaceByRegex
      fix IsDisabled when state = inactive
      modified dpt patterns algo
      fix DbLog_split
    - new: added FingerPrintFn

Es sollte keine Änderungen in Usage, Definitionen, Funktionalität, usw. auftreten, der Fokus dieser Version war auf Performance verbesserung,
einige kleinere fixes, und der Umstellung auf eigenes Package.

FingerPrintFn: ist eine Funktion, die in fhem.pl definiert ist. Verhindert mehrfache idente msgs (innerhalb 0.5 sec default).
Das Timeout ist konfigurierbar via global Attribut dupTimeout.

Es sind etliche Teile "toter code" auskommentiert drin, u.a. von einem Versuch einen FIFO zu realiseren um die Latenzzeiten beim read zu verbesseren.
Hat zwar funktioniert, aber nix gebracht, darum wurde die Idee verworfen. Würde auch sinnvoller in ein IO-Modul gehören.

Feedback willkommen! Bei Problemen bitte mit einem "list <device> und evtl. Log-Auszug, falls sinnvoll.
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,...

Online Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #101 am: 20 April 2021, 16:23:51 »
Nicht die neuste Version installiert aber mir ist gerade bei der Version 04.43 25-02-2021 etwas aufgefallen. Ich hatte autocreate gelöscht, weil ich etwas anderes probiert hatte. Dann habe ich es wieder neu definiert. Das hat dazu geführt, dass alle meine vorhandenen KNX Geräte nach und nach auf disable 1 gesetzt wurden von autocreate, obwohl diese schon definiert waren. Ist das ein Fehler in autocreate oder KNX.pm?
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: 568
Antw:10_KNX.pm Weiterentwicklung
« Antwort #102 am: 20 April 2021, 16:55:16 »
Hi,
Zitat
dass alle meine vorhandenen KNX Geräte nach und nach auf disable 1 gesetzt wurden von autocreate

das kann im laufenden betrieb nur passieren:
1) wenn eine message für das device/ga vom bus kommt 
UND
2) die intenen strukturen den betreffenden GA nicht finden können.... $modules{KNX}{defptr}{$gadCode}
dann schlägt autocreate zu!
dann müssten allerdings auch devices mit namen KNX_xxyyzz angelegt werden und diese auf disabled gesetzt werden...
vorhandene devices werden nie auf disable gesetzt (zumindest nicht in der KNX.pm).
Wenn man das disable attr löscht, mach ich ein defmod auf diesen devicenamen, um die setlist/getlist wiederherzustellen, das sollte eigenlich auch kein solches problem verursachen!

ist das im laufenden Betrieb passiert oder nach einem shutdown/restart ?
hast du das autocreate gelöscht u. neu definiert oder ignoretypes-Attr geändert ?
gibts auffälliges im Log?

ich werde versuchen, das nachzustellen...
« Letzte Änderung: 20 April 2021, 17:17:30 von 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,...

Online Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #103 am: 20 April 2021, 17:55:14 »
Lass mich mal überlegen :D. Autocreate war gelöscht und seit dem gab es auf jeden Fall restarts. Dann habe ich es neu definiert und einen restarts gemacht. Daraufhin sind natürlich die ersten Nachrichten gekommen und jedes Device, dass eine Nachricht bekommen hat wurde auf disable 1 gesetzt.

Das das nicht passieren darf dachte ich mir. Es wurden auch keine Geräte neu angelegt, sondern die vorhandenen haben das Attribute bekommen. Wo der Fehler jetzt liegt kann ich dir aktuell nicht sagen. War auch verwundert.
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 tom1607

  • New Member
  • *
  • Beiträge: 8
Antw:10_KNX.pm Weiterentwicklung
« Antwort #104 am: 23 April 2021, 22:50:18 »
Hi zusammen,

ich habe hier ein Problem und weiss nicht was es verursacht hat. Ich bekomme seit 2 Tagen lauter fehler.

vielleicht habt Ihr eine Idee

2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w08709440c6a00
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w08713441a5200
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0871b2c36
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0871c41ecf800
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0872e2f91
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0872f42b57800
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0873942f99800
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0873ac2ab6400
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01064w08709440ebc00
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01064w08713441c9200
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01064w08714c380c200
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01064w08727c2516400
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C0ff1fw0946400000000
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01003w09415302f363838202020200000000000
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C01064w08709440cc600
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C01064w08713441a6c00
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C0120aw091000000
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C01064w08714c37e0c00
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C01064w0872f42b31000
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01378w0970315ff
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01064w08726426f1400
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01064w0872f42b7fc00
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01064w0873942fcc000
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01064w0873ac2ad5000

hier noch ein auszug aus dem fhem log

2021.04.23 22:30:40 5: RawMessage read: 2900bcd0106447490300804446
2021.04.23 22:30:40 5: Message read - CtrlByte: 11010000 Source: 1064 Dest: 4749 Data: 00804446
2021.04.23 22:30:40 5: knx: dispatch C01064w087494446
2021.04.23 22:30:40 3: knx: Unknown code C01064w087494446, help me!
2021.04.23 22:30:40 5: KNXTUL - Read started
2021.04.23 22:30:40 5: RawMessage read: 2900bcc012024c1605008044315400
2021.04.23 22:30:40 5: Message read - CtrlByte: 11000000 Source: 1202 Dest: 4c16 Data: 008044315400
2021.04.23 22:30:40 5: knx: dispatch C01202w0941644315400
2021.04.23 22:30:40 3: knx: Unknown code C01202w0941644315400, help me!
2021.04.23 22:30:41 5: KNXTUL - Read started
2021.04.23 22:30:41 5: RawMessage read: 2900bcd01064471b0300802c36
2021.04.23 22:30:41 5: Message read - CtrlByte: 11010000 Source: 1064 Dest: 471b Data: 00802c36
2021.04.23 22:30:41 5: knx: dispatch C01064w0871b2c36
2021.04.23 22:30:41 3: knx: Unknown code C01064w0871b2c36, help me!
2021.04.23 22:30:41 5: KNXTUL - Read started
2021.04.23 22:30:41 5: RawMessage read: 2900bcd0106447390500804307f400
2021.04.23 22:30:41 5: Message read - CtrlByte: 11010000 Source: 1064 Dest: 4739 Data: 00804307f400
2021.04.23 22:30:41 5: knx: dispatch C01064w087394307f400
2021.04.23 22:30:41 3: knx: Unknown code C01064w087394307f400, help me!
2021.04.23 22:30:41 5: KNXTUL - Read started
2021.04.23 22:30:41 5: RawMessage read: 2900bcd01064473a050080c2b6a800
2021.04.23 22:30:41 5: Message read - CtrlByte: 11010000 Source: 1064 Dest: 473a Data: 0080c2b6a800
2021.04.23 22:30:41 5: knx: dispatch C01064w0873ac2b6a800
2021.04.23 22:30:41 3: knx: Unknown code C01064w0873ac2b6a800, help me!
2021.04.23 22:30:41 5: changing value, ATTR: verbose, VALUE: 1
2021.04.23 22:32:01 3: GAEBUS opening ebus1 device 192.168.3.226(8888)
2021.04.23 22:32:01 3: GAEBUS device opened (ebus1)

grüße
Tom
« Letzte Änderung: 23 April 2021, 22:52:01 von tom1607 »