Baustein hängt sich spontan auf (LBS19002408 - Kostal Piko)

[leppenraub]

Hallo zusammen,

von mir stammt der Baustein LBS19002408, der einen Kostal Wechselrichter regelmäßig nach seinen aktuellen Leistungsdaten frägt. Eigentlich sind es zwei relativ simple curl-Abfragen, die in ein Exec-Skript gepackt sind, der Baustein "hängt" sich aber aus bislang unerfindlichem Grund gelegentlich auf. Schreiben von Debug-Logfiles haben mich auch noch nicht im Ansatz auf eine Spur gebracht. Einzige Lösung bislang: Neustart von Edomi.

Habt ihr eine Idee, was ich noch prüfen kann oder wo der Fehler liegen könnte?

Aktuelle Verschaltung:

image.png

[jonofe]

Wenn du nur per curl Daten abrufst und dann auf die Ausgänge gibst und dazu dann noch eine Frequenz von 15 Sekunden hast, dann ist en Daemon-LBS nicht notwendig. Ich würde das EXEC Skript nach einem Durchlauf terminieren und über E1 den LBS jede Sekunde triggern.

Außerdem hast du ein set_time_limit(86400); was dazu führt, dass sich das Skript nach dieser Laufzeit terminiert.
Bei einem Daemon LBS sollte das set_time_limit(0); sein, denn du willst ja, dass der LBS dauerhaft läuft.
Dennoch würde ich das eher als normalen EXEC LBS umsetzen wie oben beschrieben.

Im EXEC Bereich müssen die Funktionsnamen übrigens nicht mit "LB_LBSID_" beginnen, da hast du dann alle Freiheiten.

[leppenraub]

Super, Danke für Deine Hilfe! Das set_time_limit(0); war der Schlüssel.

Ich hatte da (zunächst) ein ganz anderes Konzept im Hinterkopf, denn ich dachte, dass mit dem "set_time_limit" das Skript im Fall einer Fehlfunktion (auf jeden Fall) beendet wird. Im ersten Schritt hatte ich das limit auf 15 min und habe den Baustein alle 10 min getriggert. Seltsamerweise lief der Baustein auch mit initialer Triggerung (siehe oben) und limit von 15 min dauerhaft.

Wo siehst Du die Vorteile, den Baustein nicht als Exec-Skript laufen zu lassen? Oder worin liegen die Nachteile in der jetzigen Implementierung?

[jonofe]

Wo siehst Du die Vorteile, den Baustein nicht als Exec-Skript laufen zu lassen? Oder worin liegen die Nachteile in der jetzigen Implementierung?

Du hast halt dauerhaft einen php Prozess laufen,der Ressourcen verbraucht und wenn dieser abstürzt ist die Funktion des LBS nicht mehr gegeben und du musst ggf. manuell neustarten. Daemon LBS braucht man eigentlich dann, wenn irgendwas passieren kann, was nicht aus dem LBS selbst getriggert wird, z.B. beim HUE LBS ist dies notwendig, um auch Statusänderungen mitzubekommen, die man in der HUE App und mit HUE Tastern macht oder um Bewegungsmeldungen von der HUW Bridge mitzubekommen.
Wenn eine definierte Funktion nur aus der EDOMI Logic Engine getriggert wird, dann ist ein solcher Daemon LBS nicht notwendig.

[leppenraub]

Ah, verstehe. Im Fall, dass ich "hochfrequente" (als unter 1 min) Abfrageergebnisse brauche, habe ich in der Vergangenheit dazu tendiert, einen Daemon zu laufen zu lassen anstatt den Baustein jede Sekunde zu triggern. Oft war ich auch mit einem Stau der Logic-Queue konfrontiert, die ich mit dieser Strategie reduzieren konnte.

[leppenraub]

Hab mittlerweile mit diesem Baustein sehr eigenartiges Verhalten beobachtet:

1. Baustein umgebaut ohne Exec-Script und Trigger alle 15 Sekunden: Hatte den Effekt, dass sich der Edomi komplett aufgehangen hat und gar keine Logiken mehr verarbeitet hat.

2. Wieder zurück auf Exec-Script und maximale Ausführungsdauer auf "unendlich/0" gestellt: Funktioniert grundsätzlich aber der Baustein hängt sich im Schnitt einmal pro Tag auf

Fehlerlog (auch das des Bausteins) bringt mir keine Erkenntnisse. Habt ihr noch Ideen, wo ich recherchieren könnte bzw. was hier schief läuft?

[jonofe]

1. Baustein umgebaut ohne Exec-Script und Trigger alle 15 Sekunden: Hatte den Effekt, dass sich der Edomi komplett aufgehangen hat und gar keine Logiken mehr verarbeitet hat.

Ohne EXEC Skript würde ich nicht machen, da dann genau das passieren kann, was du beobachtet hast, nämlich dass sich die EDOMI-Logikschleife aufhängt, wenn sich dein Skript aufhängt.

Mit EXEC, aber ohne Daemon (Endlos While Schleife) wäre meine Präferenz. Dann kann sich durchaus mal ein Aufruf (eine Instanz des EXEC Skripts aufhängen oder in einem Timeout hängen ohne die EDOMI Gesamtlogik und auch ohne die Funktion deines LBS zu beeinträchtigen, denn bei jedem Trigger wird ja eine neue Instanz gestartet und beim Ende des Durchlaufs beendet.

Die Ursache für das Aufhängen kann eigentlich nur im CURL Befehl liegen und hier insbesonder daran dass du kein Timeout spezifiziert hast. Ich würde immer ein Connection Timeout und ein Execution Timeout setzen. Dann kannst du sicher sein, dass dein Curl Aufruf auch nach endlicher Zeit terminiert:

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 3);  // connection timeout in seconds​
curl_setopt($ch, CURLOPT_TIMEOUT, 3); // execution timeout in seconds​ 

Falls du doch ein Daemon Skript machst, dann sollte die While Schleife nicht mit

$call=1;
while ($call) 

sondern mit

while (getSysInfo(1) >= 1) 

gestartet werden. Dadurch ist sichergestellt, dass die Schleife beim Beenden von EDOMI terminiert.

[leppenraub]

Super, Danke! Hab ich umgehend eingebaut und werde nun beobachten und berichten, ob Besserung eingetreten ist.

[leppenraub]

Scheint geholfen zu haben, seit 4 Tagen keine Ausfälle mehr - Vielen Dank nochmal!

Baustein wurde auch im Download-Bereich aktualisiert.