Hallo,
ich habe mehrere HM-Funksteckdosen mit Leistungsmessung HM-ES-PMSw1-Pl.
Ein get Device reglist liefert nur noch:
list: register | range | peer | description
0: confBtnTime | 1 to 255min | | 255=permanent special:permanent
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
sowie get Device_Pwr reglist
list: register | range | peer | description
1: sign | literal | | signature (AES) options:off,on
1: statusInfoMinDly | 0.0 to 15.5s | | status message min delay special:unused
1: statusInfoRandom | 0 to 7s | | status message random delay
1: transmitTryMax | 1 to 10 | | max message re-transmit
und get Device_Sw reglist
list: register | range | peer | description
1: sign | literal | | signature (AES) options:off,on
1: statusInfoMinDly | 0.0 to 15.5s | | status message min delay special:unused
1: statusInfoRandom | 0 to 7s | | status message random delay
1: transmitTryMax | 1 to 10 | | max message re-transmit
Insbesondere nutze ich beim Schalterkanal das Register powerUpAction, das ich zwar weiterhin setzen und im Webinterface auch mit get abfragen kann, aber das Reading R-powerUpAction fehlt wie auch die ganzen anderen Registerreadings (auch im Leistungsmessungskanal).
Es kann sein, dass das schon eine ganze Weile so ist, die Funktionen werden hier selten gebraucht. Konkret handelt es sich um einen Watchdog, der schaut, ob die Dose in den letzten 36 Stunden durchgängig an war (z.B. um einen Rasenroboter daran zu betreiben) und setzt das Register nötigenfalls auf "on", damit der Roboter nach einem Stromausfall wieder geladen wird:
define watchdog_St_aussen_powerup_on watchdog Steckdose_aussen:on 36:00:00 Steckdose_aussen:off {if (ReadingsVal("Steckdose_aussen","R-powerUpAction","") eq "off")
Oder es ist eben Winter und an der Dose ist nichts oder die Weihnachtsbaumbeleuchtung, die täglich geschaltet wird und die nach Stromausfall aus bleiben soll:
define watchdog_St_aussen_powerup_off watchdog Steckdose_aussen:off 36:00:00 Steckdose_aussen:on {if (ReadingsVal("Steckdose_aussen","R-powerUpAction","") eq "on") {fhem("set Steckdose_aussen regSet powerUpAction off")}}
Die Abfrage hat den Zweck, die Register-Schreibzugriffe (Flash-Speicher!) zu reduzieren (nur, wenn es was zu ändern gibt, denn der watchhdog läuft auch nach jedem FHEM-Neustart los). Ohne das besagte Register funktioniert diese Abfrage natürlich nicht mehr. Das ging jahrelang tadellos und plötzlich nicht mehr. Woran kann das liegen? Wo sind die ganzen Register-Readings hin?
Zum Abrufen der Register ist es ein get-Befehl und kein set-Befehl (aber vermutlich nur falsch beschrieben ;) )
Was steht denn beim Attribut "expert"?
Setzte das mal auf 1_allReg (wenn es schon auf 1_allReg steht, dann ist es komisch)
Zukünftig besser komplette lists von Devices die "gestört" sind...
Gruß, Joachim
Danke. Ja, natürlich get, das war ein Vertipper. Ich habe das korrigiert.
So, jetzt habe ich ein paar Dinge herausgefunden. Das expert-Attribut war nicht gesetzt, mit 1_allReg erscheinen alle Register wieder, AUSSER dem R-powerUpAction.
Mit dem Befehl get regTable erhalte ich (unabhängig davon) alles, was ich brauche:
No regs found for:
Steckdose_aussen type:powerMeter -
list:peer register :value
1: powerUpAction :off
1: sign :off
1: statusInfoMinDly :2 s
1: statusInfoRandom :1 s
1: transmitTryMax :6
self01
lg sh
ActionType jmpToTarget jmpToTarget
CtDlyOff geLo geLo
CtDlyOn geLo geLo
CtOff geLo geLo
CtOn geLo geLo
CtValHi 100 100
CtValLo 50 50
MultiExec on off
OffDly [s] 0 0
OffTime unused unused
OffTimeMode absolut absolut
OnDly [s] 0 0
OnTime unused unused
OnTimeMode absolut absolut
SwJtDlyOff off off
SwJtDlyOn on on
SwJtOff dlyOn dlyOn
SwJtOn dlyOff dlyOff
Das Register ist da und zeigt den richtigen Zustand an. Es fehlt nur das passende Reading dafür, weshalb ich dieses nicht mit
{ReadingsVal("Steckdose_aussen","R-powerUpAction","")} abfragen kann. Bevor ich gestern ein clear readings gemacht habe, stand (in FHEM) noch ein alter Wert von 2017 drin, den hat das ReadingsVal immer ermittelt. Da stand dann immer "on", egal, was eingestellt war, weshalb ich das lange nicht bemerkt habe.
Ich habe die anderen baugleichen Dosen verglichen, da ist es genau so.
Hier ist ein Listing des Kanals (das Device heißt Steckdose_aussen_HM und der zugehörige Sw-Kanal nur Steckdose_aussen)
Internals:
DEF 4B2E3456
FUUID 5d4230b0-f33f-9cc2-2900-78aa904xxxy39f85
NAME Steckdose_aussen
NOTIFYDEV global
NR 665
NTFY_ORDER 50-Steckdose_aussen
STATE on
TYPE CUL_HM
chanNo 01
device Steckdose_aussen_HM
peerList self01,
READINGS:
2019-08-11 12:00:18 R-sign off
2019-08-11 12:00:18 R-statusInfoMinDly 2 s
2019-08-11 12:00:18 R-statusInfoRandom 1 s
2019-08-11 12:00:18 R-transmitTryMax 6
2019-08-11 12:00:12 deviceMsg on (to vccu)
2019-08-11 12:00:12 level 100
2019-08-11 12:00:12 pct 100
2019-08-11 12:00:18 peerList self01,
2019-08-11 12:00:12 recentStateType info
2019-08-11 12:00:12 state on
2019-08-11 12:00:12 timedOn off
helper:
cfgChkResult No regs found for:
Steckdose_aussen type:powerMeter -
list:peer register :value
1: powerUpAction :off
1: sign :off
1: statusInfoMinDly :2 s
1: statusInfoRandom :1 s
1: transmitTryMax :6
self01
lg sh
ActionType jmpToTarget jmpToTarget
CtDlyOff geLo geLo
CtDlyOn geLo geLo
CtOff geLo geLo
CtOn geLo geLo
CtValHi 100 100
CtValLo 50 50
MultiExec on off
OffDly [s] 0 0
OffTime unused unused
OffTimeMode absolut absolut
OnDly [s] 0 0
OnTime unused unused
OnTimeMode absolut absolut
SwJtDlyOff off off
SwJtDlyOn on on
SwJtOff dlyOn dlyOn
SwJtOn dlyOff dlyOff
dlvl C8
dlvlCmd ++A0112577B14B2E930201C80000
peerFriend peerSens,peerVirt
peerIDsRaw ,4B2E3456,00000000
peerOpt 3:powerMeter
regLst 1,3p
expert:
def 1
det 1
raw 0
tpl 0
regCollect:
role:
chn 1
shadowReg:
tmpl:
nb:
cnt 8
Attributes:
devStateIcon .*on:on_aussendose .*off:off_aussendose
expert 1_allReg
fp_FPDisplay1 465,625,0
group Stromversorgung
model HM-ES-PMSw1-Pl
peerIDs 00000000,4B2E3456,
room Aussenbereich,Rasenroboter
und hier vom Device
Internals:
DEF 4B2E34
FUUID 5d4230b0-f33f-9cc2-10e7-ea096exxxy024b5e
HMLAN1_MSGCNT 5959
HMLAN1_RAWMSG E4B2E34,0000,1A68968C,FF,FFB7,48845E4B2E3400000082511B0001400026093501
HMLAN1_RSSI -73
HMLAN1_TIME 2019-08-11 12:17:44
HMLAN2_MSGCNT 21
HMLAN2_RAWMSG E4B2E34,0000,25634516,FF,FFB6,3DA0104B2E342577440100000000
HMLAN2_RSSI -74
HMLAN2_TIME 2019-08-01 02:23:08
HMUART1_MSGCNT 5959
HMUART1_RAWMSG 0500004248845E4B2E3400000082511B0001400026093501
HMUART1_RSSI -66
HMUART1_TIME 2019-08-11 12:17:44
IODev HMUART1
LASTInputDev HMLAN1
MSGCNT 11939
NAME Steckdose_aussen_HM
NOTIFYDEV global
NR 657
NTFY_ORDER 50-Steckdose_aussen_HM
STATE CMDs_done
TYPE CUL_HM
channel_01 Steckdose_aussen
channel_02 Steckdose_aussen_HM_Pwr
channel_03 Steckdose_aussen_HM_SenPwr
channel_04 Steckdose_aussen_HM_SenI
channel_05 Steckdose_aussen_HM_SenU
channel_06 Steckdose_aussen_HM_SenF
lastMsg No:48 - t:5E s:4B2E34 d:000000 82511B0001400026093501
protLastRcv 2019-08-11 12:17:44
protRcv 5985 last_at:2019-08-11 12:17:44
protSnd 137 last_at:2019-08-11 12:00:19
protState CMDs_done
rssi_HMUART1 cnt:6 min:-71 max:-65 avg:-68.83 lst:-65
rssi_at_HMLAN1 cnt:5959 min:-79 max:-67 avg:-70.66 lst:-73
rssi_at_HMLAN2 cnt:21 min:-75 max:-74 avg:-74.23 lst:-74
rssi_at_HMUART1 cnt:5959 min:-76 max:-63 avg:-67.9 lst:-66
READINGS:
2019-08-01 02:22:16 Activity alive
2019-08-11 11:50:53 CommandAccepted yes
2016-11-05 19:18:03 D-firmware 2.5
2016-11-05 19:18:03 D-serialNr NEQ0387654
2019-06-21 20:20:06 PairedTo 0x257744
2019-06-21 20:20:06 R-confBtnTime permanent
2016-11-05 19:18:27 R-intKeyVisib visib
2016-11-05 19:18:27 R-localResDis off
2016-11-05 19:18:27 R-pairCentral 0x257744
2018-11-21 17:22:39 powerOn 2018-11-21 17:22:39
2019-06-21 20:15:10 sabotageAttackId_ErrIoId_F10000 cnt:24
2019-07-03 22:16:30 sabotageAttack_ErrIoAttack cnt 3
2019-08-11 12:00:19 state CMDs_done
helper:
HM_CMDNR 72
cSnd 012577444B2E340103,012577444B2E3401044B2E340103
mId 00AC
peerFriend
peerOpt -:powerMeter
regLst 0
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 1
raw 0
tpl 0
io:
newChn +4B2E34,00,02,00
nextSend 1565518664.47414
prefIO
rxt 0
vccu vccu
p:
4B2E34
00
02
00
mRssi:
mNo 48
io:
HMLAN1:
-73
-73
HMLAN2:
HMUART1:
-62
-62
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
HMUART1:
avg -68.8333333333333
cnt 6
lst -65
max -65
min -71
at_HMLAN1:
avg -70.669071991945
cnt 5959
lst -73
max -67
min -79
at_HMLAN2:
avg -74.2380952380953
cnt 21
lst -74
max -74
min -75
at_HMUART1:
avg -67.9001510320522
cnt 5959
lst -66
max -63
min -76
shadowReg:
RegL_00. 00:00 02:81 0A:25 0B:77 0C:B1 15:FF 18:00
tmpl:
Attributes:
IODev HMLAN1
IOgrp vccu
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
event-on-change-reading .*
expert 1_allReg
firmware 2.5
group °Steckdosen
model HM-ES-PMSw1-Pl
room Rasenroboter
serialNr NEQ0387654
subType powerMeter
webCmd getConfig:clear msgEvents
Also habe eben geschaut, das R-powerUpAction Reading steht im Kanal sw (switch).
Wie aktuell ist dein fhem?
Weil mittlerweile die models alle mit Großbuchstaben sind (hat aber verm. nichts mit dem Problem zu tun):
HM-ES-PMSw1-Pl (bei dir)
HM-ES-PMSW1-PL (bei mir)
Welche FW haben deine Steckdosen?
Weil das Feature gibt es ja erst mit FW2.5 (ok, steht im Device und passt)
Hast du mal ein getConfig gemacht, dadurch werden die Register ausgelesen (und das R-powerUpAction, wie an dem "R-" zu sehen ist, ist ein Register im Gerät was ausgelesen und dann angezeigt wird)...
Gruß, Joachim
Hi,
und wenn Du als Workaround? das Register direkt abfragst anstatt das Reading?
Beispiel:
{fhem("get PSD3_Sw reg powerUpAction")}
Gruß Otto
Zitat von: Otto123 am 11 August 2019, 12:38:08
{fhem("get PSD3_Sw reg powerUpAction")}
Hallo Otto,
Sachen gibt's... ;)
Man lernt nie aus... :)
Gruß, Joachim
vielleicht kommt das reading mit attr expert 251_anything.
Komischerweise finde ich keine Möglichkeit das direkt in FHEM ohne Perl Syntax zur Anwendung zu bringen :(
Also sowas geht set LichtKuL {(fhem("get PSD3_Sw reg powerUpAction"))} aber ohne {(fhem(""))} gelingt es mir nicht.
Ist wahrscheinlich nicht vorgesehen :)
Gruß Otto
Zitat von: frank am 11 August 2019, 12:56:39
vielleicht kommt das reading mit attr expert 251_anything.
1_allReg reicht bei mir ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 11 August 2019, 13:11:41
1_allReg reicht bei mir ;)
Gruß, Joachim
kann ich auch bestätigen. Ich habe auch mal mutig clear readings gemacht. Mein R-powerUpAction Reading war von 2016 :) nach einem getConfig ist es wieder da und auch aktuell.
Gruß Otto
Vermutlich (wie bereits angemerkt) fehlt das noch beim TE:
Zitat von: Otto123 am 11 August 2019, 13:41:56
kann ich auch bestätigen. Ich habe auch mal mutig clear readings gemacht. Mein R-powerUpAction Reading war von 2016 :) nach einem getConfig ist es wieder da und auch aktuell.
Gruß Otto
Gruß, Joachim
die Registerliste ist schon komplett.
Allerdings wundert mich das Model "HM-ES-PMSw1-Pl".
Beim Booten sollte "HM-ES-PMSW1-PL" ( alles Großbuchstaben ) eingestellt werden.
Grundsätzlich ist das Attribut "model" nun in Großbuchstaben.
Wie schaffst du es, hier kleine Buchstaben unterzubringen?
Da ist er wieder! Danke!
Natürlich hatte ich getConfig gemacht und auch expert 251_anything versucht. Das war es aber nicht. FHEM ist auch aktuell.
... Besen, Besen sei es gewesen... Der Meister hat mich darauf gebracht. MadMax hat es bereits bemerkt, aber auch ich habe das als nicht entscheidend angesehen. ;)
Meine Konfiguration ist schon eine Weile alt und ich bin noch ein Dinosaurier, der alles in der fhem.cfg zu stehen hat. Dort wird beim FHEM-Start dem Device (noch von früher)
attr Steckdose_aussen_HM model HM-ES-PMSw1-Pl
(mit Kleinbuchstaben) zugewiesen. Interessanterweise hat FHEM das prinzipiell als das richtige Modell übernommen und läßt sogar von der Weboberfläche aus keine Änderung zum richtigen (Großbuchstaben) zu. Das Attribut zu löschen bringt nichts, dann weiß FHEM gar nicht, was das ist. Ich habe in der HMConfig.pm nachgesehen, wie es richtig heißen muss und das Attribut in der fhem.cfg berichtigt:
attr Steckdose_aussen_HM model HM-ES-PMSW1-PL
Nach einem getConfig auf Deviceebene war alles wieder da.
Sind nun alle HM-Devices komplett in Großbuchstaben? Ich werde daraufhin meine Config nochmal durchsehen müssen.
Danke Euch. Ottos direkte Registerabfrage kannte ich auch noch nicht, danke.