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


[Amenophis86]

Das war aber nicht die Ausgabe, welche ich meint du müsstest knxd so starten können, dass du siehst welche Telegramme rein kommen. Dann kann man das zB mit der Aufzeichnung des Bus- oder Gruppenmonitor vergleichen und schauen, ob hier schon Unterschiede zu erkennen sind.

[Amenophis86]

Du hast aber recht, laut Doku sollte mit - f was kommen. Komisch. Versuch mal die Logs zu aktivieren und schau mal, ob da was rein kommt.

[Schneewa]

logs aktiviert - leider dasselbe Bild

gestern um 11:13 Fehm gestartet, dann leider nichts mehr

stimmt vielleicht mein

Code: [Auswählen]

KNXD_OPTS nicht oder kann man da was ändern

[Amenophis86]

Nur um sicher zu gehen. Du hast ein IP Interface und greifst mittels KNXD über das Interface auf den BUS zu. Du kannst aus FHEM heraus Befehle an KNX senden und zum Beispiel Lampen ein und Ausschalten und das geht auch nur, wenn KNXD läuft und es geht nicht, wenn KNXD gestoppt oder ganz ausgeschaltet ist, korrekt?

Hast du noch andere Geräte, die über das Interface zu greifen, dass vielleicht alle Tunnel belegt sind?

[Schneewa]

folgendes Teil habe ich verbaut und angeschlossen

TUL - TPUART USB light - https://busware.de/tiki-index.php?page=TUL von dem Wiki - https://wiki.fhem.de/wiki/EIB_/_KNX

gerade getestet

• schalten aus Fhem funktioniert knxd - running
• schalten aus Fhem funktioniert nicht knxd-gestoppt - im ETS kommt sogar die Fehlermeldung Verbindungsunterbrechung

Ich habe 15 Geräte am KNX Bus beginnend mit der Linie 1.1.1

Was ich vielleicht auch noch dazu sagen muss - jedes einzelene Gerät hat ein eigenes Projekt um mir die Lizenz zu ersparen - hat zwar einen höheren Aufwand zwecks Gruppenadressen, funktioniert aber tadellos - ausser das lesen... 

[Amenophis86]

Alle Geräte sind auf der gleichen Linie, kein Linienkoppler dazwischen?

Du hast gesagt, dass die Rückmeldungen verspätet ankommen, aber sie kommen an, richtig? Was wir rausfinden müssen ist, ob sie bei KNXD schon verspätet ankommen. Das heißt entweder musst du die Logs aktiv bekommen, das man da was sieht und natürlich auch bissi was schalten. Oder du musst -f aktiv bekommen, dass man dort was sieht. Es muss natürlich auch immer was gesendet werden in der Zeit, wenn nix gesendet wird, dann kann man auch nix sehen

Was ich vielleicht auch noch dazu sagen muss - jedes einzelene Gerät hat ein eigenes Projekt um mir die Lizenz zu ersparen - hat zwar einen höheren Aufwand zwecks Gruppenadressen, funktioniert aber tadellos - ausser das lesen... 

Gespart am falschen Ende. Die Demo ist kostenlos und kann 5 Geräte. Die Lite bekommste nach einem kostenlosen KNX Kurs auf der Seite sehr günstig und kann 20 Geräte. Die Home kann 64 Geräte und der Preis ist überschaubar. Dazu kommt, dass es immer wieder Aktionen gibt. Aber gut, hat mit dem Thema vermutlich wenig zu tun.

[Schneewa]

einmal vielen Dank für deine Geduld und Hilfe für mein Problem

Alle Geräte sind auf der gleichen Linie, kein Linienkoppler dazwischen?

habe keinen Linienkoppler dazwischen

Du hast gesagt, dass die Rückmeldungen verspätet ankommen, aber sie kommen an, richtig?

ja

Was wir rausfinden müssen ist, ob sie bei KNXD schon verspätet ankommen. Das heißt entweder musst du die Logs aktiv bekommen, das man da was sieht und natürlich auch bissi was schalten. Oder du musst -f aktiv bekommen, dass man dort was sieht. Es muss natürlich auch immer was gesendet werden in der Zeit, wenn nix gesendet wird, dann kann man auch nix sehen

werde versuchen, dass hinzubekommen   

[Amenophis86]

Bisher hab ich ja noch nicht geholfen außer blöde Fragen zu stellen

[Schneewa]

das ist definitiv ein Fhem Problem

knx protokolliert mit

Code: [Auswählen]

knxtool vbusmonitor1 ip:localhost

0/1/4 ist der Ausgang der gesetzt wurde
0/1/5 ist die Abfrage vom KNX, ob der Ausgang geschalten wurde

Abfrage ist unmittelbar eingetroffen

Code: [Auswählen]

LPDU: BC 11 CE 01 04 E1 00 80 F8 :L_Data low from 1.1.206 to 0/1/4 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
LPDU: BC 11 0B 01 05 E1 00 80 3C :L_Data low from 1.1.11 to 0/1/5 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
wie bekommen wir das hin....

[Amenophis86]

Dann machste jetzt gleichzeitig nochmal den Eventmonitor bei fhem an und schaust, ob da auch was passiert. Die GA muss natürlich vorher entsprechend definiert sein.

[Schneewa]

0/1/4 Ess_Fussboden_Temp1_ein ist der Ausgang der gesetzt wurde

Code: [Auswählen]

2021-08-06 10:05:25 KNX Ess_Fussboden_Temp1_ein setG1: on
2021-08-06 10:05:25 KNX Ess_Fussboden_Temp1_ein on
2021-08-06 10:05:25 KNX Ess_Fussboden_Temp1_ein last-sender: fhem

0/1/5 Ess_Fussboden_Temp1_ist_ein ist die Abfrage vom KNX, ob der Ausgang geschalten wurde

Code: [Auswählen]

2021-08-06 10:09:50 KNX Ess_Fussboden_Temp1_ist_ein getG1: on
2021-08-06 10:09:50 KNX Ess_Fussboden_Temp1_ist_ein last-sender: 1/1/11
2021-08-06 10:09:50 KNX Ess_Fussboden_Temp1_ist_ein on

ca 5 min. Verzögerung

[Amenophis86]

Hast du zeitgleich das Debug von KNXD und den Gruppenmonitor laufen lassen und gesehen, ob hier auch die Verzögerung war?

[Schneewa]

Ja, leider ist die Verzögerung Fhem geschuldet

habe gleichzeitig auch eine VM mit IObroker am laufen. Habe in der Zwischenzeit eine KNX Instanz erzeugt.
Greife vom IOBroker auf die Hardware von Fhem (TUL) zu - hier werden die Daten sofort aktualisiert.

komisch ist nur, wenn ich einen Ausgang setze kommt der sofort an und der Zustand wird mir auch in Fhem sofort angezeigt.

Ich denke, ich werde den KNX wohl oder übel auf den IOBroker umsiedeln müssen.

[Amenophis86]

Das wundert mich sehr. Du kannst mal erwin anschreiben, dass er es sich nochmal ansieht. Er ist da wesentlich tiefer drinnen als ich und hat vielleicht noch eine Idee.

[Schneewa]

welchen Erwin meinst du?

[Amenophis86]

Den Nutzer erwin hier im Forum

[erwin]

hi,

ich hab nicht wirklich eine idee, daher noch mehr Fragen:

1) mach bitte ein list <device> von dem Ess_Fussboden_Temp1_ist_ein

2)setze verbose auf 5 für die beiden devices und mach ein setG1 on. und poste den Log
l.g. erwin

[Schneewa]

Hi Erwin

Seitdem ich einige KNX Geräte jetzt ausgelagert habe (IOBroker) funktionieren die anderen wieder einwandfrei

Eine Frage - kann es sein, dass mein Fhem allgemein nicht mehr nachkommt - Ich nutze Fhem eigentlich nur als Schnittelle (keine Visu) - habe natürlich einige Geräte wie Enocean, Zwave, S7, KNX im Einsatz.

ausser apptime ist mir nichts bekannt, das ich die Geschwindigkeit mir ansehen kann

[erwin]

Hi,
deine delays (5 minuten?) könnten schon von irgendwelchen IO-operationen kommen, die in ein timeout laufen. .. muss aber nicht unbedingt ein KNX-Gerät sein, dass hier blockiert... könnte jedes beliebige IO-Modul sein.
Ich würde mal im Log nach timeouts oder disconnect's suchen. Oder auch ein io-device nach dem anderen auf verbose 5 setzen, z.b. TUL, Zwave, Enocean, usw...
Ohne visu "siehst" du das blockieren nicht sofort...
ausser apptime gibts noch top (auf der linux ebene), für cpu/speicherauslastung... wenn der fhem prozess auf 100% cpu geht, wird alles langsam....
PS: könnte auch ein sehr grosses filelog sein, oder ein notify das eine loop erzeugt, wird mühsam die suche nach dem verursacher....
PSS: onewire ist auch so ein Kandidat der gerne blockiert, falls du es im Einsatz hast...
l.g. erwin 

[Amenophis86]

Mach doch mal zum testen eine cfg in der du nur ein KNX Device hast und auch KNXD zum verbinden. Lass das laufen und schau, ob sich was verändert. Alternativ kannste auch ein zweites FHEM mit nem anderen Port aufsetzen. Dann schauste mal, ob hier irgendwelche Probleme sind. Wenn nein, dann gibt es zwei Möglichkeiten entweder nach und nach in deiner richtigen Installation deaktivieren, bis du den Schuldigen gefunden hast oder die sauber Installation nach und nach aufbauen und schauen ab wann der die Verzögerung kommt. Alles langwierig und nervig aber was besseres fällt mir auch gerade nicht ein.

[Schneewa]

Hi all

allgemeine Frage zum apptime

Code: [Auswählen]

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
 Sonos                                    SONOS_Read                            2857      716   64845.47    90.57     0.00     0.00 12.08. 12:43:44 HASH(Sonos)
 tmr-S7_GetUpdate                         HASH(0x5610c6050490)                  1390    15802 5531770.93   350.07  2954.64   407.27 12.08. 09:05:38 HASH(SPS_Allgemein_1)
 tmr-S7_GetUpdate                         HASH(0x5610c60575c8)                  1232    15802 4576976.36   289.65  3175.08   467.70 12.08. 11:55:51 HASH(SPS_Allgemein)
 tul                                      TUL_Read                              1116    33432 5624966.83   168.25     0.00     0.00 12.08. 15:40:04 HASH(tul)
 Strom_L3_notify                          notify_Exec                           1103     1720  280256.37   162.94     0.00     0.00 12.08. 15:40:04 HASH(Strom_L3_notify); HASH(Strom_L3)
 tmr-S7_GetUpdate                         HASH(0x5610c62168a0)                  1042    15802 4633448.21   293.22  3348.25   464.11 12.08. 12:16:00 HASH(SPS_Zwave)
 Strom_L3_SPS                             S7_AWrite_Set                         1000     6795  277306.27    40.81     0.00     0.00 12.08. 15:40:04 HASH(Strom_L3_SPS); Strom_L3_SPS; -11.177
 tmr-Calendar_PollChild                   HASH(0x5610c94e1f10)                   935        1     935.07   935.07   724.14   724.14 12.08. 14:36:03 HASH(Abfall)
 Muelltermine_notify                      notify_Exec                            898        5     898.87   179.77     0.00     0.00 12.08. 14:36:03 HASH(Muelltermine_notify); HASH(Abfall)

ich bin eigentlich immer davon ausgegangen, dass die avarage Time die wichtigere ist - oder doch die max Zeit  - die max. Zeit ist eigentlich nur ein Spitzenwert

[erwin]

hi,

ich sehe das auch so, die average ist meist aussagekräftiger - bzw. auch total, wenn mans mit der startzeit von apptime korrelliert!
Was mir noch aufgefallen ist: dein TUL_Read-average ist vgl. mit meinen messungen sehr lang! Bei mir sind das ca. 25ms, bei dir 168!
Das deutet auf ein Problem in der Verbindung zum KNXD /oder mit dem KNXD hin? Zusätzlich erscheint mit die Anzahl sehr hoch, wobei ich nicht weiß, wie lange apptime schon gelaufen ist.
Wieviel läüft denn am KNX-bus? Zum nachdenken: der bus läuft mit 9600Bps, das entspricht etwa 1000Bytes/sec.... Eine msg ist ca. 25 Bytes lang...
Weiters: das S7 device braucht sehr viel Zeit und count, das kenn ich nicht, aber kannst das mal rausnehmen und testen?
l.g. erwin
 
PS: was du noch tun kannst: definiere ein doIFtools device
dann: set statistics enable - eine zeitlang laufen lassen - get statistics report - das zeigt dir wer wieviele events erzeugt hat...

[Schneewa]

Hi

PS: was du noch tun kannst: definiere ein doIFtools device
dann: set statistics enable - eine zeitlang laufen lassen - get statistics report - das zeigt dir wer wieviele events erzeugt hat...

das Tool kenn ich gar nicht - man lernt nie aus ....  - werde ich probieren und posten

Die S7 kann ich leider nicht rausnehmen - auf die wird alles geschrieben

[Schneewa]

sehr interessantes Tool

Ich habe das  tool ca. 1 Stunde am laufen knx Zählung

Code: [Auswählen]

                                                                               Total: 12698     ∅:14019   
                                                                              Devices: 169       
                                                                        Events/device: 75       
so wie du richtig geschrieben hast kann der KNX 40 Meldungen in der Sekunde verarbeiten - das wären in der Stunde 144000 Meldungen - ich verarbeite ca. 14100 Meldungen - das sollte passen 

aber bei der Abfrage

Code: [Auswählen]

get checkDOIF kommt einiges

wie z.B.:

Code: [Auswählen]

replace {fhem "set...")} with set... (plain FHEM command) - das verwende ich oft - wo liegt da der Fehler  aus der commandref werde ich nicht schlau

[erwin]

- das verwende ich oft - wo liegt da der Fehler  aus der commandref werde ich nicht schlau

Das ist keine Meldung vom KNX-modul, sondern vom doiftool ! - daher findest du im help text vom KNX nix dazu.
ich verwend keine doif's, aber wenn ichs richtig interpretiere soll das heissen statt fhem("set otto 12345") -> "set otto 12345" verwenden...
l.g. erwin

[Schneewa]

Eine Frage noch zum Fhem Event Monitor

Wenn du den laufen lässt, sind zwischen den Abfragen noch Zeiten übrig - ich glaube immer noch, dass ich mein Fhem allgemein nicht nachkommt

ein Bsp. anbei

Code: [Auswählen]

2021-08-13 21:45:23 S7_AWrite Server_CPU_Power_SPS 3.55
2021-08-13 21:45:24 S7_AWrite Strom_L1_SPS 5.998
2021-08-13 21:45:24 KNX Strom_L1 getG1: 5.998
2021-08-13 21:45:24 KNX Strom_L1 last-sender: 1/1/12
2021-08-13 21:45:24 KNX Strom_L1 5.998
2021-08-13 21:45:25 S7_AWrite Strom_L2_SPS 1.845
2021-08-13 21:45:25 KNX Strom_L2 getG1: 1.845
2021-08-13 21:45:25 KNX Strom_L2 last-sender: 1/1/12
2021-08-13 21:45:25 KNX Strom_L2 1.845
2021-08-13 21:45:25 S7_AWrite Strom_L3_SPS 4.682
2021-08-13 21:45:26 KNX Strom_L3 getG1: 4.682
2021-08-13 21:45:26 KNX Strom_L3 last-sender: 1/1/12
2021-08-13 21:45:26 KNX Strom_L3 4.682
2021-08-13 21:45:26 S7_AWrite 1_1_1_Buderus_Status_Zeitstempel_SPS 214526
2021-08-13 21:45:26 S7_AWrite Buderus_Kesseltemp_Ist_SPS 71.00
2021-08-13 21:45:27 KNX Buderus_Kesseltemp_Ist getG1: 71.00
2021-08-13 21:45:27 KNX Buderus_Kesseltemp_Ist last-sender: 1/1/1
2021-08-13 21:45:27 KNX Buderus_Kesseltemp_Ist 71.00
2021-08-13 21:45:27 S7_AWrite Spannung_L1_N_SPS 227.100
2021-08-13 21:45:27 KNX Spannung_L1_N getG1: 227.100
2021-08-13 21:45:27 KNX Spannung_L1_N last-sender: 1/1/12
2021-08-13 21:45:27 KNX Spannung_L1_N 227.100
2021-08-13 21:45:28 S7_AWrite Buderus_Kesseltemp_Ist_SPS 71
2021-08-13 21:45:28 S7_AWrite Spannung_L2_N_SPS 230.300
2021-08-13 21:45:28 KNX Spannung_L2_N getG1: 230.300
2021-08-13 21:45:28 KNX Spannung_L2_N last-sender: 1/1/12
2021-08-13 21:45:28 KNX Spannung_L2_N 230.300
2021-08-13 21:45:28 S7_AWrite Spannung_L3_N_SPS 229.200
2021-08-13 21:45:29 KNX Spannung_L3_N getG1: 229.200
2021-08-13 21:45:29 KNX Spannung_L3_N last-sender: 1/1/12
2021-08-13 21:45:29 KNX Spannung_L3_N 229.200
2021-08-13 21:45:29 KNX Wirkenergie_A_minus getG1: 12399784
2021-08-13 21:45:29 KNX Wirkenergie_A_minus last-sender: 1/1/12
2021-08-13 21:45:29 KNX Wirkenergie_A_minus 12399784
2021-08-13 21:45:29 KNX Wirkenergie_A_minus Wirkenergie_A_minus_kWh: 12399.784
2021-08-13 21:45:30 KNX T1_Wirkenergie_A_minus getG1: 12399784
2021-08-13 21:45:30 KNX T1_Wirkenergie_A_minus last-sender: 1/1/12
2021-08-13 21:45:30 KNX T1_Wirkenergie_A_minus 12399784
2021-08-13 21:45:30 KNX T1_Wirkenergie_A_minus T1_Wirkenergie_A_minus_kWh: 12399.784
2021-08-13 21:45:31 KNX T2_Wirkenergie_A_minus getG1: 0
2021-08-13 21:45:31 KNX T2_Wirkenergie_A_minus last-sender: 1/1/12
2021-08-13 21:45:31 KNX T2_Wirkenergie_A_minus 0
2021-08-13 21:45:31 KNX T2_Wirkenergie_A_minus T2_Wirkenergie_A_minus_kWh: 0
2021-08-13 21:45:31 ZWave ZWave_SENSOR_MULTILEVEL_56.04 voltage: 20.80 V
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer eventremaining: 204
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer eventremaining_next: 869
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer eventcurrenttime: 1628883931
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer eventcurrenttime_next: 1628883931
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer eventcurrenttime_hr: 21:45:31
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer eventcurrenttime_next_hr: 21:45:31
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer eventremaining_hr: 00:03:24
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer eventremaining_next_hr: 00:14:29
2021-08-13 21:45:32 KNX T3_Wirkenergie_A_minus getG1: 0
2021-08-13 21:45:32 KNX T3_Wirkenergie_A_minus last-sender: 1/1/12
2021-08-13 21:45:32 KNX T3_Wirkenergie_A_minus 0
2021-08-13 21:45:32 KNX T3_Wirkenergie_A_minus T3_Wirkenergie_A_minus_kWh: 0
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer recordings_next_counter: 27548
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer recordings_next_counter_hr: 07:39:08
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer snrdb: 88
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer snr: 88
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer ber: 0
2021-08-13 21:45:32 ENIGMA2 VU_Duo_4k_Wohnzimmer acg: 80
2021-08-13 21:45:33 KNX T4_Wirkenergie_A_minus getG1: 0
2021-08-13 21:45:33 KNX T4_Wirkenergie_A_minus last-sender: 1/1/12
2021-08-13 21:45:33 KNX T4_Wirkenergie_A_minus 0
2021-08-13 21:45:33 KNX T4_Wirkenergie_A_minus T4_Wirkenergie_A_minus_kWh: 0
2021-08-13 21:45:33 KNX Druck_Wasser getG1: 3.44
2021-08-13 21:45:33 KNX Druck_Wasser last-sender: 1/1/15
2021-08-13 21:45:33 KNX Druck_Wasser 3.44
2021-08-13 21:45:34 S7_AWrite Wirkenergie_A_plus_SPS 17001.842
2021-08-13 21:45:34 KNX Wirkenergie_A_plus getG1: 17001842
2021-08-13 21:45:34 KNX Wirkenergie_A_plus last-sender: 1/1/12
2021-08-13 21:45:34 KNX Wirkenergie_A_plus 17001842
2021-08-13 21:45:34 KNX Wirkenergie_A_plus Wirkenergie_A_plus_kWh: 17001.842
2021-08-13 21:45:35 S7_AWrite Druck_Ortswasser_SPS 5.03999996185303
2021-08-13 21:45:35 S7_AWrite T1_Wirkenergie_A_plus_SPS 17001.842
2021-08-13 21:45:35 KNX T1_Wirkenergie_A_plus getG1: 17001842
2021-08-13 21:45:35 KNX T1_Wirkenergie_A_plus last-sender: 1/1/12
2021-08-13 21:45:35 KNX T1_Wirkenergie_A_plus 17001842
2021-08-13 21:45:35 KNX T1_Wirkenergie_A_plus T1_Wirkenergie_A_plus_kWh: 17001.842
2021-08-13 21:45:35 HTTPMOD PV_Anlage_CommonInverterData DAY_ENERGY: 95270
2021-08-13 21:45:35 HTTPMOD PV_Anlage_CommonInverterData IDC: 0
2021-08-13 21:45:35 HTTPMOD PV_Anlage_CommonInverterData TOTAL_ENERGY: 19830798
2021-08-13 21:45:35 HTTPMOD PV_Anlage_CommonInverterData UDC: 3.1000000000000001
2021-08-13 21:45:35 HTTPMOD PV_Anlage_CommonInverterData YEAR_ENERGY: 15134842


[erwin]

Hi,

sind zwischen den Abfragen noch Zeiten übrig

das versteh ich nicht!

ich glaube immer noch, dass ich mein Fhem allgemein nicht nachkommt

Das glaub ich auch! Du solltest mal versuchen, die Anzahl events zu begrenzen, z.b. jene die du nicht für logging od. weiterverarbeitung brauchst.
Stichwort: event-onchange-reading...usw.
konkretes beispiel: last-sender - ändert sich praktisch nie - kommt aber bei jeder Änderung eines Wertes- verwendest du das weiter?
weiters: reading getG1 vs. state: sind 2 events mit jeweils gleichem Wert - welchen verwendest du weiter?
Damit hast du schon eine reduktion um 2/3 der events!
l.g. erwin 

[Schneewa]

Hi Erwin

Erstmal vielen Dank für deine Geduld und deine Hilfe für mein Problem!!

Code: [Auswählen]

sind zwischen den Abfragen noch Zeiten übrig
damit habe ich gemeint, dass bei mir in wirklich jeder Sekunde mindestens ein Event gefeuert wird

konkretes beispiel: last-sender - ändert sich praktisch nie - kommt aber bei jeder Änderung eines Wertes- verwendest du das weiter?
weiters: reading getG1 vs. state: sind 2 events mit jeweils gleichem Wert - welchen verwendest du weiter?
Damit hast du schon eine reduktion um 2/3 der events!

Wie kann ich das reduzieren...

Bsp. aus dem Event Monitor

Code: [Auswählen]

2021-08-13 21:45:26 KNX Strom_L3 getG1: 4.682
2021-08-13 21:45:26 KNX Strom_L3 last-sender: 1/1/12
2021-08-13 21:45:26 KNX Strom_L3 4.682
list Reading - das Reading wurde automatisch angelegt - soll ich die nicht verwendeten Readings löschen - werden die nicht wieder automatisch angelegt?

Code: [Auswählen]


Internals:
   DEF        0/1/76:dpt14
   DEVNAME    Strom_L3
   FIRSTGADNAME g1
   FUUID      5dc67d7c-f33f-70d9-1939-438f39e9fac68bdc
   GETSTRING  g1:noArg
   IODev      tul
   LASTInputDev tul
   MSGCNT     728
   NAME       Strom_L3
   NR         3973
   NTFY_ORDER 50-Strom_L3
   SETSTRING  g1
   STATE      -13.408
   TYPE       KNX
   tul_MSGCNT 728
   tul_RAWMSG C0110cw0014cc156872a
   tul_TIME   2021-08-14 12:42:02
   GADDETAILS:
     g1:
       CODE       0014c
       GROUP      0/1/76
       MODEL      dpt14
       NO         1
       OPTION     
       RDNAMEGET  getG1
       RDNAMEPUT  putG1
       RDNAMESET  setG1
       SETLIST   
   GADTABLE:
     0014c      g1
   READINGS:
     2021-08-14 08:59:49   IODev           tul
     2021-08-14 12:42:02   getG1           -13.408
     2021-08-14 12:42:02   last-sender     1/1/12
     2021-08-14 12:42:02   state           -13.408
Attributes:
   IODev      tul
   alias      Strom_L3
   room       Leistungsmessung

weiterverabeitet wird nur das State - anbei das notify

Code: [Auswählen]

Internals:
   DEF        Strom_L3 {fhem "set Strom_L3_SPS ".ReadingsVal("Strom_L3","state",0.0);}
   FUUID      5dc67d7d-f33f-70d9-c413-a38f7c2768c4dc0d
   NAME       Strom_L3_notify
   NOTIFYDEV  Strom_L3
   NR         4084
   NTFY_ORDER 50-Strom_L3_notify
   REGEXP     Strom_L3
   STATE      2021-08-14 12:45:04
   TRIGGERTIME 1628937904.86506
   TYPE       notify
   READINGS:
     2021-08-14 08:59:45   state           active
Attributes:
   alias      Strom_L3_notify
   room       Leistungsmessung

lg

[erwin]

Hi,

1)

Code: [Auswählen]

attr KNX Strom_L3  event-on-change-reading state.. und das für ALLE ähnlichen Fälle. /Devices wo du nur den state weiterverarbeitest...
2)

Code: [Auswählen]

defmod Strom_L3_notify notify Strom_L3:state:.* set Strom_L3_SPS $EVTPART1
attr Strom_L3_notify addStateEvent 1..wobei ich mir jetzt nicht sicher bin, ob es $EVTPART1 oder $EVTPART0 richtig ist.- Kannst du im Eventmonitor od. Log checken.

Im prinzip machst du bisher aus einer Änderung im KNX-Device 3 Events  UND 3 mal das notify - und 3mal fhem("set....)

falls das funktioniert, kannst du 3  notifies in 1 zusammenfassen:

Code: [Auswählen]

define Strom_L_notify notify Strom_L[1-3]:state:.* set $NAME_SPS $EVTPART1
attr Strom_L_notify addStateEvent 1
l.g. erwin

[Schneewa]

Hi,

1)

ist Gold wert  und funktioniert bestens

2)

Mein notify habe ich aus einem Bsp. von Fhem Wiki

define Temperaturkorrektur_317_Knob_notify notify Temperaturkorrektur_317_Knob {\
fhem "set Temperaturkorrektur_317 ".ReadingsVal("Temperaturkorrektur_317_Knob","state","0");;\
}

Code: [Auswählen]

https://wiki.fhem.de/wiki/S7

Im prinzip machst du bisher aus einer Änderung im KNX-Device 3 Events  UND 3 mal das notify - und 3mal fhem("set....)

Wenn es jetzt nur mehr eine Änderung gibt, muss ich das notify jetzt trotzdem ändern
ich frag nur, weil wenn das so ist - sitze ich ein paar Stunden 

[Amenophis86]

Ich habe bei fast allen meinen Device

Code: [Auswählen]

attr xx event-on-change-reading .* gesetzt. Es gibt eigentlich nur wenige Geräte, bei welchen man auf ein Event lauschen muss, welches aber den Status nicht verändert. Damit kann mann sehr viel Last reduzieren.

[erwin]

hi,

das notify aus dem wiki ist ja nicht falsch, aber halt nur beschränkt elegant 
ich würde den Aufwand machen, mal mit einem notify nach dem letzen vorschlag ( 3 statt eins) beginnen und testen,
dann gibts bei künftigen Änderungen weniger Aufwand.

PS: schau dir den copy command an - damit kannst du devices und notifies kopieren - und anschließend nur die wenigen Änderungen machen...

Code: [Auswählen]

copy device1 device2

l.g. erwin

[Schneewa]

Hi euch Beiden

erste Erfolgsmeldungen 

nur das umstellen der KNX Readings

Code: [Auswählen]

event-on-change-reading state- sind mittlerweile auf 191 abgewachsen - werden jetzt alle sofort eingelesen - Vergleich mit IOBroker kein Zeitversatz

als nächstes werde ich meine Notify's angehen

das dauert jetzt ein bisschen länger - ich werde berichten

Vielen Vielen Dank 

[GammaTwin]

Grüße,

ich hätte da noch eine Verfeinerung. Da ein reines

Code: [Auswählen]

event-on-change-reading stateschon sehr rigoros alles abblockt, is mir das zu derb 

Hier eine Lösung, um nur das "last-sender" von unnötigen Updates auszuschließen.

Code: [Auswählen]

event-on-change-reading .*
event-on-update-reading (?!last-sender).*

[erwin]

Hi GammaTwin,

... stimmt natürlich, mir ist's darum gegangen von 14000 Events in der Stunde mal radikal runterzukommen....
Und wenns keiner braucht ... (e.g. Filelog/dblog,...)
Sobald die notifies nicht mehr mehrfach getriggert werden, kann man bei Bedarf noch tunen.
l.g.erwin

[Schneewa]

eine Frage zum 

Code: [Auswählen]

event-on-update-reading
Wenn ich jetzt von einem knx Reading (z.B.: in Betrieb) alle 20 min ein Event gefeuert bekomme würde ich

Code: [Auswählen]

event-on-change-reading .*
event-on-update-reading state

das funktioniert auch - jedoch, wenn jetzt eine 0 gefeuert wird, werde wieder alle 3 getG1, lastsender, state gefeuert

Code: [Auswählen]

event-on-update-reading state, (?!last-sender).*, (?!getG1).*
funktioniert leider nicht

[Amenophis86]

Verstehe deine Frage nicht. Was haste genau für Werte, was ist gesetzt und was genau soll passieren?

[Schneewa]

bei

Code: [Auswählen]

event-on-change-reading .*
event-on-update-reading state

wird immer das "state" gefeuert wenn das KNX Modul ein Update sendet, auch wenn keine Änderung stattfindet

jedoch, kommt es zu einer Änderung werden mit dieser Einstellung alle 3 Readings "getG1", "lastsender", "state" gefeuert

die Einstellung von GammaTwin hätte mir gut gefallen, in diesem Fall wären "getG1", "lastsender" vom update ausgenommen

[Amenophis86]

Hast du mal die CommandRef zum Unterschied zwischen update und change gelesen? Da ist es sehr gut erklärt was du willst.

[Schneewa]

Hi Amenophis86

stimmt - ich sehe den Wald vor lauter Bäumen nicht mehr 

Fortschrittsbericht:
mit jeder Änderung nimmt mein Fhem richtig fahrt auch 

Ich denke wir können die Frage als gelöst erklären

Vielen Vielen Dank an alle

[erwin]

Hi,
...eine Überlegung aus der Design-Sicht:
du schickst jede/viele Änderungen von KNX devices an dein SPS. - mittels notify und zwar den Wert aus state.
Soweit ich eine SPS verstehe, ist das eine state-machine. Soll heissen: Jeder wert der dort mal gespeichert ist, bleibt auch dort!
Daher ist es nicht nötig, wiederholende gleiche werte an die SPS zu schicken.
Konsequenz: event-on-change-reading.
Ändern würde ich in dem Bereich erst wenn du die notifies eingeschränkt hast auf state!
getG1 und state haben immer den gleichen Wert, zumindest bei den definitionen, die ich von dir bisher gesehen habe.
in FHEM-WEB hast du auch ohne events die aktuellen werte in den readings (nach page refresh) !
l.g. erwin

[Schneewa]

Hi Erwin

Vielen Dank - Die Readings von der SPS hatte ich schon mit einem event-on-change-reading versehen

Code: [Auswählen]

Internals:
   ADDRESS    354
   AREA       db
   DATATYPE   float
   DB         501
   DEF        db 501 354 float
   FUUID      5dc67d80-f33f-70d9-4e5a-7c7c2df1e795bcd6
   IODev      SPS_KNX
   LASTInputDev SPS_KNX
   LENGTH     4
   MSGCNT     16950
   NAME       Strom_L3_SPS
   NR         4198
   SPS_KNX_MSGCNT 16950
   SPS_KNX_TIME 2021-08-16 17:39:47
   STATE      4.143
   TYPE       S7_AWrite
   READINGS:
     2021-08-16 11:05:18   IODev           SPS_KNX
     2021-08-16 17:39:41   state           4.143
   helper:
     bm:
       S7_AWrite_Set:
         cnt        2797
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        16.08. 16:35:26
         max        0.0841071605682373
         tot        76.6443145275116
         mAr:
           HASH(Strom_L3_SPS)
           Strom_L3_SPS
           3.715
Attributes:
   IODev      SPS_KNX
   alias      Strom_L3_SPS
   event-min-interval .*:600
   event-on-change-reading state:0.01
   room       Leistungsmessung

eine andere Frage:

Ich habe ein Reading indem ich ein Usereading erstellt habe
jetzt muss ich beide aktualisieren, damit das Event gefeuert wird - weiterverarbeitet wird das Userreading - gibt es da eine andere/bessere Lösung

Reading

Code: [Auswählen]

Internals:
   ADDRESS    32
   AREA       db
   DATATYPE   float
   DB         526
   DEF        db 526 32 float
   FUUID      5d90471e-f33f-70d9-f0e2-4d915d87e80ecd37
   IODev      SPS_Allgemein
   LASTInputDev SPS_Allgemein
   LENGTH     4
   MSGCNT     27701
   NAME       Aussen_Wind_SPS
   NR         361
   SPS_Allgemein_MSGCNT 27701
   SPS_Allgemein_TIME 2021-08-16 21:47:29
   STATE      2.07999992370605
   TYPE       S7_ARead
   READINGS:
     2021-08-16 11:05:17   IODev           SPS_Allgemein
     2021-08-16 21:47:29   state           2.07999992370605
     2021-08-16 21:47:29   state_Wind      2.08
   helper:
     bm:
       S7_ARead_Attr:
         cnt        5
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        16.08. 17:24:01
         max        4.60147857666016e-05
         tot        0.000130891799926758
         mAr:
           set
           Aussen_Wind_SPS
           event-on-change-reading
           state_Wind.*
Attributes:
   IODev      SPS_Allgemein
   alias      Aussen_Wind_SPS
   event-min-interval .*:600
   event-on-change-reading state:0.01,state_Wind:0.01
   room       Aussen
   userReadings state_Wind {sprintf("%.2f", ReadingsVal($name,"state",0))}


[erwin]

Hi,

wenn das ein KNX device wäre:

Code: [Auswählen]

attr <device> stateCmd {sprintf("%.2f", $state)}.. aber es ist ja ein SPS device, da musst du in der cmd-ref von S7_... suchen...
l.g. erwin