Abfrage, ob Device online

[mcfly71]

Hallo Gemeinde,

ich habe einen Aktor, der einen schlechten Empfang hat (Leider unumgänglich). Deshalb wollte ich vor dem Schalten des Aktors erstmal testen, ob die Kommunikation jetzt im  Moment ok ist. Daher hatte ich die Idee, einen statusRequest abzusetzen, danach den state zu checken auf "nicht" missing ack oder resend fail, das protokoll lastrecv zu checken und dann erst zu schalten.
Mein Problem ist: Baue ich das alles in eine Funktion ein, so liest der nicht die neuen Daten, sondern die alten Daten (sehe ich am protlastrecv.
Wie kann ich das synchron in einer Funktion verwirklichen, oder gibt es gar eine ganz andere Möglichkeit ??
Für eure Hilfe wäre ich sehr dankbar...

Hier eine version, die nicht funktioniert:
   #my $oldValue= "";
   #my $newValue= "";
   #my $datumZeitProtokoll= "";
   
   
   #$oldValue= InternalVal ( "ROLLO1", "STATE", "-1" );
   #return "offline" if ( ($oldValue eq "ResndFail") || ($oldValue eq "MISSING ACK") || ($oldValue eq "-1") );
   
   #fhem ( "set ROLLO1 statusRequest" );
   
   #$newValue= InternalVal ( "ROLLO1", "STATE", "-1" );
   #return "offline" if ( ($newValue eq "ResndFail") || ($newValue eq "MISSING ACK") || ($newValue eq "-1") );
   
   #$datumZeitProtokoll= InternalVal ( "ROLLO1", "protLastRcv", "-1" );
   #return "offline" if ( ($datumZeitProtokoll eq "-1") );
   
   #return "online: ".$oldValue."/".$newValue."/".$datumZeitProtokoll;

VG
mcfly

[justme1968]

ich denke das ist nicht der richtige ansatz. ich weiss ja nicht wie sich dein schlechter empfang auswirkt aber ich kann mir nicht denken das es hilfreich ist noch mehr zu senden. zumal es ja sein kann das der statusRequest geht und das senden danach wieder nicht.

der sicherere weg ist den aktor einfach zu schalten und danach zu schauen ob es geklappt hat. wenn es daran zweifel gibt dann noch mal versuchen. das prüfen und noch mal versuchen kannst du mit einem fhem sleep oder at etwas verzögert hinter den ersten schaltvorgang setzen. da kannst du dann prüfen ob der aktuelle status der ist den du erwartest.

das verzögern mit at oder sleep ist wichtig damit fhem zwischendurch weiter arbeiten kann. auch das abarbeiten des kommandos und die rückübermittlung dauert je nach kommando und empfangsbedingungen ja auch unterschiedlich lange. deshalb kann eine feste synchrone sequenz  nicht funktionieren.

ansonsten ist es vermutlich besser das übel an der wurzel zu packen und z.b. den hm repeater zu verwenden.

gruss
  andre

[martinp876]

Internal STATE wird von Reading state abgeleitet. Du kannst also prüfen, ob der timestamp des Readings state sich ändert
ReadingsTimestamp ( "ROLLO1", "stae", "-1").

CUL_HM prüft bei einem Rollo, ob der gewünschte Level erreicht wird und macht ggf. einen zweiten Versuch. Sollte dies nicht funktionieren wird "levelMissed"geschrieben. Das könntest du ggf nutzen, um noch einmal zu triggern.
Es arbeitet aber nur für level-einstellungen, nicht für andere Kommandos!

[mcfly71]

Hallo Martin und Andre,

die Ideen von euch hatte ich auch, nur:
@Andre: Das will ich gerade vermeiden, da ich bemerkt habe, dass es passieren kann, einen Aktor zu schalten, und fhem bekommt keine Rückmeldung, der Aktor aber defacto "an" ist, sodass die kritische Aktion jetzt "an" ist, aber fhem es eigentlich nicht weiss, somit habe ich dann Angst, dass fhem die Aktion nicht mehr stoppen kann (Ich würde das auch für eine Bewässerung benutzen nicht nur für Rollos und das ist kritisch).
Deshalb hatte ich die Idee zuerst mal zu testen, ob der Empfang und die Rückmeldung da ist.

@Martin: Die Timestamps geben denselben Datumswert zurück, wie auch meine bisherigen Readings.

Noch irgendwelche Ideen, ausser 1000e defines, die nach z.B. 3 sek. nach der statusRequest die Prüfung durchführen ?

VG
mcfly

[justme1968]

mit einem aktor der nicht zuverlässig schaltet die bewässerung zu steuern ist leichtsinnig.

du solltest dafür sorgen das der empfang klappt. siehe repeater.

wenn der empfang gestört sein kann hilf dir deine reihenfolge auch nicht. der request geht durch und das schalten danach hat ein problem. auch hier wäre es umgekehrt zuverlässiger. erst schalten und dann mit statusRequest noch mal nachschauen.

und selbst dann solltest du die bewässerung nur mit on-for-timer schalten. das läuft komplett im aktor und nach dem timeout schaltet der aktor selbständig ab. auch ohne empfang.

gruss
  andre

[martinp876]

@Martin: Die Timestamps geben denselben Datumswert zurück, wie auch meine bisherigen Readings.

wenn eine Antwort kommt muss das Datum geaendert werden. Wenn keine Autwort kommt wird am Device ein missingAck gemeldet. Am Channel nicht.

a) device und channel trennen
wenn dein Rollo die ID 123456 hat definieren den Channel
define RolloCh CUL_HM 12345601

nun kommt das missing ack in Device und ein erfolgreicher Status im Channel.

b) frage im reading state das Datum ab, wenn das Reading nicht missing ack ist

c) frage nach missingAck ab

[mcfly71]

Hallo Martin,

das mit dem channel verstehe ich nicht. Die Namensgebung ist auch für euch verwirrend, denn die rollos sind umgebaute devices. Ich verwende Rollotrons, die per HM-LC-SW1-BA-PCB geschaltet werden.
Worüber wir also hier sprechen ist obiges Device. Da sind dann keine channels (oder ?).


vg
mcfly

[martinp876]

Hi mcfly,

im Einsteigerdoc habe ich es ausführlicher erklärt (zumindest versucht):
jedes HM Geräte hat ein "device" welches das Protokoll bearbeitet. Auserdem hat es 1 oder mehrere Channel, welche die Aktionen ausführen - das ist immer so. Das Device verteilt die messages im Gerät an die Channel und kümmert sich um das Senden.
In FHEM ist jedes Device und jeder channel eine Entity. Im Status des Device sind die Protokollzustände zu sehen.

Ausnahme sind ein-channel devices. Hier wird nur eine Entity angelegt, die das Device UND den einen channel beinhaltet. Grund ist einzig, es nicht zu aufwändig aussehen zu lassen. Der STATE in diesem Fall ist nicht das Protokoll sondern der Channelstatus.

Du kannst eine ein-channel-entity jederzeit in 2 eintities aufspalten. Definiere also den Channel mit 01 am ende.
define actor_channel01 CUL_HM <hmIdDef>01
und du hast es aufgespaltet. Das kann man immer machen - ist eigentlich sauberer.
Gruß
Martin

[mcfly71]

Hallo Martin,

ok , dann werde ich das mal versuchen.... vielen Dank erstmal....

vg
mcfly