Hallo zusammen,
ich habe in einem Device - bzw. einem Kanal eines Devices - folgendes userReading:
gerundet {sprintf("%.0f",ReadingsVal($name,"state",0))}
Der Wert wird mittels DbLog in eine Datenbank geschrieben.
Das Device hat dafür die Attribute:
DbLogExclude .*
DbLogInclude gerundet
event-on-change-reading gerundet
Schaue ich in die Datenbank (MariaDB), finde ich dazu immer einen dreifachen, identischen Eintrag. Screenshot ist beigefügt.
In einem anderen Device (ebenfalls Zwischenstecker mit Leistungsmessung) habe ich analog ebenfalls das userReading "gerundet" angelegt.
Dazu finde ich in der Datenbank einen doppelten, identischen Eintrag.
Hier noch ein list des Devices/Kanals mit den dreifachen Einträgen:
Internals:
DEF 34XXXXXX
FUUID XXX
NAME ke_026_warmwasser_leistung
NR 172
NTFY_ORDER 48-ke_026_warmwasser_leistung
STATE 0 W
TYPE CUL_HM
chanNo 03
device ke_026_warmwasser
disableNotifyFn 1
Helper:
DBLOG:
gerundet:
DBLogging:
TIME 1646840482.2844
VALUE 0
READINGS:
2022-02-08 17:08:29 R-cndTxCycAbove off
2022-02-08 17:08:29 R-cndTxCycBelow off
2022-02-08 17:08:29 R-cndTxDecAbove 200
2022-02-08 17:08:29 R-cndTxDecBelow 0
2022-02-08 17:08:29 R-cndTxFalling off
2022-02-08 17:08:29 R-cndTxRising off
2022-02-08 17:08:29 R-sign off
2022-02-08 17:08:29 R-txThrHiPwr 200 W
2022-02-08 17:08:29 R-txThrLoPwr 100 W
2022-03-04 16:00:10 RegL_01. 00:00 08:00 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:4E 8A:20 8B:00 8C:00 8D:27 8E:10
2022-03-04 16:00:07 cfgState updating
2022-03-09 16:40:33 commState CMDs_done
2022-03-09 16:52:04 gerundet 0
2022-03-09 16:52:04 state 0
helper:
peerFriend peerAct,peerVirt
peerIDsRaw ,00000000
peerIDsState complete
peerOpt 4:powerMeter
regLst 1,4p
cmds:
TmplKey :no:1645725642.36533
TmplTs 1645725642.36533
cmdKey 1:0:0::ke_026_warmwasser:00AC:03:
cmdLst:
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 -actChn- [({single})] [({set}|unset)] [actor|remote|both]
peerSmart -peerOpt-
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
sign [(on|{off})]
tplDel -tplDel-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
lst:
condition slider,0,1,255
peer
peerOpt <hier stehen jede Menge Devices>
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
peerIDsH:
00000000 broadcast
regCollect:
role:
chn 1
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
DbLogInclude gerundet
event-on-change-reading gerundet
model HM-ES-PMSW1-PL
peerIDs 00000000
stateFormat state W
userReadings gerundet {sprintf("%.0f",ReadingsVal($name,"state",0))}
Hat jemand eine Idee, warum der gleiche Wert dreimal im Log auftaucht?
Fehlen noch weitere Infos, um das zu beurteilen?
Vielen Dank schonmal für jegliche Hilfe und Tipps!
VG
Andreas
**EDIT*** Der dreifache Wert erscheint nur in der current Tabelle in der Datenbank...in der history Tabelle ist er nur einfach vorhanden...
Hallo Joachim,
danke für die schnelle Antwort.
Hmmm, erklärt das denn auch die exakt gleichen Zeitstempel?
**EDIT*** Den Event Monitor sehe ich mir mal an, wenn der Zwischenstecker beim nächsten Mal einschaltet...danke für den Tipp.
VG
Andreas
Mist, hätte nicht löschen sollen, sorry!!!
Aber nach dem ich event-on-change-reading gesehen hatte war ich mir nicht mehr so sicher...
...und mit DBLog kenne ich mich nicht aus...
Gruß, Joachim
Alles klar, danke trotzdem nochmal.
Finde es auch seltsam, dass bei einem anderen Device mit identischen Atrributen der Wert "nur" zweimal in die current Tabelle geschrieben wird...
VG
Andreas
Also dann formuliere ich noch mal nach...
Wie geschrieben (und gelöscht): mal den Eventmonitor aufmachen. Wenn dort 3x der Event kommt, dann ist klar warum er in der DB landet (so denke ich).
Und eigentlich immer: Trigger bei userReadings
Gruß, Joachim
Hattest du nicht vorher geschrieben Kein Trigger bei userReadings ?
VG
Andreas
Ja aber weil du eben KEINEN hast ;)
Und aber (immer) einen haben solltest... 8)
Gruß, Joachim
;D
Guten Morgen,
hallo Joachim,
habe jetzt mal in den Eventmonitor geschaut...dort taucht nur ein Event auf, wenn sich das Reading ändert.
In die Datenbank wird der Wert weiterhin dreimal in die Tabelle current geschrieben.
VG
Andreas
Hallo Andreas,
hmm, dann habe ich leider keine Idee... :-\
Sorry, Joachim
Vorab: Das ist ein CUL_HM-(sub)-Device, das könnte etwas "spezieller" sein wie ein normales.
Du solltest du daher zunächst darum kümmern, dass die Events _richtig_ und im gewünschten Umfang kommen.
Z. B. in https://forum.fhem.de/index.php/topic,125930.msg1207017.html#msg1207017 ist zu erkennen, welches Attribut am Hauptdevice zu setzen wäre.
Dann:
Zitatevent-on-change-reading gerundet
ist "Unfug".
Ein userReading sollte einen Trigger haben, und von daher brauchst du eben im mindesten Falle das "Basisreading", das hier (unglücklicherweise!) state zu sein scheint, das triggernd zu aktualisieren wäre. Da dort ggf. noch weitere "unbrauchbare" Events drin sind, müßtest du die im Perl-Code ignorieren.
Hallo Vize,
zudem kannst Du das {sprintf("%.0f",ReadingsVal($name,"state",0))} durch {ReadingsNum($name,'state',0,0))} ersetzten. Wenn dein state einen numerischen Wert liefert, ist ReadingsNum angebracht, und der ReadingsNum funktion kann man die Anzahl der zu rundenden Stellen mitgeben (hier die letzte 0).
Hallo zusammen,
danke für die zusätzlichen Tipps!
Werde ich mal angehen,
@Beta-User
Das "event-on-change-reading" habe ich hier genommen, um das hier aus dem Wiki umzusetzen:
Wird event-on-change-reading für ein einzelnes Reading gesetzt, erzeugen alle übrigen Readings des Gerätes keine Events mehr, auch nicht wenn Werte sich ändern.
Dachte, damit erreiche ich, dass das Device/der Kanal dann nicht mehr bei Änderung der restlichen Readings Events feuert.
Habe ich da einen Denkfehler, oder warum meinst du, das sei "Unfug"?
@Jamo
Danke für den Tipp. In deinem Vorschlag ist allerdings eine schließende Klammer zuviel... ;-)
VG
Andreas
Hmmm, nachdem ich den Tipp von Jamo umgesetzt habe, tauchen im Logfile nun regelmäßig diese Einträge auf
2022.03.18 16:52:06 1: PERL WARNING: Argument "Error" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1592.
2022.03.18 16:52:06 1: PERL WARNING: Use of uninitialized value $v in numeric gt (>) at ./FHEM/98_SVG.pm line 1592.
2022.03.18 16:52:06 1: PERL WARNING: Use of uninitialized value $v in numeric lt (<) at ./FHEM/98_SVG.pm line 1593.
2022.03.18 16:52:06 1: PERL WARNING: Argument "Error" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 1976.
2022.03.18 16:52:06 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/98_SVG.pm line 1976.
2022.03.18 16:52:06 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/98_SVG.pm line 1975.
Die waren vorher nicht da...kann mir da jemand helfen, um der Sache auf die Spur zu kommen?
Danke!
VG
Andreas
Zitat von: Vize am 18 März 2022, 16:51:47
Das "event-on-change-reading" habe ich hier genommen, um das hier aus dem Wiki umzusetzen:
[...]
Dachte, damit erreiche ich, dass das Device/der Kanal dann nicht mehr bei Änderung der restlichen Readings Events feuert.
Habe ich da einen Denkfehler, oder warum meinst du, das sei "Unfug"?
Eigentlich braucht ein userReading ein triggerndes Event, damit es überhaupt aktualisiert wird. Mir ist ehrlich gesagt schleierhaft, warum das überhaupt in dieser Konstellation geschrieben wird... Es ist jedenfalls mAn. eine "Henne-Ei"-Problem ohne Anwesenheit eines Huhns, deswegen behaupte ich weiter, es sei "Unfug". (Ich habe nicht in den Code von fhem.pl geschaut, vielleicht mag sonst jemand wissendes aufklären, warum hier überhaupt was passiert).
Jedenfalls ist es nicht sauber und du solltest:
- state zu den triggernden Readings hinzufügen
- keine "Kommunikations"-Events in den Channels zulassen und
- dem userReading einen Trigger verpassen (auf "state").
Zitat von: Vize am 18 März 2022, 16:54:58
Die waren vorher nicht da...kann mir da jemand helfen, um der Sache auf die Spur zu kommen?
Schau mal in das rein, was das FileLog geschrieben hast, das du für das SVG auszuwerten versuchst.
Hallo Beta-User,
besten Dank nochmal für deine Erläuterungen. Das meiste habe ich verstanden...
Bei deinem letzten Satz habe ich wohl ein Brett vor dem Kopf.
Was meinst du mit "was, das FileLog geschrieben hast, das du für das SVG auszuwerten versuchst"?
Ich nutze DbLog und lasse mir daraus die SVG-Plots erzeugen...
VG
Andreas
Na ja, wie dem auch sei: Es wird ein Wert irgendwohin geschrieben, der nicht so ist, wie SVG das gerne hätte.
Ggf. mal den Plot-Editor bemühen und die Daten ("preprocessed values" oder so) anzeigen lassen.
Ok, danke dir nochmal für deine Geduld.
Ist nur seltsam, dass das vorher nicht auftrat. Hab sonst nix geändert, auch nicht an den SVG-Plots...nur den Tipp von Jamo mit ReadingsNum getestet.
Hab eben mal auf den "alten Zustand" mit ReadingsVal gestellt, aber die Logeinträge kommen immer noch.
VG
andreas
Guten Morgen,
ich habe es nun mal so umgestellt, dass ich mir das Reading aus einem anderen Kanal des Devices loggen lasse, ohne auf das Reading "state" Bezug nehmen zu müssen.
Dazu habe ich dort das userReading
power_gerundet:power.* {ReadingsNum($name,'power',0,0)}
angelegt.
Dazu dann noch
event-on-change-reading power,power_gerundet
damit die weiteren "unwichtigen" Readings keine Events erzeugen.
**EDIT*** Das lässt sich noch durch
event-on-change-reading power.*
verkürzen. ***EDIT***
Über
DbLogInclude power_gerundet
wird das Reading nun in die Datenbank geschrieben.
Auch hier das gleiche Verhalten wie im Ausgangspost, das Reading erscheint in der current Tabelle dreimal und in der history Tabelle einmal.
Vielleicht hat ja noch jemand eine Idee, sonst nehme ich den Mehrfacheintrag in der current Tabelle einfach hin.
Sonniges Wochenende noch!
VG
Andreas
Guten Morgen,
so, habe dann doch noch eine Lösung gefunden.
Wurde sogar schonmal hier im Forum behandelt...siehe hier (https://forum.fhem.de/index.php/topic,55354.msg547811.html#msg547811)
Ja, ich weiß, hätte ich auch vorher danach suchen können...
Jedenfalls werden nach Anlegen eines Indexes für die Tabelle current nun die Werte nicht mehr doppelt in die Datenbank geschrieben.
Für die Tabelle history hatte ich den Index schon von Beginn an drin, daher tauchten dort die Werte nicht doppelt auf.
Das Ganze funktioniert wohl auch mit Anlegen eines "Primary Key" in der Tabelle.
Bezüglich der Fehlermeldungen im Logfile zum SVG habe ich das so gelöst, dass ich die SVG-Plots alle gelöscht und nochmal neu angelegt habe.
Die Warnungen im Logfile tauchen nun nicht mehr auf.
Vielen Dank nochmal an alle für die Tipps und die Unterstützung!
VG
Andreas