ERROR: HTTP Client

[whe]

Mit der neuen Version 1.7.1. finde ich in meinem log dutzende dieser Meldungen:

2020-05-05 01:02:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 01:29:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 02:41:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 02:56:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 02:59:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 03:38:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 03:41:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 03:50:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 04:35:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 05:05:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 05:29:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response
2020-05-05 05:59:43 ERROR logics.lib.scheduler HTTP Client: Remote end closed connection without response

Keine Ahnung, wo diese herrühren, in der Nacht gibt es bei mir sicher kaum Aktivitäten aus Logiken.
Allerdings fällt mir auf, dass die Meldungen zwar unregelmäßig kommen, der Abstand in Minuten ist aber immer durch 3 teilbar.
Ich vermute, dass eine Logik im 3 Minuten Rhythmus den Fehler verursacht; da gibt's bei mir nur eine.
in der alten Version 1.5.1 gab es aber keine Fehlermeldungen.
Hier meine Logik, in der ich via HTTP diverse Werte aus meiner Pool Steuerung abrufe.
da gab es zeitweise Fehlermeldungen, nachdem ich aber den try: eingebaut hatte kam da nix mehr.
was mache ich da falsch ? oder kann es auch eine andere Ursache geben ?

# OSF2
#
import http
import urllib
import logging
logger = logging.getLogger('logics.'+__name__)
myurl = "http://192.168.178.40/stathei.htm"
try:
    req = urllib.request.urlopen(myurl)
    data = req.read().decode('UTF-8')
except urllib.error.HTTPError as e:
    logger.error('HTTP Fehler mit error code: ', e.code)
except urllib.error.URLError as e:
    logger.error('URL Fehler {} bei Adresse {} aufgetreten'.format(e.reason, myurl))
except http.client.RemoteDisconnected as e:
    logger.error('HTTP Client: {}'.format(e))
    pass
else:
    sh.Pool.Status.Heizung(data)
    words = data.split()
    if words[1] == 'Solarheizung':
        sh.Pool.Status.Solar("true")
    else:
        sh.Pool.Status.Solar("false")
    if words[1] == 'Wärmetauscher-Heizung':
        sh.Pool.Status.WP("true")
    # else:
    #     sh.Pool.Status.WP("false")
    #    #logger.info(data)
    #
req = urllib.request.urlopen("http://192.168.178.40/statfil.htm")
data = req.read().decode('UTF-8')
sh.Pool.Status.Filteranlage(data)
words = data.split()
if words[0] == 'Filtern' or words[0] == 'Filterbetrieb':
    sh.Pool.Status.Pumpe("true")
else:
    sh.Pool.Status.Pumpe("false")
    sh.Pool.Status.WP("false")
#
req = urllib.request.urlopen("http://192.168.178.40/statpum.htm")
data = req.read()
sh.Pool.Status.Pumpe.Stufe(data)
req = urllib.request.urlopen("http://192.168.178.40/tempa.htm")
data = req.read()
sh.Pool.Istwerte.Luft(data)
req = urllib.request.urlopen("http://192.168.178.40/temps.htm")
data = req.read()
sh.Pool.Istwerte.Solar(data)
req = urllib.request.urlopen("http://192.168.178.40/tempw.htm")
data = req.read()
sh.Pool.Istwerte.Wasser(data)
#
#req = urllib.request.urlopen("http://192.168.178.40/istwerte.htm")
#data = req.read()
#logger.info(data) 

[whe]

Sorry, habe das schon länger nicht mehr im Visier.
die Meldung scheint aus der Logik zu kommen.

[bmx]

Sieht für mich so aus, als ob Deine Pool Steuerung alle 3 Minuten mit sich selbst Schach spielt und keine Zeit hat Dir Werte mitzuteilen ;-)

Der Begleittext oben verwirrt mich. Du hast oben zwar Fehlermeldungen gepostet aber schreibst später "nachdem ich aber den try: eingebaut hatte kam da nix mehr."

Wenn Du oben einen Disconnect auf die IP hattest, ist es unwahrscheinlich, das die unteren requests durchlaufen.

Im übrigen würde ich die lib requests nutzen und nicht urllib.

[Morg]

Daher kommt dein Fehler:

except http.client.RemoteDisconnected as e:
    logger.error('HTTP Client: {}'.format(e))
    pass

Die Gegenseite beendet die Verbindung, nachdem sie sie angenommen hat, aber ohne Daten zu lesen oder zu schreiben.

Warum sie das tut, müsstest du auf der Gegenseite rausfinden. Gibt es da ein Webinterface, einen Status, ein Log?

Wie oft läuft denn die Logik? Wie sieht den crontab-Eintrag aus?

[whe]

zu #4
ja, das wollte ich in #2 aussagen, dass mir das klar geworden ist.
der Hersteller der Pool-Steuerung (OSF) meint, das wäre normal, dass ab und zu requests abgewiesen würden.

zu #3
ohne try gab es natürlich Abstürze im python. Mir fällt nur auf, dass es in SHNG 1.5 keine Meldungen gibt, unter 1.7.1 aber sicher 30-40 pro Tag. Das kann an der neuen Python Version liegen. ich versuche mal wieder lib.requests zu nehmen.

danke für Eure Hilfe; experimentiere weiter.

[Morg]

Wenn der Hersteller schon bestätigt, dass sein Produkt nix taugt (in dieser Hinsicht... ), dann würde ich mir nicht die Mühe machen, eine andere Client-LIbrary zu probieren, wozu denn?

Nimm aus dem Codeschnipsel die Logger-Anweisung raus und Ruhe ist. Ansonsten funktioniert es doch, oder? Ggf. in der Logik dann noch "still" beenden und gut.

Das ist ja dann offensichtlich ein Fehler, den du nicht beheben kannst, sondern um den du herum arbeiten musst.

[whe]

Heute habe ich meine beiden Systeme getauscht und das neue SmarthomeNG 1.7.1 vom alten Pi2 Testrechner in meinen Pi3 gesteckt und schon sind die Fehlermeldungen verschwunden.

Mit etwas Aufwand hatte ich noch meine Logik auf das "Requests" Paket umgestellt, leider ohne Erfolg. Auch time.sleep zwischen den Requests haben nichts gebracht.
Ich vermute jedoch, dass es irgendein Timing Problem ist, weil sich das Problem mit dem schnelleren Pi3 in Luft ausgelöst hat.
Jetzt erhalte ich die Meldungen auch aus dem alten System, welches jetzt auf dem langsameren Pi2 läuft, obwohl ich in SmrathomeNG 1.5.1 solche Meldungen nie hatte.

Vielleicht hat jetzt doch jemand eine Idee, weshalb dem so ist.
Auf jeden Fall werde ich das noch mal mit OSF diskutieren.

[bmx]

Vielleicht solltest Du Mal fragen ob die nicht alle benötigten Werte in eine Json Response packen können...

[whe]

danke für den Tipp, werde ich sicher bald machen.

wäre sicher schön/einfach und wünschenswert. Aber das ist nun mal deren Lösung, mit der ich auch zurecht komme.
zudem gibt es dort zig Parameter, die man abfragen und setzen kann.

Aber ob das mein timing Problem mit dem langsamen Pi2 löst, bezweifle ich.
wollte mal mit timeout im header experimentieren; aber eigentlich ist mein Problem mit dem Pi3 gelöst