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
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.
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
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
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)
Mir fällt leider auch nix auf. Ist das bei allen Telegrammen so, die von KNX auf FHEM weitergeleitet werden oder nur bei bestimmten?
aufgefallen ist es mir beim ABB AE/S4.1.1.3 Analogeingang 4-fach REG
bei den anderen TN eher nicht - zumindest nicht offensichtlich ;)
das ist leider bei jedem Teilnehmer :-[
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?
Fhem schon mehrmals durchgestartet - Beim Neustart ist die Verzögerung so bei einer Minute - es scheint, dass es bei längerer Laufzeit schlechter wird
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?
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?
Debug von KNXD, nix von FHEM: https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen
das kann ich mir erst am Abend genauer ansehen - ich melde mich wenn ich Infos habe - besten dank schon mal :)
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:~#
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.
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.
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
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?
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... :-[
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.
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 ;)
Bisher hab ich ja noch nicht geholfen außer blöde Fragen zu stellen :D
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.... :-\
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.
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
Hast du zeitgleich das Debug von KNXD und den Gruppenmonitor laufen lassen und gesehen, ob hier auch die Verzögerung war?
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.
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.
welchen Erwin meinst du?
Den Nutzer erwin hier im Forum :)
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
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
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
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.
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
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...
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
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
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
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
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
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
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
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 ::)
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.
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
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
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).*
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
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
Verstehe deine Frage nicht. Was haste genau für Werte, was ist gesetzt und was genau soll passieren?
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
Hast du mal die CommandRef zum Unterschied zwischen update und change gelesen? Da ist es sehr gut erklärt was du willst.
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
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
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))}
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