Hallo alle,
ich betreibe seit Jahren FHEM auf einem Raspi und habe diversen Sensoren und Aktoren in Betrieb. NUn wollte ich heute zwei neue Diff. Temp. Sensoren pairen (HM-WDS30-OT2-SM) und komme einfach nicht zurecht damit. Generell betreibe ich das System über ein Funkmodul als IO Device im Raspi und einer VCCU. Nun habe ich die beiden Sensoren über "set VCCU hmPairForSec 1000" gepaired und sie werden auch erkannt. Allerdings bekomme ich statt Temperaturwerten nur "???" und im Channel 5 steht T:0,5. Hat jemand eine Idee woran das liegen kann? IOgroup ist VCCU:HMLAN1 ... Welche Infos bräuchtet Ihr noch, um das beurteilen zu können? Vielen Dank für Eure Hilfe!!
Grüße
Zitat von: foly12 am 27 Dezember 2020, 22:45:59
Welche Infos bräuchtet Ihr noch, um das beurteilen zu können?
Wie immer: siehe https://forum.fhem.de/index.php/topic,71806.0.html
Hi,
ein list von dem HM-WDS30-OT2-SM wäre hilfreich.
Gruß Otto
Hier der List dazu:
Internals:
CFGFN
DEF 4BDBF0
FUUID 5fe8fe8a-f33f-004e-2974-183d13fcdd1d32f0
HMLAN1_MSGCNT 22
HMLAN1_RAWMSG 050000411686704BDBF0000000000564
HMLAN1_RSSI -65
HMLAN1_TIME 2020-12-27 23:28:49
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 22
NAME HM_4BDBF0
NOTIFYDEV global
NR 285
STATE T: 0.5
TYPE CUL_HM
channel_01 HM_4BDBF0_T1
channel_02 HM_4BDBF0_T2
channel_03 HM_4BDBF0_T1_T2
channel_04 HM_4BDBF0_T2_T1
channel_05 HM_4BDBF0_Event
lastMsg No:16 - t:70 s:4BDBF0 d:000000 000564
protCmdDel 10
protLastRcv 2020-12-27 23:28:49
protRcv 23 last_at:2020-12-27 23:28:49
protResnd 3 last_at:2020-12-27 22:43:08
protResndFail 1 last_at:2020-12-27 22:46:05
protSnd 4 last_at:2020-12-27 22:46:00
protState CMDs_done_Errors:1
rssi_at_HMLAN1 cnt:23 min:-71 max:-64 avg:-65.47 lst:-65
READINGS:
2020-12-27 22:37:14 D-firmware 1.1
2020-12-27 22:37:14 D-serialNr NEQ0533006
2020-12-27 23:28:49 battery ok
2020-12-27 22:38:39 cfgState updating
2020-12-27 22:46:05 commState CMDs_done_Errors:1
2020-12-27 23:28:49 state T: 0.5
2020-12-27 23:28:49 temperature 0.5
helper:
HM_CMDNR 22
PONtest 1
mId 00A8
peerFriend
peerOpt -:THSensor
regLst 0
rxType 140
supp_Pair_Rep 0
cfgChk:
idRc01 RegL_00.
cmds:
TmplKey :no:1609105039.62218
TmplTs 1609105039.62218
cmdKey 0:1:0::HM_4BDBF0:00A8:01:
cmdLst:
assignHmKey noArg
burstXmit 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) [-peerChn-]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
tplSet_0 -tplChan-
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 0
det 0
raw 1
tpl 0
io:
newChn +4BDBF0,00,00,00
nextSend 1609108129.59298
prefIO
rxt 2
vccu
p:
4BDBF0
00
00
00
mRssi:
mNo 16
io:
HMLAN1:
-61
-61
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
rssi:
at_HMLAN1:
avg -65.4782608695652
cnt 23
lst -65
max -64
min -71
shadowReg:
RegL_00. 02:01 0A:2C 0B:D9 0C:F7
tmpl:
Attributes:
IODev HMLAN1
IOgrp VCCU:HMLAN1
autoReadReg 4_reqStatus
expert rawReg
firmware 1.1
model HM-WDS30-OT2-SM
room CUL_HM
serialNr NEQ0533006
subType THSensor
webCmd getConfig:clear msgEvents
Viele Grüße
Foly
Anscheinend hat er Problemen, um die Konfiguration zu holen, bzw. das Pairing ist nicht vollständig.
Ggf das Pairing wiederholen (set vccu hmpairfordoc, dann auf Konfigtaste drucken)
Ansonsten, was steht in Kanal 1 oder 2 ("list")?
trotzdem ist die temp sicherlich richtig.
ich denke da wird die differenz temp aus chn3 oder chn4 gezeigt.
schau dir die temps in den 4 temp-channels an.
links sind ja in den internals.
ausserdem mach ein fhem update.
edit: fhem ist doch schon up to date.
Deswegen wollte ich ein list von Kanal 1 oder 2 sehen, da sie sagt: "Allerdings bekomme ich statt Temperaturwerten nur "? ? ?""
Nw:
Kanal1 = T1
Kanal2 = T2
Kanal3 = T1-T2
Kanal4 = T2-T1
Das Ding ist definitiv nicht fertig angelernt.
Dann hat dieser Sensor die Eigenheit im Hauptkanal (auch im state) den Differenzwert der beiden Sensoren anzuzeigen.
Also weiter anlernen ;) Knöpfchen drücken nicht vergessen. Daten übertragen...
Danke für Euren Support!!! ANbei ein List des Kanal 1 und Kanal 2.
Ich habe ihn nun mehrmals angelernt, incl. Reset des Sensors ... daran kanns m.E. nicht mehr liegen. Interessanterweise habe ich das Problem ja bei beiden neuen Sensoren. Der existierende Sensor funktioniert gut.
Internals:
CFGFN
DEF 4BDBF001
FUUID 5fe8fe8a-f33f-004e-c9da-1dee9f8594763d6d
NAME HM_4BDBF0_T1
NOTIFYDEV global
NR 287
STATE ???
TYPE CUL_HM
chanNo 01
device HM_4BDBF0
READINGS:
2020-12-27 22:38:39 cfgState updating
helper:
getCfgListNo
peerFriend
peerOpt p:THSensor
regLst
cmds:
TmplKey :no:1609105039.7783
TmplTs 1609105039.7783
cmdKey 1:0:0::HM_4BDBF0:00A8:01:
cmdLst:
burstXmit noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 -actChn- [({single})] [({set}|unset)] [actor|remote|both]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
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 0
det 0
raw 1
tpl 0
role:
chn 1
tmpl:
Attributes:
model HM-WDS30-OT2-SM
peerIDs ,
Kanal 2
Internals:
CFGFN
DEF 4BDBF002
FUUID 5fe8fe8a-f33f-004e-7968-ac5835e8ebcc63a2
NAME HM_4BDBF0_T2
NOTIFYDEV global
NR 288
STATE ???
TYPE CUL_HM
chanNo 02
device HM_4BDBF0
READINGS:
2020-12-27 22:38:39 cfgState updating
helper:
getCfgListNo
peerFriend
peerOpt p:THSensor
regLst
cmds:
TmplKey :no:1609105039.78573
TmplTs 1609105039.78573
cmdKey 1:0:0::HM_4BDBF0:00A8:02:
cmdLst:
burstXmit noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 -actChn- [({single})] [({set}|unset)] [actor|remote|both]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
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 0
det 0
raw 1
tpl 0
role:
chn 1
tmpl:
Attributes:
model HM-WDS30-OT2-SM
peerIDs ,
Zitat von: foly12 am 28 Dezember 2020, 09:34:41
Danke für Euren Support!!! ANbei ein List des Kanal 1 und Kanal 2.
Ich habe ihn nun mehrmals angelernt, incl. Reset des Sensors ... daran kanns m.E. nicht mehr liegen. Interessanterweise habe ich das Problem ja bei beiden neuen Sensoren. Der existierende Sensor funktioniert gut.
Solange er nicht richtig angelernt ist, funktioniert die Anzeige in FHEM auch nicht richtig.
Reset bringt keine Vorteile, löschen auch nicht.
Angelernt ist erst, wenn hminfo nicht meckert oder die Readings R-pairCentral und PairedTo mit der eigenen hmId gefüllt sind!
set VCCU hmPairForSec 120Dann etwas warten
configtaster am Sensor drücken (der liegt innen!!!)
Warten bis CMDs_done im STATE erscheint.
Wenn die obengenannten Readings noch nicht da sind:
Nochmal das Ganze - mit Ruhe! Ohne Reset, mit Ruhe, Knöpfchen drücken und LED beobachten.
Hallo Otto123,
jetzt habe ich bei jedem Sensor nochmal mind. 5x den Pairing Vorgang gestartet und allen Geräten dafür lange Zeit gegeben und beim x-ten Mal hat es nun tatsächlich funktioniert. Danke für die Tipps! Ich habe schon einige Geräte ins System gebracht, bisher hat es immer gleich funktioniert... da war mir nicht klar, dass es auch relativ viele Versuche sein können bis es klappt. Wieder etwas dazu gelernt! Danke Dir und einen guten Rutsch!
Grüße
Foly
Hallo Foly,
was hast Du für Homematic für IOs wenn ich fragen darf? Was ist HMLAN1 für Hardware?
Normal wäre ein- bis zweimal anlernen. Mehr deutet eigentlich auf Probleme mit dem IO hin.
Guten Rutsch
Otto
Hallo Otto123,
ich habe einen Raspi 2 mit HM-MOD-RPI-PCB...
Das Ganze geht jetzt weiter, soll ich dafür einen neuen Thread aufmachen? - Jetzt habe ich zwei Sensoren angelernt und einer funktioniert tadellos. Der andere ist angelernt, liefert auch Temperaturen, nach ca. 10 min funktioniert er allerdings nicht mehr. Ich habe die neuen Batterien gegen andere neue Batterien ausgetauscht, daran lags nicht. Jedesmal wenn ich die Batterien kurz entferne und wieder einsetze, ist der Sensor wieder da. ANch ein paar Minuten ist er aber wieder weg. Wenn ich dann die Pairingtaste drücke blinkt nichts mehr, bis ich wieder die Batterien kurz entferne... diesmal ist wirklich der Wurm drin. Was könnte das denn wieder sein?
Viele Grüße und Danke!
Foly12
CFGFN
DEF 707312
FUUID 5fec61e7-f33f-004e-58e6-11b6f37973dba425
HMLAN1_MSGCNT 110
HMLAN1_RAWMSG 0403002FAB80027073122CD9F700
HMLAN1_RSSI -47
HMLAN1_TIME 2020-12-30 17:39:45
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 110
NAME TS_Wohnzimmer
NOTIFYDEV global
NR 1710
STATE CMDs_pending
TYPE CUL_HM
chanNo 01
channel_01 TS_Wohnzimmer_T1
channel_02 TS_Wohnzimmer_T2
channel_03 TS_Wohnzimmer_T1_T2
channel_04 TS_Wohnzimmer_T2_T1
channel_05 TS_Wohnzimmer_Event
lastMsg No:AB - t:02 s:707312 d:2CD9F7 00
protCmdPend 6 CMDs_pending
protLastRcv 2020-12-30 17:39:45
protRcv 110 last_at:2020-12-30 17:39:45
protSnd 161 last_at:2020-12-30 17:39:45
protState CMDs_pending
rssi_at_HMLAN1 cnt:111 min:-75 max:-34 avg:-46.72 lst:-47
READINGS:
2020-12-30 17:39:45 CommandAccepted yes
2020-12-30 17:39:44 D-firmware 1.1
2020-12-30 17:39:44 D-serialNr REQ0101311
2020-12-30 17:34:26 PairedTo 0x2CD9F7
2020-12-30 17:34:25 battery ok
2020-12-30 17:40:14 cfgState RegMiss
2020-12-30 17:40:12 commState CMDs_pending
2020-12-30 17:39:04 powerOn 2020-12-30 17:39:04
2020-12-30 17:39:04 recentStateType info
2020-12-30 17:40:12 state CMDs_pending
cmdStack:
++A0012CD9F770731200040000000000
++A0012CD9F77073120103
++A0012CD9F77073120203
++A0012CD9F77073120303
++A0012CD9F77073120403
++A0012CD9F77073120503
helper:
HM_CMDNR 171
PONtest 0
cSnd 012CD9F7707312000802010A2C0BD90CF7,012CD9F77073120006
mId 00A8
peerFriend
peerOpt -:THSensor
regLst 0
rxType 140
supp_Pair_Rep 0
cfgChk:
idRc01 RegL_00.
cmds:
TmplKey :no:1609346389.73318
TmplTs 1609346389.73318
cmdKey 0:1:0::TS_Wohnzimmer:00A8:01:
cmdLst:
assignHmKey noArg
burstXmit 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) [-peerChn-]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
tplSet_0 -tplChan-
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 0
det 0
raw 1
tpl 0
io:
newChn +707312,02,00,00
nextSend 1609346385.5422
prefIO
rxt 2
vccu
p:
707312
00
00
00
mRssi:
mNo AB
io:
HMLAN1:
-39
-39
prt:
bErr 0
sProc 2
sleeping 1
try 1
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
rssi:
at_HMLAN1:
avg -46.7207207207207
cnt 111
lst -47
max -34
min -75
shadowReg:
RegL_00. 02:01 0A:2C 0B:D9 0C:F7
tmpl:
Attributes:
IODev HMLAN1
IOgrp VCCU:HMLAN1
autoReadReg 4_reqStatus
expert rawReg
firmware 1.1
model HM-WDS30-OT2-SM
room CUL_HM
serialNr REQ0101311
subType THSensor
webCmd getConfig:clear msgEvents
klingt nach defekt
Hallo Foly12,
setz mal das Attribut autoReadReg auf 0_off, dann lösch die Command Queue mit set clear msgEvents.
Danach wieder Batterien raus und wieder rein, sofern die noch Spannung haben. Wenn er dann durchläuft, hat er sich nur beim Abarbeiten der Queue aufgehangen (und voll wach Strom gefressen, daher Batterien checken).
Da ist er sensibel in der Firmware.
HMInfo wird dann sicher meckern, die fehlenden Daten stören aber nicht den Empfang der Temperaturen.
Wenn's das nicht ist, dann bleibt nur noch Hardware. War es ein Bausatz, dann ggf. Lötfehler checken?!
Gruß, Ansgar.
Mir machen die scheinbar generellen Schwierigkeiten an sich noch Sorgen: Hast Du die Stromversorgung des Pi mit dem mitgeliefertem Ferritkern versorgt?
@noansi: Das könnte es gewesen sein. Mittlerweile läuft der Sensor seit 1h ... muss ich noch weiter beobachten, aber bisher kam er bei weitem nicht so weit... Danke!!!
Will das nur verstehen, was ist denn der Grund warum das Teil sich bisher abgeschaltet hat? Und wenn ich jetzt bei diesem Sensor das Attribut verstellen muss, was macht ihn so speziell? Ich habe 6 von den Sensoren eingebunden, die anderen funktionieren ohne das Attr.?
haben alle die selbe fw?
Hallo foly12,
ZitatWill das nur verstehen, was ist denn der Grund
Da sind wir schon mindestens zwei. ;)
Ich kann nur mutmaßen, dass die Firmware bezüglich wakup/lazy config einen Bug hat und sich irgendwo festfrist, möglicherweise dauerhaft munter auf was wartend, was nicht kommt.
Zitatwarum das Teil sich bisher abgeschaltet hat?
Abgeschaltet wäre ja schön gewesen, aber ein ausgelaufener frischer Batteriesatz hat mich recht überraschend davon überzeugt, dass es ein
dauerhaft eingeschaltet war, (nebst anschließendem Strom messen).
Ich habe allerdings das Wakeup/Lazy Config in der CUL_HM Sondervariante für tsculfw etwas abgewandelt und damit scheint es zu funktionieren. Dennoch riskiere ich es nicht nochmal, AutoReadReg auf die Sensoren los zu lassen. Die Platine hatte ziemlich gelitten.
Hilft Dir aber erst mal nicht. Du hast keinen CUL oder CUL Derivat.
ZitatIch habe 6 von den Sensoren eingebunden, die anderen funktionieren ohne das Attr.?
Dann sei froh, wenn Du von denen alle Registerwerte hast und die auch gesichert sind und setzt auch bei denen das Attribut autoReadReg auf 0_off.
ZitatUnd wenn ich jetzt bei diesem Sensor das Attribut verstellen muss
Wenn ich es noch ganz schwach richtig im Kopf habe, einmal getConfig am device absetzten, dann Taste am Sensor. Beten, dass die Registerwerte alle gelesen werden. Wenn nicht queue löschen und das Spiel von vorne.
Wenn alle Registerwerte gelesen sind, sicherheitshalber nochmal Batterien raus und wieder rein. Und saveConfig.
Wenn die Registerwerte da sind, dann kannst Du Registerwerte ändern oder peeren.
Vermutlich auch dann wieder mit Taste arbeiten, beten, wenns geklappt hat Batteriereset... . Ich hab die nie gepeert oder Register ändern müssen, vermute daher nur, dass es zu gleichen Problemen kommen kann.
Wenn die Sensoren nur Temperaturdaten senden müssen (was bei autoReadReg=0_off der Fall ist), dann tun sie das aber sehr zuverlässig, bis die Batterien leer sind.
Gruß, Ansgar.
Danke Ansgar,
das erklärt vielleicht auch ein ähnliches Verhalten, was ich bei einem WDS10 mal beim letzten Batteriewechsel hatte. Da hatte ich die Flugbahn in die Tonne schon berechnet. Aber er lebt noch :)
Guten Rutsch
otto
Hallo Otto,
Zitatdas erklärt vielleicht auch ein ähnliches Verhalten, was ich bei einem WDS10 mal beim letzten Batteriewechsel hatte.
Einen HM-WDS40-TH-I-2 habe ich auch mal zum Aussteigen gebracht. Da kannte ich aber schon das Problem mit dem HM-WDS30-OT2-SM.
Da Batterien aber ohnehin nicht in die Tonne gehören, hat sich fast automatisch eine zweite Chance für jeden der Sensoren geboten. ;)
Gruß, Ansgar.
PS: auch der hat natürlich autoReadReg 0_off bekommen.
Hallo Noansi, Otto123,
Vielen Dank Euch beiden für die Hilfe!! Der Sensor sendet noch und ich habe alle autoreadreg der anderen Sensoren auch auf 0 gesetzt.
Allerdings gabs ein Missverständnis, die Batterien waren nicht leer. Der Sensor hat sich m.E. Immer komplett abgeschalten nach ca. 10 min. Danach war weder Reset noch sonst etwas möglich durch Tastendruck. Beim erneuten Einsetzen der Batterie ging dann wieder alles (mit der gleichen Batterie, immer noch voll).
Offensichtlich hat das Missverständnis zu Deinem Geistesblitz geführt, der letztendlich die Lösung war...als irgendwie hängts schon zusammen ....
@Otto123: ja, den Ferritkern habeich sauber in der Netzleitung des Raspi installiert.
Guten Rutsch!
Foly12
Hallo foly12,
ZitatDer Sensor hat sich m.E. Immer komplett abgeschalten nach ca. 10 min.
Hast Du den Strom gemessen?
Dass der Sensor nichts mehr sendet und nicht mehr auf Taste reagiert besagt nicht, dass er keinen Strom mehr zieht. Um die 20mA habe ich da noch grob in Erinnerung.
Es dauert bei dem Strom auch deutlich länger als 10 Minuten, bis die Batterien leer sind. Nur wenn man es nicht merkt, dass ein Sensor in dem Zustand ist, ist es halt sehr blöd.
Ich habe übrigens auch getConfig bei den Sensoren aus den webCmd rausgenommen, um da nicht (noch)mal in geistiger Umnachtung mal unbedacht drauf zu klicken.
Gruß, Ansgar.
Hallo Ansgar,
wie bekomme ich denn getConfig raus aus WebCMD?
Grüße
Foly12
Zitat von: foly12 am 01 Januar 2021, 22:30:49
Hallo Ansgar,
wie bekomme ich denn getConfig raus aus WebCMD?
Grüße
Foly12
Bin zwar nicht Ansgar aber:
naja wie man eben Attribute bearbeitet... ;)
Einfach in der Detailansicht des Devices auf den "Link" des Attributnamens klicken dessen Attribut man ändern will (in deinem Fall: webCmd) dann im "Eingabefeld" vor attr AttrName (also bei dir attr webCmd) dann eben das was dort steht so bearbeiten wie man es haben will (bei dir getConfig rauslöschen) und dann vorne auf 'attr' klicken.
Dann kommt (sollte) ein rotes Fragezeichen (links oben bei save) und wenn man sicher ist: save drücken. Wenn nicht (und das die einzige Änderung war!) shutdown restart und alles wieder wie vorher ;)
Gruß, Joachim