Rolladenaktor sendet "falschen" Status

[Finn]

Hallo zusammen,

eigentlich möchte ich nur einen Rolladen (HM-LC-Bl1-FM) via Astrofunktion morgens hoch und abends runterfahren.
Mein Problem ist jedoch, dass mein Aktor auf wundersame Weise nach einer automatischen Fahrt meiner CCU einen falschen Status mitteilt. Um dies genauer nachzuvollziehen habe ich die Protokollierung für diesen Aktor eingeschaltet.

Folgendes Programm nutze ich:


So sieht das Ergebnis aus:


Wie man sieht fährt der Rolladen wie gewünscht von 0% auf 100% hoch. Einige Zeit später wird jedoch wieder der Status "0%, geschlossen" gesendet. Der Rolladen fährt jedoch nicht herunter, er wurde auch nicht manuell gefahren.
Ich habe kein weiteres Programm, in dem der Aktor verwendet wird. Woran kann diese falsche Statusmeldung liegen?

[Familienvater]

Hi,

keine Ahnung woher das kommt, so langsam glaube ich an einen Fehler in der Firmware, Du bist der 3.?, der von dem Problem berichtet.
Hast Du LAN-RF-Gateways bei Dir im Einsatz?
Welche Firmware läuft auf der CCU1/2/Raspi?
Wie lange läuft Deine Zentrale normalerweise bis zu einem Reboot?

Da ich Homeputer CL nutze, habe ich für mich einfach einen Workaround eingebaut, wenn der Rolladen zur Entscheidungszeit angeblich schon den gewünschten Zustand hat, frage ich den Aktor explizit nach seinem Zustand, und entscheide danach nochmal neu, ob doch gefahren werden muss. Das ist aber in der WebUI "ein Krampf"...
Da mein Workaround bei mir Funktioniert, habe ich es auch nicht weiter verfolgt, ob das Problem noch auftritt, ich müsste mal meine Logs durchsuchen, ich meine ich hätte Ausschriften eingebaut, ob und wie oft das bei mir noch vorkommt. Gefühlt hat es mit der Laufzeit der Zentrale zu tun, ist die erst vor kurzem neu gestartet gab es gefühlt weniger Probleme, ich habe auch 2 Lan-RF-Gateways im Einsatz, von daher auch der Gedanke, ob irgend ein Gateway das Event noch mal mit deutlicher Verspätung erneut meldet, und es der rfd deshalb als neues Event und nicht als Wiederholung ansieht.
Was mit aktuell beim Schreiben noch so kommt:
Schau mal, auf wieviele Sendewiederholungen Dein Aktor eingestellt ist. Falls die Losfahr-Meldung mit bidirektionalem Handshake gesendet werden würde, und es würde dabei Funkprobleme geben, dann könnte es sein, das der Aktor die intern "puffert", als muss ich nochmal später versuchen, die erneut zu senden, und der Aktor das fataler Weise auch macht, nachdem er die Ankunftsmeldung erfolgreich übertragen hat.

Der Familienvater

[Familienvater]

Hi,

ich habe meine Logs durchsucht, und ich hatte nur im Oktober/November 2017 Probleme, seit dem nicht mehr. Ich bin aber auch seit dem Jahreswechsel von einer CCU2 auf piVCCU mit FW 2.29.23 umgestiegen, IIRC gab es aber auch HPCL-User die das gleiche Problem auf einer Raspberrymatic hatten, von daher ist es eher Plattform-unabhängig, aber mein piVCCU hat noch keine Uptime von 200+ Tagen (und zum Problem-Zeitpunkt bei mir war IIRC noch eine 2.21.x auf der CCU2), und ich hatte damals auch einfach die LAN-Rf-Gateways mal neu gestartet, und dann war gefühlt Ruhe.

Der Familienvater

[Finn]

Hey,

aus der Vergangenheit kann ich leider nicht so viel berichten, da dies meine ersten Rollladenaktoren sind. Ich konnte dieses Problem jedoch bereits direkt nach dem Einbau feststellen. Zu diesem Zeitpunkt lief bei mir noch die FW 2.29.23 (Raspberrymatic).
Vor wenigen Tagen habe ich dann ein FW-Update auf 2.31.25 durchgeführt und auf einen möglichen Bugfix gehofft. Leider keine Änderung.
Ich habe keine LAN-RF-Gateways im Einsatz und meine Zentrale läuft normalerweise problemlos bis zu einem Firmwareupdate o.ä. durch. Jedoch tritt das Problem bei mir eindeutig unabhängig von der uptime auf.

Über einen Workaround, in meinem Fall via openHab, habe ich auch schon nachgedacht. Schöner wäre jedoch so eine einfache Funktion direkt via WebUI-Programm lösen zu können... Aktuell fahre ich die Rollläden einfach ohne Abfrage der aktuellen Position.

Vielen Dank für deine Nachforschungen. Wenn es bei dir jedoch mittlerweile mit der FW 2.29.23 funktioniert, scheint es wohl eher doch ein Plattform-abhängiges Problem zu sein?

[Wortmann30]

Hallo zusammen,

das gleiche beobachtete ich auch vor einer weile, ins besondere hat es mir in meiner App Pocket Control den falschen Status gezeigt. Auf die WebUI habe ich nie geschaut.
Ich wusste das er oben ist oder unten aber die Anzeige in der App zeigte was anderes.

Habe das irgendwie immer ignoriert und toleriert bis ich das hier gelesen habe. Es war ja nur ein Aktor der das so macht.
Ich werde das jetzt nochmals genauer beobachten und protokollieren lassen.

Ich nutze RM mit aktueller Firmware und zwei weitere RM als LAN Gateway.

[Black]

Ich habs so bisher noch nicht beobachtet, habe aber grade mal bei mir in IObroker die Werte der Aktoren auf History gestellt, damit schreibt er auch mit. mal sehen, ob da was rauskommt.
Wobei ich noch kein abnormales fahren erlebt habe, sonst hätt meine Frau auch schon gemeckert.

Gruss, Black

[Wortmann30]

So habe beim Umstellen auf die Protokollierung was festgestellt das dieser Problemaktor einen Menüpunkt nicht hat...

Als ich alle mal auf die neue FW upgedatet hatte machte dieser damals Probleme, da er im Boot loder Modus hängen blieb.
Erst durch viele Klimmzüge ließ er sich wieder reanimieren...

Seht selbst ein Normaler Aktor:

Und der Fehlerhafte:

Der Menüpunkt Statusmeldungen Mindesverzögerung ist nicht da...
Beide haben die Firmware 2,11 drauf.

Wie kann man denn die FW update nochmals anstoßen? Der Knopf wird hier nicht mehr geboten wie sonst...

Zu mindest habe ich nun mal die beiden letzten Menüpunkte die auf 0 standen angepasst das sollte auch schon helfen.

@Finn

Schau doch mal bei dir nach ob das da gleich aussieht? Vielleicht ist das auch dein Problem.

[Black]

ein firmwareupdate des aktores müsstest eigentlich unter devconfig erzwingen können, wenns ich es richtig im kopf hab.

[Wortmann30]

So habe das FW update über devconfig gemacht.

Ist aber unverändert. Der Menüpunkt Statusmeldungen Mindesverzögerung ist immer noch nicht da.

Browser wurde neu gestartet und cash geleert.

Ich hatte nämlich eben genau das verhalten vor dem update. Der Rolladen wurde manuell hoch gefahren. in der App und in der WebUI wurde noch zu angezeigt.

Nach dem Update ist es allerdings noch gleich....

Wenn ich mir die Signale auf dem DBTV stick ansehe wird im Moment wenn ich über WebUI oder App sende auch Funkverkehr gezeigt. Fahre ich direkt per Tastendruck des Gerätes bleibt der Funkverkehr allerdings aus.

Vielleicht mal warten was FINN dazu sagt ich will ihm das Thema auch nicht stehlen

[manfredh]

...Browser wurde neu gestartet und cash geleert...

Dann sollten wir mal für dich sammeln?

[sorry, bei dieser Steilvorlage...]