Wartezeit nach abgebrochenen HM-Schaltbefehlen

Hardware HomeMatic
8

Die 5 Sekunden kommen von uns (kann man aktuell nicht einstellen). Wenn deine Beobachtung stimmt, würde es aber bedeuten, dass die CCU nicht damit klar kommt, wenn wir eine Ausführung verwerfen und dann eine weitere Anfragen.

Was für eine CCU hast du? Aktuell klingt das eher nach eine CCU Problem. Und ich bin mir nicht sicher, wie wir das „umschiffen“ können. Auch wenn wir das Timeout auf z.B. 30 Sekunden erhöhen (was deiner Analyse nach scheinbar nicht immer reicht) ist ja nicht garantiert, dass die CCU dann geantwortet hat. Und es bedeutet, dass dein PHP Skript dann trotzdem am Ende seiner 30 Sekunden wäre womit der Rest der Ausführung abgebrochen wird.

paresy

9

Moin,

ich habe ein Charley, also 3B+ mit Raspberrymatic. Das mit den 5s ist mir damit klar, und ja, es macht keinen Sinn, das konfigurierbar zu machen, denn das wird meiner Beobachtung nach auch nicht komplett weg sein, wenn man 30s einstellt.

Ja, es klingt so, als ob die CCU die Folge-Events verwirft (warum auch immer). Da es sich einfach reproduzieren lässt (Aktor stromlos machen), werde ich als nächsten mal dem Verdacht von Nall-Chan nachgehen, das das Problem eher bei den batteriebetriebenen Aktoren auftritt.

Das Ganze ist kein echtes Problem, aber man nimmt sich ja irgendwann auch mal die kleinen Probleme zur Brust.:slight_smile:

demel

10

Nur Mal als Ergänzung:
Bei Batterien Aktoren hat man schon Mal fix diese 1 Sekunde des Burst Signal um ALLE batteriebetrieben Aktoren zu wecken.
Anschließend dann die normale Laufzeit der Schalt- und Quittungstelegramme.
Wenn man jetzt 5 solcher Aktoren in einem Script schaltet, wird ja 5 Mal der Burst gesendet. Das geht extrem auf die Batterielaufzeit und den Duty-Cyle des Senders.
Michael

11

Das Video war ja ganz interessant, das Problem mit dem Burst war mir so nicht bekannt.

Ich habe damit auch normalerweise kein Problem, auch die Batterien sind nicht übermäßig schnell leer.

Batteriebetrieben habe ich nur 2 HmIP-PCBS-BAT, die jeweils LED-Ketten im Garten schalten, die werden am Tag 2x ein und 2x ausgeschaltet. Da habe ich zZt. kein Dauerstrom, ist aber in Planung, das im Sommer zu ersetzen.

Dann habe ich noch 4 Heizkörper (HM-CC-RT-DN), die werden batteriebetrieben bleiben müssen, da gibt es ja nix anderes.
Ich nutze die internen Heizprogramme in den Thermostaten nicht, sondern steuere die Temperatur auch per Funk.
Und ich habe ein HM-MOD-Re-8, der ja lt. Beschreibung für Batteriebetrieb gedacht ist, wird aber durch ein Netzteil versorgt. Das ist dann ja auch ein Kandidat nehme ich an.

Sonst habe ich mit Batterie nur Sensoren o.ä.

Ich denke, das ich am WE schaffe, zu testen (ob das Problem nur bei den BAT-Aktoren auftritt) - dann sehen wir weiter.

danke einstweilen
demel

12

Es gibt auch einige, dort kannst du in den Einstellungen angeben dass die keine batterie haben, bzw. das sie permanent auf Empfang sind und kein Burst brauchen.

Geräte für die Heizung sind dabei außen vor, die machen das anders. Darum dauert es auch einige Sekunden bei z.b. den Antrieben bis die neuen Werte übernommen werden.
Michael

13

HmIP-PCBS-BAT hat nicht, aber da ich im Sommer im Garten eine 24V-Versorgung aufbauen wollte, kann ich die dann ersetzen (zB durch HmIP-PCBS).

Aber leider gibt es weder bei dem HM-MOD-Re-8 noch bei dem HmIP-„Nachfolger“ HmIP-MOD-OC8 eine solche Einstellung und die kann ich nur schwer ersetzen. Da könnte ich nur 2 Stück HM-LC-Sw4-PCB 4 nehmen, da steht nix von Batterie.

Ist die Steuerung der Garage, d.h. am Tag gefühlt 20x auf/zu, aber funktioniert schon ziemlich zuverlässig. DC ist auch kein Problem, weil der über einen LAN-Gateway läuft und nicht über die CCU

demel

14

Nachdem die akademische Diskussion abgeklungen ist, mein Tip aus der Praxis: einfach nach „einiger“ Zeit nochmal probieren :loveips:

Meine Rolläden sind alle mit HM-LC-Bl1-FM bzw. HM-LC-Bl1PBU-FM Aktoren bestückt.

Das ist zwar eine etwas andere Situation, weil die alle fest ans Stromnetz angeschlossen sind.
Andererseits können die kein Roaming und sind daher auf ein LAN-Gateway fixiert. Und das ist über dLAN (Stromnetz) mit der CCU2 verbunden. Je nachdem was an Stromverbrauchern eingeschaltet ist, ist die IP-Verbindung entsprechend schlecht.

Vier der Rolläden werden als logische Gruppe von IPS gesteuert (per Zeitprogramm, über das Webinterface, über eine HM-Fernbedienung). Das geht in ca. 95% der Fälle auch gut, für den Rest muß nochmal ausgelöst werden.

Weil es halt blöd ist, wenn bei Abwesenheit in der Morgenprozedur (Nachtlichter AUS, alle Rolläden AUF) ein Fehler auftritt und damit die Rolläden 24 Stunden geschlossen sind, hab ich folgende Fehler-Recovery einprogrammiert:

Im Skript lege ich erst mal ein leeres Array zur Fehler-Notierung an.
Dann folgt die foreach-Schleife in der die HM-Aktoren angesteuert werden. Dabei wird nicht auf „Funk-Hygiene“ (wie in anderen Foren beschrieben) oder Duty-Cyle geachtet, es werden auch keine „sleep“-Pausen eingelegt. Die Zeit zwischen 2 HM-Aktionen wird nur durch den Skript-Ablauf bestimmt.
Falls der HM-Befehl einen Fehler meldet, wird das im „Array zur Fehler-Notierung“ gespeichert (Zeit, Objekt-ID, Counter=0)
Wenn am Ende des Skriptes dieses Array nicht mehr leer ist, wird

  • das Array in eine Variable gespeichert
  • in Abhängigkeit vom Counter ein Timer gesetzt zum Wiederaufruf des Skriptes.

Beim Wiederaufruf des Skriptes wird über „switch ($_IPS[‚SENDER‘])“ erkannt, dass die Fehler-Recovery ausgeführt werden muss.
Dann werden nur die immer noch als fehlerhaft markierten Aktoren nochmal angesteuert und der Counter inkrementiert.

Der Timer wird entsprechend dem Counter verändert und das Skript wird bei mir nach 5, 20, 30, 60 Sekunden nochmal als Fehler-Recovery ausgeführt (nur bis keine Fehler mehr notiert sind).

Das führt bei mir immer zum Erfolg, es sei denn der Rolladen-Motor ist schon durchgebrannt :slight_smile:

Viele Grüsse
Harald

15

Hallo Harald,

danke für den Tip

demel

16

Hallo,

@Nall-Chan: so, ich habe etwas getestet

  • HmIP-PCBS-BAT (Batteriebetrieber Schaltaktor, im Datenblatt ist der Stromverbrauch für WOR nicht angegeben, also eher kein Burst)
  • HmIP-PSM (Netzbetriebener Schaltaktor)
  • HM-LC-SW1-BA-PCB (Batteriebetrieber Schaltaktor, mit WOR)

Folgende Ergebnisse

  • es tritt bei allen 3 Geräten auf
  • es tritt nicht immer auf, aber zu 80%, bei HM etwas seltener
  • bei jedem Versuch steigt der DutyCycle deutlich an (Start bei 16%, gibt nach 8 Versuchen auf 49%), bei steigenden DC wurde natürlich immer problematischer.
  • Wartezeit zwischen 5-25s brachte mal etwas. Das ist wegen dem steigenden DC nicht wirklich testbar.

tja, was mache ich mit dem Ergebnis … ich habe eine mittlere Wartezeit von 15s für den Fehlerfall eingebaut, das wird mit einer gewissen Wahrscheinlichkeit helfen. Ist ja eher eine Schönheitskorrektur.

@paresy: ein IPS_Sleep(60000); (also 60s) wird korrekt ausgeführt.
Der maximalen Laufzeit liegt ja sicherlich die php.ini-Variable max_execution_time zugrunde und das gibt mach meiner Verständnis nicht die Dauer der Laufzeit eines PHP-Scriptes, sondern von der reinen Laufzeit wird z.B. doch alles abgezogen, was in einem system()-Call abläuft sowie anscheinend auch sleep() (lt. php.net). Sehe ich das richtig?

Das es natürlich eher kontraproduktiv ist, ein Script so lange laufen zu lassen ist natürlich klar.

demel

17

Hast du da bei schlechter Verbindung auch Probleme, dass der Socket in den Fehlerstatus geht?

Das ist ein Problem, das mich besonders nervt im Moment, weil dann so viel Folgeprobleme auftreten.

18 
17.03.2020 00:32:56 | 12183 | ERROR   | KernelMT             | InstanzManager: Fehler bei Instanz #10065, Meldung IM_CHANGESETTINGS: <br />
<b>Notice</b>:  Fehler beim lesen des Interfaces:0 in <b>C:\ProgramData\Symcon\modules\IPSHomematicExtended\RFInterfaceSplitter\module.php</b> on line <b>169</b><br />

17.03.2020 00:35:15 | 12183 | ERROR   | TimerPool            | CCU2 Socket (KeepAlive): Die Netzwerkverbindung wurde durch das lokale System getrennt.
17.03.2020 00:35:48 | 12183 | MESSAGE | HomeMatic Socket     | Einstellungen gespeichert
17.03.2020 00:35:48 | 12183 | MESSAGE | HomeMatic Socket     | Stoppe Eventserver...
17.03.2020 00:35:48 | 12183 | MESSAGE | HomeMatic Socket     | Beende Ereignis-Thread...
17.03.2020 00:35:48 | 12183 | MESSAGE | HomeMatic Socket     | Starte Eventserver...
17.03.2020 00:35:48 | 12183 | MESSAGE | HomeMatic Socket     | Erstelle Ereignis-Thread...
17.03.2020 00:35:48 | 12183 | MESSAGE | Event Control        | Wiederverbinden [CCU2 Socket] erfolgreich
17.03.2020 00:35:58 | 12183 | ERROR   | KernelMT             | InstanzManager: Fehler bei Instanz #10065, Meldung IM_CHANGESETTINGS: <br />
<b>Notice</b>:  Fehler beim lesen des Interfaces:0 in <b>C:\ProgramData\Symcon\modules\IPSHomematicExtended\RFInterfaceSplitter\module.php</b> on line <b>169</b><br />

17.03.2020 00:36:20 | 12183 | ERROR   | TimerPool            | CCU2 Socket (KeepAlive): Die Netzwerkverbindung wurde durch das lokale System getrennt.
17.03.2020 00:36:48 | 12183 | MESSAGE | HomeMatic Socket     | Einstellungen gespeichert
17.03.2020 00:36:48 | 12183 | MESSAGE | HomeMatic Socket     | Stoppe Eventserver...
17.03.2020 00:36:48 | 12183 | MESSAGE | HomeMatic Socket     | Beende Ereignis-Thread...
17.03.2020 00:36:48 | 12183 | MESSAGE | HomeMatic Socket     | Starte Eventserver...
17.03.2020 00:36:48 | 12183 | MESSAGE | HomeMatic Socket     | Erstelle Ereignis-Thread...
17.03.2020 00:36:48 | 12183 | MESSAGE | Event Control        | Wiederverbinden [CCU2 Socket] erfolgreich
17.03.2020 00:36:58 | 12183 | ERROR   | KernelMT             | InstanzManager: Fehler bei Instanz #10065, Meldung IM_CHANGESETTINGS: <br />
<b>Notice</b>:  Fehler beim lesen des Interfaces:0 in <b>C:\ProgramData\Symcon\modules\IPSHomematicExtended\RFInterfaceSplitter\module.php</b> on line <b>169</b><br />
<br />
<b>Notice</b>:  Fehler beim lesen des Interfaces:2 in <b>C:\ProgramData\Symcon\modules\IPSHomematicExtended\RFInterfaceSplitter\module.php</b> on line <b>169</b><br />

17.03.2020 00:54:55 | 12183 | ERROR   | TimerPool            | CCU2 Socket (KeepAlive): Der E/A-Vorgang wurde wegen eines Threadendes oder einer Anwendungsanforderung abgebrochen.
17.03.2020 00:55:11 | 49360 | ERROR   | TimerPool            | E-Mail empfangen (POP3) (Update): Couldn't resolve host name: Could not resolve host: pop3.strato.de
17.03.2020 00:55:48 | 12183 | MESSAGE | HomeMatic Socket     | Einstellungen gespeichert
17.03.2020 00:55:48 | 12183 | MESSAGE | HomeMatic Socket     | Stoppe Eventserver...
17.03.2020 00:55:48 | 12183 | MESSAGE | HomeMatic Socket     | Beende Ereignis-Thread...
17.03.2020 00:55:48 | 12183 | MESSAGE | HomeMatic Socket     | Starte Eventserver...
17.03.2020 00:55:48 | 12183 | MESSAGE | HomeMatic Socket     | Erstelle Ereignis-Thread...
17.03.2020 00:55:48 | 12183 | MESSAGE | Event Control        | Wiederverbinden [CCU2 Socket] erfolgreich

usw.
Zu der Zeit lief ein Backup über das dLAN

19

Also irgendwie nerven mich seit einiger Zeit auch die Fehlermeldungen der HM Komponenten.

homematic fehler.JPG
homematic fehler.JPG1165×260 49.2 KB

Was ich nicht verstehe WARUM die kommen. Duty Cycle ist bei unter 10%, Aktoren sind bei Tests und manuellem Ausführen erreichbar usw. Das blöde ist, dass mir diese Meldungen die Übersicht befüllen und so richtig kann ich nichts machen. Ich habe auch das Roaming abgeschaltet, da ich eine CCU3 und ein Langateway mit Raspberrymatic habe.

Kann man diese Meldungen unterdrücken - evtl. geht es auch in die Richtung mit der Wartezeit. Ich habe das erst seit einiger Zeit - kann es aber leider nicht direkt zuordnen.

20

Du kannst jede PHP Warnung mit dem @ Operator unterdrücken.
Aber dann bekommt man Fehler halt nicht mit.
Da Homematic ja bidirektional ist, wartet die CCU auf die Bestätigung.
Leider gibt es keine Möglichkeit den Duty-Cyle eines Aktoren oder Sensoren auszulesen, eventuell darf der Aktor den Schaltbefehl nicht quittieren und dadurch kommt der Fehler.
Michael

21

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.

22

Ja genau so.
Michael

23

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

24

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

25

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

26

prima, danke

27

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