[Modul] Unwetterzentrale - Fehler

Was mir gerade aufgefallen ist: es gibt unterschiedliche Fehlermeldungen, bei mir mit IPS 9.0 auf Windows 11 ist die Meldung anders als bei den meisten Screenshots.

Bei mir mit Symcon 9.0, Windows (amd64), 05.03.2026, b9a34e92f86a

error:0A00010B:SSL routines::wrong version number

Bei den meisten Screenshots oben

error:0A0003E7:SSL routines::invalid session

Der Fehler ist heute bei mir noch nicht wieder aufgetreten, ist zumindest bei mir sehr sporadisch. Vielleicht betreibt der DWD einen Serverpool und nur einer der vielen Server macht Probleme.

Also bei mir ist es schon recht häufig. Min. 2x täglich, eher mehr:

Bin übrigens auch auf der letzten 9.0er (stable), allerdings unter Linux…

Was auch immer das war … nun sehe ich im Log auch die SSL routines::invalid session wie bei den anderen.

Hallo,

auch bei mir der gleiche Fehler. Das Thema ist ja nun schon ein paar Tage bekannt. Es wäre sehr nett, wenn sich seitens Symcon-Team jemand der Sache annehmen könnte. Die Fehlermeldungen nerven auch mich.

Vielen Dank

2 „Gefällt mir“

Über ein Statement oder eine Zwischeninfo seitens Symcon von @paresy oder @Dr.Niels zu diesem Thema würde ich mich und sicherlich auch die anderen Verfasser von Beiträgen zu dieser Problematik sehr freuen.

Vielen Dank!

Heute bei mir weider:

Ignorier die Fehler halt. Irgendwelche Serverfehler passieren immer mal, man sollte nicht jedem temporären Fehler hinterherlaufen.

Bei mir sind auch täglich irgendwelche sporadischen Fehler bei diversen Webdiensten im Log. Solange die Dienste grundsätzlich funktionieren ist doch alles gut, einfach das Log nicht zu penibel lesen.

Das ist ja ein toller Tip. Dann braucht man hier ja gar keine Fehler mehr zu melden. Einfach alle ignorieren :slight_smile:

@DrFrank Kurze Rückfrage: Habt ihr die aktuelle Stable installiert oder die Beta Version? Dort haben wir die PHP Version entsprechend aktualisiert. Vielleicht löst dies das Problem.

paresy

Ich habe die aktuelle Stable. Ich glaube ja immernoch, dass sich beim DWD etwas geändert hat. Ich frage das Regenradar zusätzlich mit einem eigenen Skript ab und da habe ich die URL von „dwd.de/…“ auf „wettergefahren.de/…“ geändert und seitdem schmeißt mein Skript keine Fehler mehr.

Welche Beta? Im Store sehe ich keine Beta, also ist bei mir Stable 1.0 installiert.

Da es sich nicht um einen temporären sondern regelmäßig wiederkehrenden Fehler handelt, habe ich nun gestern Abend selbst nach einer Lösung gesucht, weil ich nicht noch länger warten wollte.

Zumindest bei mir unter Docker hat die folgende Änderung in der module.php Abhilfe geschaffen und seit gestern Abend habe ich keine Fehlermeldungen mehr. Ob das unter Windows auch funktioniert, vermag ich nicht zu sagen.

In der module.php habe ich den Block in der

public function RequestInfo()

zwischen „//Download picture“ und „//Radarbild auswerten“ ersetzt durch


//Download picture

$remoteImage = 'https://www.dwd.de/DWD/wetter/radar/rad_' . $this->ConvertArea($area) . '_akt.jpg';

$ch = curl_init($remoteImage);
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_FOLLOWLOCATION => true,
    CURLOPT_MAXREDIRS      => 1,
    CURLOPT_TIMEOUT        => 30,
    CURLOPT_USERAGENT      => 'Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36',
    CURLOPT_SSL_VERIFYPEER => true,
    CURLOPT_SSL_VERIFYHOST => 2,
]);

$data = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
$curlError = curl_error($ch);
curl_close($ch);

if ($data === false || $curlError !== '') {
    $this->SendDebug('cURL Error', $curlError, 0);
    return;
}

if ($httpCode !== 200) {
    $this->SendDebug('HTTP Error', 'Code: ' . $httpCode, 0);
    return;
}

//Radarbild auswerten

Damit wird die Abfrage von file_get_contents auf cURL umgestellt.

Der Fehler liegt vermutlich daran, dass file_get_contents die PHP-eigene OpenSSL-Integration nutzt und die offenbar nicht korrekt konfiguriert oder das CA-Bundle veraltet ist. cURL bringt eine eigene SSL-Implementierung mit, die unabhängig von der PHP/OpenSSL-Konfiguration funktioniert und ein aktuelles CA-Bundle verwendet.

Aber das ist nur eine Vermutung. Bitte nicht vergessen, dass bei einem Update des Moduls die Änderung wieder überschrieben wird.

Daher ersetzt der Workaround nicht die Wartung der aktuellen Version und die ausstehende Fehlerbeseitigung.

Viele Grüße

Andreas

1 „Gefällt mir“

Geht mir genau so. Im Store bekomme ich einige andere Module als Beta angezeigt, aber nicht die Unwetterzentrale.

Ich denke mal Paresy meinte die Symcon Version :slight_smile: Ist ja logisch, denn dort ist ja auch das PHP drin.

3 „Gefällt mir“

Du hast recht, er wird die Symcon-Version meinen. Da bin ich auch auf der 9.0 Stable.

Vielleicht gibt es im Zusammenhang mit dem cURL-Workaround ja bald Erkenntnisse. Ich glaube nicht, daß die Ursache die PHP-Version ist. Bis jetzt bei mir mit cURL keine Fehler mehr im Log. Das spricht eigentlich für das veraltetete CA-Bundle.

Die gute Nachricht ist, ich kann es hier Mittlerweile auch beobachten. Passiert hier eher selten, aber es passiert. Ich weiß aber noch nicht, woran es liegt.

paresy

1 „Gefällt mir“

Hallo paresy,

ich bin seit über 15 Jahren begeisterter Anhänger und Kunde von Symcon und empfehle Euer Produkt wo immer sich die Möglichkeit dafür bietet. Mein Haus wurde in den letzten Jahren sukzessive “symconisiert”.

Im Forum war ich aus zeitlichen und beruflichen Gründen fast ausschließlich als fleißiger Leser unterwegs. Jetzt habe ich mehr Zeit und bin hier aktiver, auch um zu lernen.

Leider hätte ich heute aber den “Gefällt mir nicht” Button gedrückt, wenn es diesen gäbe.

Den Verlauf der Diskussion zum Fehler im Modul Unwetterzentrale erweckt trotz “guter Ratschläge” mit könnte, scheintund vielleicht… bei mir den Eindruck, mit dem Fehler allein gelassen zu werden und daß sich bei Euch niemand der Sache wirklich annimmt. Im ersten Betrag vor 26 Tagen wird als Erstes eine Frage gestellt, die bis heute unbeantwortet blieb.

Gestern kam nun die “gute Nachricht”, daß die Meldungen der User wohl stimmen und der Fehler tatsächlich vorhanden ist. Aber wie geht es nun konkret weiter?

Der Fehler ist für die Funktion des Moduls sicher (bisher) irrelevant und eine Lappalie, nervt aber wohl viele. Die Diskussion hat die meisten Aufrufe in den letzten 4 Wochen, ist also für mehr User relevant als für diejenigen, die sich dazu hier melden und versuchen selbst eine Lösung in der Community zu finden.

Es geht mir nicht um den eigentlichen Fehler, den habe ich selbst beseitigt, sondern um das Gefühl, welches ich unabhängig vom fachlichen Inhalt der Diskussion als Euer Kunde vermittelt bekomme. Ich sehe hier Parallelen:

Zitat Symktomv: Wir brauchen nur eine funktionierende Version und bei allem Aufruf zur Freundlichkeit: Lösungen und keine Einladung zum Freizeitfrickeln.

Bisher habe ich mich bei Euch gut aufgehoben gefühlt und wünsche mir sehr, daß dies so bleibt. Gerade Euer Support unterscheidet Euch von HA und Anderen und das soll so bleiben!

Dass Ihr Eure Ressourcen nach Priorität einsetzt, ist verständlich und richtig. Manchmal aber ist ein kurzer Zwischenbescheid mit konkreter Aussage “wir sind dran und melden uns bis XX” oder auch “dafür haben wir momentan keine Zeit” mehr wert, als ein guter Ratschlag, der auch mitunter frustrierend sein kann.

Viele Grüße

Euer weiterhin treuer Kunde Andreas

2 „Gefällt mir“

Hi Andreas,

ich hoffe nicht, dass Ihr das Gefühl habt, dass wir Fehler ignorieren oder gar einfach nicht beheben wollen. Manche Fehler sind jedoch nicht super schnell nachvollziehbar oder außerhalb unseres direkten Einflussbereichs. Ich hatte das Modul kurz angetestet und wie es natürlich immer ist, hat es funktioniert. Somit wartet man auf mehr Feedback oder einen Hinweis wo genau es klemmt. Bisher ging ich z.B. davon aus, dass es nur auf Windows passiert. Dort funktioniert PHP etwas anders als auf den Linux Plattformen. Da es bei mir zu Hause aber auch auf der SymBox passiert, ändert sich das Bild und es muss ein generelles Problem sein. Da die Windows Builds von PHP von PHP selbst kommen, gehe ich nicht davon aus, dass es eine Inkompatibilität zwischen OpenSSL und PHP ist, zumal cURL funktioniert.

Ich vermute trotzdem, dass es etwas mit dem Wechsel von PHP 8.3 auf 8.5 zu tun haben wird. Bei den PHP Bugreports, die ich bereits durchsucht habe, gibt es nicht passendes zu dem Problem.

Ich bin an dem Problem weiter dran → Mir fehlt aber aktuell noch ein guter Hinweis/Tipp wann es passiert oder wie man es zuverlässig nachstellen kann. Klar können wir im Modul auf cURL umstellen, aber das löst das Problem nicht, welches wahrscheinlich auch an anderen Stellen auftritt.

paresy

PS: Das Thema von Symktomv ist leider auf einer anderen Ebene schwieriger. Im Gegensatz zu dem Thema hier, wissen wir bisher gar nicht, was er für ein System einsetzt oder woher die falschen Werte kommen können.

Der Verdacht liegt nahe. Da mit 8.5 auch der OPcache Support auf nicht Windowssystemen nicht mehr 100%ig funktioniert, könnte es vielleicht auch hier an diesem Thema liegen.
Hat schon mal jemand versucht, ob das Ausschalten des OPcache hier hilft?

Hatten wir zum OPcache irgendwo schon ein Thema? Ich weiß von Nall-Chan, dass die Statistiken nicht korrekt sind, aber die Funktion an sich sollte gegeben sein.

Trotzdem wäre das eine gute Idee. Ich kann das bei mir ja mal schnell testen.

paresy

Trotz deaktiviertem OpCache passiert der Fehler. Man kann den nachstellen, indem man einfach oft genug die Abfrage macht. Irgendwann kommt der Fehler sporadisch.

file_get_contents("https://www.dwd.de/DWD/wetter/radar/rad_shh_akt.jpg");

paresy