Frage zu den Internals eines Rolladen-Aktors

[misave]

Hallo zusammen,

ich habe ein merkwürdiges Problem mit einem Eintrag in den Internals eines Rolladenaktors.

ich betreibe zwei HMLAN1 und HMLAN2. Das betroffene Rollo hat seit einigen Tagen ein Missing ACK und die DOIF zum Runterfahren am Abend mit twilight startet nicht, ebenso wenig das morgentliche at auch nicht. Also habe ich zunächst nach den RSSI-werten der HMLAN geschaut. HMLAN2 hat -103 (steht am weitesten entfernt) HMLAN1 hat immer um die -80. Ich habe in den Attributes eingetragen:
IOgrp VCCU:HMLAN1 (ja ich weiß, ich muss die ANgabe des HMLAN nicht machen, kann ich aber)

in den Internals steht:
IODev: HMLAN2
LASTInputDev: HMLAN1

also habe zunächst das Attrribute IODev in der attr-Button-Zeile auf HMLAN1 gesetzt. Sofort springt der Eintrag in den Internals bei IODev auch auf HMLAN1.

SObald ich ein Kommando an den Aktor sende in der Kommandozeile oder mit dem Schieberegler wird das Kommando ausgeführt und der Eintrag in den Internals bei IODev springt sofort wieder auf HMLAN2.

Mir erscheint dieses erneute Rückspringen auf IODev: HMLAN2 unlogisch und falsch.

Und nun beim ausprobieren kommt erneut ein Missing ACK und die Rolllade fährt gar nicht.

Und wenn ich einige Zeit (1-2 min) warte geht es plötzlich wieder.

Spielt hier vielleicht die maximal erlaubte Funklast eine Rolle? Ich sende aber nur wenige Befehle. Speziell am Morgen um die Rolllade hochzufahren wird nichts anderes gesteuert, denn wir sind ja gar nicht zu Hause unter der Woche zu dieser Zeit.

Ich bin ratlos, was aber als 10%-Fachmann kein Wunder ist...

Danke für eure Hilfe...

[martinp876]

Attribut iodev muss dich nicht intereßieren. Ein default hmlan würde ich immer angeben, wenn es sich um stationäre devices handelt.
Fhem empfängt immer auf allen IOs( die etwas empfangen). Lastinputdevice, der Name ist Programm. Von diesem device wurde die letzte Nachricht empfangen. Es hängt mit Laufzeiten zusammen, wer der letzte ist.
Iogrp regelt das senden, nicht das empfangen. Ein lastoutputdevice gibt es nicht. Attr iodev ist quasi eins.
Einfach ruhig bleiben alles wie es soll.

[misave]

Hallo Martin,

schon mal danke. Ich lass es dann so, ich kann mir denken, dass das HMLAN2 mit schlechtem RSSI Wert trotzdem den Befehl an den Rollladenaktor sendet und somit das letzte HMLAN ist welches zum Aktor durchgedrungen ist.

Ich habe den DOIF Befehl, der morgens die Rolllade gemäß Twilight-Wert die Rolllade hochfahren sollte, mal deaktiviert. Das Log-file des Aktors hat seit vier Tagen morgens um die 08.53 - 08:47 (Aufrufzeit des DOIF) den Befehl NICHT ausgeführt und das MISSING ACK in den Status geschrieben und die Rolllade blieb unten.

Für heute morgen hatte ich das DOIF disabled und durch ein schlichtes *at 09:30 ersetzt. Und siehe da, die Rolllade fuhr ordnungsgemäß hoch.

Das DOIF hat aber viele Tage richtig funktioniert, aber eben seit einigen Tagen nicht.

Wird der DOIF-Befehl anders abgesetzt als ein Befehl aus einem *at?

Oder aber irgendwie ist Zauberei und Zufall im Spiel. Die Standorte der beiden HMLAN haben sich nicht geändert.

[Otto123]

Hallo Michael,

da beide RSSI nicht so toll sind, vielleicht willst Du etwas basteln.

Der Sendebefehl von at und DOIF  wird ja immer von HM übernommen und ist identisch. Einzig die Zeitpunkte spielen dabei eventuell eine Rolle.

Bei RSSI um die 80 und schlechter ist alles zwischen geht immer und geht gar nicht möglich. Ich sage mal, da kann der Luftdruck oder Sonne eine Rolle spielen 

Gruß Otto

[misave]

Ich gucke mal mit dem Basteln.

Ich betreibe ja schon zwei HMLAN, damit es halbwegs läuft. Der raspi mit der Software steht im Keller, ein HMLAN ist im Keller für die Fensterkontakte, der zweite HMLAN im Wohnzimmer für die devices auf dieser Etage, oben sind dann die Schlafzimmer und das entfernte Zimmer (Diagonal auf einer Hausseite entfernt) ist der "schlechte Aktor". Im Zimmer oberhalb des HMLAN funktioniert die Rollade dort problemlos, im noch weiter entfernten Bad auf der oberen Etage ist es auch kein Problem. Ich beobachte mal ob der at* besser durchkommt, obwohl es ja keinen Grund dafür gibt.