wie würde das mit dem @ aussehen, bei dem Befehl?
HM_WriteValueBoolean(55143, "STATE", true);
Einfach ein @HM_WriteValueBoolean(55143, „STATE“, true); ? Das wusste ich bisher nicht.
Ja genau so.
Michael
Die Information über den aufgetretenen Fehler sollte aber nicht verloren gehen; ich schreibe das innerhalb einer function in ein eigenes Protokoll:
function HMwriteBoolean ($InstanzID, $Parameter, $Wert=true) {
...
if (@HM_WriteValueBoolean ($InstanzID, $Parameter, $Wert)) {
return TRUE;
} else {
$Ausgabe = "HM-Fehler bei '" . $Parameter . "' [$Wert] an Instanz $InstanzID ";
IPS_RunScriptEx (LogZeile, Array ('Meldung' => $Ausgabe, 'IDnr' => $_IPS['SELF']));
... //Fehler abspeichern
return FALSE;
}
}
Viele Grüsse
Harald
Hallo,
ich bin der Sache mit den Abbrüchen in der Kommunikation zu bestimmten Komponenten etwas zu Leibe gerückt.
Und zwar habe ich mir den GitHub - psi-4ward/AskSinAnalyzerXS: Analyzer for radio telegrams in a HomeMatic environment eingerichtet, der in Kombination mit einem nanoCUL die komplette Kommunikation mit protokolliert und und erlaubt nachträglich zu schauen, das im Homematic-Umfeld los war (siehe auch AskSin Analyzer XS - Der Analyzer als Desktop-App ohne ESP). Tolles Analyse-Tool, sind schon eine Menge an Informationen, die man so präsentiert bekommt, Anzahl und Art der Telegramme aber auch die (errechneten) DutyCycle der einzelnen Komponenten.
Mein Setting: eine CCU3, die über einen HmIP-PSM als Router mit einem HmIP-PCBS-BAT kommuniziert.
Manchmal passiert es, das der Schaltbefehl im IPS aufgrund von Timeout als abgebrochen gilt, jedoch durchgeführt wurden.
Besonderheit bei einem Batteriebetriebenem Gerät ist ja, das die mit einem Burns aufgeweckt werden müssen, bei einem HmIP ist das ein Triple-Burst (also 3 Bursts)
Bei der Analyse der Telegramme habe dann gesehen, das die Dauer von dem ersten Burst bis zur Antwort vom Autor 4s betragen hat. Da die Zeitauflösung Sekunden ist, ist damit di eDauer ja noch exakt zu bestimmen, das können genauso 4,5s gewesen sein.
Wenn man dann noch einrechnet, das die Kommunikation vom IPS zur CCU und von der CCU zum IPS auch noch etwas dauert, kann es durchaus sein, das die 5s, die - so habe ich es verstanden - hart einprogrammiert ist, überschritten wird.
Gruß
demel
Zur nächsten 5.4er Version habe ich die Wartezeit auf 7 Sekunden erhöht. Es gibt außerdem Properties die ihr über IPS_SetProperty setzen könnt. Insbesondere WaitTimeDevice.
paresy
prima, danke
Ist der global, oder für jedes Interface getrennt?
Weil bei wired wird die Antwort schneller sein als RF und HmIP(RF) wohl am langsamsten.
Michael