[­gelöst] KNX answerReading / listenonly

Begonnen von Schneewa, 01 August 2021, 20:16:29

Vorheriges Thema - Nächstes Thema

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.
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...

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


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

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

#3
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
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...

Schneewa

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

Zugriff Fhem mittels tul

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

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?
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...

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?
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...

Schneewa

#9
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?
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...

Schneewa

lt. tul mittels knxd


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

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...

Schneewa

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

Schneewa

#14
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 :-[


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

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





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:~#