search

dstrigl / htheatpump

Easy-to-use Python communication module for Heliotherm heat pumps.
Other
20 stars 7 forks source link

Verbindung über Netzwerk #597

Open innriver opened 5 months ago

innriver commented 5 months ago

Hallo Daniel, vielen Dank für das tolle Tool. Es funktioniert bei mir mit meiner 12 Jahre alten Heliotherm HP12S16W-S-M-WEB einwandfrei und ich bringe auch alle Datenpunkte nach iobroker. Das Programm läuft auf einem Raspberry 3b+ unter Bookworm und einer virtuellen Python 3.11.2 Umgebung. Da ich das System aus Sicherheitsgründen nur lesend betreiben möchte und für die Einstellung weiterhin Homecontrol verwende und daher das Moxa Modem benötige verwende ich socat zum Erstellen einer virtuellen USB-Schnittstelle. Socat wird als Dienst gestartet. Allerdings wenn jetzt bestimmte Zeit kein Datenverkehr mehr besteht oder ein Fehler auftritt wird socat beendet und die virtuelle Schnittstelle ist weg. Leider liefert nach einem Neustart von socat, der im Dienst auch eingestellt ist, htrest keine Daten mehr. Ich muss nach dem Neustart von socat auch den htrest-Server neu starten. Was kann ich tun damit htrest die neu gestartete Schnittstelle wieder findet bzw. erkennt wenn die Schnittstelle geschlossen ist und einen Neustart ausführt wenn USB wieder vorhanden ist. Oder besteht die Möglichkeit htrest direkt über TCP-IP zu betreiben.

Vielen Dank und liebe Grüße Wolfgang

Hab fürs falsche Programm gepostet 😁 wollte htREST. Das Problem ist aber auch hier vorhanden. Das issue kann aber hier geschlossen oder gelöscht werden. Ich habe es für htREST neu erstellt

dstrigl commented 5 months ago

Hallo Wolfgang,

zuerst mal vielen herzlichen Dank für dein Lob und natürlich auch die "coffees" :-)

Nö, dein beschriebener Eintrag ist eigentlich schon hier richtig im htheatpump Modul. HtREST setzt auf htheatpump auf und das von dir gewünschte müsste aber im Kern, also dem htheatpump, erweitert werden.

Zu deinen Fragen: Weiß jetzt leider nicht auf die Schnelle, ob und wie ich einen notwendigen Reconnect nach einem Neustart von socat mitbekomme. Wesentlich einfacher - und vermutlich auch technisch besser - wäre es statt der seriellen Verbindung auf eine Socketverbindung per TCP umzustellen, dann könntest du auch auf socat verzichten. Wäre wahrscheinlich nicht mal so viel Aufwand, die serielle Verbindung durch eine Socketverbindung zu ersetzen.

Werd ich mir mal anschauen! Allerdings hab ich aktuell leider nicht viel Zeit, weshalb ich dir da jetzt auf die Schnelle auch nichts versprechen kann.

LG Daniel.

innriver commented 5 months ago

Hallo Daniel,

vielen Dank für deine schnelle Anwort. Das wäre natürlich super wenn man das auch über eine TCP Verbindung machen könnte. Da bin ich aber auf dich angewiesen, da ich in der Programmierung nicht wirklich drin stecke. Vielleicht findest du ja doch man etwas Zeit - wäre dir jedenfalls sehr dankbar.

Ich wünsche eine schöne Zeit. LG Wolfgang

dstrigl commented 4 months ago

Hallo Wolfgang,

ich hab dir jetzt mal einen Prototyp für die Kommunikation zur Wärmepumpe per TCP-Verbindung gebaut.

Auf Basis der letzten Release v1.3.2 hab ich einen neuen Branch erstellt: https://github.com/dstrigl/htheatpump/tree/socket-connection

Dieser arbeitet jetzt mittels Socket-Verbindung, Hostname und Port sind dabei als String in folgender Form beim Init anzugeben:

hp = HtHeatpump("tcp://192.168.11.91:4001")
hp.open_connection()
hp.login()
# query for the outdoor temperature
temp = hp.get_param("Temp. Aussen")
print(temp)
# ...
hp.logout()  # try to logout for an ordinary cancellation (if possible)
hp.close_connection()

Zum Übernehmen der Anpassungen am einfachsten in deiner Installation folgende beide Dateien

ersetzen und beim Aufruf der HtREST App im Service-File htrest.service die URL mit Hostname und Port anstatt des seriellen Device übergeben (-d tcp://192.168.11.91:4001):

...
ExecStart=/home/pi/venv/htrest/bin/htrest -d tcp://192.168.11.91:4001 --host 192.168.11.99 --port 8777 --read-only
...

LG Daniel.

dstrigl commented 4 months ago

@innriver Bitte bei Gelegenheit mal testen ;-)

innriver commented 4 months ago

@dstrigl Hallo Daniel,

vielen Dank für Deine Arbeit. Ich habe heute mal getestet - und es läuft! Beim Start von HtRest wird sofort eine Verbindung zum Moxa hergestellt. Mit iobroker kann ich dann über ein java-script und mit http://IP-Adresse:8777/api/v1/param/ die Ausgabe als JSON weiter verarbeiten. Frage jetzt mal alle 30 Sekunden ab, dann bleibt die Verbindung offen. Im Moxa ist 60000ms Inactivity time eingestellt. Wenn dann keine Abfrage mehr kommt wird die Verbindung vom Modem getrennt. Ich bin mir aber nicht sicher, ob das ein sauberes logout ist. Bei einer erneuten Abfrage wird die Verbindung wieder hergestellt und Daten kommen an. Bei der Statusabfrage vom htrest.service ist dann aber eine Warnung vorhanden: WARNING [htheatpump.htheatpump|login]: login try #1 failed: data stream broken during reading response header Ansonsten funktioniert alles so wie ich es haben wollte - auch wenn ich zwischenzeitlich auch man mit homeControl zugreife. Nochmals vielen, vielen herzlichen Dank dafür! Ich werde es die nächsten Tage, wenn ich wieder mehr Zeit habe mal laufen lassen. "coffees" sind dann auch unterwegs!

LG Wolfgang

chrisch80 commented 4 months ago

Vielen Dank für das neue feature @dstrigl, das kann ich auch gut gebrauchen weil ich ebenfalls noch homeControl im Einsatz habe. Muss aber auf den nächsten Winter warten da meine WP schon im Sommerurlaub ist (für WW habe ich eine andere). @innriver: Läuft HomeControl bei dir eigentlich auch noch unter Windows XP? Ich habe das unter Windows 10 nie zum Laufen bekommen (Windows 11 nie probiert) und der Heliotherm Support konnte mir da nie weiterhelfen. Eigentlich ist HomeControl eh Schrott. Man müsste sich halt mit Hilfe von HtRest/htheatpump selbst was basteln.

innriver commented 4 months ago

@chrisch80 Hallo, bei mir läuft HomeControl unter Win10. Ich habe aber schon vor 10 Jahren, damals noch unter Win7 als hc nach einem Frameworks-Update nicht mehr lief, über direkten Kontakt mit Heliotherm eine neue Version erhalten. Die läuft bis heute auch unter Windows 10/64bit. Zu Win11 kann ich nicht sagen, da mein Rechner nicht den Anforderungen entspricht. Ich verwende hc auch nur noch ganz selten. WebControl funktioniert ja auch schon lange nicht mehr. Zur Zeit konnte ich die wichtigsten Daten mit einem leicht abgeänderten Python-Programm hier von github (Suchfunktion Heliotherm) auslesen und mit iobroker Parsen. Falls das Moxa Modem mal defekt sein sollte würde ich sicher dann auch direkt auf die serielle Schnittstelle gehen, aber auch nur lesend. Größere Sachen verstellen macht man ja doch dann am Gerät direkt bzw. sind nach jetzt im 13. Jahr Betrieb auch nicht mehr notwendig.

LG Wolfgang

innriver commented 4 months ago

@dstrigl Hallo Daniel,

ich habe heute mal etwas getestet und dabei ist mir folgendes aufgefallen: Wenn bereits eine andere Verbindung zum Modem (Modem läuft im TCP-Server Modus) besteht und htrest wird gestartet kommt folgende Fehlermeldung: May 23 19:53:42 raspberry02 htrest[701]: ^^^^^^^^^^^^^^^^^^^^^ May 23 19:53:42 raspberry02 htrest[701]: File "/home/pi/venv/htrest/lib/python3.11/site-packages/flask_restx/marshalling.py", line 248, in wrapper May 23 19:53:42 raspberry02 htrest[701]: resp = f(*args, **kwargs) May 23 19:53:42 raspberry02 htrest[701]: ^^^^^^^^^^^^^^^^^^ May 23 19:53:42 raspberry02 htrest[701]: File "/home/pi/venv/htrest/lib/python3.11/site-packages/htrest/apis/param.py", line 60, in get May 23 19:53:42 raspberry02 htrest[701]: with HtContext(ht_heatpump): May 23 19:53:42 raspberry02 htrest[701]: ^^^^^^^^^^^^^^^^^^^^^^ May 23 19:53:42 raspberry02 htrest[701]: File "/home/pi/venv/htrest/lib/python3.11/site-packages/htrest/apis/utils.py", line 43, in __init__ May 23 19:53:42 raspberry02 htrest[701]: assert heatpump.is_open, "serial connection to heat pump not established" May 23 19:53:42 raspberry02 htrest[701]: AssertionError: serial connection to heat pump not established Das passiert auch wenn htrest bereits läuft und eine http-Abfrage getätigt wird und eine andere Verbindung besteht! Es muss jetzt ein sudo systemctl restart htrest.service durchgeführt werden. Dabei kann die andere Verbindung noch bestehen! Eine http-Abfrage funktrioniert dann wieder aber nur wenn die andere Verbindung beendet ist sonst kommt der oben beschriebene Fehler.

LG Wolfgang

dstrigl commented 4 months ago

@innriver Hallo Wolfgang,

verstehe ich jetzt leider nicht ganz, was da abläuft. Kannst du es mir nochmal etwas erklären? Von welcher "anderen" Verbindung spricht du?

innriver commented 4 months ago

@dstrigl Hallo Daniel, andere Verbindung ist Zugriff auf die Wärmepumpe über Homecontrol oder auch mit Heliodroid mit dem Smartphone und in dieser Zeit findet z.B.: htrestserver:8777/api/v1/param/ statt. Es kann keine zweite Connection hergestellt werden und das wird nicht richtig erkannt. Diese Situation wird zwar später nicht mehr vorkommen, mir ist es halt aufgefallen weil mein altes Programm mit dem ich zur Zeit noch die Datenpunkte zyklisch abfrage noch gelaufen ist. Vielleicht mache ich auch was falsch oder ich verstehe das nicht, oder es sind die Einstellungen in der Service-Unit falsch. Ich habe sie von dir unverändert übernommen. Ich starte htrest.service, im Terminalprogramm vom Moxa kann ich beobachten dass htrest eine Connection öffnet die nach 60 Sekunden (inactivity time im Moxa) wieder geschlossen wird. Wenn ich dann im Browser z.B. htrestserver:8777/api/v1/param/ aufrufe wird der Port geöffnet, IP-Adresse vom htrestserver wird im Moxa-Monitor (vorher staht da listen) angezeigt und im Browser kommen alle definierten Datenpunkte. Die Verbindung bleibt aber noch 60 Sekunden geöffnet und wird vom Moxa beendet (Anzeige disconnecting). Weitere Abfragen funktionieren einwandfrei. Nur wenn zur gleichen Zeit eine Andere Anwendung eine Abfrage ausführt geht's nicht mehr und ein Restart vom htrest.service muss erfolgen, aber erst wenn das Moxa wieder "listen" anzeigt, also wenn keine weitere Connection besteht. Das Moxa-Modem ist als TCP-Server konfiguriert.

Nachtrag: Ich habe das Modem jetzt mal wieder als Ethernet Modem konfiguriert. Hier funktioniert alles richtig. Der Port bleibt offen bis der htrest.service beendet wird. Danach können auch andere Anwendungen wieder zugreifen. Auch ein htrest restart während eines offenen Ports von einer anderen Anwendung (homecontrol) geht und lässt nach Beendigung der Anwendung auch sofort wieder API-Aufrufe zu, allerdings wird der Port nicht mehr geschlossen! Nur das Modem war dafür bekannt, dass es in dieser Betriebsart öfter die Verbindung zur Heliotherm-Systemeinheit verloren hat. Mal sehen wie es jetzt ist - werde mal testen.

LG Wolfgang

dstrigl commented 3 months ago

@innriver Hallo Wolfgang,

danke für deine Erläuterung. Jetzt - glaub ich mal - hab ich es verstanden ;-) HtREST schnappt sich die Ressource (aktuell eigentlich das serielle Device über htheatpump) exklusiv beim Starten und rechnet nicht damit das während der Laufzeit die Gegenstelle die Verbindung schließt. Hier wird es noch eine kleine Anpassung im HtREST für die Usecase benötigen. Das sollte aber nicht so schwierig sein ... schau ich mir an.

PS: Und vielen lieben Dank für die "Coffees" :-)

LG Daniel

innriver commented 3 months ago

@dstrigl Hallo Daniel,

vielen Dank. wenn es was zum testen gibt melde dich bitte.

LG Wolfgang

dstrigl commented 3 months ago

@innriver Hallo Wolfgang!

Hatte wohl einen kleinen Denkfehler im HtREST drinnen:

Bei jedem Zugriff per HtREST auf die WP wird automatisch ein login und logout gemacht. Und das login würde sogar bis zu 3 mal einen "ordentlichen" Login probieren, inklusive einem reconnect wenns nicht hinhaut. Nur war da ein unnötiges assert im __init__ des HtContext des HtREST drinnen, das verhindert hat das login einen reconnect durchführt :-(

Probier also bitte mal die folgende Zeile aus dem File htrest/apis/utils.py zu löschen: (siehe =>)

class HtContext:
    """Context manager for auto login/logout on the heat pump.

    Example:

    >>> with HtContext(ht_heatpump):
    ...     print(ht_heatpump.get_version())
    ...
    >>>
    """

    def __init__(self, heatpump: HtHeatpump):
        assert heatpump is not None, "'ht_heatpump' must not be None"
=>      assert heatpump.is_open, "serial connection to heat pump not established"
        self._heatpump = heatpump

    ...

Damit sollte es - hoffentlich - gehen! Natürlich wirst du ab und an die Meldung "login try #1 failed: ..." wiederfinden, da dein Moxa ja die Verbindung automatisch nach einer bestimmten Zeit Inaktivität schließt und davon HtREST nichts mitbekommt. Eben erst wenn wieder versucht wird auf die WP zuzugreifen, dann sollte der erste Login fehlschlagen, die Verbindung neu aufbauen und erneut probieren (und hoffentlich erfolgreich sein).

LG Daniel.

innriver commented 3 months ago

@dstrigl Hallo Daniel,

vielen Dank! Habe jetzt folgenden Test gemacht: mit HomeControl eine Verbindung zur Wärmepumpe aufgebaut - Modem zeigt Verbindung an - HtRest-service gestartet - ein paar Sekunden gewartet - HomeControl beendet - diese Verbindung wird sofort geschlossen - jetzt verbindet sich HtRest mit der Wärmepumpe und wird auch angezeigt - setze im Browser http://192.168.2.xx:8777/api/v1/param/ ab - Datenpunkte werden abgerufen und angezeigt - HtRest-Server-Verbindung bleibt offen und wird nach 60 Sekunden vom Modem geschlossen (Timeout im Modem konfiguriert) - neuer Aufruf im Browser - Verbindung wird wieder geöffnet und bleibt nach Eingang der Daten wieder eine Minute offen. Hier habe ich eine Verständnisfrage: sollte nicht HtRest nach der Browserabfrage die Verbindung selbstständig schließen? Die Startprozedur von HtRest funktioniert also. Wenn ich jetzt bei laufendem HtRest-server wieder HomeControl starte und diese Verbindung offen ist ich jetzt wieder eine Browserabfrage starte wird im Browserfenster "Connection refused" angezeigt. Ist ja auch richtig weil belegt. Wenn aber jetzt HomeControl die Verbindung trennt und wieder ein Browseraufruf erfolgt kommt jetzt die Meldung "connection not established". Bei systemctl status htrest.service wird angezeigt: May 29 12:26:18 raspberry02 htrest[752]: File "/home/pi/venv/htrest/lib/python3.11/site-packages/htrest/apis/param.py", line 60, in get May 29 12:26:18 raspberry02 htrest[752]: with HtContext(ht_heatpump): May 29 12:26:18 raspberry02 htrest[752]: File "/home/pi/venv/htrest/lib/python3.11/site-packages/htrest/apis/utils.py", line 56, in __enter__ May 29 12:26:18 raspberry02 htrest[752]: self._heatpump.login() # Hint: login() will also try a reconnect on failure May 29 12:26:18 raspberry02 htrest[752]: ^^^^^^^^^^^^^^^^^^^^^^ May 29 12:26:18 raspberry02 htrest[752]: File "/home/pi/venv/htrest/lib/python3.11/site-packages/htheatpump/htheatpump.py", line 465, in login May 29 12:26:18 raspberry02 htrest[752]: self.send_request(LOGIN_CMD) May 29 12:26:18 raspberry02 htrest[752]: File "/home/pi/venv/htrest/lib/python3.11/site-packages/htheatpump/htheatpump.py", line 301, in send_request May 29 12:26:18 raspberry02 htrest[752]: raise IOError("connection not established") May 29 12:26:18 raspberry02 htrest[752]: OSError: connection not established Jetzt hilft wieder nur noch ein sudo systemctl restart htrest.service.

PS: Modem läuft im TCP-Server Modus. Ich kann das Modem umstellen auf Ethernet-Modem. Hier funktioniert der Start von HtRest bei gleichen Bedingungen wie oben auch einwandfrei nur bleibt jetzt die HtRest Verbindung, wenn einmal aufgebaut ständig bestehen. Wenn das so richtig ist kann ich auf jeden Fall damit leben! Habe aber noch nicht im Dauerbetrieb getestet weil ich die Datenpunkte und die Abfrage dazu erst in iobroker erstellen muss.

Die utils.py sieht bei mir an der entsprechenden Stelle etwas anders aus: bei mir: def __init__(self, heatpump): assert heatpump is not None, "'ht_heatpump' must not be None" Bei dir: def __init__(self, heatpump: HtHeatpump) : assert heatpump is not None, "'ht_heatpump' must not be None" Wenn ich das so übernehme funktioniert es nicht.

Einen schönen Feiertag und liebe Grüße Wolfgang

dstrigl commented 3 months ago

@innriver Hallo Wolfgang!

Zuerst mal vielen lieben Dank für deine Tests und die Ergebnisse. Und hier die gute Nachricht: Habe das eigentliche Problem zu deinem "connection not established" gefunden!

War hier leider etwas blind und habe erst jetzt gesehen, dass ich in den ganzen htheatpump-Funktionen die Senderoutine NICHT innerhalb des try-catch Block platziert hatte, da die Senderoutine über die serielle Schnittstelle etwas anderes arbeitet als die über die Socket-Verbindung. Die Senderoutine über die serielle Schnittstelle hat keinen Fehler produziert, auch wenn keine Verbindung mehr bestand, weshalb ich sie außerhalb des try-catch Block hatte. Die Senderoutine über die Socket-Verbindung produziert allerdings einen Fehler beim Versenden über TCP, wenn die Verbindung abgebrochen wurde. Würde ich heute vermutlich prinzipiell innerhalb des try-catch Block packen, auch für die Verbindung über die serielle Schnittstelle.

Hab das jetzt mal in dem Branch socket-connection von htheatpump korrigiert, womit jetzt auch das Verhalten beim Login mit dem Reconnect so wie von mir beschrieben sein sollte. Sprich, wenn der Login fehlschlägt wird nochmal bis zu 2 mal probiert inklusive einem Reconnect. Also einfach in deiner Installation das File htheatpump.py durch das im obigen Branch ersetzen.

Zu deiner Verständnisfrage "sollte nicht HtRest nach der Browserabfrage die Verbindung selbstständig schließen?": Das kommt auf den Use-Case drauf an! Wenn ich jetzt alle 5 Sekunden etwas über HtREST mit der WP mache, dann macht es wenig Sinn, jedes mal die Verbindung zu schließen und neu aufzubauen. Vorausgesetzt HtREST ist die einzige Anwendung die auf die WP zugreift. Wenn jetzt mehrere Anwendungen zugreifen wollen oder die Abfragen auch recht lange zeitlich auseinanderliegen, dann macht es Sinn die Verbindung jedes mal nach der Abfrage zu schließen und neu aufzubauen.

Ich hab dir das jetzt mal in einem eigenen Branch der HtREST Anwendung vorbereitet inkl. einer Anpassungen, dass wenn beim Starten der Anwendung keine Verbindung zur WP hergestellt werden konnte (weil z.B. gerade HomeControl noch eine Verbindung offen hat) das nur als Warnung und nicht als Fehler gewertet wird (und somit die Anwendung trotzdem startet und nicht mit einem Fehler abbricht): socket-connection

Hier sind die beiden Files htrest/apis/utils.py und htrest/app.py betroffen. Also einfach diese beiden Files in deiner Installation durch die im Branch ersetzen!

Überall wo in den obigen beiden Files ein Kommentar # TODO? steht wäre das automatische Schließen und wieder Öffnen bei jeder Anfrage an HtREST vorbereitet. Also, wenn du das so umgesetzt haben möchtest einfach in den beiden Files die Zeilen mit diesem Kommentar einkommentieren (sprich die Raute # vorne entfernen), wie z.B. hier:

htrest/apis/utils.py:

    def __enter__(self):
=>      # self._heatpump.open_connection()  # TODO?
        self._heatpump.login()  # Hint: login() will also try a reconnect on failure
        return self

    def __exit__(self, *args):
        self._heatpump.logout()
=>      # self._heatpump.close_connection()  # TODO?

Die Anpassungen von mir in den beiden Files siehst du auch schön hier: Changes

Das mit dem "... utils.py sieht bei mir an der entsprechenden Stelle etwas anders aus" ist nur, weil ich das Ganze in einer neueren Version umgesetzt und rauskopiert habe, wo ich type-Hints verwendet habe. Kannst du derweilen getrost ignorieren.

LG Daniel.

innriver commented 3 months ago

@dstrigl Hallo Daniel,

vielen vielen lieben Dank! Jetzt sieht alles sehr gut aus. Ich habe alle Möglichkeiten durchgespielt und es funktioniert nach meiner Ansicht richtig. Auch das automatische Schließen und wieder Öffnen funktioniert. Soweit ich das sehen konnte kommen auch alle Datenpunkte die ich in in der htparms.csv konfiguriert habe richtig zurück. Nur wenn ich die Softwareversion mit aufnehme wird eine Warnung ausgeworfen : "parameter name doesn't match with 'Softwareversion' ['2.06K']" brauch ich aber nicht. Jetzt alles noch in iobroker integrieren - erster Test geht auch schon - aber Rentner und Zeit....... Sind das jetzt zwei verschiedene Versionen für socket-connection und für ser-connection? Nochmals vielen, vielen Dank für deine hervorragende Arbeit und die Zeit die du aufgewendet hast.

LG Wolfgang

dstrigl commented 3 months ago

@innriver Hallo Wolfgang,

vielen vielen lieben Dank! Jetzt sieht alles sehr gut aus. Ich habe alle Möglichkeiten durchgespielt und es funktioniert nach meiner Ansicht richtig.

gern geschehen! Freut mich, wenn es jetzt funktioniert :-)

Nur wenn ich die Softwareversion mit aufnehme wird eine Warnung ausgeworfen : "parameter name doesn't match with 'Softwareversion' ['2.06K']" brauch ich aber nicht.

Das mit der Softwareversion ist etwas speziell, weshalb ich es im default-CSV auch auskommentiert habe: https://github.com/dstrigl/htheatpump/blob/master/htheatpump/htparams.csv

Die Softwareversion, welche unter dem Datenpunkt SP,NR=9 zu finden ist hat nämlich im Rückgabefeld NAME die eigentliche Versionsnummer und im Rückgabefeld VAL eine numerische Nummer (was auch immer genau, vielleicht Build-Nummer oder so) stehen:

"SP,NR=9,ID=9,NAME=3.0.20,LEN=4,TP=0,BIT=0,VAL=2321,MAX=0,MIN=0,WR=0,US=1"

Sprich unter NAME ist bei jeder WP je nach installierter Version ein anderer Text zu finden. Verhält sich also komplett anders als alle anderen Datenpunkte auf der WP, denn die haben unter NAME einen eindeutigen Namen stehen, der den DP identifiziert. Deshalb hab ich es mal bei mir im CSV ausgenommen. Stattdessen hat htheatpump eine eigene Funktion dafür: get_version() Diese liefert als Tuple diese beiden Felder zurück.

Sind das jetzt zwei verschiedene Versionen für socket-connection und für ser-connection?

Ich hab das jetzt mal im htheatpump und HtREST Modul als eigenen Branch implementiert, möchte das Ganze aber in den master-Branch einfließen lassen und in der nächsten Release dabei haben. Dabei soll dann meiner Idee nach beides unterstützt werden und per Argument steuerbar sein (z.B. ob automatischer Close nach jedem Request). Kann dir nur noch nicht sagen, wann diese neue Release kommt, da ich aktuell dazu (leider) recht wenig Zeit finde.

LG Daniel.

innriver commented 3 months ago

@dstrigl Hallo Daniel,

Kann dir nur noch nicht sagen, wann diese neue Release kommt, da ich aktuell dazu (leider) recht wenig Zeit finde.

Ich bin zur Zeit mehr als zufrieden mit dem wie es jetzt ist. Ich habe ja nie damit gerechnet so schnell eine lauffähige Version mit socket-connection zu erhalten. Ich kann dir nicht genug dafür danken. Werde es in den nächsten Wochen dann in mein Produktiv-System einbauen. Dann wird auch wieder der "Kaffeedurst" gestillt werden.

PS: ein Problem hab ich noch: Ich habe heute eine Neuinstallation auf einen anderen PI gemacht. Beim Start kommt: ImportError: cannot import name 'url_quote' from 'werkzeug.urls' (/home/pi/venv/htrest/lib/python3.11/site-packages/werkzeug/urls.py) Hardware ist die gleiche: RPI 3B mit bookworm 64 bit und Python 3.11 Aufgefallen ist mir dass Flask und Werkzeug in den folgenden Versionen installiert wurden:

(htrest) pi@raspberry07:~ $ pip show werkzeug Name: Werkzeug Version: 3.0.3

(htrest) pi@raspberry07:~ $ pip show flask Name: Flask Version: 2.0.3

Wenn ich Werkzeug 2.0.3 installiere funktioniert alles. Flask auf 3.0.3 hochziehen bringt auch nichts - htrest will 2.0.3.

LG Wolfgang

dstrigl commented 3 months ago

@innriver Hallo Wolfgang!

Freut mich, wenn du mehr als zufrieden bist! Bin echt oft überwältigt wie viele Leute inzwischen auf meine Module zurückgreifen. Leider finde ich aktuell zu wenig Zeit diese so weiter zu entwickeln, wie ich es gerne würde.

Das mit dem ImportError ist ein bekannten Problem im Flask Modul mit einer inkorrekten Abhängigkeitsdefinition: Why did Flask start failing with "ImportError: cannot import name 'url_quote' from 'werkzeug.urls'"?

I had the same problem.
It is because Werkzeug 3.0.0 was released and Flask doesn't specify the dependency correctly (requirements says Werkzeug>=2.2.0).

Da hilft aktuell nur, Werkzeug auf die funktionierende Version genau fix festzupinnen. So wie du es eh schon gemacht hast.

Das sollte auch noch kompatibel sein:

pip3 install Werkzeug==2.1.2 --upgrade
pip3 install flask==2.1.3 --upgrade

LG Daniel.