Einstellungen für Min+PV-Laden werden bei Speichern nicht übernommen

[joern]

welche Fehlermeldung kommt dann wenn händisch aufgerufen wird?

pi@Solar-Pi-OWB:~ $ python3 /var/www/html/openWB/runs/mqttsub.py
Traceback (most recent call last):
File "/var/www/html/openWB/runs/mqttsub.py", line 910, in <module>
client.loop_forever()
File "/usr/local/lib/python3.5/dist-packages/paho/mqtt/client.py", line 1779, in loop_forever
...
File "/var/www/html/openWB/runs/mqttsub.py", line 546, in on_message
if (int(msg.payload) >= 0 and int(msg.payload) <=1):
ValueError: invalid literal for int() with base 10: b''

Hallo,
ich habe ebenfalls exakt dasselbe Problem und gestern abend ziehmlich viel rumprobiert.

Konfiguration:
- selbst installiert, Pi3+, Stretch, (vorher mit Buster probiert),
- go-e, SoC Tesla, SMA-HomeManager, SMA-ModbusTCP-WR, KEIN Speicher
- sowohl mit 1.8.400Beta als auch mit 1.8.412Nightly

Offenbar beendet sich mqttsub.py mit Fehlermeldung bei mehren Gelegenheiten und zwar u.a., wenn man die LademodusAuswahl auf der MainPage ändert (z.B. Stop -> PV) oder wenn man die Konfiguration in Ladeeinstellungen ändert.

mqttsub.py endet dabei in unterschiedlichen Zeilen, jedoch immer beim Versuch ein Rückgabewert mit int() umzuwandeln, weil ins msg.payload folgendes drin war: b''
Ich kenne mich mit python nicht so gut aus, aber ich glaube, dass soll ein NullString sein.

Beim ändern der PC-Ladeeinstellungen mit der nightly kommt z.B. diese Fehlermeldung:

Code: Alles auswählen

File "/var/www/html/openWB/runs/mqttsub.py", line 287, in on_message
    if (int(msg.payload) >= -100000 and int(msg.payload) <= 100000):
ValueError: invalid literal for int() with base 10: b''

Beim Ändern der LademodusAuswahl steigt die mqttsub.py in der nightly (in der beta mit anderer Zeilennummer) ständig an der Zeile 742 aus:

Code: Alles auswählen

File "/var/www/html/openWB/runs/mqttsub.py", line 742, in on_message
    if (int(msg.payload) >= 0 and int(msg.payload) <=4):
ValueError: invalid literal for int() with base 10: b''

Erst nachdem ich in der mqttsub.py davor die folgende Zeile als Nothilfemaßnahme eingefügt hatte, konnte ich erstmal überhaupt mal von STOP auf irgendeinen Lademodus umschalten:

Code: Alles auswählen

if(msg.payload != b''):

Natürlich hilft das nicht gegen die eigentlich Ursache, aber es hilft dagegen, dass die mqttsub.py ständig abstürzt.
Wieso die msg.payload offenbar unerwartet kein Zahlenwert (int) enthält, übersteigt aktuelle meine debugging-Fähigkeiten.

Ich hoffe das hilft euch beim Auffinden der Ursache.

jörn

[openWB]

An irgendeiner Stelle scheint hier statt eines string/int ein byte reinzukommen, das verursacht den Fehler.

[Der-Kieler]

Bei mir wechselt er den Status, aber es dauert mehrere Minuten (nicht immer, manchmal auch sofort). Ebenso beim speichern geänderter Ladeeinstellungen.
Probiere es doch mal aus, ob es bei Dur genauso ist.

Der Support stellt zwar immer wieder den Fehler fest, nur eine Lösung oder den Versuch einer Lösung gibt es nicht. Es wurde bei mir mehrfach darauf verwiesen, dass man doch bitte die Stand-alon Lösung kaufen möge, wenn man nicht in der Lage ist das Programm richtig zu installieren. :-/

[openWB]

Das steht schon auf der Agenda,
Priorität haben allerdings Bestandskunden, Auftragsprojekte und im Nachgang Communityprobleme.

[Der-Kieler]

Das steht schon auf der Agenda,
Priorität haben allerdings Bestandskunden, Auftragsprojekte und im Nachgang Communityprobleme.

Das ist doch mal eine Aussage! - Bisher hatte ich den Eindruck, dass das Thema ignoriert wird, weil Ihr den Fehler beim User vermutet.
Also ist der Fehler als solcher erkannt und wird wenn Zeit ist bearbeitet. Schön, dass das jetzt geklärt ist.

[LutzB]

Der Support stellt zwar immer wieder den Fehler fest, nur eine Lösung oder den Versuch einer Lösung gibt es nicht.

Zumindest ich warte noch auf die Logmeldungen, die nach der Änderung im mqtt.log stehen...

[joern]

Bei mir wechselt er den Status, aber es dauert mehrere Minuten (nicht immer, manchmal auch sofort). Ebenso beim speichern geänderter Ladeeinstellungen.
Probiere es doch mal aus, ob es bei Dur genauso ist.

Passt schon: die mqttsub.py stürzt ab und wird dann durch die cron5min.sh mittels crontab nach spätestens 5 min wieder neu gestartet und arbeitet dann den Rest von mqtt ab.

jörn

[joern]

Zumindest ich warte noch auf die Logmeldungen, die nach der Änderung im mqtt.log stehen...

Ich übernehme mal:
wenn ich den Lademodus ändere, taucht im mqtt.log folgendes auf:

Code: Alles auswählen

2020-10-25 21:30:35 Topic: openWB/set/ChargeMode Message: 2
2020-10-25 21:30:35 Topic: openWB/set/system/topicSender Message: local client uid: veejn sent: openWB/set/ChargeMode

Wenn ich den mqttsub.py Prozess dann von Hand wieder neu starte, tauchen noch folgende Zeilen auf:

Code: Alles auswählen

2020-10-25 21:33:53 Topic: openWB/set/graph/RequestMonthLadelog Message: 0
2020-10-25 21:33:53 Topic: openWB/set/graph/RequestDayGraph Message: 0
2020-10-25 21:33:53 Topic: openWB/set/graph/RequestMonthGraph Message: 0

Habe ich die Frage richtig verstanden?

jörn

[joern]

An irgendeiner Stelle scheint hier statt eines string/int ein byte reinzukommen, das verursacht den Fehler.

Genau genommen, ist es sogar immer ein "empty byte", also: b''

Ihr erwartet eigentlich ein String und statt dessen kommt ein byte?
Der Unterschied zwischen string und byte ist ja bekanntlich nur das encoding (UTF-8), bzw. auch bei python3 gab es diesbezüglich im handling wohl bei älteren Versionen wohl mal Unterschiede, ob man string oder byte zurück bekommt.

Könnte hier vielleicht irgendwo der Unterschied liegen, zwischen einem selbst eingerichtetem Pi3 und der Pi-Installation im "openWB series2"?

Bei mir ist Python 3.5.3 installiert - läuft das bei euch auch?

Wenn ich "locale" eingebe, dann kommt:

Code: Alles auswählen

LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
...

jörn

P.S. ich habe bereits eine "openWB s2 custom" bestellt - es dann aber wegen der Förderung auf "Reservierung" umgestellt und möchte jetzt die Zeit bis zur Lieferung mit dieser selbst-installierten openWB überbrücken. Da ich die automatische PhasenUmschaltung benötige, bleibe ich auch dabei.

[LutzB]

Vom Prinzip her schon. Mit der letzten Änderung wird geloggt, bevor die Nachricht verarbeitet wird und der Prozess wegen unerwarteter Daten abschmiert. Das ist anscheinend bei Dir nicht der Fall. Hast Du auch das Problem und die aktuelle Nightly drauf?