Hallo zusammen,
ich habe 9 HM-LC-Bl1PBU-FM seit etwa mehr als einem Jahr im Einsatz.
Ab un zu passtiert, dass nach Empfang eines Befehls, der eine oder der andere Aktor einfach nicht reagiert.
Ich kann es leider nicht reproduzieren, deswegen kann ich nur wenig Info anbieten.
Hier ist ein Extrakt vom Gerät-Log:
2017-01-31_17:06:43 eg.wz.rollo.sud.links level: set_0
2017-01-31_17:06:43 eg.wz.rollo.sud.links set_0
2017-01-31_17:06:44 eg.wz.rollo.sud.links deviceMsg: on (to VCCU)
2017-01-31_17:06:44 eg.wz.rollo.sud.links level: 100
2017-01-31_17:06:44 eg.wz.rollo.sud.links motor: stop:on
2017-01-31_17:06:44 eg.wz.rollo.sud.links pct: 100
2017-01-31_17:06:44 eg.wz.rollo.sud.links on
2017-01-31_17:06:44 eg.wz.rollo.sud.links timedOn: off
hier ein LIST des Geräts:
Internals:
DEF 41D71E
HMCUL_MSGCNT 5
HMCUL_RAWMSG A0D0AA41041D71EAAA00106010000::-65.5:HMCUL
HMCUL_RSSI -65.5
HMCUL_TIME 2017-01-31 22:22:29
HMLANHUB_MSGCNT 5
HMLANHUB_RAWMSG E41D71E,0000,05522645,FF,FFDA,0AA41041D71EAAA00106010000
HMLANHUB_RSSI -38
HMLANHUB_TIME 2017-01-31 22:22:29
IODev HMCUL
LASTInputDev HMLANHUB
MSGCNT 10
NAME eg.wz.rollo.sud.links
NOTIFYDEV global
NR 270
NTFY_ORDER 50-eg.wz.rollo.sud.links
STATE off
TYPE CUL_HM
lastMsg No:0A - t:10 s:41D71E d:AAA001 06010000
protLastRcv 2017-01-31 22:22:29
protSnd 7 last_at:2017-01-31 22:22:29
protState CMDs_done
rssi_HMCUL cnt:1 max:-68 lst:-68 avg:-68 min:-68
rssi_at_HMCUL min:-65.5 avg:-65.09 cnt:5 max:-64.5 lst:-65.5
rssi_at_HMLANHUB max:-37 cnt:5 lst:-38 avg:-38.79 min:-41
Readings:
2017-01-31 17:06:44 CommandAccepted yes
2017-01-30 12:36:44 D-firmware 2.8
2017-01-30 12:36:44 D-serialNr MEQ1097826
2017-01-30 12:38:13 PairedTo 0xAAA001
2017-01-30 12:38:14 R-driveDown 25 s
2017-01-30 12:38:14 R-driveTurn 1.5 s
2017-01-30 12:38:14 R-driveUp 27 s
2017-01-30 12:37:47 R-pairCentral 0xAAA001
2017-01-30 12:37:48 R-powerUpAction off
2015-12-11 07:35:41 R-sign off
2017-01-30 12:38:13 RegL_00. 02:01 0A:AA 0B:A0 0C:01 15:FF 18:00 00:00
2017-01-30 12:38:14 RegL_01. 08:00 09:00 0A:00 0B:00 0C:FA 0D:01 0E:0E 0F:0F 10:00 30:06 57:24 56:00 00:00
2017-01-31 22:22:29 deviceMsg off (to VCCU)
2017-01-31 22:22:29 level 0
2016-11-19 16:35:09 levelMissed desired:0
2017-01-31 22:22:29 motor stop:off
2017-01-31 22:22:29 pct 0
2017-01-30 12:36:30 powerOn 2017-01-30 12:36:30
2017-01-31 22:22:29 recentStateType info
2017-01-30 07:39:11 sabotageAttackId_ErrIoId_F11034 cnt:2
2017-01-31 22:22:29 state off
2017-01-31 22:22:29 timedOn off
Helper:
HM_CMDNR 10
cSnd ,11AAA00141D71E020100
dlvlCmd ++A011AAA00141D71E020100
mId 006A
rxType 1
supp_Pair_Rep 0
Ack:
Dir:
cur stop
rct down
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +41D71E,00,00,00
nextSend 1485897749.83362
rxt 0
vccu VCCU
p:
41D71E
00
00
00
prefIO:
HMCUL
Mrssi:
mNo 0A
Io:
HMCUL -63.5
HMLANHUB -38
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rpt:
IO HMCUL
flg A
ts 1485897749.74099
ack:
HASH(0x2ccd530)
0A8002AAA00141D71E00
Rssi:
Hmcul:
avg -68
cnt 1
lst -68
max -68
min -68
At_hmcul:
avg -65.1
cnt 5
lst -65.5
max -64.5
min -65.5
At_hmlanhub:
avg -38.8
cnt 5
lst -38
max -37
min -41
Attributes:
IODev HMCUL
IOgrp VCCU:HMCUL
autoReadReg 4_reqStatus
expert 2_full
firmware 2.8
model HM-LC-Bl1PBU-FM
peerIDs 00000000,
rollo struct.eg.rollos
room z.eg.Wohnzimmer
serialNr MEQ1097826
subType blindActuator
userattr rollo rollo_map structexclude
webCmd statusRequest:toggleDir:on:off:up:down:stop
Wie man im Log sieht, empfängt das Gerät den Befehl, der Motor dreht sich aber nicht.
Hat jemand vielleicht eine Idee?
Danke schon mal!
Ciao
Mojn!
Hängt das Rollo vielleicht? Das hatte ich bei meinem ersten eingebauten Aktor. Ich bin fast wahnsinnig geworden, bis ich darauf gekommen bin. Vorher hatte der nie mechanisch gehangen...
Gruß, Bernd
Gesendet von iPhone mit Tapatalk
Hallo Bernd,
das Rollo hängt nicht, wenn ich das Befehl wiederhole, funktioniert es einwandfrei.
Danke aber für den Tipp ;)
Ciao,
Marco
Hey, das ist ja exakt der gleiche Fehler wie in meinem gestrigen Thread: https://forum.fhem.de/index.php/topic,66124.0.html
Ich suche auch noch nach der Ursache.
Hi,
ich habe gestern deinen Thread übersehen und bei der Suche nicht gefunden... komisch...
naja... Fakt ist... das Problem macht mich verrückt :)
Ich hoffe es gibt eine Lösung (man könnte dafür ein Check der Ausführung des Befehls einbauen, aber das fände ich ein bisschen zu "gebastelt" :))
Ciao!
Ich hatte den Thread ursprünglich recht allgemein in Punkto Homematic gelassen.
Erst heute hatte ich den Titel um den Begriff HM-LC-Bl1PBU-FM erweitert.
Wahrscheinlich hast du deswegen auch nichts gefunden.
Irgendwie beruhigt mich das ja, dass es noch andere Leidtragende gibt.
Aber irgendwie ist bei uns komisch.
Wie fährst du die Jalousien herunter?
Mehrere Jalousien einzeln über ein DOIF mit Verzögerung?
Oder über ein Structure? Evtl. sogar mit async_delay-Attribut?
Ich habe bereits drei HM-CFG-USB2 ausprobiert. Du scheinst ein HMCUL und ein HMLAN einzusetzen, oder?
Also kann es doch auch nicht an der Hardware liegen.
Ich hatte mal mehrere HMUSB zu einer VCCU zusammengefasst. So hatte ich eigentlich auch noch überall die Attribute IODev und IOgrp gefüllt. Aber natürlich nur mit dem - mittlerweile - einzig existierenden HMUSB. Also eine VCCU mit nur einem Gerät. Vorsichtshalber entferne ich aber gerade überall die VCCU-Zuordnung, um den Fehler dort auszuschließen.
Ich fahre sie auf den unterschiedlichen Art und Weisen huch und runter :)
- bei Bedarf einzeln durch die Tablet UI oder FHEM Web
- Wenn ich am WE früh aufstehe, dann durch eine Structure (ich habe eine für dem EG und eine für den OG)
- Programmiert mit einem DOIF pro Rollo, abhängig von der Helligkeit eines Sensors, oder (beim Ausfall des Sensors) mit Twilight.
Die DOIFs lösen alle gleichzeitig ohne Verzögerung aus (für 9 Rollos, in der Früh und Abends)
Ich habe insgesamt 18 DOIFs, weil ich die Automatik pro Rollo für das Hoch und Runterfahren einzeln ausschalten will... für z.B. länger schlafen in der Früh, oder um Abends nicht das gefühl zu haben, eingesperrt zu sein :). Wenn wir den Alarm auf "Nicht anwesend" scharf schalten werden alle DOIFS aktiviert und beim entschärfen werden sie auf dem vorherigen Status zurückgesetzt.
Die DOIFs rufen eine PERL-Funktion auf, die anhand der aktuellen Position und der gewünschte Position und Richtung entscheiden, ob das "Rollo set xxx" Befehl geschickt wird oder nicht (um das Netzt-Verkehr zu optimieren).
Das hat aber in diesem Fall keine Auswirkung, da das Befehl laut Geräte-Log empfangen wird. Der Motor bleibt allerdings auf "Stop".
Ciao!
Hast du hier (https://forum.fhem.de/index.php/topic,66124.msg574906.html#msg574906) die neusten Beiträge gelesen?
Startest du evtl. auch desöfteren FHEM neu und könnte unser Fehler evtl. damit zusammenhängen?