Hallo zusammen,
ich betreibe seit knapp zwei Jahren (FHEM auf Raspberry, CUL, ein Rolladenaktor, ein Dimmer und eine schaltbare Steckdose) ohne größere Probleme.
Seit einem Stromausfall letzte Woche wurde der Rolladenaktor manchmal nicht angesprochen, nun reagiert er gar nicht mehr - Missing Ack.
Auch ein Löschen in FHEM, Reset des Aktors und neues Pairing führt sofort zu "Missing Ack", wenn ich den ersten Befehl absetzen will. Der Schalter selbst funktioniert bei manueller Betätigung.
List zeigt folgendes :
Internals:
CFGFN
CUL_0_MSGCNT 4
CUL_0_RAWMSG A0A2B800256F66211066900::-66:CUL_0
CUL_0_RSSI -66
CUL_0_TIME 2019-07-21 15:07:53
DEF 56F662
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 4
NAME HM_56F662
NOTIFYDEV global
NR 116
STATE ???
TYPE CUL_HM
lastMsg No:2B - t:02 s:56F662 d:110669 00
protLastRcv 2019-07-21 15:07:53
protSnd 3 last_at:2019-07-21 15:07:53
protState CMDs_done
rssi_at_CUL_0 cnt:4 min:-66 max:-55.5 lst:-66 avg:-62.5
READINGS:
2019-07-21 15:07:53 CommandAccepted yes
2019-07-21 15:07:52 D-firmware 2.11
2019-07-21 15:07:52 D-serialNr OEQ0265662
2019-07-21 15:07:52 R-pairCentral set_0x110669
helper:
HM_CMDNR 43
PONtest 1
cSnd 0111066956F662000802010A110B060C69,0111066956F6620006
mId 006A
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +56F662,00,00,00
nextSend 1563714473.67256
prefIO
rxt 0
vccu
p:
56F662
00
00
00
mRssi:
mNo 2B
io:
CUL_0 -64
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 00
qReqStat 00
role:
chn 1
dev 1
prs 1
rssi:
at_CUL_0:
avg -62.5
cnt 4
lst -66
max -55.5
min -66
shadowReg:
RegL_00. 02:01 0A:11 0B:06 0C:69
Attributes:
IODev CUL_0
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.11
model HM-LC-Bl1PBU-FM
room CUL_HM
serialNr OEQ0265662
subType blindActuator
webCmd statusRequest:toggleDir:on:off:up:down:stop
Habt Ihr Ideen?
Danke für Eure Hilfe
Andy
Nach meiner Erfahrung verlieren die Homematic Devices bei Stromausfall/leeren Batterien gerne mal ihre Konfiguration. Als wenn der Brown Out Detector nicht richtig konfiguriert sei und beim Verlust der Betriebsspannung das EEPROM Inhalt kaputt geht.
Dann hilft nur neu anlernen.
Neu angelernt habe ich ja.
Muss ich dabei eventuell eine besondere Reihenfolge berücksichtigen?
- in FHEM löschen, Reset des Aktors und neues Anlernen
- nur neues Anlernen
habe ich bereits versucht. Missing Ack bleibt bestehen
In fhem löschen ist m. E. nicht notwendig.
IODev in den Anlernmodus versetzen und dann den Config Knopf am Schalter drücken sollte reichen. Allerdings ist ein CUL auch nicht ideal für Homematic.
Laut den Readings ist der Schalter noch nicht richtig gepaired (R-pairCentral set_0x110669) und verweigert daher wohl alle Kommandos.
interresant, dein Aktor ist bereits gepairt mit 110669 !
ich würde ihn mal stromlos machen , der hängt bestimmt
Zitat von: fhem-hm-knecht am 21 Juli 2019, 16:26:20
interresant, dein Aktor ist bereits gepairt mit 110669 !
Eben nicht
Zitat von: kaihs am 21 Juli 2019, 16:04:40
Laut den Readings ist der Schalter noch nicht richtig gepaired (R-pairCentral set_0x110669) und verweigert daher wohl alle Kommandos.
Zitat von: amenomade am 21 Juli 2019, 16:36:55
Eben nicht
eben Doch
No:2B - t:02 s:56F662 d:110669 00
;)
Ja, aber Fhem kriegt es nicht mit. Der Register wird nicht berücksichtigt.
Aber Du hast Recht, stromlos machen könnte helfen.
Zitat von: amenomade am 21 Juli 2019, 16:53:31
Ja, aber Fhem kriegt es nicht mit. Der Register wird nicht berücksichtigt.
Aber Du hast Recht, stromlos machen könnte helfen.
Ich habe mal die Sicherung für ein paar Minuten rausgenommen
Ich nehme an, so wäre es richtig:
PairedTo 0x110669
R-pairCentral 0x110669
Das ist meine schaltbare Steckdose, funktioniert prächtig.
Das hier ist der Dimmer:
R-pairCentral set_0x110669
Obwohl hier das PairedTo Attribut fehlt und R-pairCentral ein set-Prefix hat, funktioniert auch der Dimmer fehlerfrei
Der Rolladenaktor hat denselben Eintrag wie der Dimmer (R-PairCentral mit set_, kein PairedTo) und funktioniert nicht
Kommt vermutlich drauf an WO bzw. warum das set_ noch da ist:
Pairing beim Aktor im Register eingetragen aber noch kein Rücklesen in fhem -> set_ ABER: Aktor wird wohl funktionieren, da er ja von "seiner" Zentrale die Kommandos erhält
Pairing beim Aktor noch nicht eingetragen (und auch noch keine Rückmeldung) -> set_ ABER: Aktor verweigert Befehle von einer noch nicht bekannten Zentrale...
Zumindest meine Theorie hierzu...
Gruß, Joachim
so viele "_set" in den readings und das bei gutem rssi/funk deutet für mich auf timing probleme hin.
1. tsculfw von noansi auf den cul flashen
2. freezes in fhem kontrollieren
Zitat von: frank am 21 Juli 2019, 18:48:12
so viele "_set" in den readings und das bei gutem rssi/funk deutet für mich auf timing probleme hin.
1. tsculfw von noansi auf den cul flashen
2. freezes in fhem kontrollieren
Da schließe ich mich an!
Wobei (selbst erfahren und "durchgemacht") letztendlich ein richtiges HM-IO immer noch die beste (und letztendlich) einfachste Lösung ist... :)
Gruß, Joachim
Zitat von: frank am 21 Juli 2019, 18:48:12
so viele "_set" in den readings und das bei gutem rssi/funk deutet für mich auf timing probleme hin.
1. tsculfw von noansi auf den cul flashen
2. freezes in fhem kontrollieren
Danke, werde ich bei Gelegenheit mal versuchen. Muss ich dabei etwas beachten, oder sollte hinterher zumindest theoretisch alles noch so gehen wie vorher?
Ich hab jetzt den Raspi / CUL mal woanders aufgestellt (Stockwerk über dem Aktor, Entfernung etwa 2m im Ggensatz zu vorher nur 1 m) und siehe da, der Aktor spricht wieder an.
Allerdings habe ich einige weitere "set_" provoziert (driveUp, down, ...) und die Readings sind ansonsten auch unverändert (R-PairCentral mit set_, kein PairedTo)
Wenn das Gerät mit fhem "spricht" könnte ein getConfig helfen
Zitat
Danke, werde ich bei Gelegenheit mal versuchen. Muss ich dabei etwas beachten, oder sollte hinterher zumindest theoretisch alles noch so gehen wie vorher?
Theoretisch: ja.
Einfach wie im entsprechenden Thread beschrieben...
Allerdings (das war auch der Grund das nicht mehr weiter zu machen, obwohl es danach [sehr] gut lief): es werden einige fhem-Module "ersetzt" und sind dann vom update (besser) auszuschließen... Ist immer etwas fraglich wann die "nachgezogen" werden...
Gruß, Joachim
Zitat von: amenomade am 21 Juli 2019, 19:20:17
Wenn das Gerät mit fhem "spricht" könnte ein getConfig helfen
Danke, die Attribute scheinen jetzt sauber eingelesen:
2019-07-21 19:29:11 PairedTo 0x110669
2019-07-21 19:29:12 R-driveDown 26 s
2019-07-21 19:29:12 R-driveTurn 0.5 s
2019-07-21 19:29:12 R-driveUp 30 s
2019-07-21 19:29:11 R-pairCentral 0x110669
Ich lasse jetzt mal einen Tag die "at"-Befehle laufen und baue den Raspi dann wieder an seinen ursprünglichen Platz, wenn alles funktioniert