Licht aus Befehl

Hallo,
schalte ich damit 100%ig

das Licht bzw einen HM Schalter aus ?
Will erst per HM Statusabfrage den Zustand prüfen, und falls der auf ON steht, soll er den AbschaltBefehl senden, solange
bis der HM Schalter Status auf OFF ist, und dann das Script beenden.
danke schon mal.


$id = 12742 /*[Backend\Physikalische Instanzen\Obergeschoss\Wintergarten\Licht\HomeMatic Gerät 2er oben innen]*/;
do
{
$svs=IPS_GetStatusVariableIdents($id);
if(@HM_RequestStatus($id, $svs[0]) === true)
{
HM_WriteValueBoolean($id, "STATE", false);
}

}
while($svs === false);

Das erinnert mich an den Ostfriesenwitz, bei dem der Ostfriese einen Stein und ein Streichholz verwendet, um das Licht auszuschalten. Mit dem Stein wirft er die Birne kaputt und mit dem Streichholz geht er nachsehen, ob es auch wirklich aus ist… :wink:

Im Ernst, was genau soll diese Schleife bezwecken? Höhere Verlässlichkeit? Ich bezweifle, dass das bei HM so funktioniert bzw. Sinn macht.

naja der einfache HM WriteBoolean oder so ist manchmsl über den Lan Adapter nicht so verläslich. Drum die Kontrolle.
Konstruktive Vorschläge erbeten.
obwohl Ostfriesenwitze auch net sind.

jepp, sehe ich auch so.

daher fütter ich meine bewegungsmelder skripte nur noch mit

HM_WriteValueFloat(59107 /[Grundstück\Haus\EG\Eingangsbereich\Licht]/ , „ON_TIME“, 120);
HM_WriteValueBoolean(59107 /[Grundstück\Haus\EG\Eingangsbereich\Licht]/, „STATE“, true);

das ist aber auch ohne sichere kontrolle, oder ?

Wird im Aktor ausgeführt und funktioniert deshalb normalerweise zuverlässig :rolleyes:

Gruß
Bruno

Ändert sich die lokale STATE-Variable in IPS denn wirklich nur dann, wenn der Aktor den Befehl tatsächlich empfangen und verstanden hat?

Wenn es so wäre, dann würde dein Ansatz ja prinzipiell Sinn machen, wobei ich mich dann fragen würde, warum IPS dieses Problem nicht selbst behandelt. Mir fiele spontan jedenfalls kein Fall ein, in dem man trotz BiDi ein „fire & forget“ machen will. Das Mindestmaß an intelligentem Verhalten, dass eine fehlgeschlagene Sendung wiederholt wird, hätte ich jetzt eigentlich als Standard erwartet.

Vielleicht habe ich aber auch nur Glück bei meinem Setup.

Wenn der Befehl nicht ankommt, keine Veränderung, wie auch :wink:

warum IPS dieses Problem nicht selbst behandelt. Mir fiele spontan jedenfalls kein Fall ein, in dem man trotz BiDi ein „fire & forget“ machen will. Das Mindestmaß an intelligentem Verhalten, dass eine fehlgeschlagene Sendung wiederholt wird, hätte ich jetzt eigentlich als Standard erwartet.

Macht HM selber, bis 10x, dann nicht mehr. Trotzdem kommen manche Befehle nicht an. Einfach mal im Forum schauen, Dauerthema :rolleyes:

Vielleicht habe ich aber auch nur Glück bei meinem Setup.

Ja :slight_smile:

Gruß
Bruno

Danke, wieder was gelernt. Ich bin ja ganz froh dass ich von dieser Problematik bislang verschont worden bin.

Im Zweifel würde ich selbst allerdings wohl eher dazu tendieren, einen weiteren LAN-Adapter einzusetzen, anstatt mich auf solche potentiellen Endlosschleifen zu verlassen (wenn der Aktor gar nicht reagiert läuft man fix auf ein Skript Timeout bzw. müllt sich die Queue zu).

Naja ich glaube an dem HM_RequestStatus Befehl stimmt was nicht.
weil wenn ich den so ausprobiere klappt es nicht, das der Status vom Aktor ausgelesen wird und in die Variable überträgt.


$id = 55658 /*[Backend\Physikalische Instanzen\Untergeschoss\Bürozimmer\Licht\HomeMatic Gerät]*/;
$s1 = HM_RequestStatus($id);
if ($s1 === true)

{
Setvalue(23544 /*[Test Area\licht\std]*/,true);
}
else
{
Setvalue(23544 /*[Test Area\licht\std]*/,false);
}

Über das Skript kann ich auf die Schnelle nix sagen, die Status-Variable wird jedoch immer aktualisiert, von dem her kannst Du doch die abfragen.

naja ich habs auch das der Befehl im IPS ausgegührt wird bzw das Script ausgeführt wurde, aber der Aktor nicht den Status geändert hat. Der State im IPS der Homematicinstanz ist aber dann nicht der den der Aktor tatsächlich hat. Drum möchte ich den Aktor Status nochmal abfragen unf ggf erneut den Befehl senden.

Hab auch in meiner Lan Adapter Software sehr oft Servicemeldungen. Hauptsächlich „Gerätekomunikation war gestört“.
mit freundlichen Grüßen
and merry Chrismas

Das ist jetzt aber wirklich exakt das, was ich befürchtet habe und weswegen ich eingangs auch bemerkte, dass diese Schleife in meinen Augen keinen Sinn hat. :rolleyes:

Ganz ehrlich, das Problem ist algorithmisch nur behelfsmäßig zu umgehen. Da muss, um sauber Abhilfe zu schaffen, ein weiterer LAN-Adapter her, oder dessen Position geändert werden. Zumal wenn du dauernd UNREACH-Fehler hast.

Hast Du bei der Instanz den Haken bei „Status emulieren“ drin ?

also der Lan Adapter ist zu manchen Aktoren nur 2,5 Meter weg von der Positionierung dürfte ein 2. Lan Adapter keinen Sinn machen.

Ja die emulation ist an. hmmm ich glaub worauf du hinaus willst. Aber erzähl mal.

mit freundlichen Grüßen

Such selbst oder denk nach was das sein bzw. bewirken könnte :wink: :rolleyes:

naja die state Variable dürfte dann den realen Zustand des Aktors wieder spiegeln, wenn die Emulation aus ist.
Ich werds mal umstellen und nochmal prüfen.

Gewonnen :smiley: :smiley:

thx

dann werd ich mal die Schleife nochmal ausprobieren obs dann funzt.

also irgendwie rutscht doch noch immer mal ein verkehrter Status durch und ich bräuchte doch eine konkrete Abfrage vom ips an den Aktor nur hab ich nicht so recht die Ahnung das mit dem HM_ RequestStatus durchzuführen.
hat da einer von euch ein Bsp. vielleicht ?