Hallo zusammen,
ich beschäftige mich seit kurzem auch mit fhem - hauptsächlich für eine Rollladensteuerung. An dieser Stelle möchte ich mich erstmal für den hervorragenden support und das Projekt an sich bedanken! Viele Fragen konnte ich durch die Dokumentation und die zahlreichen Beiträge hier schon klären.
Nun aber zu meinem Problem:
Ich verwende 15 HM-LC-BL1-FM Unterputz-Rollladenaktoren und steuere diese mittels sunset/sunrise automatisch an. FHEM läuft bei mir in der aktuellsten Version auf einem Raspberry Pi mit HMLAN. Soweit funktioniert alles bestens. Ab und zu bleibt dabei ein Rolladen unten bzw. oben. Was ich festgestellt habe:
- Es sind so gut wie alle Rollladen betroffen.
- Es scheint nicht auf einen geringen RSSI-Wert zurückzuführen sein. Selbst Aktoren, die sehr nah am HMLAN stehen, sind betroffen.
- Ist ein Rollladen betroffen, zeigt sich ein seltsames Verhalten, welches ich hier in den diversen threads noch nicht gefunden habe: Wenn ich versuche, den betroffenen Rollladen manuell mittels Taster direkt am Aktor in die gewünschte Position zu fahren (auf oder zu), so fährt er pro Tastendruck nur ein kleines Stück (10% laut logfile).
- Der jeweilige Befehl ist angekommen, es findet sich kein MISSING ACK.
Gerne poste ich hier noch die entsprechenden log-files (vom jeweiligen Aktor oder den globalen?). Allerdings weiß ich nicht, welcher Detaillierungsgrad benötigt wird und wie ich diesen erhalte (verbose=x?).
Hier ein Auszug von heute morgen (Rollladen sollte hochfahren, blieb aber unten):
2013-08-28_06:31:05 az_R2 level: set_100
2013-08-28_06:31:05 az_R2 set_100
2013-08-28_06:31:05 az_R2 level: 0 %
2013-08-28_06:31:05 az_R2 deviceMsg: down (to HMLAN1)
2013-08-28_06:31:05 az_R2 down
2013-08-28_06:31:05 az_R2 motor: stop:down
2013-08-28_06:31:05 az_R2 level: 0 %
2013-08-28_06:31:05 az_R2 deviceMsg: down (to HMLAN1)
2013-08-28_06:31:05 az_R2 down
2013-08-28_06:31:05 az_R2 motor: up:down
2013-08-28_06:31:44 az_R2 level: 100 %
2013-08-28_06:31:44 az_R2 deviceMsg: up (to broadcast)
2013-08-28_06:31:44 az_R2 up
2013-08-28_06:31:44 az_R2 motor: stop:up
2013-08-28_06:31:51 az_R2 level: 100 %
2013-08-28_06:31:51 az_R2 deviceMsg: up (to broadcast)
2013-08-28_06:31:51 az_R2 up
2013-08-28_06:31:51 az_R2 motor: stop:up
schöne Grüße
Jo
Hallo Jo,
das mit den 10% - meine Vermutung:
wenn der Aktor an Ende ist (also 0% oder 100%) und man noch einmal "weiter" fahren will schaltet er noch einmal in die Richtung. Dabei rechnet er
0% -10 % = 0%
oder
100% + 10% = 100%
Das ganze macht sinn aus mehreren Gründen.
Scenario 1) man hat einen neuen Aktor, drive-time ist 50sec im Aktor(default) aber der Rollo braucht 70sec. Dann fährt der Rollo runter bis 0% (Aktor) aber beleibt eigentlich bei 30% (physik) stehen. Mit einem weiteren Tastendruck kann der User noch einmal runter fahren.
Scenario 2) Der Rollo steht auf 10% und der Storm fällt aus, kommt wieder. Der Aktor nimmt nach powerUp an, dass er bei 50% steht. Du kannst jetzt also sagen "fahre nach 100%" und der Aktor wird um 50% fahren, bleibt also bei 60% stehen (denkt er sei bei 100%). Jetzt kannst du noch 4-5 mal drücken, dann rechnet der Aktor 100% +4*10%=100%, aber der Rollo ist physikalisch auf 100%.
Hab ichs schön kompliziert erklärt?
Es könnte also sein, dass dein Aktor einen powerOn erhalten hat.
- ist das Scenario möglich?
- kannst du ein powerOn reading sehen?
- geht das fahren um 10% in beide Richtungen oder nur eine?
Gruss Martin
Hallo Martin,
die 10% finde ich leider nicht mehr in den log-files. Könnten auch andere Werte sein. Für einen kompletten Weg sind es aber ca. 10 Betätigungen.
Folgendes passiert: Das Rollo ist komplett geschlossen und soll öffnen (morgens). Leider bleibt es unten. Wenn ich nun manuell am Taster öffnen möchte, fährt er pro Tastendruck immer nur ein kleines Stück. Dies ist abends genauso, also Rollo ist oben und soll runter fahren, bleibt aber oben.
Leider tritt der Fehler natürlich nicht auf, wenn man ihn braucht. Gerade eben sind alle Rollladen ordnungsgemäß runtergefahren.
Die Fahrzeiten der Rollladen habe ich übrigens eingestellt. Das Relais fällt also ab, wenn der Rolladen in der jeweiligen Endposition angekommen ist (bzw. kurz danach).
Wenn Der Rollladen in einer Endposition ist, kann ich ihn ja auch nicht dazu bewegen, noch weiter zu fahren. Wenn er komplett oben ist und ich dann den Rauf-Taster betätige, dann passiert gar nichts. Das interne Relais zieht dann auch nicht an.
Scenario 1 kann ich eigentlich ausschließen, wegen der angegebenen Fahrzeiten. Scenario 2 ebenfalls, weil definitiv nicht der Strom ausgefallen ist.
>Hab ichs schön kompliziert erklärt?
Ja :)
Wenn ich drüber nachdenke geht das Fahren in "10%"-Schritten in beide Richtungen. Wenn ich also versuche, das Teil doch zu überreden und 3-4x drücke, mir es dann aber anders überlege und zurück will, geht es auch nur in kleinen Schritten.
>- kannst du ein powerOn reading sehen?
Wo/wie genau sehe ich das?
Beim nächsten Mal werde ich es mal genau notieren.
schöne Grüße
Jo
ZitatWenn Der Rollladen in einer Endposition ist, kann ich ihn ja auch nicht dazu bewegen, noch weiter zu fahren. Wenn er komplett oben ist und ich dann den Rauf-Taster betätige, dann passiert gar nichts. Das interne Relais zieht dann auch nicht an.
ist bei meinem definitiv nicht so. Zum einen "weiss" der Aktor nicht, ob ein Rollo am Endanschlag ist, sondern nimmt es nur an, zum anderen kann ich mein Rollo zum Endanschlag fahren und, wenn ich noch einmal drücke klackt der Aktor noch einmal (wieviel % weiss ich nicht)
hast du einmal statusRequest im Fehlerfall gemacht? Dann solltest du erfahren wo er Aktor glaubt zu stehen. Wäre ein wichtiger Hinweis
zum powerOn sollte es ein Reading geben, das auch so heisst
Gruss Martin
Hallo Martin,
ich habe jetzt nochmal ganz genau gehorcht und kann bestätigen, dass der Aktor auch in "Endposition" weiter anzieht, wenn ich den Taster drücke. Die Zeit, nach der er wieder abfällt, müßte ungefähr mit derjenigen zusammenpassen, die im Fehlerfall auftritt. Leider tritt der Fehler nach wie vor nicht wieder auf. Die beiden Infos bekommst Du, sobald wieder ein Rolladen stehen bleibt.
schöne Grüße
Jo
Hallo,
heute morgen sind wieder zwei Rollladen unten geblieben. Das log-file sieht dabei immer so aus:
2013-08-30_06:31:05 az_R2 level: set_100
2013-08-30_06:31:05 az_R2 set_100
2013-08-30_06:31:05 az_R2 level: 0 %
2013-08-30_06:31:05 az_R2 deviceMsg: down (to HMLAN1)
2013-08-30_06:31:05 az_R2 down
2013-08-30_06:31:05 az_R2 motor: stop:down
2013-08-30_06:31:06 az_R2 level: 0 %
2013-08-30_06:31:06 az_R2 deviceMsg: down (to HMLAN1)
2013-08-30_06:31:06 az_R2 down
2013-08-30_06:31:06 az_R2 motor: up:down
2013-08-30_06:31:51 az_R2 level: 100 %
2013-08-30_06:31:51 az_R2 deviceMsg: up (to broadcast)
2013-08-30_06:31:51 az_R2 up
2013-08-30_06:31:51 az_R2 motor: stop:up
Allerdings sehen die log-Einträge (zumindest in diesem Detaillierungsgrad) genau so aus, wie bei einem Rolladen, der tatsächlich gefahren ist.
Der Aktor scheint davon auszugehen, dass er wirklich gefahren sei. Die kleinen "10%"-Schritte beim Druck auf die hardware-Tasten treten nur in der Fahrtrichtung auf, die zuvor hätte gefahren werden sollen. Wenn er also hätte aufgehen sollen (morgens), dann kann ich in kleinen Schritten auffahren. Schließen benötigt jedoch nur einen Tastendruck. Abends ist es dann andersrum.
statusRequest versuche ich heute abend nachzuliefern.
schöne Grüße
Jo
Hi Jo,
klar is damit (wie du gesagt hast) - der Aktor ist der meinung gefahren zu sein. Er vermeldet nach 45sec ein 100%, also komplett offen. Wenn du also jetzt weiter nach oben willst, tritt in Kraft, was ich erklärt habe.
Sicher ist also, dass die message "fahre hoch" angekommen ist und - teilweise_ ausgeführt wird.
Die Frage ist also: Warum fährt der Aktor nicht, obwohl er es meldet. Es konnte ein Problem des Relais sein (hoffentlich nicht) oder ein SW bug im Aktor.
Das erste, was ich in Verdacht habe, den Aktor verwirren zu können ist das Zwangs-stop, das vor jedem fahren kommt. Da ich vermute, dass es eigentlich nicht gebraucht wird kannst du es einmal ohen probieren.
Datei im Anhang.
Hallo Martin,
vielen Dank für Deine Hilfe, die Datei werde ich gleich mal testen.
Ich habe mal mit
attr global verbose 5
versucht, ein paar mehr Details zu erhalten. Den relevanten Ausschnitt habe ich mal angehängt. Diesmal ist der Aktor "gz2_R" nicht hochgefahren.
schöne Grüße
Jo
Hi Jo,
dein Rollo gz2_R vermeldet, dass er nach 29sec seine 100% erreicht hat.
- das war nicht mit der neuen Datei? Das stop kommt immer noch
- deine Rollos sind nicht mit FHEM gepairt? Da könnten statusmessages verloren gehen.
Martin
Hallo Martin,
angegeben hatte ich für diesen etwas weniger:
set gz2_R regSet driveUp 24
Richtig, das war noch bevor ich die neue Datei eingebaut habe. Mit der neuen Datei sind heute Morgen alle Rollladen wie gewünscht hochgefahren. Mal sehen, was heute Abend passiert.
Eigentlich hatte ich alle Aktoren mit fhem gepairt:
set HMLAN1 hmPairForSec 600
und dann jeweils >4s den entsprechenden Taster gedrückt. Das hat eigentlich für alle geklappt.
Kann ich das bedenkenlos wiederholen oder zerschießt mir das die fhem.cfg wieder?
schöne Grüße
Jo
Nachtrag: Auch heute Abend sind alle Aktoren zuverlässig heruntergefahren. Die modifizierte Datei scheint die Situation in der Tat zu verbessern.
schöne Grüße
Jo
Hi Jo,
ich habe eine "erweiterte" version in
http://forum.fhem.de/index.php?t=msg&goto=93257&rid=251#msg_93257 (//forum.fhem.de/index.php?t=msg&goto=93257&rid=251#msg_93257)
bereitgestellt. vielleicht kannst du diese auch probieren? Ich wünsche mir einen breiteren test vor der "breiten" einführung - die Änderungen sind zu komplex....
Gruss Martin
Hallo Martin,
danke, werde ich gleich einspielen und testen.
schöne Grüße
Jo
Hallo,
nachdem meine Rollladen jetzt sehr zuverlässig gelaufen sind, habe ich vorgestern ein update gemacht (26.10.2013). Heute Morgen sind zum ersten Mal seit Langem mal wieder zwei Rolladen unten geblieben :-\
Ich weiß natürlich nicht, ob das auf das Update zurückzuführen ist, wollte es aber dennoch mal melden. Davor hatte ich die Version vom 20.10.2013. Typischer Auszug aus dem log-file:
2013-10-28_06:36:36 wz_R1 level: set_100
2013-10-28_06:36:36 wz_R1 set_100
2013-10-28_06:36:36 wz_R1 level: 0 %
2013-10-28_06:36:36 wz_R1 deviceMsg: down (to HMLAN1)
2013-10-28_06:36:36 wz_R1 down
2013-10-28_06:36:36 wz_R1 running: -
2013-10-28_06:36:36 wz_R1 motor: up:down
2013-10-28_06:37:13 wz_R1 level: 100 %
2013-10-28_06:37:13 wz_R1 deviceMsg: up (to broadcast)
2013-10-28_06:37:13 wz_R1 up
2013-10-28_06:37:13 wz_R1 running: -
2013-10-28_06:37:13 wz_R1 motor: stop:up
2013-10-28_06:38:36 wz_R1 level: 100 %
2013-10-28_06:38:36 wz_R1 deviceMsg: up (to HMLAN1)
2013-10-28_06:38:36 wz_R1 up
2013-10-28_06:38:36 wz_R1 running: -
2013-10-28_06:38:36 wz_R1 motor: stop:up
Ergebnis ist wie immer: Das Gerät meint, in Endposition zu sein. Man muss dann halt mehrmals den Taster drücken, um das Teil wirklich hoch zu fahren.
schöne Grüße
Jo
Hallo Jo,
einen Zusammenhang mit einem der updates sehe ich nicht, da am Blind nichts geaendert wurde.
Es sieht so aus:
Rollo war 0% um 36:36
Rollo meldet 100% um 37:13, also nach 37 sec.
=> wie lange dauert das hoch fahren normal?
Gruss Martin
Hallo Martin,
definiert habe ich 32 s für R-driveUp, was auch so ungefähr passt. 37 s ist also mehr als genug.
Heute sind wieder alle Rollladen zuverlässig gefahren. Ich werde mal weiterhin beobachten.
schöne Grüße
Jo
Hallo,
ich habe mal wieder ein seltsames Phänomen beobachtet. Morgens fahren bei mir alle Rollladen hintereinander hoch. Meistens klappt das sehr zuverlässig, manchmal bleibt der eine oder andere unten (und abends andersrum halt).
Heute sind auf einen Schlag 5 Stück mitten in der Sequenz nicht gefahren. Ein Auszug aus dem log sieht so aus:
2014-02-17_07:08:15 wz level: set_100
2014-02-17_07:08:15 wz set_100
2014-02-17_07:08:15 wz level: 0 %
2014-02-17_07:08:15 wz pct: 0
2014-02-17_07:08:15 wz deviceMsg: down (to HMLAN1)
2014-02-17_07:08:15 wz down
2014-02-17_07:08:15 wz timedOn: down
2014-02-17_07:08:15 wz motor: stop:down
Das bedeutet doch eigentlich, dass fhem weiß, dass er nicht gefahren ist, oder? Manuell ließen sie sich fahren, als seien sie nicht gefahren (1x Taster betätigen = volle Fahrt nach oben). Weiterhin findet sich im log nichts Auffälliges (keine HMLAN disconnects oder dergleichen).
Wenn es funktioniert, sieht es eher so aus:
2014-02-16_08:30:59 wz level: set_100
2014-02-16_08:30:59 wz set_100
2014-02-16_08:30:59 wz level: 0 %
2014-02-16_08:30:59 wz pct: 0
2014-02-16_08:30:59 wz deviceMsg: down (to HMLAN1)
2014-02-16_08:30:59 wz down
2014-02-16_08:30:59 wz timedOn: down
2014-02-16_08:30:59 wz motor: up:down
2014-02-16_08:31:35 wz level: 100 %
2014-02-16_08:31:35 wz pct: 100
2014-02-16_08:31:35 wz deviceMsg: up (to broadcast)
2014-02-16_08:31:35 wz up
2014-02-16_08:31:35 wz timedOn: down
2014-02-16_08:31:35 wz motor: stop:up
Es fehlt also der zweite Teil, nachdem der Rollladen gefahren ist :-\
An der Funkverbindung kann es nicht liegen - es gibt Aktoren, die viel schlechtere Verbindungen haben und dennoch gefahren sind.
Ich gebe die Befehle zum Fahren der Rollladen in 5s-Abständen, da ich dachte, es sei zuverlässiger, als alle Befehle gleichzeitig zu geben. Kann das einen Unterschied machen? Es läuft wie geschrieben eigentlich sehr zuverlässig.
FHEM aktualisiere ich beinahe täglich.
schöne Grüße
Jo
hi Jo,
du hast sicher ein lustiges map am laufen, das die vielen 'down' schreibt.
Wichtig ist, dass der Motor 'stop' sendet obwohl die 100% nicht erreicht sind. Ich vermute HM hat ein designproblem in den messages. Die messagelaenge wird wohl nicht geprueft, und es gibt keine pruefsumme ueber die message. daher scheint bei messages gleichen Formats aber mit optionalen Parametern die optionalen(aber wichtigen) gelegentlich irgendwo verloren zu gehen (und wenn es im Empfaenger ist).
Wenn ich es richtig sehe kommt man nicht umhin hier eine end2end ueberwachung zu erstellen (war schon gelegentlich gefordert...)
Ich werde einmal nachdenken, wie man dies machen kann.
Gruss Martin
Überprüfe die Einstellungen der Laufzeiten. Ich hatte schon einmal die komische Situation, dass ein Aktor diese 'vergessen' hatte.
hm - er sagt aber 100% und der Motor stoppt bei 0%. Ausserdem geht es ohne re-programming am Abend wieder....
da faellt mir auf:
tritt so eine Problem auch auf, wenn du statt pct 100 (oder 100) ein set on/off nutzt?
Das koennte ein Hinweis sein, woran sich ein Blind verschlucken koennte
Gruss Martin
Zitathm - er sagt aber 100% und der Motor stoppt bei 0%.
Stimmt, das passt nicht dazu. Habe nicht aufmerksam gelesen :-[
Zitat von: martinp876 am 18 Februar 2014, 08:07:02
hi Jo,
du hast sicher ein lustiges map am laufen, das die vielen 'down' schreibt.
[...]
Gruss Martin
Hallo,
danke Euch erstmal :D
Was bedeutet denn "map"? Habe ich etwas falsch implementiert?
Ein typisches Kommando sieht bei mir so aus:
define wz_runter at *{sunset(0,"16:00:00","22:00:00")} set wz 0
Es ist richtig, dass ich in meinen Kommandos immer "set 100" oder "set 0" schreibe, und nicht "set off" oder "set on". Kann das einen Unterschied machen?
Heute sind übrigens alle Rollladen wieder brav hoch- und abends runter gefahren ???
schöne Grüße
Jo
on/off und pct macht keinen unterschied - hatte ich geirrt.
Demnach sieht es nach einer echten schwachstelle bei HM aus - oder einem schlichten Bug. Das Kommando wird akzeptiert und beantwortet aber aus irgendeinem Grund falsch interptetiert. Nachdem ich so garkeinen Grund erkennen kann, das ein Problem ausserhalb des Aktors besteht gibt es auch keins zu loesen. Somit muss man es mit einer end2end ueberwachung loesen.
Ich werde einmal nachdenken.
Hi Jo,
es ist seit heute eine Version drin, die auf den Endwert abfragt. Da sollte also nichts mehr dazwischen kommen koennen.
Und genau das ist auch ein Problem. Wenn du also von FHEM dein Rollo von 0% auf 100% faehrst - in 1 min - und dann von ausserhalb FHEM ein stop oder fahre-nach-0-% triggerst (irgend eine remote) wird das Rollo dies ausfuehren. FHEM wird dann aber (bei Stop) merken, dass es noch nicht 100% sind und einfach noch einmal auf 100% schalten - bis es erreicht ist.
=> so kann das nicht bleiben.
a) FHEM wird nur einen Versuch/repeat machen.
b) peering laesst sich nicht schnell und sicher feststellen - insbesondere da user ihre registerlisten und peerlisten - insbsondere bei remotes und buttondevices nicht aktuell halten. Ich werde pauschal einbauen, dass bei einem Button-press "in Richtung des Device" alle wiederholungen ALLER CHANNELS dieses Device gestoppt werden.
c) den trigger internen Peers kann ich nicht abfangen - hier muss option a) greifen
d) signalisierung
ich werde ein reading ausdenken, dass einen Fehler wirft, so das Ziel des FHEM kommands nicht erreicht wird. Name muss ich noch ausdenken (vorschlaege?)
Damit sollte das ganze maximal 'passiv' sein.
Gruss Martin
Hallo Martin,
das klingt für mich schonmal sehr vielversprechend. Werde ich heute abend mal testen. Vielen Dank!
schöne Grüße
Jo
Du solltest einen Log-eintrag sehen - sonst kommt keine Meldung.
Provizieren kannst du es, indem du das Kommando absetzt (FHEM) und vor erreichen und "stop" ueber einen Taster ein anderes Kommando absetzt.
Wenn du also von 0% ein set 100% sendest und dann per remote ein
- stop => rollo stoppen und faengt wieder an
- 0% => rollo stoppt und faehrt auf 0%, Nach Stop faehrt FHEM auf 100%
Aktuell versucht FHEM endlos die 100% zu erreichen - bis es klappt - und zwar immer wenn der Rollo (und Dimmer) das Ende der Aenderung signalisiert (also stop).
Ab morgen nur noch ein Versuch - dann ein Reading. Wer will kann dann noch ein Notify einbauen, der dies beliebig oft wiederholt.
Im Fehlerfall (ab Morgen) wird ein reading
levelMissed <level>
kommen - wenn nach einem Versuch das Ziel nicht erreicht wird.
Gruss Martin
Bei mir funktionieren die Jalousieaktoren einwandfrei. Ich poste hier mal meine config, versuch sie einfach mal zu übernehmen.
define WZ_Rollladen CUL_HM 220CEC
attr WZ_Rollladen IODev HMLAN
attr WZ_Rollladen alias Wohnzimmer: Rollladen
attr WZ_Rollladen autoReadReg 4_reqStatus
attr WZ_Rollladen devStateIcon 0:fts_shutter_100:Auf \d:fts_shutter_100:Auf 1\d:fts_shutter_90:Auf 2\d:fts_shutter_80:Auf 3\d:fts_shutter_70:Auf 4\d:fts_shutter_60:Auf 5\d:fts_shutter_50:Auf 6\d:fts_shutter_40:Auf 7\d:fts_shutter_30:Zu 8\d:fts_shutter_20:Zu 9\d:fts_shutter_10:Zu 100:fts_window_2w:Zu down.*:fts_shutter_down:Stop up.*:fts_shutter_up:Stop
attr WZ_Rollladen eventMap on:Auf 080:Halbschatten 050:Schatten 015:Zu 001:Dunkel stop:Stop
attr WZ_Rollladen expert 2_full
attr WZ_Rollladen firmware 1.7
attr WZ_Rollladen fp_Grundriss 269,371,0,
attr WZ_Rollladen group Rollladen
attr WZ_Rollladen model HM-LC-BL1-FM
attr WZ_Rollladen peerIDs 00000000,
attr WZ_Rollladen room Wohnzimmer
attr WZ_Rollladen serialNr XXXXXXXXXX
attr WZ_Rollladen stateFormat { if (ReadingsVal("WZ_Rollladen","motor",0) =~ /^d/){ sprintf("%s", ReadingsVal("WZ_Rollladen","motor",0));; } elsif (ReadingsVal("WZ_Rollladen","motor",0) =~ /^u/) { sprintf("%s", ReadingsVal("WZ_Rollladen","motor",0));; } else { sprintf("%.0f", ReadingsVal("WZ_Rollladen","level",0));; } }
attr WZ_Rollladen subType blindActuator
attr WZ_Rollladen webCmd Auf:Halbschatten:Schatten:Zu:Dunkel:Stop
define FileLog_WZ_Rollladen FileLog ./log/WZ_Rollladen-%Y.log WZ_Rollladen
attr FileLog_WZ_Rollladen logtype text
attr FileLog_WZ_Rollladen room CUL_HM
define WZ_Rolladen_Automatik dummy
attr WZ_Rolladen_Automatik alias Wohnzimmer: Rollladenautomatik
attr WZ_Rolladen_Automatik devStateIcon An|on:fts_shutter_automatic:off Aus|off:fts_shutter_manual:on
attr WZ_Rolladen_Automatik eventMap on:An off:Aus
attr WZ_Rolladen_Automatik fp_Grundriss 220,371,0,
attr WZ_Rolladen_Automatik group Rollladen
attr WZ_Rolladen_Automatik room Wohnzimmer
define WZ_Rolladen_Auf at *{sunrise("HORIZON=-3.0",0,'07:00',)} { if ( Value("WZ_Rolladen_Automatik") eq "on" or "An") {fhem("set WZ_Rollladen on")} }
Hallo,
ich bin heute auf dieses Thema hier gestossen und kann bestätigen, mit unserm HM_LC_BL1_SM dieselbe "Unzuverlässigkeit" usw. verhielt es sich auch so wie beschrieben.
Mir fehlt das Hintergrundwissen, ob das ein "bug" oder ein "feature" von HM ist. Auf jeden Fallwar es nicht das, was ich von der Rolladenstuerung erwartet habe und haben wollte.
Meine Lösung - quick and dirty - Befehl jeweils 2x kurz hintereinander losschicken. Seitdem ist der Spuk vorbei.
Da ich diese nicht so schöne "Lösung" nur bei diesem Aktor beobachtet habe, tippe ich in Richtung "feature" ;-) das ich aber nicht benötige.
Aus meiner .cfg Datei zu diesem Aktor:
# cmd aktor_rolladen_wohnzimmer DOWN # aus bel. Stellung 5 sec RUNTER
# cmd aktor_rolladen_wohnzimmer UP # aus bel. Stellung 5 sec RAUF
# cmd aktor_rolladen_wohnzimmer OFF # aus bel. Stellung RUNTER bis End-Schalter
# cmd aktor_rolladen_wohnzimmer ON # aus bel. Stellung RAUF bis End-Schalter
define atc04_rolladen_wz_runter at *{sunset("CIVIL",0,"16:30","22:30")} set aktor_rolladen_wohnzimmer off
# repeat
define atc04a_rolladen_wz_runter at *{sunset("CIVIL",60,"16:30","22:30")} set aktor_rolladen_wohnzimmer off
#
#
define atc07_rolladen_wz_rauf at *{sunrise("CIVIL",900,"07:00","09:30")} set aktor_rolladen_wohnzimmer on
# repeat
define atc07a_rolladen_wz_rauf at *{sunrise("CIVIL",960,"07:00","09:30")} set aktor_rolladen_wohnzimmer on
Vielleicht hilft dieser Praxis-Tipp oder es findet sich eine plausible Erklärung, um das nicht gewollte Verhalten des Aktors zu vermeiden.
jhs
hi jhs,
ich kann wenig feature erkennen, aber viel bug...
das doppelte senden sollte nicht mehr notwendig sein mit der aktuellen Version. FHEM prueft auf den Endstand.
Gruss Martin
Hallo Martin,
als kurze Rückmeldung, die Rollladen fahren bisher zuverlässig. Allerdings hatte ich heute zum ersten Mal folgende log-Einträge:
CUL_HM wR5 repeat, level C8 instead of 00
CUL_HM aR2 repeat, level C8 instead of 00
Ich hoffe, das hat nur Gutes zu bedeuten ;D
schöne Grüße
Jo
Hi Jo,
nun, wie man es sieht. zwei mal sind die Rolladen nicht gefahren (schlecht) - es wurde wiederholt. Danach war alles gut (gut).
Hätte das wiederholen keinen Erfolg gehabt wäre das Reading "levelMissed" gesetzt worden. Ist nicht eingetreten, also wieder "gut"
Gruss Martin
Danke. Bleibt natürlich die Frage, warum sie nicht beim ersten Versuch gefahren sind. An der Funkverbindung liegt es sicherlich nicht und disconnected war der HMLAN auch nicht. Dann begebe ich mich mal auf die Suche ::)
schöne Grüße
Jo
Heute Morgen trat wieder bei einem der Rollladen ein repeat, level 00 instead of C8 auf. Und der steht ca. 3 m vom HMLAN entfernt. Es scheint so, als hätte Deine Änderung in der Tat geholfen :) Danke dafür!
schöne Grüße
Jo
Hallo,
der Thread ist zwar etwas älter, aber mein Problem scheint hierher zu passen...
Seit ein Paar Tagen (seit der Zeitumstellung, ob nun Zufall ist oder nicht) spielen meine HM-Aktoren verrückt.
Per AT fahren sie abends runter iund nach einer Minute wieder hoch. Alle ziemlich gleichzeiztig. Man muss sie dann schon 1-2 Mal aus FHEM per Hand antriggern, damit endlich Ruhe ist. Manchmal fährt dann 5 Min später doch noch eine hoch >:(
Im Log findet sich etwas in der Art:
2015.10.28 14:00:00 3: CUL_HM EG_HA_SA01.Zirkulationspumpe repeat, level 00 instead of C8
2015.10.28 14:06:00 3: CUL_HM EG_HA_SA01.Zirkulationspumpe repeat, level C8 instead of 00
2015.10.28 15:30:00 3: CUL_HM EG_HA_SA01.Zirkulationspumpe repeat, level 00 instead of C8
2015.10.28 15:36:00 3: CUL_HM EG_HA_SA01.Zirkulationspumpe repeat, level C8 instead of 00
2015.10.28 16:45:00 3: CUL_HM EG_HA_SA01.Zirkulationspumpe repeat, level 00 instead of C8
2015.10.28 16:51:06 3: CUL_HM EG_HA_SA01.Zirkulationspumpe repeat, level C8 instead of 00
2015.10.28 17:06:37 3: CUL_HM sz_rollo repeat, level C8 instead of 46
2015.10.28 17:06:38 3: CUL_HM wz_rollo_l repeat, level C8 instead of 00
2015.10.28 17:06:38 3: CUL_HM wz_rollo_r repeat, level C8 instead of 00
2015.10.28 17:06:38 3: CUL_HM kb_rollo repeat, level C8 instead of 46
2015.10.28 17:06:39 3: CUL_HM ka_rollo repeat, level C8 instead of 46
2015.10.28 17:06:55 3: CUL_HM sz_rollo repeat, level 46 instead of C8
2015.10.28 17:06:56 3: CUL_HM kb_rollo repeat, level 46 instead of C8
2015.10.28 17:06:56 3: CUL_HM sz_rollo repeat, level 46 instead of C8
2015.10.28 17:06:56 3: CUL_HM kb_rollo repeat, level 46 instead of C8
2015.10.28 17:07:56 3: CUL_HM ku_rollo repeat, level 00 instead of C8
2015.10.28 17:14:23 3: CUL_HM wz_rollo_l repeat, level C8 instead of 00
2015.10.28 17:14:23 3: CUL_HM wz_rollo_r repeat, level C8 instead of 00
2015.10.28 17:17:11 3: CUL_HM bz_rollo repeat, level 00 instead of C8
2015.10.28 17:23:08 3: CUL_HM ku_rollo repeat, level 00 instead of C8
2015.10.28 17:23:08 3: CUL_HM kb_rollo repeat, level 46 instead of C8
2015.10.28 17:23:47 3: CUL_HM ka_rollo repeat, level 46 instead of C8
2015.10.28 17:23:48 3: CUL_HM sz_rollo repeat, level 46 instead of C8
2015.10.28 17:23:54 3: CUL_HM wz_rollo_l repeat, level 00 instead of C8
2015.10.28 17:23:54 3: CUL_HM wz_rollo_l repeat, level 00 instead of C8
2015.10.28 17:23:59 3: CUL_HM wz_rollo_r repeat, level 00 instead of C8
2015.10.28 17:32:22 3: CUL_HM bz_rollo repeat, level 00 instead of C8
2015.10.28 17:36:05 3: CUL_HM wz_rollo_l repeat, level 28 instead of 00
2015.10.28 17:36:05 3: CUL_HM wz_rollo_r repeat, level 28 instead of 00
2015.10.28 17:36:38 3: CUL_HM wz_rollo_l repeat, level 26 instead of 00
2015.10.28 17:36:38 3: CUL_HM wz_rollo_r repeat, level 26 instead of 00
2015.10.28 17:36:59 3: CUL_HM wz_rollo_r repeat, level 2A instead of 00
2015.10.28 17:37:43 3: CUL_HM wz_rollo_l repeat, level 38 instead of 26
2015.10.28 17:38:27 3: CUL_HM wz_rollo_l repeat, level 26 instead of C8
2015.10.28 17:38:27 3: CUL_HM wz_rollo_r repeat, level 27 instead of C8
2015.10.28 17:38:27 3: CUL_HM ku_rollo repeat, level 00 instead of C8
2015.10.28 17:38:27 3: CUL_HM sz_rollo repeat, level 46 instead of C8
2015.10.28 17:38:27 3: CUL_HM kb_rollo repeat, level 46 instead of C8
2015.10.28 17:38:28 3: CUL_HM ka_rollo repeat, level 46 instead of C8
2015.10.28 17:47:30 3: CUL_HM bz_rollo repeat, level 00 instead of C8
Was könnte hier falsch laufen?
was du mit falsch laufen meinst...???
klar ist es ein Problem, daher auch die Behebung. Es ist schlecht, wenn man wiederholen muss. Aber besser man wiederholt.
Eine Bessere Lösung ist nicht zu sehen. Man könnte noch langsamer schalten - am besten warten bis der Rollo gefahren ist, dann der nächste.
Kurz - ich habe keine Lösung, kollisionen zu vermeiden - ich versuche mit ihnen umzugehen. dazu zählt der repeat, einmalig. genauso wie das msgrepeat.
Sollte es konkrete Probleme geben brauche ich die msglogs und die Kommandos/Aktionen.
Zitat von: martinp876 am 29 Oktober 2015, 20:58:11
was du mit falsch laufen meinst...???
Naja, das Problem ist ja, dass die Rolladen zuerst zwar geschlossen werden, dann aber nach 1-2 Minuten wieder alle oben sind. :( Die Befehle werden quasi wieder revidiert. Früher (ich nehme an mit einer älterer CUL_HM Version) das Problem nie trat nie auf. Konfiguration habe ich nicht geändert.
Die Aktionen sind einfach, einem Aktor wird ein Wert gesendet und sofort tritt meist ein repeat. Das führt aber nicht immer dazu, dass der letzte Befehl revidiert wird:
2015.10.29 21:20:01 3: CUL_HM set wz_rollo_l 0
2015.10.29 21:20:01 3: CUL_HM wz_rollo_l repeat, level 02 instead of 00
Ist mir ein Rätsel....
Kann gerade nicht nachstellen passiert irgendwie nur beim ersten herunterfahren.
Gerade habe ich ein Rollo hoch und wieder herunter gefahren, war aber unauffällig...
2015.10.29 21:33:46.845 0: HMLAN_Send: HMLAN1 I:-1B689D
2015.10.29 21:33:47.026 0: HMLAN_Parse: HMLAN1 R:E416C78 stat:0000 t:009309CC d:FF r:FFAE m:3E A011 416C78 1B689D 0201C8
2015.10.29 21:33:47.154 0: HMLAN_Parse: HMLAN1 R:E1B689D stat:0000 t:00930A4B d:FF r:FFA4 m:3E 8002 1B689D 416C78 0101001048
2015.10.29 21:34:07.454 0: HMLAN_Send: HMLAN1 I:K
2015.10.29 21:34:07.463 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0101517 d:26ECA7 O:416C78 t:009359AD IDcnt:002A L:9 %
2015.10.29 21:34:19.038 0: HMLAN_Parse: HMLAN1 R:E416C78 stat:0000 t:00937220 d:FF r:FFAF m:3F 8002 416C78 1B689D 00
2015.10.29 21:34:31.923 0: HMLAN_Parse: HMLAN1 R:E416C78 stat:0000 t:0093B313 d:FF r:FFAD m:40 A011 416C78 1B689D 020100
2015.10.29 21:34:31.935 0: HMLAN_Parse: HMLAN1 R:E1B689D stat:0000 t:0093B391 d:FF r:FF9C m:40 8002 1B689D 416C78 0101C8204C
2015.10.29 21:34:32.463 0: HMLAN_Send: HMLAN1 I:K
2015.10.29 21:34:32.474 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0101517 d:26ECA7 O:416C78 t:0093BB61 IDcnt:002A L:9 %
2015.10.29 21:34:56.915 0: HMLAN_Parse: HMLAN1 R:E1B689D stat:0000 t:00941AD7 d:FF r:FFA1 m:41 A410 1B689D 416C78 06010000
2015.10.29 21:34:56.931 0: HMLAN_Send: HMLAN1 I:+1B689D,00,00,
2015.10.29 21:34:57.012 0: HMLAN_Send: HMLAN1 S:+1B689D,00,00,00
2015.10.29 21:34:57.013 0: HMLAN_Send: HMLAN1 S:SB54F7E75 stat: 00 t:00000000 d:01 r:B54F7E75 m:41 8002 416C78 1B689D 00
2015.10.29 21:34:57.200 0: HMLAN_Parse: HMLAN1 R:RB54F7E75 stat:0002 t:00000000 d:FF r:7FFF m:41 8002 416C78 1B689D 00
2015.10.29 21:34:57.471 0: HMLAN_Send: HMLAN1 I:K
2015.10.29 21:34:57.480 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0101517 d:26ECA7 O:416C78 t:00941D15 IDcnt:002B L:9 %
Ich lasse logging laufen, vlt. sieht man morgen mehr...
Danke schon mal für die Mühe! :)
02 instead of 00
Es ist bei 1% stehen geblieben. 0 war beauftragt, also noch einmal senden.
Zitat von: martinp876 am 29 Oktober 2015, 22:33:19
02 instead of 00
Es ist bei 1% stehen geblieben. 0 war beauftragt, also noch einmal senden.
Was komisch ist, die Befehle werden korrekt ausgeführt. Die Rolladen stehen zumindest so, wie sie sollen. Und dann, nach paar Minuten fahren auch alle wieder hoch. Wie verhext. ;D
Ich hoffe, ich habe morgen einen Log von dieser Situation.
Hallo,
ich habe noch mal meine Scripte durchgesehen, ich habe eine dunkle Vorahnung, evtl. bin ich selbst an dem Problem schuld. Ich prüfe das und melde mich morgen wieder. Vielen Dank erstmal!
Grüße,
Alexander
Hallo Martin!
Ich nehme alles zurück und behaupte das Gegenteil ;D
Das Problem habe ich gefunden, war ein 'wildgewordener' Script von mir, das zu dieser Jahreszeit gar nicht erst aktiv sein solle. In Verbindung mit der Zeitumstellung entstand letztendlich das Problem.
Vielen Dank für Deine Mühe!
Grüße,
Alexander