Hallo,
mein Problem passt thematisch zu diesem Thread: Link (http://forum.fhem.de/index.php?topic=11942.0) .
Diesmal habe ich allerdings kein Problem mit verlorenen Rückmeldungen, sondern mit nicht ausgeführten Befehlen.
Um 7:00 Uhr sollen 8 Rolläden gleichzeitig hochfahren. Das funktioniert oft einwandfrei. Manchmal bleiben einige Läden unten. Das allerdings ohne einen "missing ack" sondern mit scheinbar angenommenen aber nicht ausgeführtem Befehl. Das leuchtet mir einfach nicht ein und lässt sich nur mit
einem Bug im Actuator erklären? Es handelt sich um blindActuatoren vom Typ HM-LC-Bl1PBU-FM.
Ein paar Logauszüge:
Rolladen2 funktioniert einwandfrei:
2013-04-20_07:00:00 WZ_Rolladen2 set_on
2013-04-20_07:00:03 WZ_Rolladen2 level: 7.5 %
2013-04-20_07:00:03 WZ_Rolladen2 deviceMsg: 7.5 % (to HMLAN1)
2013-04-20_07:00:03 WZ_Rolladen2 7.5 %
2013-04-20_07:00:03 WZ_Rolladen2 motor: up:7.5 %
2013-04-20_07:00:36 WZ_Rolladen2 level: 100 %
2013-04-20_07:00:36 WZ_Rolladen2 deviceMsg: on (to HMLAN1)
2013-04-20_07:00:36 WZ_Rolladen2 on
2013-04-20_07:00:36 WZ_Rolladen2 motor: stop:on
Rolladen 4 auch:
2013-04-20_07:00:00 WZ_Rolladen4 set_on
2013-04-20_07:00:03 WZ_Rolladen4 level: 6.5 %
2013-04-20_07:00:03 WZ_Rolladen4 deviceMsg: 6.5 % (to HMLAN1)
2013-04-20_07:00:03 WZ_Rolladen4 6.5 %
2013-04-20_07:00:03 WZ_Rolladen4 motor: up:6.5 %
2013-04-20_07:00:37 WZ_Rolladen4 level: 100 %
2013-04-20_07:00:37 WZ_Rolladen4 deviceMsg: on (to HMLAN1)
2013-04-20_07:00:37 WZ_Rolladen4 on
2013-04-20_07:00:37 WZ_Rolladen4 motor: stop:on
Rolladen 1 bleibt unten:
2013-04-20_07:00:00 WZ_Rolladen1 set_on
2013-04-20_07:00:01 WZ_Rolladen1 level: 1.5 %
2013-04-20_07:00:01 WZ_Rolladen1 deviceMsg: 1.5 % (to HMLAN1)
2013-04-20_07:00:01 WZ_Rolladen1 1.5 %
2013-04-20_07:00:01 WZ_Rolladen1 motor: up:1.5 %
2013-04-20_07:00:01 WZ_Rolladen1 level: 3 %
2013-04-20_07:00:01 WZ_Rolladen1 deviceMsg: 3 % (to HMLAN1)
2013-04-20_07:00:01 WZ_Rolladen1 3 %
2013-04-20_07:00:01 WZ_Rolladen1 motor: down:3 %
2013-04-20_07:00:07 WZ_Rolladen1 level: 0 %
2013-04-20_07:00:07 WZ_Rolladen1 deviceMsg: off (to HMLAN1)
2013-04-20_07:00:07 WZ_Rolladen1 off
2013-04-20_07:00:07 WZ_Rolladen1 motor: stop:off
und Rolladen 3 auch:
2013-04-20_07:00:00 WZ_Rolladen3 set_on
2013-04-20_07:00:01 WZ_Rolladen3 level: 1.5 %
2013-04-20_07:00:01 WZ_Rolladen3 deviceMsg: 1.5 % (to HMLAN1)
2013-04-20_07:00:01 WZ_Rolladen3 1.5 %
2013-04-20_07:00:01 WZ_Rolladen3 motor: up:1.5 %
2013-04-20_07:00:01 WZ_Rolladen3 level: 3 %
2013-04-20_07:00:01 WZ_Rolladen3 deviceMsg: 3 % (to HMLAN1)
2013-04-20_07:00:01 WZ_Rolladen3 3 %
2013-04-20_07:00:01 WZ_Rolladen3 motor: down:3 %
2013-04-20_07:00:07 WZ_Rolladen3 level: 0 %
2013-04-20_07:00:07 WZ_Rolladen3 deviceMsg: off (to HMLAN1)
2013-04-20_07:00:07 WZ_Rolladen3 off
2013-04-20_07:00:07 WZ_Rolladen3 motor: stop:off
Ich hatte dieses Verhalten schon früher beobachtet. Neu ist heute, dass die fehlerhaften Läden scheinbar (gesehen habe ich das nicht) kurz hoch und dann wieder runterfahren obwohl kein weiterer Befehl gekommen ist?!
Das ausführliche HMLAN-Log schicke ich per PM direkt an Martin.
Gruß
Georg
Hi Georg,
bei Rollo WZ_Rolladen1, WZ_Rolladen2 und KU_Rolladen wird ein off gesendet.
Gute nachricht, es ist kein Bug des HM, ist also lösbar.
Schlechte Nachricht, in FHEM klappt etwas nicht.
Kannst du einmal dein Kommando schickten? Alles was dazu gehoert. Ist da etwas mit toggel drin?
Aktuell habe ich keine erklaerung, woher das off kommt.
Gruss
Martin
Hi Martin,
Es gibt eine struct mit den Rolläden:
define Rolladen_Garten structure room AZ_Rolladen KU_Rolladen WZ_Rolladen1 WZ_Rolladen2 WZ_Rolladen3 WZ_Rolladen4
attr Rolladen_Garten webCmd on:stop:off
Und ein at, zum auslösen:
define Rolladen_Garten_hoch at *{sunrise(1800,"7:00","9:00")} set Rolladen_Garten on
Mehr ist da nicht.
Gruß
Georg
Hi,
Der machaismus ist, dass nach dem Ack des 'on' ein 'off' geschickt wird, bei 3 der Rollladen.
Es wird also sauber der Reihe nach verarbeitet.
Ich werde noch einmal im Code schauen.
Kann es sein dass es noch irgend ein anderen Notify gibt, dass dies anstossen kann?
Aber immerhin fehlt das "set_off". Seltsam ist das schon
Gruss
Maritn
noch etwas:
tritt es immer auf? oder wechselt es?
Zur Info,
habe das Problem einmal nachstellen koennen - werde es untersuchen.
Gruss
Martin
Hi Martin,
das Du es nachstellen kannst, ist natürlich sehr gut.
hier noch die Infos:
- Weder die Aktoren, noch die Strukturen sind bei anderen ats oder notifys verwendet.
- Der Effekt tritt sporadisch auf. Alle paar Tage.
Georg
Hallo Georg,
sieht leider bei mir auch so aus: Ich hatte den Fehler einmal.
Noch habe ich keine Ahnung wo der Befehl herkommt. Offensichtlich ist er nicht durch "set" gegangen, da sonst ein Log gekommen sein sollte. Automatiken, die ein set machen habe ich nicht....
Bin also noch nicht durch.
Gruss
Martin
Hallo,
ich habe den Effekt jetzt auch mal live beobachten können. Rolladen fährt ein Stück runter und dann wieder hoch. Ich werde jetzt mal mit der "sleep 0.5" Variante die Rolläden leicht zeitversetzt fahren. Um einfach mal zu verifizieren, ob dann alles sauber läuft.
Gruß
Georg
Hallo,
bei mir taucht auch seit dem 26.04.13 abends das Problem auf. Mal mit einem Rollladen, mal auch mit 2. Ich kann noch nicht so richtig erkennen, woran es liegt.
Hier mal die Auszüge aus dem Log. Vielleicht hilft das ja was.
2013-04-28_20:44:41 WZ_Nord_Rolladen level: set_runter
2013-04-28_20:44:42 WZ_Nord_Rolladen set_runter
2013-04-28_20:44:42 WZ_SuedOst_Rolladen level: set_runter
2013-04-28_20:44:42 WZ_SuedOst_Rolladen set_runter
2013-04-28_20:44:42 WZ_Terasse_Rolladen level: set_runter
2013-04-28_20:44:42 WZ_Terasse_Rolladen set_runter
2013-04-28_20:44:43 WZ_Nord_Rolladen level: runter00 %
2013-04-28_20:44:43 WZ_Nord_Rolladen deviceMsg: hoch (to HMLAN1)
2013-04-28_20:44:43 WZ_Nord_Rolladen hoch
2013-04-28_20:44:43 WZ_Nord_Rolladen motor: down:hoch
2013-04-28_20:44:43 WZ_SuedOst_Rolladen level: runter00 %
2013-04-28_20:44:43 WZ_SuedOst_Rolladen deviceMsg: hoch (to HMLAN1)
2013-04-28_20:44:43 WZ_SuedOst_Rolladen hoch
2013-04-28_20:44:43 WZ_SuedOst_Rolladen motor: down:hoch
2013-04-28_20:44:43 WZ_Terasse_Rolladen level: runter00 %
2013-04-28_20:44:43 WZ_Terasse_Rolladen deviceMsg: hoch (to HMLAN1)
2013-04-28_20:44:43 WZ_Terasse_Rolladen hoch
2013-04-28_20:44:43 WZ_Terasse_Rolladen motor: down:hoch
2013-04-28_20:44:43 WZ_Nord_Rolladen level: 96 %
2013-04-28_20:44:43 WZ_Nord_Rolladen deviceMsg: 96 % (to HMLANrunter)
2013-04-28_20:44:43 WZ_Nord_Rolladen 96 %
2013-04-28_20:44:43 WZ_Nord_Rolladen motor: up:96 %
2013-04-28_20:44:44 WZ_SuedOst_Rolladen level: 95 %
2013-04-28_20:44:44 WZ_SuedOst_Rolladen deviceMsg: 95 % (to HMLANrunter)
2013-04-28_20:44:44 WZ_SuedOst_Rolladen 95 %
2013-04-28_20:44:44 WZ_SuedOst_Rolladen motor: up:95 %
2013-04-28_20:44:49 WZ_SuedOst_Rolladen level: runter00 %
2013-04-28_20:44:49 WZ_SuedOst_Rolladen deviceMsg: hoch (to HMLAN1)
2013-04-28_20:44:49 WZ_SuedOst_Rolladen hoch
2013-04-28_20:44:49 WZ_SuedOst_Rolladen motor: stop:hoch
2013-04-28_20:44:49 WZ_Nord_Rolladen level: runter00 %
2013-04-28_20:44:49 WZ_Nord_Rolladen deviceMsg: hoch (to HMLAN1)
2013-04-28_20:44:49 WZ_Nord_Rolladen hoch
2013-04-28_20:44:49 WZ_Nord_Rolladen motor: stop:hoch
2013-04-28_20:45:12 WZ_Terasse_Rolladen level: runter %
2013-04-28_20:45:12 WZ_Terasse_Rolladen deviceMsg: runter % (to HMLAN1)
2013-04-28_20:45:12 WZ_Terasse_Rolladen runter %
2013-04-28_20:45:12 WZ_Terasse_Rolladen motor: stop:runter %
Wie man sieht, fährt der Terassenrolladen normal und die anderen beiden bleiben oben bzw. gehen direkt wieder hoch.
Der Befehl wird über ein Structure geschaltet, welche wie folgt definiert ist:
define Alle_Rollaeden structure room WZ_Nord_Rolladen WZ_NordOst_Rolladen WZ_SuedOst_Rolladen WZ_Terasse_Rolladen K_Rolladen HWR_Rolladen GWC_Rolladen Bad_Rolladen GZ_Rolladen KZ_Rolladen SZ_Rolladen
attr Alle_Rollaeden clientstate_behavior relative
attr Alle_Rollaeden clientstate_priority hoch|on runter %
attr Alle_Rollaeden devStateIcon hoch:shutter_open:runter runter.*:shutter_closed:hoch
attr Alle_Rollaeden eventMap 100:hoch 1:runter 50:halb 85:Frost_oben
attr Alle_Rollaeden room Rollaeden
attr Alle_Rollaeden webCmd hoch:runter:stop
Die Attribute wurden auch auf die jeweiligen Rollläden vererbt.
Das Notify sieht wie folgt aus:
define Alle_Rollaeden_runter at *{sunset("HORIZON=-3",0,"17:00","22:00")} {\
fhem("set Alle_Rollaeden runter;; define WZ_Raffstore_runter at +00:02:00 set WZ_Raffstore zu")\
}
Das letzte Update habe ich am 24.04.13 gemacht.
2013.04.24 14:39:08 0: Server started with 64 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3075 2013-04-15 15:19:48Z rudolfkoenig $, pid 5953)
Als Ergänzung sei vielleicht noch zu sagen, dass Morgens alle 10 Rollläden ohne Probleme alle hochfahren. Die Hoch-Befehle erfolgen allerdings nicht über die Structure sondern die Aktoren werden einzeln aufgeführt. Ein Notify mit Sunrise löst eine Funktion aus, in welcher in einer Schleife alle Rollläden abgearbeitet werden. Sie fahren aber immer noch gleichzeitig laut Log. Also keine extra eingebauten Verzögerungen.
Gruß
So ich habe gestern abend das Notify abgeändert und habe den "runter" Befehl nicht mehr an die structure geschickt sondern an jeden Rollladen einzeln aber in einem Befehl.
Aber auch das war leider nicht des Rätsels Lösung? Ein Rollladen fuhr laut Log wieder kurz runter und dann direkt wieder hoch ohne einen Befehl fürs Hoch zu bekommen.
Irgendwelche Ideen, wie man das Problem beheben kann?
Oder was würdest du benötigen Martin, um den Thema auf die Schliche zu kommen?
Gruß Christian
Hallo Christian,
du hast das Problem seit 26.4. Hast du da einen update gemacht? Welchen Version hattest du davor?
Wie oft tritt das Problem auf
Gruss
Martin
Hallo Martin,
ich habe am 26.04. keine Update gemacht. Das Update war am 24.04.
Seit 26.04.13 tritt das Problem nun jeden Abend auf, mal ein Rollladen mal auch zwei.
Und gestern Abend habe ich wieder ein Update gemacht und nun trat das Problem heute morgen auch mit meinem SZ_Rollladen auf.
013-05-01_09:00:00 SZ_Rolladen set_hoch
2013-05-01_09:00:00 SZ_Rolladen level: 3runter %
2013-05-01_09:00:00 SZ_Rolladen deviceMsg: 3runter % (to HMLAN1)
2013-05-01_09:00:00 SZ_Rolladen 3runter %
2013-05-01_09:00:00 SZ_Rolladen motor: up:3runter %
2013-05-01_09:00:00 SZ_Rolladen level: 33 %
2013-05-01_09:00:00 SZ_Rolladen deviceMsg: 33 % (to HMLANrunter)
2013-05-01_09:00:00 SZ_Rolladen 33 %
2013-05-01_09:00:00 SZ_Rolladen motor: down:33 %
2013-05-01_09:00:03 SZ_Rolladen level: 30 %
2013-05-01_09:00:03 SZ_Rolladen deviceMsg: 30 % (to HMLANrunter)
2013-05-01_09:00:03 SZ_Rolladen 30 %
2013-05-01_09:00:03 SZ_Rolladen motor: stop:30 %
Das Notify: define SZ_Rolladen_hoch_we at 09:00:00 set SZ_Rolladen hoch
Das letzte Update davor habe ich am 09.04.13 gemacht
2013.04.09 21:41:34 0: Server started with 63 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3053 2013-04-08 14:31:22Z rudolfkoenig $, pid 29119)
Gruß
Christian
Hallo Christian,
Das ist ziemlich gut zu reproduzieren.
Kannst du die roh-logs einschalten mit
attr global verbose 1
attr global mseglog 1
attr <hmlan> loglevel 1
Nach dem Fehler ein list des Device machen.
Gruss
Martin
Hallo Martin,
so nach umstellen der LogLevels war natürlich heute abend kein Fehler vorhanden.
Ich werde es beobachten und sobald der Fehler wieder auftritt das List vom betreffenden Rollladen posten.
Gruß
Christian
Hallo Martin,
so heute morgen war der Fehler nun wieder da.
Hier das List vom Rollladen:
Internals:
DEF 1B3F7A
EVENTS 6
HMLAN1_MSGCNT 6
HMLAN1_RAWMSG E1B3F7A,0000,A2937A31,FF,FFBB,BDA4101B3F7ACE771106010200
HMLAN1_RSSI -69
HMLAN1_TIME 2013-05-02 05:37:46
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 6
NAME WZ_NordOst_Rolladen
NR 51
NTFY_TRIGGERTIME 2013-05-02 05:37:46
STATE runter %
TYPE CUL_HM
lastMsg No:BD - t:10 s:1B3F7A d:CE7711 06010200
protCmdDel 0
protLastRcv 2013-05-02 05:37:46
protResnd 4 last_at:2013-05-02 05:37:39
protResndFail 1 last_at:2013-05-01 20:50:14
protSnd 3 last_at:2013-05-02 05:37:34
protState CMDs_done_events:5
rssi_HMLAN1 avg:-63.66 min:-65 max:-63 lst:-63 cnt:3
rssi_at_HMLAN1 avg:-67.83 min:-69 max:-67 lst:-69 cnt:6
Readings:
2013-05-02 05:37:40 CommandAccepted yes
2012-02-14 21:35:11 PairedTo 0xCE7711
2012-02-14 21:35:12 R-driveDown 19.8 s
2012-02-14 21:35:12 R-driveTurn 0 s
2012-02-14 21:35:12 R-driveUp 20.7 s
2012-02-14 21:35:11 R-pairCentral 0xCE7711
2013-05-02 05:37:46 deviceMsg 1 % (to HMLAN1)
2013-05-02 05:37:46 level 1 %
2013-05-02 05:37:46 motor stop:1 %
2013-04-12 14:17:36 powerOn -
2013-05-02 05:37:46 state 1 %
2013-04-04 20:21:43 virtLevel set_1
Helper:
burstEvtCnt 5
mId 006A
rxType 1
Respwait:
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
msg A0DBDA4101B3F7ACE771106010200::-69:HMLAN1
ts 1367465866.96402
ack:
HASH(0xd3f778)
BD8002CE77111B3F7A00
Rssi:
Hmlan1:
avg -63.6666666666667
cnt 3
lst -63
max -63
min -65
At_hmlan1:
avg -67.8333333333333
cnt 6
lst -69
max -67
min -69
Attributes:
devStateIcon hoch:shutter_open runter.*:shutter_closed halb:shutter_halfopen
eventMap on:hoch 1:runter 50:halb
expert 2_full
firmware 2.1
fp_EG 183,948,0,
model HM-LC-Bl1PBU-FM
peerIDs
room Wohnzimmer
serialNr JEQ0104791
subType blindActuator
webCmd hoch:runter:halb:stop
Gruß Christian
Hallo Christian,
hast du jetzt im Log die messages vom Fehlerfall? Die bitte auch noch schicken.
Gruss
Martin
Hallo Martin,
so nun komme ich dazu, die Auszüge aus dem Logfile zu Posten:
Logfile meiner Rollläden
2013-05-02_05:37:34 WZ_NordOst_Rolladen set_hoch
2013-05-02_05:37:39 WZ_NordOst_Rolladen level: 25 %
2013-05-02_05:37:39 WZ_NordOst_Rolladen deviceMsg: 25 % (to HMLANrunter)
2013-05-02_05:37:39 WZ_NordOst_Rolladen 25 %
2013-05-02_05:37:39 WZ_NordOst_Rolladen motor: up:25 %
2013-05-02_05:37:40 WZ_NordOst_Rolladen level: 27 %
2013-05-02_05:37:40 WZ_NordOst_Rolladen deviceMsg: 27 % (to HMLANrunter)
2013-05-02_05:37:40 WZ_NordOst_Rolladen 27 %
2013-05-02_05:37:40 WZ_NordOst_Rolladen motor: down:27 %
2013-05-02_05:37:46 WZ_NordOst_Rolladen deviceMsg: runter % (to HMLAN1)
2013-05-02_05:37:46 WZ_NordOst_Rolladen runter %
2013-05-02_05:37:46 WZ_NordOst_Rolladen motor: stop:runter %
Das Hauptlogfile von dem besagten Zeitraum habe ich als Datei angefügt.
Der betreffende Rollladen ist der "1B3F7A"
Ich hoffe das sind die Infos, welche du brauchst.
Sonst gebe mir einfach Bescheid, was ich noch tun kann, damit wir dem Fehler auf die Schliche kommen.
Gruß
Christian
Hallo Christian,
ich denke, ich habe das Problem identifiziert.
Werde (hoffentlich) heute Abend ein paar Tests machen und dann eine neue Version einchecken.
Gruss
Martin
Hallo,
hier noch einmal ein Status von mir:
Ich steuere jetzt seit 1 Woche die Rolläden mit einem sleep 0.5 kurz nacheinander an. Seit dem ist alles fehlerfrei gelaufen. Auch wenn dieser Workaround nicht die Lösung sein sollte zeigt er zumindest, dass die Probleme durch die gleichzeitige Ansteuerung anstehen.
Gruß
Georg
Hallo Martin,
ich habe gestern Abend dein Update geladen. (allerdings weiß ich nicht, ob dies mit meinem Problem zusammen hängt).
Aber heute Morgen sind alle 10 Rollläden ohne Probleme hoch gefahren.
Ich werde es beobachten.
Gruß
Christian
Hallo Martin,
konntest Du das Problem von Christian jetzt eigentlich schon fixen und im CVS einchecken?
Ich habe nämlich m. E. das gleiche Problem wie Christian, allerdings mit einem HM-LC-BL1-FM, und auch nicht so regelmäßig.
Zwar habe ich gestern (09.05.2013, ~13:26) geupdatet, und damit die "10_CUL_HM.pm 3159 2013-05-07" erhalten, aber heute morgen ist ein Rollo dennoch nicht hochgefahren, obwohl er ein "set_Auf" erhalten hat:
2013-05-10_05:24:16 Rollo_WohnF set_Auf
2013-05-10_05:24:20 Rollo_WohnF level: 0 %
2013-05-10_05:24:20 Rollo_WohnF deviceMsg: Zu (to HMLAN)
2013-05-10_05:24:20 Rollo_WohnF Zu
2013-05-10_05:24:20 Rollo_WohnF motor: stop:Zu
Der Befehl wurde übrigens via "at" abgesetzt:
define Rollo_std_hoch at *{sunrise("REAL",0,"05:15","09:00")} { if (!($we)) { fhem("set Rollo_Bad,Rollo_WohnT,Rollo_WohnF,Rollo_WC,Rollo_Kueche Auf");; } }
Viele Grüße
Salvador
Hallo Leute,
Ich habe das selbe Problem mit dem HM-LC-SW1-PL2. Mal schaltet er, und mal nicht. Ich habe ein Tuxradio 2 für FS20 und einen Hmlan im Einsatz. Als ich meine Homematic Komponenten nur über den integrierten CUL des Tuxradio 2 geschaltet habe(hatte noch kein FS20) hatte ich kein Problem, erst als ich auf HMLAN umgestiegen bin, ist es aufgetaucht. Es taucht sporadisch auf. Mein Schalten geht über folgenden Befehl :
define Einschalt at *06:55:00 { if (Value("Garageklein") eq "close" and $wday ==2 or $wday==3 or $wday==4) { fhem("set LampHM on-for-timer 1")}}
attr Einschalt room Garagen
Also nichts aufregendes.
Der Fehler taucht aber manchmal auch auf, wenn ich die Lampe über das Fontend mit set .. on schalte.
Jemand eine Idee?
Viele Grüße
Frank
Hi,
ich bin leider nicht viel weiter mit der Suche. Es scheint ein Problem eines 'alten' befehls in der command-Queue zu sein. Fakt ist, dass der Befehl von HMLAN gesendet wird aber nicht aus einem 'set' Kommando stammt.
Falls jemand noch logs hat waere gut.
Gruss
Martin
Hallo Martin,
wie gesagt,
bei mir läuft es interessanterweise seit dem 06.05.13 nun wieder ohne Probleme.
Bis auf das Update habe ich seit dem aber auch nichts weiter geändert.
@Martin: Da es ja evtl. ein Problem mit alten Befehlen ist: Hilft es die Logs der vorhergehenden alten Befehle (der vor dem Befehl mit den Problemen) mit zu loggen?
Ich hätte da sicher was anzubieten. Allerdings sind das halt ne Menge Einträge im Log.
Gruß
Christian