[­gelöst] KNX answerReading / listenonly

[Schneewa]

Hi all

Ich habe leider ein Verständnisproblem 

kann mir einer von den Experten den Unterschied von den Attributen

answerReading vs listenonly erklären

besten dank

[Amenophis86]

answerReading antwortet bei einer Anfrage auf dem KNX Bus mit dem in FHEM hinterlegten Wert. Kann man zum Beispiel nutzen um Werte über einen Bus Restart hinaus zu speichern.

listenonly heißt, dass FHEM die GA nur mithört aber darauf nicht senden darf.

[Schneewa]

Hi Amenophis86,

Danke für die schnelle Antwort.

ich habe folgendes Problem.

Bei einem abgehenden Befehl vom FHEM kommt der Befehl sofort bei dem Ziel KNX Teilnehmer an - das sehe ich im ETS.
Bei abgehenden Variablen vom KNX Teilnehmer z.B.: bei einer Druck Abfrage, kommen die Werte aber erst 3-4 Minuten verzögert bei FHEM an - Ziel kann ich im ETS nicht eingeben

kann ich das irgendwie beschleunigen

Reading Fehm

lesen vom KNX BUS

Code: [Auswählen]


Internals:
   DEF        0/0/149:dpt9
   DEVNAME    Druck_Brunnen
   FIRSTGADNAME g1
   FUUID      604ceb5e-f33f-70d9-730f-c0a71b1c227ac7ad
   GETSTRING  g1:noArg
   IODev      tul
   LASTInputDev tul
   MSGCNT     11
   NAME       Druck_Brunnen
   NR         4423
   NTFY_ORDER 50-Druck_Brunnen
   SETSTRING  g1:slider,-670760,13415,670760
   STATE      3.36
   TYPE       KNX
   tul_MSGCNT 11
   tul_RAWMSG C01107p00095182a
   tul_TIME   2021-08-02 06:56:00
   GADDETAILS:
     g1:
       CODE       00095
       GROUP      0/0/149
       MODEL      dpt9
       NO         1
       OPTION     
       RDNAMEGET  getG1
       RDNAMEPUT  putG1
       RDNAMESET  setG1
       SETLIST    :slider,-670760,13415,670760
   GADTABLE:
     00095      g1
   READINGS:
     2021-08-02 06:48:13   IODev           tul
     2021-08-02 06:56:00   getG1           3.36
     2021-08-02 06:56:00   last-sender     1/1/7
     2021-08-02 06:56:00   state           3.36
Attributes:
   IODev      tul
   alias      Druck_Brunnen
   listenonly 1
   room       Wassermessung

schreiben auf dem KNX Bus

Code: [Auswählen]

Internals:
   DEF        0/0/84:dpt1.001
   DEVNAME    Buero_Fussboden_Temp_ein
   FIRSTGADNAME g1
   FUUID      5c7c2cfb-f33f-70d9-cbbf-106d71f9d183943f
   GETSTRING  g1:noArg
   IODev      tul
   NAME       Buero_Fussboden_Temp_ein
   NR         728
   NTFY_ORDER 50-Buero_Fussboden_Temp_ein
   SETSTRING  g1:off,on
   STATE      on
   TYPE       KNX
   GADDETAILS:
     g1:
       CODE       00054
       GROUP      0/0/84
       MODEL      dpt1.001
       NO         1
       OPTION     
       RDNAMEGET  getG1
       RDNAMEPUT  putG1
       RDNAMESET  setG1
       SETLIST    :off,on
   GADTABLE:
     00054      g1
   READINGS:
     2021-08-02 06:48:13   IODev           tul
     2021-08-02 06:54:09   last-sender     fhem
     2021-08-02 06:54:09   setG1           on
     2021-08-02 06:54:09   state           on
Attributes:
   IODev      tul
   alias      Buero_Fussboden_Temp_ein
   room       Buero


[Amenophis86]

Mir wäre nichts bekannt was das verlangsamen könnte. Es gibt ja keine direkte Zielangabe bei KNX. Es wird einfach ein Telegramm auf den Bus gegebene und geht an jeden Teilnehmer auf dem Bus (Ausnahme ein LK ist dazwischen und block es für die weitere angeschlossene Linie). Jeder Empfänger entscheidet dann, ob er auf das Telegramm reagieren muss oder nicht. Dazu findet ein Abgleich statt, ob die entsprechende GA mit einem KO verknüpft ist. Ist das nicht der Fall, dann wird das Telegramm ignoriert. Du kannst quasi gar nicht einem Sender sagen schickt das Telegramm direkt nur an den Aktor, es bekommen immer alle.

Warum nun auf dem Rückweg eine Verzögerung ist, lässt sich schwer sagen. Wie greift FHEM auf KNX zu? Hängt vielleicht dein FHEM oder die Hardware auf der FHEM läuft und deswegen kommt es erst so spät an?

Edit:
Fehler korrigiert

[Schneewa]

Mir wäre nichts aufgefallen - ich habe mal den tul und die apptime eingefügt

Zugriff Fhem mittels tul

Code: [Auswählen]

Internals:
   AckLineDef
   Clients    :KNX:EIB:
   DEF        knxd:localhost 1.1.255
   DevType    EIBD
   DeviceAddress 011ff
   DeviceName knxd:localhost
   FD         17
   FUUID      5c7c2cf8-f33f-70d9-1623-16167f95da2dcb1f
   NAME       tul
   NR         63
   PARTIAL   
   RAWMSG     C0110cw0014cc0ad26e8
   REFUSED   
   STATE      Initialized
   TYPE       TUL
   tul_MSGCNT 12982
   tul_TIME   2021-08-02 09:36:50
   MatchList:
     2:KNX      ^C.*
     3:EIB      ^B.*
   helper:
     bm:
       TUL_Read:
         cnt        382
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        02.08. 09:32:13
         max        0.345738887786865
         tot        66.5936894416809
         mAr:
           HASH(0x55f9406b9f00)
Attributes:
   alias      tul
   room       System

apptime

Code: [Auswählen]

tul                                      TUL_Read                               345      543   94793.55   174.57     0.00     0.00 02.08. 09:32:13 HASH(tul)


[Amenophis86]

Mir fällt leider auch nix auf. Ist das bei allen Telegrammen so, die von KNX auf FHEM weitergeleitet werden oder nur bei bestimmten?

[Schneewa]

aufgefallen ist es mir beim ABB AE/S4.1.1.3 Analogeingang 4-fach REG

bei den anderen TN eher nicht - zumindest nicht offensichtlich 

[Schneewa]

das ist leider bei jedem Teilnehmer 

[Amenophis86]

Dann stimmt wohl allgemein etwas nicht. Wie greifst du mit FHEM auf den KNX BUS zu? Hast du deinen FHEM Server mal neugestartet? Ist es dann auch noch so oder kommt es erst nach eine gewissen Zeit?

[Schneewa]

Fhem schon mehrmals durchgestartet - Beim Neustart ist die Verzögerung so bei einer Minute - es scheint, dass es bei längerer Laufzeit schlechter wird

[Amenophis86]

Wie greifst du denn von FHEM auf den BUS zu? Mittels KNXD? Hast du das mal im Debug laufen lassen, kommen da die Meldungen direkt an?

[Schneewa]

lt. tul mittels knxd

Code: [Auswählen]

Internals:
   AckLineDef
   Clients    :KNX:EIB:
   DEF        knxd:localhost 1.1.255
   DevType    EIBD
   DeviceAddress 011ff
   DeviceName knxd:localhost
   FD         16
   FUUID      5c7c2cf8-f33f-70d9-1623-16167f95da2dcb1f
   NAME       tul
   NR         63
   PARTIAL   
   RAWMSG     C0110cw0013700000000
   REFUSED   
   STATE      Initialized
   TYPE       TUL
   tul_MSGCNT 5914
   tul_TIME   2021-08-03 09:50:47
   MatchList:
     2:KNX      ^C.*
     3:EIB      ^B.*
Attributes:
   alias      tul
   room       System

was genau meinst du mit debug? - die verbose einstellungen?

[Amenophis86]

Debug von KNXD, nix von FHEM: https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen

[Schneewa]

das kann ich mir erst am Abend genauer ansehen - ich melde mich wenn ich Infos habe - besten dank schon mal 

[Schneewa]

Hi anbei der Debug

journalctl -u knxd.service -f

-f sollte in Echtzeit schreiben - habe es 1 Stunde mitlaufen lassen - ich werde aber leider nicht schlau daraus

Code: [Auswählen]

root@debian:~# journalctl -u knxd.service -f
-- Logs begin at Tue 2021-08-03 11:13:50 CEST. --
Aug 03 11:13:52 debian systemd[1]: Starting KNX Daemon...
Aug 03 11:13:52 debian systemd[1]: Started KNX Daemon.
Aug 03 11:13:54 debian knxd[417]: F00000105: [18:B.tpuarts] Link down, terminating
Aug 03 11:13:54 debian systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Aug 03 11:13:54 debian systemd[1]: knxd.service: Failed with result 'exit-code'.
Aug 03 11:14:05 debian systemd[1]: knxd.service: Service RestartSec=10s expired, scheduling restart.
Aug 03 11:14:05 debian systemd[1]: knxd.service: Scheduled restart job, restart counter is at 1.
Aug 03 11:14:05 debian systemd[1]: Stopped KNX Daemon.
Aug 03 11:14:05 debian systemd[1]: Starting KNX Daemon...
Aug 03 11:14:05 debian systemd[1]: Started KNX Daemon.
^C
root@debian:~#

Vielleicht hilft das weiter...

knxd.conf

Code: [Auswählen]

KNXD_OPTS="-e 1.0.1 -E 1.0.200:10 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx"

START_KNXD=YES



Code: [Auswählen]

root@debian:~# /etc/init.d/knxd status
● knxd.service - KNX Daemon
   Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: ena                                         bled)
   Active: active (running) since Tue 2021-08-03 11:14:05 CEST; 5h 45min ago
 Main PID: 655 (knxd)
    Tasks: 1 (limit: 3480)
   Memory: 632.0K
   CGroup: /system.slice/knxd.service
           └─655 /usr/bin/knxd -e 1.0.1 -E 1.0.200:10 -u /tmp/eib -D -T -R -S -…

Aug 03 11:14:05 debian systemd[1]: Starting KNX Daemon...
Aug 03 11:14:05 debian systemd[1]: Started KNX Daemon.
root@debian:~#