Ich betreibe einen HM-ES-TX-WM mit FW 2.5 und ES-IEC an einem SmartMeter.
Jedoch habe ich das Problem daß Logeinträge mehrfach (26-fach!) auflaufen, und dann mit jeweils aktuellen Zeitstempeln. Der tatsächliche Zählerstand ist dann jedoch schon längst weiter.
Das zersägt mir natürlich das Diagramm und die gleitenden Mittelwerte.
2021-05-25_15:20:18 Strom_IEC_01 W: 5726.0436 P: 126
2021-05-25_15:22:18 Strom_IEC_01 W: 5726.048 P: 125
2021-05-25_15:28:13 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:05 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:05 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:05 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:05 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:08 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:26 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:26 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:26 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:57 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:57 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:32:57 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:48:17 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:48:17 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:48:17 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:48:17 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:51:17 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:51:17 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:51:17 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:51:17 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:55:56 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:55:56 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:55:56 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:55:56 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:57:48 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:57:54 Strom_IEC_01 W: 5726.0646 P: 168
2021-05-25_15:59:46 Strom_IEC_01 W: 5726.4895 P: 209
2021-05-25_15:59:51 Strom_IEC_01 W: 5726.4895 P: 209
2021-05-25_16:01:46 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:01:46 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:01:51 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:42 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:45 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:47 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:47 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:48 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:48 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:48 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:49 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:49 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:50 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:50 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:52 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:05:57 Strom_IEC_01 W: 5726.4945 P: 151
2021-05-25_16:07:40 Strom_IEC_01 W: 5726.6295 P: 2110
2021-05-25_16:07:40 Strom_IEC_01 W: 5726.6295 P: 2110
2021-05-25_16:07:44 Strom_IEC_01 W: 5726.6295 P: 2110
2021-05-25_16:09:38 Strom_IEC_01 W: 5726.6937 P: 2118
2021-05-25_16:09:39 Strom_IEC_01 W: 5726.6937 P: 2118
2021-05-25_16:09:44 Strom_IEC_01 W: 5726.6937 P: 2118
2021-05-25_16:11:37 Strom_IEC_01 W: 5726.6937 P: 2118
2021-05-25_16:11:39 Strom_IEC_01 W: 5726.6937 P: 2118
Meine Versuche mit R-samplPerCycl und R-transmDevTryMax (beide auf 1) brachten keine Besserung, was könnte man da noch tun? Ein weiterer HM-ES-TX-WM mit FW 1.2 am Gaszähler läuft hingegen problemlos.
Nebenbei bemerkt sind im Device die OBIS-Kennzahlen abgeschnitten. Tatsächlich ist text1 auf 16.7.0 eingestellt, angezeigt wird für den Stromzähler jedoch nur:
text1 16.7.
text2 1.8.0
Und beim Gaszähler anstatt 1.7.0 und 1.8.0
text1 1-0:1.7
text2 1-0:1.8
erzeugst du diese events selber?
2021-05-25_15:20:18 Strom_IEC_01 W: 5726.0436 P: 126
zeig mal ein list.
mit attr event-on-change-reading sollte es jedenfalls deutlich weniger werden.
Das was geloggt wird ist lediglich ein
userReadings state {"W: " .ReadingsVal("Strom_IEC_01","energyIEC",0)/10000 ." P: " .ReadingsVal("Strom_IEC_01","powerIEC",0)/100 }
was mit aus
2021-05-25 18:45:32 energyIEC 57279378
und
2021-05-25 18:45:32 powerIEC 24700
einen vernünftigen Logeintrag
2021-05-25 18:45:37 state W: 5727.9378 P: 247
macht.
Ein event-on-change-reading würde das oberflächlich heilen, aber wie gesagt ist der tatsächliche Zählerstand bei 168W Leistung nach einer halben Stunde längst weiter. Für mich sieht das so aus als ob der EM-ES-TX-WM ein fertiges Paket in der Sendequeue hat, darauf kein ACK bekommt und das immer wieder schickt. Anstatt zum späteren Zeitpunkt einen neuen Momentanwert zu verwenden.
1. dein userreading nutzt keinen trigger deshalb wird es bei jedem event dieses devices getriggert.
=> trigger einbauen.
2. du überschreibst das bereits existierende reading state, das vom device genutzt wird.
=> eigenen reading namen nutzen.
schau dir die events auf dem eventmonitor an, dann weisst du warum es ist, wie es ist.
was ist mit dem "list Strom_IEC_01"?
1. Das Device wirft regulär alle ~119 Sekunden einen Event. Da der Strombezug immer größer 100W ist ändert sich immer auch der Zählerstand. event-on-change-reading wäre im Normalfall immer gegeben.
Hier mal ein Beispiel (Gutfall) im Event monitor nachdem sich der Sensor wieder beruhigt hat:
2021-05-25 22:24:36 CUL_HM Strom battery: ok
2021-05-25 22:24:36 CUL_HM Strom_IEC_01 energyIEC: 57288470
2021-05-25 22:24:36 CUL_HM Strom_IEC_01 energyTariff: 0
2021-05-25 22:24:36 CUL_HM Strom_IEC_01 energyUnit: 1
2021-05-25 22:24:36 CUL_HM Strom_IEC_01 powerIEC: 21700
2021-05-25 22:24:36 CUL_HM Strom_IEC_01 powerSign: 0
2021-05-25 22:24:36 CUL_HM Strom_IEC_01 powerTariff: 0
2021-05-25 22:24:36 CUL_HM Strom_IEC_01 powerUnit: 0
2021-05-25 22:24:36 CUL_HM Strom_IEC_01 W: 5728.847 P: 217
2021-05-25 22:24:36 CUL_HM Strom battery: ok
2021-05-25 22:26:34 CUL_HM Strom battery: ok
2021-05-25 22:26:34 CUL_HM Strom_IEC_01 energyIEC: 57288536
2021-05-25 22:26:34 CUL_HM Strom_IEC_01 energyTariff: 0
2021-05-25 22:26:34 CUL_HM Strom_IEC_01 energyUnit: 1
2021-05-25 22:26:34 CUL_HM Strom_IEC_01 powerIEC: 19400
2021-05-25 22:26:34 CUL_HM Strom_IEC_01 powerSign: 0
2021-05-25 22:26:34 CUL_HM Strom_IEC_01 powerTariff: 0
2021-05-25 22:26:34 CUL_HM Strom_IEC_01 powerUnit: 0
2021-05-25 22:26:34 CUL_HM Strom_IEC_01 W: 5728.8536 P: 194
2021-05-25 22:28:33 CUL_HM Strom battery: ok
2021-05-25 22:28:33 CUL_HM Strom_IEC_01 energyIEC: 57288601
2021-05-25 22:28:33 CUL_HM Strom_IEC_01 energyTariff: 0
2021-05-25 22:28:33 CUL_HM Strom_IEC_01 energyUnit: 1
2021-05-25 22:28:33 CUL_HM Strom_IEC_01 powerIEC: 19900
2021-05-25 22:28:33 CUL_HM Strom_IEC_01 powerSign: 0
2021-05-25 22:28:33 CUL_HM Strom_IEC_01 powerTariff: 0
2021-05-25 22:28:33 CUL_HM Strom_IEC_01 powerUnit: 0
2021-05-25 22:28:33 CUL_HM Strom_IEC_01 W: 5728.8601 P: 199
2021-05-25 22:28:33 CUL_HM Strom battery: ok
2021-05-25 22:30:31 CUL_HM Strom battery: ok
2021-05-25 22:32:29 CUL_HM Strom battery: ok
2021-05-25 22:32:29 CUL_HM Strom_IEC_01 energyIEC: 57288732
2021-05-25 22:32:29 CUL_HM Strom_IEC_01 energyTariff: 0
2021-05-25 22:32:29 CUL_HM Strom_IEC_01 energyUnit: 1
2021-05-25 22:32:29 CUL_HM Strom_IEC_01 powerIEC: 19200
2021-05-25 22:32:29 CUL_HM Strom_IEC_01 powerSign: 0
2021-05-25 22:32:29 CUL_HM Strom_IEC_01 powerTariff: 0
2021-05-25 22:32:29 CUL_HM Strom_IEC_01 powerUnit: 0
2021-05-25 22:32:29 CUL_HM Strom_IEC_01 W: 5728.8732 P: 192
2021-05-25 22:34:28 CUL_HM Strom battery: ok
2021-05-25 22:34:28 CUL_HM Strom_IEC_01 energyIEC: 57288796
2021-05-25 22:34:28 CUL_HM Strom_IEC_01 energyTariff: 0
2021-05-25 22:34:28 CUL_HM Strom_IEC_01 energyUnit: 1
2021-05-25 22:34:28 CUL_HM Strom_IEC_01 powerIEC: 19000
2021-05-25 22:34:28 CUL_HM Strom_IEC_01 powerSign: 0
2021-05-25 22:34:28 CUL_HM Strom_IEC_01 powerTariff: 0
2021-05-25 22:34:28 CUL_HM Strom_IEC_01 powerUnit: 0
2021-05-25 22:34:28 CUL_HM Strom_IEC_01 W: 5728.8796 P: 190
2021-05-25 22:34:28 CUL_HM Strom battery: ok
2021-05-25 22:36:26 CUL_HM Strom battery: ok
2021-05-25 22:36:26 CUL_HM Strom_IEC_01 energyIEC: 57288859
2021-05-25 22:36:26 CUL_HM Strom_IEC_01 energyTariff: 0
2021-05-25 22:36:26 CUL_HM Strom_IEC_01 energyUnit: 1
2021-05-25 22:36:26 CUL_HM Strom_IEC_01 powerIEC: 18800
2021-05-25 22:36:26 CUL_HM Strom_IEC_01 powerSign: 0
2021-05-25 22:36:26 CUL_HM Strom_IEC_01 powerTariff: 0
2021-05-25 22:36:26 CUL_HM Strom_IEC_01 powerUnit: 0
2021-05-25 22:36:26 CUL_HM Strom_IEC_01 W: 5728.8859 P: 188
2021-05-25 22:38:25 CUL_HM Strom battery: ok
2021-05-25 22:38:25 CUL_HM Strom_IEC_01 energyIEC: 57288920
2021-05-25 22:38:25 CUL_HM Strom_IEC_01 energyTariff: 0
2021-05-25 22:38:25 CUL_HM Strom_IEC_01 energyUnit: 1
2021-05-25 22:38:25 CUL_HM Strom_IEC_01 powerIEC: 19000
2021-05-25 22:38:25 CUL_HM Strom_IEC_01 powerSign: 0
2021-05-25 22:38:25 CUL_HM Strom_IEC_01 powerTariff: 0
2021-05-25 22:38:25 CUL_HM Strom_IEC_01 powerUnit: 0
2021-05-25 22:38:25 CUL_HM Strom_IEC_01 W: 5728.892 P: 190
2021-05-25 22:38:25 CUL_HM Strom battery: ok
Filelog:
2021-05-25_22:24:36 Strom_IEC_01 W: 5728.847 P: 217
2021-05-25_22:26:34 Strom_IEC_01 W: 5728.8536 P: 194
2021-05-25_22:28:33 Strom_IEC_01 W: 5728.8601 P: 199
2021-05-25_22:32:29 Strom_IEC_01 W: 5728.8732 P: 192
2021-05-25_22:34:28 Strom_IEC_01 W: 5728.8796 P: 190
2021-05-25_22:36:26 Strom_IEC_01 W: 5728.8859 P: 188
2021-05-25_22:38:25 Strom_IEC_01 W: 5728.892 P: 190
2) Das Reading "state" (nicht STATE) hat nicht existiert, daher hatte ich auch bewußt das userReadings so gesetzt, vgl. auch https://forum.fhem.de/index.php?topic=74380.0
Nur damit sieht man in der Übersicht den Momentanwert, was bei einem anderen reading namen nicht der Fall wäre.
3) list Strom_IEC_01
Internals:
DEF 4D15AA01
FUUID 60815fe0-f33f-8590-2f99-1e59a44e6df89339
NAME Strom_IEC_01
NOTIFYDEV global
NR 363
NTFY_ORDER 50-Strom_IEC_01
STATE W: 5728.892 P: 190
TYPE CUL_HM
chanNo 01
device Strom
OLDREADINGS:
READINGS:
2021-04-22 14:37:15 R-mtrType IEC
2021-04-22 14:37:15 R-sign off
2021-05-25 16:05:45 R-transmitTryMax 6
2021-05-25 19:54:40 cfgState updating
2021-05-25 22:02:02 commState CMDs_done
2021-05-25 22:38:25 energyIEC 57288920
2021-05-25 22:38:25 energyTariff 0
2021-05-25 22:38:25 energyUnit 1
2021-05-25 22:38:25 powerIEC 19000
2021-05-25 22:38:25 powerSign 0
2021-05-25 22:38:25 powerTariff 0
2021-05-25 22:38:25 powerUnit 0
2021-05-25 22:02:02 recentStateType info
2021-05-25 22:38:25 state W: 5728.892 P: 190
2021-05-25 16:05:52 text1 16.7.
2021-05-25 16:05:52 text2 1.8.0
helper:
getCfgListNo
peerFriend
peerIDsState peerUnread
peerOpt -:powerSensor
regLst 1
cmds:
TmplKey :no:1621955513.81541
TmplTs 1621955513.81541
cmdKey 1:0:0::Strom:00DE:01:
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)]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
sign [(on|{off})]
text -txt1- [-txt2-]
tplDel -tplDel-
tplSet_0 -tplChan-
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
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 1
raw 1
tpl 0
peerIDsH:
role:
chn 1
tmpl:
Attributes:
model HM-ES-TX-WM
peerIDs peerUnread
room AA,Alle,System
userReadings state {"W: " .ReadingsVal("Strom_IEC_01","energyIEC",0)/10000 ." P: " .ReadingsVal("Strom_IEC_01","powerIEC",0)/100}
Zitat von: gichtl am 25 Mai 2021, 23:06:02
2) Das Reading "state" (nicht STATE) hat nicht existiert, daher hagge ich auch bewußt das userReadings so gesetzt, vgl. auch https://forum.fhem.de/index.php?topic=74380.0
Nur damit sieht man in der Übersicht den Momentanwert, was bei einem anderen reading namen nicht der Fall wäre.
STATE ist KEIN Reading!
Und mich würde wundern, wenn das Device ohne dein userReadings KEIN Reading state hätte...
Und dass man das in der Übersicht nicht sieht/sehen würde ist Quatsch: stateFormat
Ansonsten hat Frank ja alles geschrieben was "überarbeitungswürdig" ist ;)
Gruß, Joachim
Daß es hier nicht um STATE geht hatte ich ja bereits geschrieben.
Für stateFormat müßte im Gegensatz zum userReading zusätzlich auch noch addStateEvent gesetzt werden um einen logbaren Event zu bekommen.
Nochmal zurück zur Antwort von frank:
1) das userReading wird bei jedem Event getriggert. Das ist jedoch exakt das was ich will, also einen Event für jeden übermittelten Zählerstand+Momentanleistung.
2) das existierende reading state vom device habe ich gar nicht genutzt, ich verwende stattdessen state vom Channel 1 (Strombezug)
Ich habe daher wie in der ersten Antwort vorgeschlagen ein event-on-change-reading auf state gesetzt und damit die mehrfach empfangenen identischen Zählerstände zumindest oberflächlich abgefangen. Das funktioniert wie gewünscht.
Was du bzgl. stateFormat von dir gibst ist ebenso Quatsch.
Und das kann ich so nicht stehen lassen...
(und DU nicht ich sprach vom READING namens STATE ;) )
Ich würde empfehlen mal in der commadref zu userReadings, stateFormat und FileLog zu lesen.
Du kannst auch jedes andere Reading zur"Anzeige" in STATE nehmen und ebenso jedes andere Reading loggen.
attr Device stateFormat beliebigesReading
Und schon wird das in STATE "angezeigt"...
Loggen genauso, einfach RegEx entsprechend setzen...
Ebenso was frank (und ich) bzgl. Trigger beim userReadings geschrieben haben gilt...
ABER: jedem seine Meinung und jedem sein System...
Viel Spaß, Joachim
ich zähle 7 events pro zyklus vom chn.
da hätte ich jetzt auch 7x state events erwartet.
vielleicht ein fhem schutzmechanismus, oder wegen dem speziellen state reading.
interessanter wären natürlich die events gewesen, wenn es nicht gut läuft. ;)
zeig mal noch ein list vom hauptdevice.
@MadMax-FHEM:
Wo sprach ich von einem READGING namens STATE? Ich habe mich ausschließlich auf das Reading "state" bezogen und explizit NICHT auf STATE. 8)
Für den Gaszähler (vom selben Typ) zeige ich den Zählerstand tatsächlich per stateFormat an. Allerdings wird allein dadurch noch kein Event erzeugt. Und somit hilft ein beliebiges RegEx auch nicht um STATE geloggt zu bekommen. Aber ich möchte in dem speziellen Fall den Zählerstand auch gar nicht im Log haben, daher ist das für mich wunderbar okay.
@frank:
Im Schlechtfall sehen die Events genau so aus, nur daß die eben n-Mal mit identischer Payload zu verschiedenen Zeitpunkten auftauchen.
Ideal wäre wenn man dem HM-ES-TX-WM diese Retransmits aufgrund dem vermutlich fehlenden ACK abgewöhnen könnte so daß die verworfen werden und stattdessen beim nächsten Transmit-Cycle die nächsten aktuellen Werte geliefert werden. Der transmDevTryMax im Device steht hingegen schon auf dem kleinsten Wert 1. Das müßte vermutlich eine 0 sein damit er keinen Retransmit schickt, was aber außerhalb vom Range liegt.
powerSensor - transmDevTryMax range:1 to 10 : max message re-transmit
list Strom
Internals:
DEF 4D15AA
FUUID 60815fe0-f33f-8590-0ed9-77b3c55985d2c8e5
HMLAN1_MSGCNT 1155
HMLAN1_RAWMSG E4D15AA,0000,040B8D28,FF,FF99,EF86604D15AA000000420100000000000000000000
HMLAN1_RSSI -103
HMLAN1_TIME 2021-05-26 18:54:04
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 1155
NAME Strom
NOTIFYDEV global
NR 361
NTFY_ORDER 50-Strom
STATE CMDs_done
TYPE CUL_HM
channel_01 Strom_IEC_01
channel_02 Strom_IEC_02
lastMsg No:EF - t:60 s:4D15AA d:000000 420100000000000000000000
protLastRcv 2021-05-26 18:54:04
protRcv 1148 last_at:2021-05-26 18:54:04
protResnd 3 last_at:2021-05-26 09:25:48
protSnd 44 last_at:2021-05-26 18:32:40
protState CMDs_done
rssi_at_HMLAN1 cnt:1155 min:-109 max:-97 avg:-100.31 lst:-103
READINGS:
2021-05-25 20:51:53 Activity alive
2021-05-26 09:25:42 CommandAccepted yes
2021-04-22 15:03:53 D-firmware 2.5
2021-04-22 15:03:53 D-serialNr NEQ0863362
2021-05-25 17:11:53 IODev HMLAN1
2021-05-25 16:05:50 PairedTo 0x157897
2021-04-22 14:37:15 R-baudrate Bd9600
2021-04-22 15:01:25 R-pairCentral 0x157897
2021-04-22 14:37:15 R-powerMode mainPower
2021-04-22 14:37:15 R-protocolMode modeSML
2021-05-25 16:05:50 R-samplPerCycl 1
2021-04-22 14:37:15 R-serialFormat s8D0PN1S
2021-05-25 16:05:50 R-transmDevTryMax 1
2021-05-25 20:32:19 RegL_00.
2021-05-26 18:54:04 battery ok
2021-05-25 19:54:40 cfgState updating
2021-05-26 18:32:40 commState CMDs_done
2021-05-24 04:02:08 powerOn 2021-05-24 04:02:08
2021-05-26 18:32:40 state CMDs_done
helper:
HM_CMDNR 239
cSnd 011578974D15AA02040000000001,011578974D15AA02040000000001
mId 00DE
peerFriend -
peerOpt -:powerSensor
regLst 0
rxType 12
supp_Pair_Rep 0
cmds:
TmplKey :no:1621955513.77173
TmplTs 1621955513.77173
cmdKey 0:1:0::Strom:00DE: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
text -txt1- [-txt2-]
tplDel -tplDel-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
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 1
raw 1
tpl 0
io:
flgs 0
newChn +4D15AA,00,00,00
nextSend 1622048044.72462
rxt 2
vccu VCCU
p:
4D15AA
00
00
00
prefIO:
HMLAN1
mRssi:
mNo EF
io:
HMLAN1:
-101
-101
peerIDsH:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
rssi:
at_HMLAN1:
avg -100.318614718615
cnt 1155
lst -103
max -97
min -109
tmpl:
Attributes:
IODev HMLAN1
IOgrp VCCU:HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert allReg,rawReg
firmware 2.5
model HM-ES-TX-WM
room Alle,System
serialNr NEQ0863362
subType powerSensor
Zitat
2) Das Reading "state" (nicht STATE) hat
Liest es sich halt wie: Reading state nicht Reading STATE... ;)
Ich wollte nur Sicherstellen, dass eben klar ist, dass STATE kein Reading ist, sondern ein Internal... :)
Und ein userReadings loggen geht ganz einfach, sofern man das möchte.
Da muss man kein Reading state "verbiegen"...
Ebensowenig um es im STATE anzuzeigen...
Wie (mehrfach) geschrieben: nur zur Klarstellung (für Mitleser)...
Gruß, Joachim
ZitatIch wollte nur Sicherstellen, dass eben klar ist, dass STATE kein Reading ist, sondern ein Internal...
... exakt das wollte ich auch 8)
Ein userReading zu loggen ist wie jedes andere reading auch gar nicht das Problem, auch nicht per stateFormat den STATE anzupassen. Nur bekommt man eben für den STATE keinen Event und somit den nicht direkt geloggt.