Hallo Zusammen,
ich habe seit einiger Zeit die folgende Fehlermeldung im Log-File, grundsätzlich funktioniert aber alles.
2021.03.21 07:40:52 1: PERL WARNING: Argument "onoff:" isn't numeric in numeric gt (>) at (eval 327969) line 1, <GEN22264> line 38.
2021.03.21 07:40:52 1: PERL WARNING: Argument "onoff:" isn't numeric in numeric gt (>) at (eval 327973) line 1, <GEN22264> line 42.
2021.03.21 07:40:52 1: PERL WARNING: Argument "onoff:" isn't numeric in numeric gt (>) at (eval 327977) line 1, <GEN22264> line 46.
2021.03.21 07:40:52 1: PERL WARNING: Argument "onoff:" isn't numeric in numeric gt (>) at (eval 327981) line 1, <GEN22264> line 50.
...
Ich überwache über die Leistung den Zustand einer Wärmepumpe und werte dies wie im FhemWiki unter HourCounter beschrieben über ein UserReading aus:
userReadings onoff {(ReadingsVal("HM_6440EA_SenPwr","state",0) >10)?1:0;;}
Internals:
DEF HM_6440EA_SenPwr:onoff:.1 HM_6440EA_SenPwr:onoff:.0
FUUID 5f5242ee-f33f-9c2c-b41d-ce649e312e329374
NAME hc_Waermepumpe
NR 1420
NTFY_ORDER 50-hc_Waermepumpe
STATE 0
TYPE HourCounter
VERSION 1.0.1.2 - 24.12.2014
READINGS:
2021-03-21 08:20:45 countsOverall 156
2021-03-21 08:20:45 countsPerDay 0
2021-03-21 08:20:45 pauseTimeEdge 19629
2021-03-21 08:20:45 pauseTimeIncrement 19629
2021-03-21 08:20:45 pauseTimeOverall 11920323
2021-03-21 08:20:45 pauseTimePerDay 0
2021-03-21 08:20:45 pulseTimeEdge 237332
2021-03-21 08:20:45 pulseTimeIncrement 42486
2021-03-21 08:20:45 pulseTimeOverall 4580086
2021-03-21 08:20:45 pulseTimePerDay 30040
2021-03-21 08:20:45 state 0
2021-03-20 20:32:38 tickChanged 311
2021-03-21 00:00:05 tickDay 1
2021-03-21 08:00:03 tickHour 16
2021-03-20 16:29:03 tickMonth 0
2021-03-21 08:20:45 tickUpdated 496
2021-03-21 00:00:05 tickWeek 1
2021-03-20 16:29:03 tickYear 0
2021-03-21 08:20:45 value 1
helper:
OFF_Regexp HM_6440EA_SenPwr:onoff:.0
ON_Regexp HM_6440EA_SenPwr:onoff:.1
calledByEvent
changedTimestamp 2021-03-21 08:20:45
forceClear
forceDayChange
forceHourChange
forceMonthChange
forceWeekChange
forceYearChange
isFirstRun
sdRoundHourLast 1616310000
value 1
cmdQueue:
Attributes:
alias hc_Waermepumpe
Darüber hinaus lasse ich mich per Pushover über die Zustände informieren. Hier vermute ich den Fehler. Ich kann mir aber keinen Reim aus der Fehlermeldung machen, da der State von "onoff" für mich numerisch (0/1) ist.
Internals:
DEF ([HM_6440EA_SenPwr:onoff] == 1)
(set PushMsg msg 'Info' 'Wärmepumpe an!' 'Mein-iPhone' 0 '')
DOELSEIF
([HM_6440EA_SenPwr:onoff] == 0)
((set PushMsg msg 'Info' 'Wärmepumpe aus! Laufzeit: {(sprintf("%.1f",[hc_Waermepumpe:pulseTimeEdge]/3600))} h' 'Mein-iPhone' 0 ''))
FUUID 5f53ce7c-f33f-9c2c-952c-a80bae2fef884659
MODEL FHEM
NAME push_Waermepumpe
NOTIFYDEV global,HM_6440EA_SenPwr
NR 1423
NTFY_ORDER 50-push_Waermepumpe
STATE cmd_1
TYPE DOIF
VERSION 24016 2021-03-19 23:34:44
READINGS:
2021-03-21 08:25:50 Device HM_6440EA_SenPwr
2021-03-21 07:27:34 cmd 1
2021-03-21 07:27:34 cmd_event HM_6440EA_SenPwr
2021-03-21 07:27:34 cmd_nr 1
2021-03-21 08:25:50 e_HM_6440EA_SenPwr_onoff 1
2021-03-21 07:26:57 mode enabled
2021-03-21 07:27:34 state cmd_1
2021-03-21 07:27:34 wait_timer no timer
Regex:
accu:
cond:
HM_6440EA_SenPwr:
0:
onoff ^HM_6440EA_SenPwr$:^onoff:
1:
onoff ^HM_6440EA_SenPwr$:^onoff:
attr:
cmdState:
wait:
0:
15
1:
15
waitdel:
condition:
0 ::ReadingValDoIf($hash,'HM_6440EA_SenPwr','onoff') == 1
1 ::ReadingValDoIf($hash,'HM_6440EA_SenPwr','onoff') == 0
do:
0:
0 set PushMsg msg 'Info' 'Wärmepumpe an!' 'Mein-iPhone' 0 ''
1:
0 (set PushMsg msg 'Info' 'Wärmepumpe aus! Laufzeit: {(sprintf("%.1f",[hc_Waermepumpe:pulseTimeEdge]/3600))} h' 'Mein-iPhone' 0 '')
2:
helper:
DEVFILTER ^global$|^HM_6440EA_SenPwr$
NOTIFYDEV global|HM_6440EA_SenPwr
event 883.61,onoff: 1
globalinit 1
last_timer 0
sleepdevice HM_6440EA_SenPwr
sleepsubtimer -1
sleeptimer -1
timerdev HM_6440EA_SenPwr
timerevent 883.61,onoff: 1
triggerDev HM_6440EA_SenPwr
timerevents:
883.61
onoff: 1
timereventsState:
state: 883.61
onoff: 1
triggerEvents:
883.61
onoff: 1
triggerEventsState:
state: 883.61
onoff: 1
internals:
readings:
all HM_6440EA_SenPwr:onoff
trigger:
uiState:
uiTable:
Attributes:
alias push_Wärmepumpe
room Push
wait 15:15
Wie werde ich die Fehlermeldungen los?
odie13690
Hi,
der Fehler muss woanders liegen
Zitatisn't numeric in numeric gt (>) at
Er meckert größer als und nicht gleich an :)
BTW: userReadings onoff {(ReadingsVal("HM_6440EA_SenPwr","state",0) >10)?1:0;;} -> userReadings onoff {(ReadingsNum("HM_6440EA_SenPwr","state",0) >10)?1:0}
Gruß Otto
Hi,
oh ja, ich habe noch ein zweites Device mit Überwachung.
Internals:
DEF ([+01:00] and [?Pumpensumpf_Leistung:onoff:sec]>3600)
(set PushMsg msg 'Status' 'Pumpensumpf überprüfen' 'Mein-iPhone' 0 '')
FUUID 5f9c7868-f33f-9c2c-a25e-bccc47bbe4d0df36
MODEL FHEM
NAME doif_PumpensumpfUeberwachen
NOTIFYDEV global
NR 1429
NTFY_ORDER 50-doif_PumpensumpfUeberwachen
STATE initialized
TYPE DOIF
VERSION 24016 2021-03-19 23:34:44
READINGS:
2021-03-21 19:49:31 cmd 0
2021-03-21 19:49:31 mode enabled
2021-03-21 19:49:31 state initialized
2021-03-21 19:49:31 timer_01_c01 21.03.2021 20:49:31
Regex:
accu:
condition:
0 ::DOIF_time_once($hash,0,$wday) and ::ReadingSecDoIf('Pumpensumpf_Leistung','onoff')>3600
days:
do:
0:
0 set PushMsg msg 'Status' 'Pumpensumpf überprüfen' 'Mein-iPhone' 0 ''
1:
helper:
DEVFILTER ^global$
NOTIFYDEV global
globalinit 1
last_timer 1
sleeptimer -1
intervalfunc:
localtime:
0 1616356171
realtime:
0 20:49:31
time:
0 +01:00
timeCond:
0 0
timer:
0 0
timers:
0 0
triggertime:
1616356171:
localtime 1616356171
hash:
uiTable:
Attributes:
alias doif_PumpensumpfUeberwachen
do always
Internals:
DEF 32883603
FUUID 5c4f5000-f33f-9c2c-5628-ba2497392cae8602
NAME Pumpensumpf_Leistung
NOTIFYDEV global
NR 483
NTFY_ORDER 50-Pumpensumpf_Leistung
STATE 0.65
TYPE CUL_HM
chanNo 03
device HM_328836
READINGS:
2019-01-28 19:56:06 R-cndTxCycAbove off
2019-01-28 19:56:06 R-cndTxCycBelow off
2019-01-28 19:56:06 R-cndTxDecAbove 200
2019-01-28 19:56:06 R-cndTxDecBelow 0
2019-01-28 19:56:06 R-cndTxFalling off
2019-01-28 19:56:06 R-cndTxRising off
2019-01-28 19:56:06 R-sign off
2019-01-28 19:56:06 R-txThrHiPwr 200 W
2019-01-28 19:56:06 R-txThrLoPwr 100 W
2021-02-17 13:14:44 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
2021-02-17 13:14:41 cfgState updating
2021-03-21 19:52:25 onoff 0
2021-03-21 19:52:25 state 0.65
helper:
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 4:powerMeter
regLst 1,4p
cmds:
TmplKey :no:1616254133.3006
TmplTs 1616254133.3006
cmdKey 1:0:0::HM_328836:00AC:03:
cmdLst:
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|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
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
role:
chn 1
tmpl:
Attributes:
alias Pumpensumpf_Leistung
group x_Aktordetails
model HM-ES-PMSW1-PL
peerIDs 00000000
userReadings onoff {(ReadingsNum("Pumpensumpf_Leistung","state",0) >10)?1:0;;}
odie13690
Da versteh ich die Meldung auch noch nicht.
Er meckert ja explizit an
Argument "onoff:" isn't numeric in numeric gt (>) at
Also "er" liest onoff: und soll es mit > vergleichen.
Es ist auch kein Fehler: er warnt "nur": onoff: ist für ihn numerisch null :)
Hi,
grundsätzlich funktioniert ja auch alles wie es soll. Mich stören nur die mehreren 100 Zeilen "Hinweise" pro Tag im LogFile.
odie13690
du könntest mal stacktrace einschalten, da siehst etwas mehr von der Warning und könntest evtl. den Verursacher finden.
attr global stacktrace 1
Im Moment scheint ja nicht klar, woher die Meldung kommt, oder kannst Du das dem zuornden, was Du hier vorgestellt hast?
"onoff" ist z.B. ein Standard-Reading bei HUEDevices
mit list .* onoff siehst Du alle Devices, die das Reading haben.
Vielleicht kommt es ja aus einer ganz anderen Ecke. Bei mehreren hundert Meldungen?
Andere Überlegung: das ist so eine Homematic Schaltsteckdose mit Leistungsmessung, korrekt?
Homematics neigen dazu, sehr viele Events zu produzieren. So wie dein userReadings definiert ist wird das bei jedem beliebigen Event des Devices getriggert. Das könntest Du auf das Pwr Reading eingrenzen:
Zitat<reading>[:<trigger>] [<modifier>] { <perl code> }
If <trigger> is given, then all processing for this specific user reading is only done if one of the just updated "reading: value" combinations matches <trigger>, which is treated as a regexp
userReadings onoff:power.* {(ReadingsVal($name,"power",0) >10)?1:0}Den Devicenamen kannst Du mit $name ersetzen. So wird das userReading nur bei Event von power gerechnet. Das sollte die Anzahl der Meldungen schon mal reduzieren. Die sind ja auch alle "gleichzeitig", das deutet schon in die Richtung von vielen Events des Homematic.
Du könntest auch mal ein list vom Homematic hier einstellen.
Hi,
ich habe nur die beiden Devices mit dem onoff-Reading (mit list .* onoff sicherheitshalber geprüft). Und das > schränkt es dann auf das eine Device ein.
Ja, es handelt sich um einen HomeMatic Schaltaktor mit Leistungsmessung. Hier das List:
Internals:
DEF 328836
FUUID 5c4f5000-f33f-9c2c-9504-53403de763b49b11
HMLAN1_MSGCNT 1632
HMLAN1_RAWMSG E328836,0000,0A0671A3,FF,FFBE,D3845E32883600000080092D000041000808DC01
HMLAN1_RSSI -66
HMLAN1_TIME 2021-03-22 19:12:00
HMLAN2_MSGCNT 1
HMLAN2_RAWMSG E328836,0000,AB60D165,FF,FF97,39A45F3288362BAA798008A10015FE01DD08FDFF
HMLAN2_RSSI -105
HMLAN2_TIME 2021-03-22 17:19:50
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 1633
NAME HM_328836
NOTIFYDEV global
NR 477
NTFY_ORDER 50-HM_328836
STATE CMDs_done
TYPE CUL_HM
channel_01 Pumpensumpf
channel_02 Pumpensumpf_Verbrauch
channel_03 Pumpensumpf_Leistung
channel_04 Pumpensumpf_Strom
channel_05 Pumpensumpf_Spannung
channel_06 Pumpensumpf_Frequenz
lastMsg No:D3 - t:5E s:328836 d:000000 80092D000041000808DC01
protLastRcv 2021-03-22 19:12:00
protRcv 1616 last_at:2021-03-22 19:12:00
protSnd 443 last_at:2021-03-22 18:56:23
protState CMDs_done
rssi_HMLAN1 cnt:24 min:-72 max:-57 avg:-63.54 lst:-64
rssi_at_HMLAN1 cnt:1632 min:-85 max:-57 avg:-68.3 lst:-66
rssi_at_HMLAN2 cnt:1 min:-105 max:-105 avg:-105 lst:-105
READINGS:
2021-03-20 16:38:44 Activity alive
2019-01-28 19:55:00 D-firmware 2.5
2019-01-28 19:55:00 D-serialNr LEQ0931299
2021-03-22 17:05:56 PairedTo 0x2BAA79
2019-01-28 19:56:00 R-pairCentral 0x2BAA79
2021-03-22 17:05:56 RegL_00. 00:00 02:01 0A:2B 0B:AA 0C:79 15:FF 18:00
2021-03-22 17:05:55 cfgState updating
2021-03-22 18:56:24 commState CMDs_done
2021-03-22 17:05:49 powerOn 2021-03-22 17:05:49
2021-03-22 18:56:24 state CMDs_done
helper:
HM_CMDNR 211
PONtest 0
cSnd 112BAA793288360201000000,112BAA793288360201C80000
mId 00AC
peerFriend
peerOpt -:powerMeter
regLst 0
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey :no:1616254130.61548
TmplTs 1616254130.61548
cmdKey 0:1:0::HM_328836:00AC:00:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
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
io:
newChn +328836,00,00,00
nextSend 1616436720.50604
prefIO
rxt 0
vccu
p:
328836
00
00
00
mRssi:
mNo D3
io:
HMLAN1:
-62
-62
HMLAN2:
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rssi:
HMLAN1:
avg -63.5416666666667
cnt 24
lst -64
max -57
min -72
at_HMLAN1:
avg -68.3039215686274
cnt 1632
lst -66
max -57
min -85
at_HMLAN2:
avg -105
cnt 1
lst -105
max -105
min -105
shadowReg:
tmpl:
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
alias HM_328836
autoReadReg 4_reqStatus
expert defReg,rawReg
firmware 2.5
model HM-ES-PMSW1-PL
room CUL_HM
serialNr LEQ0931299
subType powerMeter
webCmd getConfig:clear msgEvents
odie13690
Also in deinem HomeMatic Schaltaktor mit Leistungsmessung kann ich kein Reading power finden.
READINGS:
2021-03-20 16:38:44 Activity alive
2019-01-28 19:55:00 D-firmware 2.5
2019-01-28 19:55:00 D-serialNr LEQ0931299
2021-03-22 17:05:56 PairedTo 0x2BAA79
2019-01-28 19:56:00 R-pairCentral 0x2BAA79
2021-03-22 17:05:56 RegL_00. 00:00 02:01 0A:2B 0B:AA 0C:79 15:FF 18:00
2021-03-22 17:05:55 cfgState updating
2021-03-22 18:56:24 commState CMDs_done
2021-03-22 17:05:49 powerOn 2021-03-22 17:05:49
2021-03-22 18:56:24 state CMDs_done
helper:
Die Power wird im channel_02 Pumpensumpf_Verbrauch erzeugt. Dort sollte dann auch das userreading stehen.
Wie Otto geschrieben hat, solltest Du ausserdem in userReadings onoff:power.* {(ReadingsVal($name,"power",0) >10)?1:0}
das ReadingsVal durch ReadingsNum ersetzten. Sonst, falls das reading nicht existiert, wird ein string zurueckgeliefert, ReadingsVal($name,"power",0) erwartet als letztes Argument einen String (also ReadingsVal($name,"power","0") und keine Zahl.
Also entweder ReadingsVal($name,"power","0") oder ReadingsNum($name,"power",0);
Für > ist dann ReadingsNum($name,"power",0) richtig.
@odie13690
danke für das list. Du hast ja weiter oben schon eins vom Pumpensumpf_Verbrauch gezeigt, da ist aber auch kein power reading? Das wundert mich, bei meinem HM-ES-PMSW1-PL gibts da etliche readings mit volt, current, energy, power etc. Gibts vielleicht ein Register zu setzen, kann ich im Moment nicht mehr sagen. Sollte aber auch mit state gehen, und der Hinweis mit ReadingsNum von Jamo ist korrekt, das habe aber nur ich falsch hingeschrieben, Du hattest das ja schon drin. Ob das userReadings onoff:state.* {(ReadingsNum($name,"state",0) >10)?1:0} dann funktioniert musst Du mal testen. Sollte dann weniger Meldungen bringen, da ja nur noch auf state das Reading gerechnet wird.
Was sagt stacktrace?