Wartezeit nach abgebrochenen HM-Schaltbefehlen

Hallo,

ich habe folgende Situation:

ich habe ein Script, in dem nach bestimmten Kriterien zu bestimmten Zeiten HM-Gerät geschaltet werden.
Mache ich natürlich ganz normal mit HM_WriteValueBoolean() (e.a.).
Den Rückgabewert der HM_WriteValue*()-Funktionen werte ich aus und bekomme so mit, ob es funktioniert hat oder auch nicht.

Es ist also nicht jede Aktion ein Script das über ein Zeit-Ereignis ausgelöst wird sondern es ist ein Script, das eventuell mehrere Schaltvorgänge, die „zum gleichen Zeitpunkt“ stattfinden sollen, nach einander auslöst. Also eigentlich prima serialisierte HM_WriteValue-Aufrufe, das sollte eigentlich nix schief gehen.

Das funktioniert wunderbar … solange alle Aktoren einwandfrei angesprochen werden können.

Meine Beobachtung ist diese: ist eine Komponente nicht erreichbar, wird von HM_WriteValue*() nach relativ genau 5 Sekunden ein false zurückgeliefert. Alle - in einem gewissen Zeitraum - danach erfolgenden Schaltvorgänge schlagen ebenfalls fehl, auch wenn dieser Autor einwandfrei erreichbar ist. Die Schaltbefehle werden sogar zum Teil ausgeführt, nur IPS meint, das wäre schief gegangen.

Die HM-IO-Instanz ist i.d.R. in diesen Situation unverändert verbunden, zeigt also typischerweise kein Operation aborted an.

Auch wenn es selten vorkommt … mich nervt das etwas, und daher würde ich gerne etwas daran ändern, das einzelne fehlgeschlagenen Operationen für einige Zeit alle Aktionen blockieren.

Da ich eine Schalt-Aktion nach der anderen mache, dachte ich, das sollte ja kein Problem sein - ist aber definitiv und nachvollziehbar ein Problem,
Dann habe ich gedacht, warte nach einem Fehler mal ein paar Senkungen … ein paar Sekunden helfen aber nicht.
Dann habe ich die Zeit auf 30 Sekunden ausgedehnt - reicht mal, mal auch nicht.

Da das Ganze in einem Script läuft bin ich natürlich daran gebunden, das ich insgesamt nur 30s zur Verfügung habe. Ich würde aber altennativ diese Schaltvorgänge auch über eine Queue laufen lassen und das dann verzögert abarbeiten.

Das macht aber nur dann wirklich Sinn, wenn ich entweder testen könnte, ob die CCU nach einem vorigen Abbruch wieder bereit ist oder eine Zeit finde, die mit hoher Wahrscheinlichkeit reicht. Einfach nach einem Fehlschlag x Minuten zu warten bis zur nächsten Operation ist vielleicht etwas zu simpel.

Hat da jemand ein Hinweis für mich, in welche Richtung ich denken oder wo ich meine Suche intensivieren sollte?

Rein interessehalber: sind die 5 Sekunden, bis eine Operations als fehlgeschlagen gemeldet wird, eigentlich irgendwo einstellbar? In der IO-Instanz nicht, da gibt es nur 30-Sekunden-Intervalle und auf der CCU-Seite kenn ich da auch keine Einstellung.

demel

Wenn ein Aktor nicht erreichbar ist, ist die Wartezeit CCU Sache. Diese wartet ja auf die Quittung vom Aktor.
Parallel dürften in HM Socket eine Wartezeit laufen, damit ein ausbleiben der Antwort von der CCU erkannt wird.

Erster Schritt der Fehlersuche wäre jetzt die Art der Meldung in Symcon, wenn WriteValue fehlschlägt.
Und zusätzlich würde ich den Status vom HM Socket und den Duty-Cyle der CCU überwachen.

Ich habe festgestellt das es zu 90% an der CCU liegt, welche dann aufgrund von z.b. Duty-Cyle, einfach nicht sendet aber auch keinen Fehler an Symcon meldet.
Da kommt dann ein Timeout bei WriteValue.
Michael

Hallo Michael,

ich habe mich da wohl etwas unklar ausgedrückt. Es ist definitiv immer ein CCU-Problem bzw. ein Problem des Aktors.
Kann einen ganz einfachen Grund haben, Bsp: der Aktor ist batteriebetrieben, Akku ist alle und wird aber trotzdem zeitgesteuert ausgelöst.
Und - zack - die anderen in dem gleichen Zeitraum anzuschaltenden Lampen bleiben dunkel.

Es geht also weniger um Fehlersuche, warum das nicht geschaltet wird sondern mehr darum, das dieser „Fehler“ keine weiteren Auswirkungen hat.
Schreibe ich natürlich ins IPS-Log, kann das also prima nachvollziehen :wink:

Ich verstehe Dich jetzt so, das der Abbruch des HM_WriteValue*() nach 5s ein Timeout der Socket auf IPS-Seite ist und nichts mit einer Reaktion der CCU zu tun hat. Dann hilft ja nix als bei einem Fehler doch ein recht großzügige Pause zu machen und dann erst bei dem nächsten weiter zu machen.

In dem o.g. Fällen ist das kein DutyCycle-Problem (ich habe im Schnitt +/-20%) und da wundert es mich schon, das die CCU erst nach längeren Zeit wieder bereit ist.

Meine Hoffnung war das jemand eine Vorstellung hat, wie lang diese Zeit ist oder ob es eine Chance gibt, irgendwie anders zu erkennen, wann die CCU wieder bereit ist „zu arbeiten“.
Wenn der DutyCycle hoch ist, ist das natürlich kaum zu kalkulieren, aber das ist bei mir eher selten (oder wenn, dann richtig heftig).

Danke für deine wie immer super schnelle Antwort
demel

Hat keiner bestritten :slight_smile:

Ist doch auch Fehlersuche.

Falsch. Ich sagte das ja sowohl CCU auf den Aktor als auch IPS auf die CCU warten.
Darum ist die Fehlermeldung ja wichtig.
Wie lange die CCU auf die Antwort des Aktors wartet, habe ich nie ausprobiert.

Ich hatte früher ein Script welches immer alle Jalousie Aktoren angesteuert hat. Auch wenn ein Aktor nicht reagiert hat, haben die nachfolgenden problemlos funktioniert. Da war nur eine 200ms Pause zwischen den Befehle.

Darum meine Frage ob der Status vom Socket protokolliert oder du im Log danach geschaut hast.
Eventuell bricht die ganze Verbindung bei dir weg (warum auch immer) und deswegen dauert es dann 30 Sekunden bis der Socket wieder verbunden ist.

Ich habe aktuell nur zwei batteriebetriebe Aktoren. Gerade nach dem einen (YouTube?) Beitrag zum Thema wie sehr negativ diese Geräte sich auf den Funkverkehr und auch den Duty-Cyle auswirken, bin ich froh das ich diese Aktoren eigentlich nur 1-2 Mal im Jahr ansteuer :smiley:
Michael

Wenn Du die HomeMatic-IO-Instanz meinst, die ist im Normalfall nicht unterbrochen, es gibt also kein Operation aborted o.ä.
wenn Du das nicht meinst, welche Socket?

Wenn die funktionieren gibt’s überhaupt kein Problem, aber wenn das Teil von der CCU nicht erreichbar ist, gibt es eben diese Folgefehler.

rein interessehalber: hast Du den Beitrag noch griffbereit?

demel

Das meinte ich bei meinen Jalousie Aktoren mit wenn einer nicht reagiert. Ist dann ja identisch zu nicht erreichbar von der CCU.
Den Beitrag habe ich nicht gerade griffbereit.
Kann ich morgen Mal suchen.
Meine das auf einem Homematic Usertreffen von einem Entwickler.
Gefunden. Ab ca 19:30 geht es um batteriebetriebene Empfänger (Aktoren) welche mit diesem Burst Telegramm geweckt werden müssen.

Michael

prima, schaue ich mir an

demel

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

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

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

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

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

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

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

Hallo Harald,

danke für den Tip

demel

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

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.

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

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

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.

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