CUL_HM ROLLLADEN_GAST_1 repeat, level 00 instead of C8

Jens_B · 21 März 2014, 07:23:16

Hallo zusammen,
ich habe hier immer wieder im Logfile obengenanntes stehen. Wenn der ROLLLADEN_GAST_1 oder auch ein anderes Rollladen device geöffnet oder geshclossen wird.
Muß ich mir das Gedanken machen? Was hat das zu bedeuten?
Ich habe einen Weekdaytimer mit folgender Definition dort verwendet:

Code Auswählen

ROLLLADEN_GAST_1 05:40|auf ( (!$we) && (Value("ZEITSTEUERUNG") eq "an"))

Gruß
Jens

martinp876 · 21 März 2014, 08:07:13

Hi Jens,

da es Probleme gab (offensichtlich gibt) dass Rollos ein "setze Level 40%" nicht ausführen und mit "ok, bin bein 0% stehen gebleiben" quittieren ist eine Wiederholung für diesen Fall eingebaut worden.
In deinem Fall hast du 100% gewünscht, das Rollo hat geantwortet: Alles klar, bin bereits bei 0%. FHEM macht genau einen Versuch es zu wiederholen. Sollte auch der Schief gehen würde ein Fehler-reading erzeugt.

Es ist zumindest unschön, dass es passiert. Das Problem liegt bei HM. FHEM fängt es ab. Doppelfehler werden NICHT korrigiert sondern alarmiert.

Gruss Martin

Jens_B · 21 März 2014, 10:07:43

Ok, aber ich habe ja nicht Set 100% gemacht, sondern es wird morgens der Rollladen mit Set Rollladen auf (=on) gesendet. Und der Rolladen ist zu dem Zeitpunkt noch auf "zu"(=off) . Das passiert auch gelegentlich bei dem anderen Rollladen im Schlafzimmer.
Unter Umständen auch beim runterfahren abends.
Ist das Device defekt? oder sollte ich das einfach ignorieren?
Die Schalter sind übrigens alle gerad neu gekauft.
Gruß Jens

Gesendet von meinem iPad mit Tapatalk

martinp876 · 21 März 2014, 12:26:10

ob on oder 100, das ist identisch.
Das Device scheint nicht defekt, es ist irgend ein Bug in der HM FW - alles andere lässt sich nicht erklären.
Es liegt voraussichtlich nicht an 100% 0% oder einem sonstigen Wert - manchmal wird der Wert einfach nicht genutzt.
Du hast also kein defektes Device, das ist ein systematischer Fehler.

FHEM fängt das auf (ein Versuch). Sollte das Rollo einmal nicht fahren lass es mich wissen - bislang habe ich noch von keinem "nicht-fahren" gehört seit der Anpassung

Gruss Martin

Jens_B · 21 März 2014, 14:18:10

Ok, danke für deine ausführliche Erklärung. Bisher ist sind die Rollladen alle noch immer hoch gefahren. Allerdings habe ich sie auch erst seit einige Tagen im Einsatz.

Gesendet von meinem iPhone mit Tapatalk

Alcamar · 05 Juni 2015, 08:19:46

Ich habe neuerdings das gleiche Verhalten mit einem Rollladen. Morgens fahren 8 Rollläden hoch. Einer macht das nicht und liefert im Log die Fehlermeldung:

Code Auswählen

2015.06.05 05:56:42 3: CUL_HM XX_Jalousie_X repeat, level 00 instead of C8

Es kommt sporadisch mal vor, dass dieser und ein zweiter Rollo nicht hoch bzw. herunterfahren. Wenn ich im Web dann einfach ein "Status Request" klicke fährt der Rollo dann hoch bzw. runter. Er zieht also den zuletzt erhaltenen Befehl nach.

Um sicherzustellen, dass alle gesendeten Befehle abgearbeitet wurden, habe ich mir überlegt, ob ich nicht allen Rollos einfach ein "Status Request" standardmäßig (nach)schicke. Weiß aber nicht, ob geht bzw. ob es nicht eine bessere Alternative gibt.

Deudi · 05 Juni 2015, 09:31:13

Zitat von: Alcamar am 05 Juni 2015, 08:19:46
Es kommt sporadisch mal vor, dass dieser und ein zweiter Rollo nicht hoch bzw. herunterfahren. Wenn ich im Web dann einfach ein "Status Request" klicke fährt der Rollo dann hoch bzw. runter. Er zieht also den zuletzt erhaltenen Befehl nach.

Auch wenn es dir nicht weiter hilft: Genau den Effekt hatte ich auch mal vor ein paar Wochen. Ist seit dem letzten Update (siehe Sig.) nicht mehr aufgetreten.

martinp876 · 06 Juni 2015, 08:03:11

Kannst du ein log schicken ?
Haengt vermutlich mit der anzahl der rollos zusammen. Das mit dem statusrequest kenne ich noch nicht. Kannst du vor einem statusrequest ein list machen ? Koennte sein, dass noch kommandos haengen.... was nicht sein darf...

isy · 31 August 2015, 21:17:33

Hallo zusammen,
ich habe die Meldung im FHEM log heute zum ersten Mal festgestellt:
2015.08.31 20:48:38 3: CUL_HM ez_rollo_t repeat, level C8 instead of 00
2015.08.31 20:48:38 3: CUL_HM ku_rollo_l repeat, level C8 instead of 00
2015.08.31 20:48:39 3: CUL_HM ez_rollo_l repeat, level C8 instead of 00
2015.08.31 20:48:42 3: CUL_HM ez_rollo_r repeat, level C8 instead of 00
2015.08.31 20:48:43 3: CUL_HM ez_rollo_m repeat, level C8 instead of 00

Betrifft alle Rollladen, die in einer Gruppe bei Sonnenuntergang mit DOIF runtergefahren werden.
HMINFO mit RSSI meldet Werte um -60dB, ez_rollo_m mit -88 relativ schlecht heute (sonst besser, Ursache unklar), fuhr auch als letzter runter.
HF Pegel zu schlecht?

Update: Habe am gleichen Tag eine vccu aktiviert. Log geprüft, Meldungen kommen vorher nicht vor.

Gruß Helmut

All-Ex · 31 August 2015, 22:57:45

Bei mir kommen auch hin und wieder solche Meldungen. Die Meldungen kommen meistens, nachdem ich einen shutdown restart gemacht habe und dann das erste mal ein Rollo verändere. Ich nutze einen HM-LC-Bl1PBU-FM mit Firmware 2.3

Die Rollos fahren aber immer an die richtige Stelle. Hier mal als Beispiel ein Neustart und dann die Fahrt von 100 auf 90:

Zitat2015.08.31 22:34:33 0: Server started with 198 defined entities (version $Id: fhem.pl 9163 2015-08-30 07:57:51Z rudolfkoenig $, os linux, user root, pid 4714)
2015.08.31 22:34:33 1: HMLAN_Parse: hmlan1 new condition ok
[...]
2015.08.31 22:34:52 3: CUL_HM set rol.dg.sz.su.li statusRequest
[...]
2015.08.31 22:36:18 3: CUL_HM set rol.dg.sz.su.li 90
2015.08.31 22:36:18 3: CUL_HM rol.dg.sz.su.li repeat, level 00 instead of 14

Zitat2015-08-31_22:34:53 rol.dg.sz.su.li deviceMsg: on (to hmlan1)
2015-08-31_22:34:53 rol.dg.sz.su.li level: 100
2015-08-31_22:34:53 rol.dg.sz.su.li motor: stop:on
2015-08-31_22:34:53 rol.dg.sz.su.li pct: 100
2015-08-31_22:34:53 rol.dg.sz.su.li on
2015-08-31_22:34:53 rol.dg.sz.su.li timedOn: off
2015-08-31_22:36:18 rol.dg.sz.su.li level: set_90
2015-08-31_22:36:18 rol.dg.sz.su.li set_90
2015-08-31_22:36:18 rol.dg.sz.su.li deviceMsg: on (to hmlan1)
2015-08-31_22:36:18 rol.dg.sz.su.li level: 100
2015-08-31_22:36:18 rol.dg.sz.su.li motor: stop:on
2015-08-31_22:36:18 rol.dg.sz.su.li pct: 100
2015-08-31_22:36:18 rol.dg.sz.su.li on
2015-08-31_22:36:18 rol.dg.sz.su.li timedOn: off
2015-08-31_22:36:18 rol.dg.sz.su.li deviceMsg: on (to hmlan1)
2015-08-31_22:36:18 rol.dg.sz.su.li level: 100
2015-08-31_22:36:18 rol.dg.sz.su.li motor: up:on
2015-08-31_22:36:18 rol.dg.sz.su.li pct: 100
2015-08-31_22:36:18 rol.dg.sz.su.li on
2015-08-31_22:36:18 rol.dg.sz.su.li timedOn: off
2015-08-31_22:36:22 rol.dg.sz.su.li deviceMsg: 90 (to hmlan1)
2015-08-31_22:36:22 rol.dg.sz.su.li level: 90
2015-08-31_22:36:22 rol.dg.sz.su.li motor: stop:90
2015-08-31_22:36:22 rol.dg.sz.su.li pct: 90
2015-08-31_22:36:22 rol.dg.sz.su.li 90
2015-08-31_22:36:22 rol.dg.sz.su.li timedOn: off

martinp876 · 04 September 2015, 22:52:06

unklar, was es mit einer vccu zu tun hat.
Aber: nach welchen Kommando kommt das? Sinn ist es Rollos die manchmal nicht die gewünscht Position einnehmen noch einmal zu triggern. Das Problem ist, dass dein Rollo auf 90% soll und antwortet "bin auf 100, motor Stop".
Das ist sehr schade - und unklar. bei mir ist es nicht so - es kommt ein
"bin auf 100%, fahre hoch". Dann wartet FHEM bis der Motor still steht.
Meiner ist auch ein Bl1-PBU FW 2.3.
Die Abfrage ist notewndig um bei "falschfahren" einmal zu korrigieren.

gibt es auch messagelogs?

All-Ex · 05 September 2015, 08:34:39

Eine VCCU habe ich nicht im Einsatz, alles hängt direkt am HMLAN.

Gerade konnte ich das Verhalten nach einem Neustart von FHEM reproduzieren:

Code Auswählen

# $Id: fhem.pl 9195 2015-09-03 07:23:40Z rudolfkoenig $ 
# $Id: 10_CUL_HM.pm 9201 2015-09-04 21:28:56Z martinp876 $ 
# $Id: 00_HMLAN.pm 9103 2015-08-22 05:23:08Z martinp876 $

Code Auswählen

2015.09.05 08:26:12.209 3: CUL_HM set rol.dg.sz.su.re 40
2015.09.05 08:26:12.210 0: HMLAN_Send:  hmlan1 S:+336943,00,01,00
2015.09.05 08:26:12.210 0: HMLAN_Send:  hmlan1 S:S9C2F09C0 stat:  00 t:00000000 d:01 r:9C2F09C0 m:03 A011 8CF27A 336943 020178
2015.09.05 08:26:12.379 0: HMLAN_Parse: hmlan1 R:R9C2F09C0 stat:0001 t:02045589 d:FF r:FFC9     m:03 8002 336943 8CF27A 0101800036
2015.09.05 08:26:12.382 3: CUL_HM rol.dg.sz.su.re repeat, level 80 instead of 78
2015.09.05 08:26:12.479 0: HMLAN_Send:  hmlan1 S:S9C2F0A6E stat:  00 t:00000000 d:01 r:9C2F0A6E m:04 A011 8CF27A 336943 020178
2015.09.05 08:26:12.773 0: HMLAN_Parse: hmlan1 R:R9C2F0A6E stat:0001 t:0204571A d:FF r:FFC8     m:04 8002 336943 8CF27A 0101802036

rol.dg.sz.su.re ist ein HM-LC-Bl1PBU-FM mit Firmware 2.3.

Edit: Hier noch das Log vom Aktor ab dem Befehl set rol.dg.sz.su.re 40:

Code Auswählen

2015-09-05_08:26:12 rol.dg.sz.su.re level: set_40
2015-09-05_08:26:12 rol.dg.sz.su.re set_40
2015-09-05_08:26:12 rol.dg.sz.su.re deviceMsg: 36 (to hmlan1)
2015-09-05_08:26:12 rol.dg.sz.su.re level: 36
2015-09-05_08:26:12 rol.dg.sz.su.re motor: stop:36
2015-09-05_08:26:12 rol.dg.sz.su.re pct: 36
2015-09-05_08:26:12 rol.dg.sz.su.re 36
2015-09-05_08:26:12 rol.dg.sz.su.re timedOn: off
2015-09-05_08:26:12 rol.dg.sz.su.re deviceMsg: 36 (to hmlan1)
2015-09-05_08:26:12 rol.dg.sz.su.re level: 36
2015-09-05_08:26:12 rol.dg.sz.su.re motor: down:36
2015-09-05_08:26:12 rol.dg.sz.su.re pct: 36
2015-09-05_08:26:12 rol.dg.sz.su.re 36
2015-09-05_08:26:12 rol.dg.sz.su.re timedOn: off
2015-09-05_08:26:16 rol.dg.sz.su.re deviceMsg: 40 (to hmlan1)
2015-09-05_08:26:16 rol.dg.sz.su.re level: 40
2015-09-05_08:26:16 rol.dg.sz.su.re motor: stop:40
2015-09-05_08:26:16 rol.dg.sz.su.re pct: 40
2015-09-05_08:26:16 rol.dg.sz.su.re 40
2015-09-05_08:26:16 rol.dg.sz.su.re timedOn: off

Das Rollo ist an die richtige Stelle gefahren. Es gibt also "nur" die Meldung im Log.

All-Ex · 05 September 2015, 08:46:43

Hier noch ein zweiter Fall von einem anderen Rollo mit dem Befehl set rol.og.ga.li down. Das Rollo stand vorher auf 0%. Wenn der Fall auftritt sind immer alle Rollos betroffen.

Code Auswählen

2015.09.05 08:43:08.193 3: CUL_HM set rol.og.ga.li down
2015.09.05 08:43:08.194 0: HMLAN_Send:  hmlan1 S:+339354,00,01,00
2015.09.05 08:43:08.194 0: HMLAN_Send:  hmlan1 S:S9C3E8A70 stat:  00 t:00000000 d:01 r:9C3E8A70 m:03 A011 8CF27A 339354 0201B4
2015.09.05 08:43:08.357 0: HMLAN_Parse: hmlan1 R:R9C3E8A70 stat:0001 t:0213D6E5 d:FF r:FFD7     m:03 8002 339354 8CF27A 0101C80042
2015.09.05 08:43:08.360 3: CUL_HM rol.og.ga.li repeat, level C8 instead of B4
2015.09.05 08:43:08.469 0: HMLAN_Send:  hmlan1 S:S9C3E8B17 stat:  00 t:00000000 d:01 r:9C3E8B17 m:04 A011 8CF27A 339354 0201B4
2015.09.05 08:43:08.470 0: HMLAN_Send:  hmlan1 I:K
2015.09.05 08:43:08.623 0: HMLAN_Parse: hmlan1 V:03C4 sNo:LEQ0578982 d:2BACF9 O:8CF27A t:0213D7DF IDcnt:001F L:10 %
2015.09.05 08:43:08.758 0: HMLAN_Parse: hmlan1 R:R9C3E8B17 stat:0001 t:0213D876 d:FF r:FFD8     m:04 8002 339354 8CF27A 0101C82042

Code Auswählen

2015-09-05_08:43:08 rol.og.ga.li level: set_10
2015-09-05_08:43:08 rol.og.ga.li set_10
2015-09-05_08:43:08 rol.og.ga.li deviceMsg: off (to hmlan1)
2015-09-05_08:43:08 rol.og.ga.li level: 0
2015-09-05_08:43:08 rol.og.ga.li motor: stop:off
2015-09-05_08:43:08 rol.og.ga.li pct: 0
2015-09-05_08:43:08 rol.og.ga.li off
2015-09-05_08:43:08 rol.og.ga.li timedOn: off
2015-09-05_08:43:08 rol.og.ga.li deviceMsg: off (to hmlan1)
2015-09-05_08:43:08 rol.og.ga.li level: 0
2015-09-05_08:43:08 rol.og.ga.li motor: down:off
2015-09-05_08:43:08 rol.og.ga.li pct: 0
2015-09-05_08:43:08 rol.og.ga.li off
2015-09-05_08:43:08 rol.og.ga.li timedOn: off
2015-09-05_08:43:14 rol.og.ga.li deviceMsg: 10 (to hmlan1)
2015-09-05_08:43:14 rol.og.ga.li level: 10
2015-09-05_08:43:14 rol.og.ga.li motor: stop:10
2015-09-05_08:43:14 rol.og.ga.li pct: 10
2015-09-05_08:43:14 rol.og.ga.li 10
2015-09-05_08:43:14 rol.og.ga.li timedOn: off

martinp876 · 06 September 2015, 21:32:02

Nach meinem Verständnisses ein bug der fw. Mein aktor antwortet mit up oder down nach dem Kommando. Ich kann also ableiten, dass der zustand nicht final ist und warte. Dein aktor antwortet mit stop und dem level.fhem erkennt, dass der aktor steht (nicht regelt) und der gewünschte level nicht erreicht wurde wird noch einmal gesendet. Siehe da, dann klappte auch bei deinem aktor.
Wäre die Frage ob es auch ohne das resent geklappt hätte.die Funktion ist eingebaut, weil zumindest rolloaktoren ihren Endwert nicht erreichten