Rollladenaktor HM-LC-BL1-FM unzuverlässig

[Jojo11]

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

[Jojo11]

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[martinp876]

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

[hexenmeister]

Überprüfe die Einstellungen der Laufzeiten. Ich hatte schon einmal die komische Situation, dass ein Aktor diese 'vergessen' hatte.

[martinp876]

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

[hexenmeister]

hm - er sagt aber 100% und der Motor stoppt bei 0%.

Stimmt, das passt nicht dazu. Habe nicht aufmerksam gelesen   

[Jojo11]

hi Jo,

du hast sicher ein lustiges map am laufen, das die vielen 'down' schreibt.
[...]

Gruss Martin

Hallo,

danke Euch erstmal 
Was bedeutet denn "map"? Habe ich etwas falsch implementiert?
Ein typisches Kommando sieht bei mir so aus:

Code Auswählen Erweitern


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

[martinp876]

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.

[martinp876]

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

[Jojo11]

Hallo Martin,

das klingt für mich schonmal sehr vielversprechend. Werde ich heute abend mal testen. Vielen Dank!

schöne Grüße
Jo

[martinp876]

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

[Arek]

Bei mir funktionieren die Jalousieaktoren einwandfrei. Ich poste hier mal meine config, versuch sie einfach mal zu übernehmen.

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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")} }

[jhs]

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

[martinp876]

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

[Jojo11]

Hallo Martin,

als kurze Rückmeldung, die Rollladen fahren bisher zuverlässig. Allerdings hatte ich heute zum ersten Mal folgende log-Einträge:

Code Auswählen Erweitern


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 

schöne Grüße
Jo