cuxd curl oder system curl oder wget

[joerg_rw]

... und die darauffolgenden 3 parameter (stderr, stdout, stdin) sind nicht wirksam/notwendig.<<

Da bin ich auch schon drauf reingefallen. Das hilft Dir nur bei fire&forget-Aufrufen (HTTP-Befehle an Aktoren, Telegram etc.). Fragst Du Daten ab, Die Du weiterverarbeiten willst, brauchst Du stdout.

Gruß Xel66

Das kannst du dann aber so wie ich das verstehe auch nicht als background process ("...&;") laufen lassen, und nur auf diesen Fall bezog sich die zitierte Aussage.
Das hat mich nebenbei ca 5 Jahre minimum gekostet bis ich kapiert habe dass die GUI "Programme" nicht sequenziell abgearbeitet werden sondern jeder einzelne "Programmschritt" - also "Systemvariable FOOBAR mit 7s Verzoegerung auf 'obskur' setzen" - als eigener Job in irgendeinen Scheduler eingehaengt wird und niemand garantieren kann in welcher Reihenfolge diese Jobs dann abgearbeitet werden und wann (gestaffelte Verzoegerungen mal aussen vor). Und ich bin mir bis heute nicht sicher nach welchen Kriterien (labels/tags/hashes/IDs) die "Aktivitaeten mit laufenden Verzoegerungen" in dieser Scheduler-Liste gesucht werden die dann abgebrochen werden sollen - download/file.php?id=95580&mode=view von viewtopic.php?p=707697#p707697 krieg ich Kopfschmerzen, was wird da wann vorzeitig abgebrochen?
In diesen leicht offtopic Zusammenhang: kann man eigentlich nicht die Verzoegerungszeit-Eingabe auf der GUI auch auf was kleineres als Sekunden patchen, also dass man z.B. zumindest Zehntelsekunden angeben kann: "verzoegert um [ 0.3] Sekunden" - wueste BASIC Zeilennummer-Erinnerungen klingen an .

[Xel66]

Das kannst du dann aber so wie ich das verstehe auch nicht als background process ("...&;") laufen lassen, und nur auf diesen Fall bezog sich die zitierte Aussage.

Genau. Aber viele rufen eben Wetterdaten und manche sogar die Spritpreise (was auch immer man damit automatisieren kann, vielleicht das Garagentor) ab. Und hier müssen eben die abgerufenen Daten weiterverarbeitet werden und die CCU muss zwangsweise auf deren Vorhandensein warten. Als Faustformel könnte man nehmen: Datenabfragen per CUxD und fire&forget per system.Exec():. Damit dürfte man auf dem sicheren Pfad sein. Aber jeder hat seine Vorlieben.

Das hat mich nebenbei ca 5 Jahre minimum gekostet bis ich kapiert habe dass die GUI "Programme" nicht sequenziell abgearbeitet werden ...

Vor etwas mehr als dieser Zeit gab es mal eine einsteigerfreundliche Beschreibung (ich meine in einem damals noch kostenpflichtigen ELV-Journal) über die interne Arbeitsweise der CCU. Da wurde mit solchen Beschreibungen "es wird ein Zettel mit einem Merker an den Datenpunkt gehängt" recht allgemeinverständlich beschrieben. Leider versinken solche hilfreichen Darstellungen im Nirvana und viele Anwender stolpern im Nachgang über die merkwürdige Arbeitsweise, weil die CCU sich eben zwar strikt logisch, aber eben nach eigenen Spielregeln verhält (Abarbeitung von oben nach unten etc.). Erfahrungen mit anderen Systemen sind für den Anwender da eher hinderlich.

In diesen leicht offtopic Zusammenhang: kann man eigentlich nicht die Verzoegerungszeit-Eingabe auf der GUI auch auf was kleineres als Sekunden patchen, also dass man z.B. zumindest Zehntelsekunden angeben kann:

Würde ich auch begrüßen, sei es nur, um die Befehle in eine Abarbeitungsreihenfolge zu bekommen. Je nach Auslastung der Funkschnittstelle könnten so kurze Abfolgen in Zehntelsekunden aber schon kritisch sein. Die Aktoren arbeiten ja auch mit Verzögerungen von Statusmeldungen im vollen Sekundenbereich, um Kollisionen zu verhindern. Versuche mal mehrere Rollladen mit so kurzen Verzögerungen per Script zu verfahren. Der ein oder andere (klassiche) wird eben nicht mitfahren (wie bei "sofort"). HmIP kann damit wohl umgehen (Stickwort: listen before talk)

Gruß Xel66

[MichaelN]

Aber viele rufen eben Wetterdaten

Ja, täglich 4x.Seit Jahren. Ohne Probleme. Sogar jetzt, wo AccuWeather die kostenlose API dicht gemacht hat, kein Hänger. Meine Routine ist planmäßig auf die Backup Lösung umgesprungen.

[Xel66]

Ja, täglich 4x.Seit Jahren. Ohne Probleme.

Ich auch (ebenfalls problemlos via CUxD), und hatte auch AccuWeather für die Vorhersage. Habe aber schon vor ein paar Wochen die CCU auf BrigthSky umgestellt, nachdem mein AccuWeather-Implementation im HomeAssistant (hatte ich parallel zu met.no in Betrieb) einen Schluckauf hatte. Ich hatte das als erste Auswirkungen für das angekündigte Aus der freien Abrufbarkeit interpretiert.

Das aktuelle örtliche Wetter schreibt mir eine WH3000-Wetterstation in die CCU als Systemvariablen. Eine zweite (Display-)Basisstation der gleichen Außeneinheit schreibt die Daten über die Ecowitt-Integration in den HomeAssistant. Parallel schreibe ich die Wetterdaten auch noch zu Weather Underground hoch.

Gruß Xel66

[It-noob]

schon ein paar Jahre zurück und einer system.exec mit einem '&' bug, hatte ich folgende Zeilen verfasst:

Code: Alles auswählen

string stderr; string stdout;
system.Exec("timeout 3 nohup wget --timeout=2 --no-check-certificate -q -O /dev/null '"#url#"'" , &stdout, &stderr);

das erste "timeout 3" bezieht sich auf system.exec und beendet alles danach folgende nach 3 sekunden (meine Haupt-Absicherung der Rega)
nohup koppelt das wget von der Rega / system.exec ab (no hangup) (und ändert das stdout)
--timeout=2 gehört zu wget und lässt wget nach 2 sekunden terminieren
--no-check-certificate ist nur bei ssl interessant, nicht aber bei der erwähnten http URL
-q = quite
-O = output nach /dev/null
&stdout, &stderr fängt evtl rückgabewerte ab

aber wie war das noch mit den vielen Köchen und viele Wege.

[joerg_rw]

--timeout=2 gehört zu wget und lässt wget nach 2 sekunden terminieren

das ist eben die Falle auf die auch ich erstmal reingefallen bin. Tatsaechlich hilft --timeout hier wenig bis gar nicht, da:

-T seconds
--timeout=seconds
. This is equivalent to specifying --dns-timeout, --connect-timeout, and --read-timeout, all at the same time.

--read-timeout=seconds
. Set the read (and write) timeout to seconds seconds. The "time" of this timeout refers to idle time: if, at any point in the download,
. no data is received for more than the specified number of seconds, reading fails and the download is restarted. This option does
. not directly affect the duration of the entire download.

-t number
--tries=number
. Set number of tries to number. Specify 0 or inf for infinite retrying. The default is to retry 20 times, with the exception of fatal
. errors like "connection refused" or "not found" (404), which are not retried.

Kurz zusammengefasst: im schlechtesten Fall kannst du bis zu 20 mal timeout Verzoegerung haben bis wget abbricht, und du kannst stundenlang 42 byte pro Sekunde downloaden ohne dass wget ueberhaupt abbricht