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

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

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

logs aktiviert - leider dasselbe Bild

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

stimmt vielleicht mein 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?
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

#19
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 ;)

Zitat von: Schneewa am 04 August 2021, 12:31:53
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.
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

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

ZitatAlle Geräte sind auf der gleichen Linie, kein Linienkoppler dazwischen?
habe keinen Linienkoppler dazwischen

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

ZitatWas 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 :D
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

#23
das ist definitiv ein Fhem Problem

knx protokolliert mit

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

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

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

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

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

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


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

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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Schneewa

#32
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 
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

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

#35
Hi all

allgemeine Frage zum apptime


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...
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Schneewa

#37
Hi

Zitat
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

#38
sehr interessantes Tool

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

                                                                               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 get checkDOIF kommt einiges

wie z.B.: 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

Zitat- 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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

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


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,
Zitatsind zwischen den Abfragen noch Zeiten übrig
das versteh ich nicht!
Zitatich 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 
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Schneewa

Hi Erwin

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


sind zwischen den Abfragen noch Zeiten übrig


damit habe ich gemeint, dass bei mir in wirklich jeder Sekunde mindestens ein Event gefeuert wird

Zitat
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

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?



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


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

#43
Hi,

1)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)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:
define Strom_L_notify notify Strom_L[1-3]:state:.* set $NAME_SPS $EVTPART1
attr Strom_L_notify addStateEvent 1


l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Schneewa

#44
Hi,

Zitat1)

ist Gold wert  :) :) und funktioniert bestens

Zitat2)

Mein notify habe ich aus einem Bsp. von Fhem Wiki

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

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

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

erwin

hi,

das notify aus dem wiki ist ja nicht falsch, aber halt nur beschränkt elegant  ;D
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...
copy device1 device2

l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Schneewa

Hi euch Beiden

erste Erfolgsmeldungen  :) :)

nur das umstellen der KNX Readings
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
event-on-change-reading state
schon sehr rigoros alles abblockt, is mir das zu derb  ;D

Hier eine Lösung, um nur das "last-sender" von unnötigen Updates auszuschließen.
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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Schneewa

#50
eine Frage zum 
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


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


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

bei

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

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

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

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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Schneewa

#56
Hi Erwin

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

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

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:
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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...