Rolladenaktor sendet "falschen" Status

[Wortmann30]

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

Dann sollten wir mal für dich sammeln?

[sorry, bei dieser Steilvorlage...]

Schon gut
Wenn du Rechtschreibfehler findest kannst sie behalten

[Finn]

Hi Wortmann30,

bei mir sehen die Einstellungen des Aktors so aus (2.11):


Komischerweise ist das Problem heute nicht aufgetreten, der Rolladen ist 2x gefahren und der Status wurde korrekt übertragen.


Einzige Änderung ist jedoch nur, dass ich die Abfrage (nur Prüfen) der Behanghöhe im Programm entfernt habe.. Zufall?
EDIT: Problem besteht weiterhin.

[Finn]

Die Änderung am Programm hatte wohl doch nichts damit zu tun, der Aktor sendet weiterhin willkürlich einen falschen Status...

[Finn]

Hat vielleicht noch jemand eine Idee zu diesem Problem? Ich konnte es leider noch nicht lösen.. Der Aktor sendet weiterhin willkürlich einen falschen Status..


(Der Rollladen ist geöffnet)

[ubecker]

Hallo,
ich habe gerade in meinem LOG mal nachgesehen, seit August letzten Jahres bis heute ist das 8 mal bei mir vorgekommen. Da ich wie Familienvater auch mit HPCL arbeite habe ich auch dort das abgefangen so das es nicht auffällt.
Der Fehler der bei mir auftritt ist immer das ein Funkpacket von dem Aktor zur CCU verloren geht.
Der Rolladenaktor bekommt den Befehl zum Fahren danach schickt der Aktor mehrmals einen Stand.
Befehl auf
Aktor 100% (Zahnrad auf der WebUi an)
Aktor 0% (Zahnrad auf der WebUi an)
Aktor 100% (Zahnrad auf der WebUi aus)
(oder so ähnlich können auch Zwischenwerte stehen)
Auf jeden Fall sollte nach Laufzeit + Statusverzögerung der richtige Wert als Status dort stehen.
Wenn das letzte Packet verlogen gegangen ist bleibt aber in der CCU das Zahnrad stehen (Aktor in Betrieb)

Wenn jetzt bei mir nach einer gewissen Zeit noch nicht der Richtige Status vorhanden ist wird der Befehl erneut geschickt.

Warum bei dir nach Stunden ein neuer Status kommt kann ich nicht beantworten
gruß Udo

[Familienvater]

Hi,

wie gesagt, das Problem ist erstmal, das wir nicht wissen, wer der Versender/Ursprung der doppelten Pakete ist, ob die per Funk in die Zentrale kommen, oder ob der rfd irgendwann wiederholt unter "achso, hab ich Dir schon gesagt, der Aktor ist unten..." leidet.
Wenn es bei Dir gehäuft auftritt, und Du hättest eine zweite "unbenutzte" Zentrale (mit anderer Funkkennung), dann könnte man die als neutrale Instanz mitloggen lassen, und wüsste so, ob es über Funk kommt, oder ob es nach dem Empfang intern passiert, man bräuchte aber dann noch einen externen Syslogserver, damit das Syslog 24h aufgezeichnet werden könnte (man weiß ja nicht, wann es genau passiert).

Der Familienvater

[NickHM]

Wenn das letzte Packet verlogen gegangen ist bleibt aber in der CCU das Zahnrad stehen (Aktor in Betrieb)

Guten Morgen

das ist bei mir seit Jahren schon so. Mit verschiedenen HM Rolllladenaktoren.
Das führt dann dazu, dass ein Rollladen nicht gefahren wird, weil er laut CCU schon den richtigen Zustand hat. In der WebUi steht noch das Zahnrad von der letzten Fahrt vor 8....12 Std.

Der Fehler tritt ca. alle 12 Wochen mal auf. Oder öfter und ich bemerke es nicht. Denn am nächsten Morgen / Abend stimmt es dann wieder

[Familienvater]

Hi,

ich denke, man muss unterscheiden zwischen "Ende der Fahrt"-Meldung, die verloren geht (Zahnrad bleibt), und den spontan empfangenen Meldungen, das der Rolladen plötzlich seinen alten Status (vom losfahren) wieder haben soll.

Der Familienvater

[AndiN]

Hallo,

ich hatte das früher auch. Meiner Meinung nach wurde ein "Zwischenpaket" nach gesendet. Weil bei mir blieben die Rollos dann auf 1% und WORKING.

Habe das dann mit einem Skript (übergangsweise) gelöst gehabt. Nach dem Motto:
Wenn Rollo Tag oder Nacht = Tag bei Änderung
Dann Rollo XY fahren
Verzögert um 120 Sekunden ein Skript, wenn Rollo noch Working dann Rollo Stop. Dann hat die CCU den richtigen Status empfangen und gut war.

Wenn ich es heute machen würde, würde ich vermutlich zur Sicherheit noch die letzten Timestamp mit abfragen.

Hier war ein Teil der damaligen Lösung. Und hierdas Problem was ich damals hatte.

Andi

[Finn]

Hi,
Wenn es bei Dir gehäuft auftritt, und Du hättest eine zweite "unbenutzte" Zentrale (mit anderer Funkkennung), dann könnte man die als neutrale Instanz mitloggen lassen, und wüsste so, ob es über Funk kommt, oder ob es nach dem Empfang intern passiert, man bräuchte aber dann noch einen externen Syslogserver, damit das Syslog 24h aufgezeichnet werden könnte (man weiß ja nicht, wann es genau passiert).

Das klingt schon mal interessant. Da es mindestens einmal am Tag, meist sogar öfters auftritt, finde ich das schon etwas viel. Ich würde eigentlich gerne die richtige Behanghöhe abfragen können.

Würde sich eine alte CCU1 zum mitloggen eignen? Diese hätte ich noch rumliegen. Wie müsste ich diese Einrichten, damit der Funkverkehr mitgeloggt wird? Einen Syslogserver kann ich auf meinem RaspberryPi installieren.