ERROR Exception HTTPConnectionPool und Anhalten des H..ZeroExp. Services #74
Comments
|
Hi Sascha, zu Punkt 1: Powermeter nicht erreichbar Zu Punkt 2: Inverter nicht erreichbar Es ist immer schwierig die Fehlerbehandlung für jeden Anwendungsfall optimal zu gestalten. |
|
Hmm... Punkt 2 war nur das Bsp. wo das Script weiterläuft... ist mir klar, wenn die DTU bzw. der Inverter von der DTU nicht erreicht wird, eh nix mehr geht. Wobei dieser Punkt leider oft bei mir auftritt, dass der Inverter nicht erreichbar ist..., meistens erst nach dem 3 oder 4 ten Versuch ist reachable: True Dadurch wird die Regelung etwas träge.
Meine DTU steht in ca. 1 m Entfernung zum WR hat aber nur zw. 30% - 40% WLAN
Lowest panelvoltage: inf Volt damit war der Spannungswert = inf Das Scrip reagiert aber nicht darauf sondern versucht einfach weiter zu regeln. bzg. battery-mode müsste hier aber eine Reaktion erfolgen das die Spannung der Batterie ja eigentlich 0 ist? Die Ursache dafür habe ich noch nicht wirklich gefunden, ist wohl ein Thema für die OpenDTU. Konnte ich nur beheben indem ich die OpenDTU und den WR neu gestartet habe. Wie könnte man den damit umgehen / darauf reagieren? MfG Sascha |
ggf. war auch dein Raspi ohne LAN Verbindung? Der Reboot hat es dann gefixt. Wenn ich das Log anschaue fällt mir auf, dass du ziemlich oft Verbindungsprobleme hast. Spannungswert = inf ist noch ein Problem von mir, da kam von der OpenDTU wahrscheinlich kein valider Wert zurück. Das fixe ich noch. Dein Loop Intervall ist viel zu schnell. Mit Ahoy schaffe ich einen stabilen Betrieb bei 10s. Erhöhe hier mal auf min. 10-15s. Sonst hat die DTU/Inverter keine Chance die Werte zu aktualisieren weil die DTU mit Limitänderungen restlos ausgelastet ist. Wahrscheinlich ist das auch das Problem mit Inverter reachable = false und der fehlerhaft zurückgelesene Batteriespannung. Ggf. kann das auch zum Abbruch der WLAN Verbindung führen. Also im ersten Schritt würde ich das hier probieren, wahrscheinlich löst du damit schon die meisten Probleme: Wenn dein Inverter wirklich nur 1m von der DTU entfernt ist dürfte auch die Sendeleistung "MIN" anstelle "MAX" zu weniger Übertragungsfehlern beitragen. Das musst du in der DTU ausprobieren und nach ein paar Stunden die Statistik kontrollieren. |
|
Hallo, vielen Dank für die Tips. Ich habe nun schon mal die Einstellung mit LOOP_INTERVAL_IN_SECONDS = 11 getestet. OpenDTU: Inverter "HM-1500" reachable: False ist auf jeden Fall seltener und auch nicht mehr so oft direkt hintereinander. Werde nun die Einstellung der DTU auf Niedrig testen. MfG Sascha |
|
Welche Hardware für die DTU benutzt du? Eine ESP8266 ist zu schwach für so schnelle Abfragen. Du könntest desweiteren noch gucken mit welcher Frequenz dein ESP läuft. Die kann man auf 240MHZ hochdrehen. |
|
Folgende HW: Espressif ESP32 WLAN Dev Kit Board Development Bluetooth Wifi v1 WROOM32 NodeMCU & ESP32 läuft auf 240 MHz. Bei meiner gestrigen Problemlösungssuche bin ich auf der OpenDTU - Seite noch auf die Empfehlung gestoßen folgende Antenne einzusetzen --> EBYTE - NRF24L01+ PLUS - PA LNA SMA Antenne Long Range Funk Modul Raspberry Arduino. Evtl. ist die ja noch besser und zuverlässiger. Eine Überlegung wäre auch ein LAN - Erweiterung für die ESP32 Platine zu ergänzen die OpenDTU & den Raspy kabelgebunden zu betreiben. WR alternativlos Funk. Powermeter könnte ggf. noch ausgetauscht werden. |
|
Evtl löst ein billiger Devolo die Verbindungsprobleme, Strom hast du ja überall. WLAN ist leider für 24h Betrieb oftmals unzuverlässig wenn die Verbindung nicht optimal ist. Der Raspi gehört am besten auch direkt ins LAN (hast du am Router keinen Port mehr frei? Switch?). Du kannst an der DTU ja auch schauen wie oft neue Werte vom Inverter empfangen werden, wenn das länger als 10s dauert dann ist die Auslastung zu hoch (sollte ja alle 5s aktualisieren). Bei AHOY kann man auf der Status-Seite sehen wie oft die Kommunikation zum Inverter nicht geklappt hat. Evtl gibt es das ja auch bei OpenDTU. |
|
Raspi kommt noch an den LAN Port. Repeater habe ich noch rumliegen. Habe jedoch hier (Router EG und Repeater DG) die Erfahrung gemacht, dass das auch nicht immer zuverlässig ist). Wieder ein Teil mehr in der Kette. Anbei mal 8 min Auszug aus der DTU Konsole... Kommt sehr oft "missing" vor. Aber so richtig schlau werden ich daraus auch nicht. Hätt mal noch eine andere Frage, ggf. lohnt das auch für ein Issue. Welche HW-Anforderungen würdest Du an Dein Script mit meiner Form der Anwendung stellen. Einplatinen - Rechner insb. der Raspi sind ja auch sehr teuer geworden. Ggf. würde auch ein Pico oder Zero ausreichen. Bzw. was nächst günstigeres mit LAN Port. Ggf gibt es bei den Nutzern deiner SW Erfahrungen. MfG |
|
Ich glaube das läuft überall wo du ein Python Script laufen lassen kannst. Viel passiert in dem code ja nicht. |
|
Hallo reserve85, Punkt ist eigentlich geschlossen, nun hatte ich den oben beschriebenen Fehler: 2024-01-25 15:35:42,889 ERROR Exception at GetHoymilesActualPower erneut, nun aber leider bei voller Leistung von 1500 Watt. Wird nun bei einem aktuellen Stand deiner Software dieser Fehler abgefangen und die Leistung auf z.B. den reduzierten Spannungswert gesetzt? MfG |
|
nein, aber nach dem Timeout-Fehler (der kann durchaus mal vorkommen) läuft die Regelung doch wieder weiter? |
|
Nein, im Prinzip ist die WLAN-Verbindung von meinem Shelly1PM, welcher als SHELLY_IP_INTERMEDIATE = 192.168.178.25 fungiert unterbrochen. Die Regelung liest zwar weiter die Leistung am 3EM und bekommt Werte Auszug (log file habe ich angehängt ab Zeile 40612 tritt der Fehler auf): 2024-01-25 15:36:07,497 ERROR Exception at GetHoymilesActualPower Er liest ja ~ -1500 Watt aus aber passt die Leistung nicht mehr an. Die Exception wird immer wiederholt und es erfolgt kein Aufruf mehr von : def SetLimitOpenDTU(pInverterId, pLimit): Aktuell habe ich den SHELLY_IP_INTERMEDIATE auf false gesetzt. Idealerweise müsste das Script bei anhaltenden Verbindungsproblemen zu den Zählern die Leistung zumindest auf den HOY_BATTERY_REDUCE_WATT oder auf einen bestimmbaren Wert z.B. Grundlast... setzten. Vlt. wäre es die möglich so was zu implementieren. Werde aber auch mal mein WLAN verbessern. Gruß |
|
Ok, verstehe. Ich habe jetzt folgendes implementiert:
Es wäre super wenn du das bei dir mal laufen lassen könntest. |
|
Sry, schaffe es jetzt erst. Wenn ich die aktuelle Version via... https://github.com/reserve85/HoymilesZeroExport/tree/reduce_limit_on_error installiere bekomme ich die Version 1.68 und nicht 1.70. Wie installiere ich denn Version 1.70? |
|
Folgende Fehlermeldung bekomme ich im log sudo journalctl -u HoymilesZeroExport.service -n 20000 -e -f:
|
|
|
|
hab das python update vergessen sry |
|
packeging installiert und python auf 3.9 pi@piFlexCellEdgeDevice:~ $ pip3 install packaging Default version sollte aber 3.9 sein... pi@piFlexCellEdgeDevice:~ $ python --version mach ich hier noch was falsch? |
|
probiere mal manuell mit der spezifischen version zu starten: ich vermute dass er das mit version 3.7 öffnen will... warum auch immer? |
|
Bin nun etwas verwirrt, |
|
Kommt folgendes pi@piFlexCellEdgeDevice:~/HoymilesZeroExport $ python3.9 HoymilesZeroExport.py |
|
installieren von Requests... geht leider nicht pi@piFlexCellEdgeDevice:~/HoymilesZeroExport $ pip install requests |
|
probiere nochmal das:
|
|
hab das gleich noch mit packaging gemacht. python3.9 -m pip install packaging nun läuft es mit dem manuellen start python3.9 HoymilesZeroExport.py führt seltsamerweise wieder zu 3.7.3 |
|
Um zum eigentlichen Problem zurückzukommen... Version wird ja V1.69 genannt das ist dann wohl die aktuellste im Changelog, auch wenn hier oben 1.70 steht In meinem log file bekomme ich gleich am Anfang den Fehler: 2024-02-02 12:35:06,233 ERROR Exception at GetHoymilesActualPower der intermediate ShellyPM ist die IP ...25 laut meiner Frizbox ist er eigentlich erreichbar. müsste in nun mal ganz offline machen und schauen ob das auch keine Exception bzw. ein Stoppen des Scripts auslöst |
|
1.69 ist nicht richtig du brauchst die "Dev" Version hier: https://github.com/reserve85/HoymilesZeroExport/blob/reduce_limit_on_error/HoymilesZeroExport.py einfach die *.py ersetzen Edit: sicher kein Schreibfehler? Oben war es die 192.168.178.25 und unten 172? |
Kann das sein, dass du den Link falsch setzt? Die Python Version sollte glaub eher hier liegen: /usr/local/bin/python3.9? dann sollte das nämlich eher so aussehen: |
|
kann das zu? Im Script ist der "Not-Aus" implementiert und ich konnte es auch ein mal beobachten. |
## V1.81 ### script * add option to enable/disable to set the inverter to min watts when the powermeter can´t be read out. #28 (comment) + #74 ### config * add `COMMON`: `SET_INVERTER_TO_MIN_ON_POWERMETER_ERROR`
Erst mal Vielen Dank an reserve85 für die super Arbeit.
Ich betreibe das Script im Battery Mode, nun seit drei Tagen. Leider nicht ganz unterbrechungsfrei.
Vor zwei Tagen hat das Script mit folgendem Fehler einfach ausgesetzt:
2023-06-11 12:36:36,089 ERROR Exception at GetPowermeterWatts
2023-06-11 12:36:36,090 ERROR HTTPConnectionPool(host='192.168.178.23', port=80): Max retries exceeded with url: /status (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xb59f4850>: Failed to establish a new connection: [Errno 113] No route to host'))
2023-06-11 12:36:36,090 ERROR HTTPConnectionPool(host='192.168.178.23', port=80): Max retries exceeded with url: /status (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xb59f4850>: Failed to establish a new connection: [Errno 113] No route to host'))
Unter der IP ist der Shelly 3EM (RSI ~ -80dB +- 5 dB) ausgefallen
Das Ganze ist mir dann leider erst am Abend aufgefallen.
Nun lief der Inverter in der Zeit einfach mit dem letzten Limit weiter. Glücklicherweise bei ca. 300Watt.
Nun mehrere Anliegen/Fragen:
Warum setzt das Script hier einfach aus,
wenn z.B. der Inverter nicht erreicht wird, läuft die Schleife einfach weiter bis wieder ok -->
2023-06-12 21:29:34,194 ERROR Exception at GetHoymilesAvailable, Inverter 0 (HM-1500) not reachable
.
.
.
2023-06-12 21:33:06,354 ERROR Exception at GetHoymilesAvailable, Inverter 0 (HM-1500) not reachable
2023-06-12 21:33:14,514 ERROR Exception at GetHoymilesAvailable, Inverter 0 (HM-1500) not reachable
2023-06-12 21:33:20,719 INFO OpenDTU: Inverter "HM-1500" reachable: True
Könnte man hier einen Automatismus einbauen, das der Service neu gestartet wird? Oder man benachrichtigt wird um ggf. selber zu Restarten?
Wäre es möglich einen Leistungslimit für diesen Fall zu haben, dass man das Limit dann sozusagen erst mal auf die Grundlast einstellt?
MfG
Sascha
The text was updated successfully, but these errors were encountered: