Hallo,
ich habe ein seltsames Problem seit einem Stromausfall vor kurzem.
Einer meiner Lichtschalter zeigt ein komisches Verhalten und zwar nur, wenn er via FHEM geschaltet wird.
Dann passiert folgendes:
- Der Aktor schaltet ein und sofort wieder aus
- Im Logfile tauchen zwei Einträge auf:
2018.10.23 08:03:07 3: CUL_HM set DG_Licht on
2018.10.23 08:03:13 3: CUL_HM set DG_Licht getConfig
Wie gesagt - der Aktor schaltet sofort wieder aus!
Das passiert jedes mal, wenn ich via FHEM schalte.
Manuell kann ich den Schalter ganz normal bedienen. Dabei taucht dann auch NICHT der Eintrag mit "getConfig" auf. Ich kann mir keinen Reim darauf machen.
Hier ein List:
Internals:
CUL_SER_MSGCNT 176
CUL_SER_RAWMSG A0D0EA4103AE010xxxxxx0601C800::-89.5:CUL_SER
CUL_SER_RSSI -89.5
CUL_SER_TIME 2018-10-23 08:03:20
DEF 3AE010
HMLAN1_MSGCNT 182
HMLAN1_RAWMSG E3AE010,0000,45449193,FF,FFAD,0EA4103AE010xxxxxx0601C800
HMLAN1_RSSI -83
HMLAN1_TIME 2018-10-23 08:03:20
IODev myHmUART
LASTInputDev HMLAN1
MSGCNT 538
NAME DG_Licht
NOTIFYDEV global
NR 784
NTFY_ORDER 50-DG_Licht
STATE on
TYPE CUL_HM
lastMsg No:0E - t:10 s:3AE010 d:xxxxxx 0601C800
myHmUART_MSGCNT 180
myHmUART_RAWMSG 050100460EA4103AE010xxxxxx0601C800
myHmUART_RSSI -70
myHmUART_TIME 2018-10-23 08:03:20
peerList self01,self02,
protLastRcv 2018-10-23 08:03:20
protRcv 180 last_at:2018-10-23 08:03:20
protSnd 229 last_at:2018-10-23 08:03:20
protState CMDs_done
rssi_HMLAN1 cnt:1 min:-84 max:-84 avg:-84 lst:-84
rssi_at_CUL_SER cnt:176 min:-98.5 max:-82 avg:-85.6 lst:-89.5
rssi_at_HMLAN1 cnt:182 min:-92 max:-82 avg:-84.09 lst:-83
rssi_at_myHmUART cnt:180 min:-80 max:-64 avg:-69.32 lst:-70
rssi_myHmUART cnt:18 min:-78 max:-72 avg:-74.94 lst:-76
READINGS:
2018-10-23 08:03:07 CommandAccepted yes
2018-10-23 08:02:17 D-firmware 2.3
2018-10-23 08:02:17 D-serialNr MEQ0485970
2018-10-23 08:03:13 PairedTo 0xxxxxxx
2016-08-16 13:14:05 R-pairCentral 0xxxxxxx
2018-08-16 23:12:20 R-self01-lgActionType jmpToTarget
2018-08-16 23:12:20 R-self01-shActionType jmpToTarget
2018-08-16 23:12:20 R-self02-lgActionType jmpToTarget
2018-08-16 23:12:20 R-self02-shActionType jmpToTarget
2016-08-16 13:14:06 R-sign off
2018-10-23 08:03:13 RegL_00. 02:81 0A:82 0B:86 0C:FF 15:FF 18:00 00:00
2018-10-23 08:03:14 RegL_01. 08:00 30:06 57:24 00:00
2018-10-23 08:03:16 RegL_03.self01 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:64 8C:66 00:00
2018-10-23 08:03:16 RegL_03.self02 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:13 8C:33 00:00
2018-10-23 08:03:20 deviceMsg on (to CCU)
2017-09-18 08:55:48 inhibit set_off
2018-10-23 08:03:20 level 100
2018-10-23 08:03:20 pct 100
2018-10-23 08:03:15 peerList self01,self02,
2018-10-23 08:03:12 powerOn 2018-10-23 08:03:12
2018-10-23 08:03:20 recentStateType info
2018-10-23 08:03:20 state on
2018-10-23 08:03:20 timedOn off
helper:
HM_CMDNR 14
PONtest 0
cSnd 01xxxxxx3AE01001043AE0100103,01xxxxxx3AE01001043AE0100203
dlvlCmd ++A011xxxxxx3AE0100201C80000
mId 0069
peerIDsRaw ,3AE01001,3AE01002,00000000
regLst ,0,1,3p
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3AE010,00,00,00
nextSend 1540274600.29417
prefIO
rxt 0
vccu CCU
p:
3AE010
00
00
00
mRssi:
mNo 0E
io:
CUL_SER:
-89.5
-89.5
HMLAN1:
-83
-83
myHmUART:
-68
-68
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rpt:
IO CUL_SER
flg A
ts 1540274600.195
ack:
HASH(0x39effd0)
0E8002xxxxxx3AE01000
rssi:
HMLAN1:
avg -84
cnt 1
lst -84
max -84
min -84
at_CUL_SER:
avg -85.6022727272727
cnt 176
lst -89.5
max -82
min -98.5
at_HMLAN1:
avg -84.0989010989011
cnt 182
lst -83
max -82
min -92
at_myHmUART:
avg -69.3222222222222
cnt 180
lst -70
max -64
min -80
myHmUART:
avg -74.9444444444445
cnt 18
lst -76
max -72
min -78
shadowReg:
tmpl:
Attributes:
IOgrp CCU
alexaName dachlicht
alexaRoom alexa
alias DG_Licht
autoReadReg 4_reqStatus
expert 2_full
firmware 2.3
group Licht
icon light_ceiling
model HM-LC-Sw1PBU-FM
peerIDs 00000000,3AE01001,3AE01002,
room Cam,Hausstatus,Licht,alexa
serialNr MEQ0485970
subType switch
webCmd on:off
Kann mir jemand helfen? Vielen Dank.
2018-10-23 08:03:12 powerOn 2018-10-23 08:03:12
Wenn du heute morgen nicht einen Stromausfall um 8:03 hattest, wird das KondensatorProblem zuschlagen
tauschen!
Zitat von: fhem-hm-knecht am 23 Oktober 2018, 08:21:27
2018-10-23 08:03:12 powerOn 2018-10-23 08:03:12
Wenn du heute morgen nicht einen Stromausfall um 8:03 hattest, wird das KondensatorProblem zuschlagen
tauschen!
Oha! Das habe ich noch gar nicht gesehen! Nein, heute Morgen hatte ich keinen Stromausfall. Danke für den Hinweis!
Der Schalter ist nicht mal 3 Jahre alt...habe gerade zum C26 gelesen und ich habe zum Glück sogar noch einen 10uf/50V Elko hier liegen..dann werde ich den mal tauschen.
Aber ist es nicht komisch, dass dieses Fehlverhalten nur auftritt wenn er per Funk geschaltet wird? Manuell an der Wippe gibt es kein Problem.
ausserdem fehlt das attr IODev. wieso?
Zitat von: frank am 23 Oktober 2018, 09:31:02
ausserdem fehlt das attr IODev. wieso?
Weil ich eine vCCU im Einsatz habe und deshalb "IOGrp" zieht und "IODev" obsolet ist.
trotzdem soll es existieren.
Gibt es dafür eine Begründung? Würde mich jetzt wirklich intressieren.
Ich habe das Attribut bei allen Geräten entfernt, weil nach Umstellung auf HMUART überall noch der alte CUL drin stand (den es so nicht mehr gibt) und dadurch Fehlermeldungen produziert wurden (no such Input Device).
Fehlfunktionen habe ich durch das Entfernen des Attributs bisher nicht festgestellt.
zumindestens damals, bei einführung der vccu, galt:
Zitat von: martinp876 am 26 August 2014, 11:03:45wenn IOgrp gesetzt ist, wird IODev von der vccu automatisch geändert. Eigentlich sollte es nicht zu sehen sein, ich kann es aber nicht löschen, da es vom Kernal genutzt wird.
Also: wenn attr IOgrp gesetzt ist, wird IODev zum "Reading": es wird kontinuierlich "geprüft"
das aktuelle vccu-wiki sieht es aber, gerade gelesen und gewundert, scheinbar nicht mehr so streng. entweder hat sich der "fhem kernel" geändert, oder dem wiki autor war es nicht mehr so wichtig.
bei mir gibt es seit einführung der vccu beide attribute (IODev, IOgrp) bei allen devices. und das ohne fehler im log.
Zitat von: frank am 23 Oktober 2018, 11:06:13
zumindestens damals, bei einführung der vccu, galt:
das aktuelle vccu-wiki sieht es aber, gerade gelesen und gewundert, scheinbar nicht mehr so streng. entweder hat sich der "fhem kernel" geändert, oder dem wiki autor war es nicht mehr so wichtig.
bei mir gibt es seit einführung der vccu beide attribute (IODev, IOgrp) bei allen devices. und das ohne fehler im log.
Hm ok danke. Also die Fehler im Log kamen bei mir daher, weil das IoDevice mit diesem Namen nicht mehr existierte. Ich hätte es also in jedem Gerät umbenennen können oder eben löschen.
Hab es gelöscht und wie gesagt bisher keine Probleme damit gehabt.
Scheint also zumindest augenscheinlich keine Rolle zu spielen.
Zitat von: errazzor am 23 Oktober 2018, 08:36:48
Oha! Das habe ich noch gar nicht gesehen! Nein, heute Morgen hatte ich keinen Stromausfall. Danke für den Hinweis!
Der Schalter ist nicht mal 3 Jahre alt...habe gerade zum C26 gelesen und ich habe zum Glück sogar noch einen 10uf/50V Elko hier liegen..dann werde ich den mal tauschen.
Aber ist es nicht komisch, dass dieses Fehlverhalten nur auftritt wenn er per Funk geschaltet wird? Manuell an der Wippe gibt es kein Problem.
Das Fehlerbild ist manchmal massiv, manchmal filigran. Die Spannung bricht in dem Moment zusammen, wieviel hängt vom Strom ab. Funk verbraucht ev. etwas zusätzlich...
Zum IODev, ich habe zwar mal was im Wiki ergänzt aber ich denke (und hoffe) ich habe an der Stelle nichts rausgenommen.
Meines Wissens wird doch das attr IODev von FHEM gesetzt und nicht von der VCCU - die verwaltet es nur intern und es spielt keine Rolle mehr. Also bei mir gibt es attr IODev immer noch und ich würde auch nie äußern, dass man es einfach löschen sollte.
Bei Fehlern hätte ich es wahrscheinlich einfach auf einen aktuellen IO geändert. Aber bisher war das kein Problem.
Gruß Otto
Zitat von: Otto123 am 23 Oktober 2018, 11:51:42
Das Fehlerbild ist manchmal massiv, manchmal filigran. Die Spannung bricht in dem Moment zusammen, wieviel hängt vom Strom ab. Funk verbraucht ev. etwas zusätzlich...
Zum IODev, ich habe zwar mal was im Wiki ergänzt aber ich denke (und hoffe) ich habe an der Stelle nichts rausgenommen.
Meines Wissens wird doch das attr IODev von FHEM gesetzt und nicht von der VCCU - die verwaltet es nur intern und es spielt keine Rolle mehr. Also bei mir gibt es attr IODev immer noch und ich würde auch nie äußern, dass man es einfach löschen sollte.
Bei Fehlern hätte ich es wahrscheinlich einfach auf einen aktuellen IO geändert. Aber bisher war das kein Problem.
Gruß Otto
Ich werde den C26 tauschen und dann nochmal berichten. Ist ja sehr wahrscheinlich, dass es daran liegt. Danke für den Tipp.
Nochmal zum IODev: ja, das wird von FHEM gesetzt. Meine VCCU kam später dazu. Und noch später habe ich das ursprüngliche IODev ersetzt und es bekam einen neuen Namen.
Daraufhin gab es Fehler im Logfile (no such IODev) und als ich danach suchte kam ich auf den Wiki-Artikel. Dort steht, dass dieses Attribut keine Verwendung mehr findet, wenn man eine VCCU einsetzt.
Zitat
"Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen."
Ich habe das so verstanden, dass man es aber löschen *kann*.
Deshalb habe ich es gelöscht anstatt eins mit gültigem Namen einzutragen.
Das nur nochmal zur Erläuterung warum ich das so gemacht habe.
Hallo,
habe den C26 nun gerade offen vor mir liegen.
Was mich etwas stutzig macht: Der C26 ist an der Plus-Seite per Lötbrücke mit dem darunterliegenden Bauteil (ich glaube D25) verbunden.
Da ich bisher noch nichts dergleichen gelesen habe...soll das so sein?
Ich vermute mal ja, weil der Schalter so die letzten 2 Jahre funktioniert hat...wollte nur sicher gehen wenn ich den neuen Elko einlöte.
Das muss so sein - C26(+) an D25 Kathode. Das ist eine Zenerdiode 12V, die wohl den Linearregler 3,3V schützen soll.
Alles klar, vielen vielen Dank für die schnelle Antwort! Dann kann ich das Ding fertig machen.
Ich war nur verwundert weil ich mittlerweile auch Bilder gefunden habe, auf denen diese Lötbrücke NICHT existiert.
Es scheinen offenbar verschiedene Revisionen / Layouts im Umlauf zu sein ?
Viele Grüße.
EDIT: Elko C26 getauscht, Schalter funktioniert wieder einwandfrei. Das Auslöten ging recht gut mit einer dünnen Bleistiftspitze. Habe die Platine in die "3. Hand" eingespannt und von unten mit einer Zange den Elko gepackt, mit der anderen Hand von oben das Lötzinn erwärmt und dabei leichten Zug aufgebaut. Irgendwann rutschte der Elko raus.
Die Löcher habe ich mit einer manuellen Entlötsaugpumpe (so ein Klick-Ding für 5 Euro) freibekommen.
Zitat von: errazzor am 05 November 2018, 10:52:23
Es scheinen offenbar verschiedene Revisionen / Layouts im Umlauf zu sein ?
Das kann auch ein Bausatz gewesen sein und die Lötbrücke das Werk eines nicht allzu versierten Bastlers ;D
Ich vermute mal, dass sie nicht notwendig ist, da die Bautele auch per Leiterbahn verbunden sind, stört aber auch nicht.
Zitat von: tndx am 05 November 2018, 12:43:43
Das kann auch ein Bausatz gewesen sein und die Lötbrücke das Werk eines nicht allzu versierten Bastlers ;D
Ich vermute mal, dass sie nicht notwendig ist, da die Bautele auch per Leiterbahn verbunden sind, stört aber auch nicht.
Ne, mein Aktor war ein Fertigteil und da war die Lötbrücke ab Werk vorhanden.
Oben schrieb ich - ich habe Bilder im Netz gefunden, auf denen die Lötbrücke NICHT existiert.