openWB Forum

aiole hat geschrieben: ↑So Feb 11, 2024 12:30 pm Wie soll das gehen, wenn Zeitladen deaktiv ist?
M.E. ist egal, ob man mit aktivem Zeitladen und deaktiven timer oder eben deaktivierten Zeitladen operiert.

Mir wurde hier erklärt, das Zeitladen im Prinzip wie das "Nachtladen" bei 1.9 zu verstehen sei, dass es also zusätzlich auf den gewählten Lademodus angewendet würde, um beispielsweise ein Vorkonditionieren mit Hausstrom nach Zielladen zu ermöglichen.

Zielladen ist aber ein "echter" Lademodus, sollte dem entsprechend immer Priorität vor dem Zeitladen haben. Das ist auch folgerichtig, denn beim Zeitladen macht man ja mehr allgemeine Zeitpläne, währen man beim Zielladen, ins besondere mit dem "einmal"-Plan, das Fahrzeug ja zu einem konkreten Zeitpunkt voll haben will.

Wie auch immer, wenn es keine aktiven Pläne für das Zeitladen gibt sollte es nicht das Laden in anderen Modi verhindern.

Die Lösung wird wohl sein, dass ich Zeitladen einfach nicht verwenden und das mit Ziellade-Plänen zu imitieren versuche.

bye
TW

Janohmat hat geschrieben: ↑So Feb 11, 2024 4:57 pm Ich möchte nicht aussschließen das ich es falsch konfiguriert habe,
[...]
Liegts an der Config oder wo muss ich drehen?

Hatten wir hier schon öfter, ist nur nicht leicht wieder zu finden:
In der Konfiguration des Lastmanagement den Bereich "Struktur" auf klappen.
Da muss der Speicher "in" den Wechselricher, nicht darunter.

Janohmat hat geschrieben: ↑So Feb 11, 2024 4:57 pm die Konfiguration finde ich leider nicht wirklich intuitiv :\.

Ich denke, dass ist noch ein Fehler in der Umsetzung der Konfiguration, denn wenn man ein Gerät "Hersteller-Wechslerichter" und anschließend "Hersteller-Speicher" hinzu fügt, ist in 99,99% aller Fälle genau diese Konfiguration notwendig. Daher sollte es der Default sein, den Speicher "in" den Wechelrichter zu setzten...

bye
TW

Ich hatte am 11.2. ein seltsames Verhalten.
Der PV-Zähler des SolarEdge Wechelrichters ist "rückwärts" gelaufen.
Ich lese täglich den Zählerstand im Status ab, früh lag er noch bei 8104 kWh, jetzt liegt er bei 8058 kWh.
Daher habe ich mir mal über die SolarEdge SetApp App den Zählerstand angeschaut (8,06 MWh), entspricht also eher dem neuen Wert.
Ich hatte heute Nachmittag die Box sauber heruntergefahren, nach dem Neustart hatte ich zunächst kein Netzwerk (Mein Kabel war Schuld), daher habe ich zunächst gedacht, es lag ggf. daran.
Nun habe ich mir die main.log Dateien angeschaut und dabei fest gestellt, dass es in den alten Logfiles vor dem Neustart eine Abweichung im Inverterstate gab:
"{DEBUG:device0} - Raw data InverterState" gab den korrekten Zählerstand zurück, jedoch wurde mit:
"{DEBUG:component2} - Raw data InverterState" ein höherer Wert gespeichert.
Nach dem Neustart war dies weg, so dass ich heute einen negativen (wird in der Monatsauswertung zum Glück mit 0 ausgewiesen) PV-Wert habe.
In der Tagesstatistik war es wieder ein Peak.

Ich war zu dem Zeitpunkt nicht auf der aktuellen master (Ich glaube, den vom 2.2. oder so), wenn so ein Problem also bekannt oder behoben ist, bitte ignorieren.
Das Log mit den oben beschriebenen fehlerhaften Zählerwerten: P.S: Jetzt bin ich natürlich wieder auf dem aktuellen master.

Guten Morgen,

ich habe gestern das Update von 2.1.2 Beta auf 2.1.3 Beta 1 gemacht. Heute morgen habe ich einige Kuriositäten beobachtet, inklusive der Tatsache, dass das Laden in der Nacht nicht geklappt hat.

Was ich sehe, ist:

• Das Update hatte augenscheinlich problemlos funktioniert
• Das HMI hatte ich umgestellt auf Colours
• Per MQTT hatte ich (wie immer) einen Zeitplan gesendet. Der wurde mir auch angezeigt und aktiviert
• Beim Status des rechten Ladepunktes (verwende eine Duo) zeigt er mir an "Bereit" (mit Steckersymbol). Klicke ich auf die 3 Punkte, zeigt er mir "ein interner Fehler aufgetreten ist". Ob das gestern Abend schon angezeigt wurde, weiß ich nicht. War mir nicht aufgefallen. Ich denke eigentlich, dass ich das bemerkt hätte.
• Jetzt habe ich das HMI gerade auf "Standard" zurück gestellt und dabei bemerkt, dass der Preis für das strompreisbasierte Laden auf 20ct eingestellt war. So niedrig war der Preis letzte Nacht aber nicht. Vermutlich ist das der Grund, warum nicht geladen wurde. Ich hatte gestern das strompreisbasierte Laden aktiviert, aber nicht weiter konfiguriert. Im Colours Theme habe ich dafür keine Einstellmöglichkeit gesehen. Eine Erklärung für die komische Fehlermeldung ist die Preisgrenze aber nicht. "ein interner Fehler aufgetreten ist" wird mir auch im "Standard" Theme angezeigt. Auch hier nur, wenn ich auf den Ladepunkt geklickt habe. Davor sieht alles in Ordnung aus.
• In den Ladeeinstellungen wollte ich gestern meinen Stromversorger Tibber einstellen. Trage ich dann mein Token ein und klicke auf "Jetzt abrufen", bekomme ich die Fehlermeldung "Beim Abfragen der TibberID ist ein Fehler aufgetreten: AxiosError Network Error". Trage ich statt dessen die HomeID von Hand ein, wird mir angezeigt, dass ich ein Element aus der (wegen des Netzwerkfehlers leeren) Liste auswählen soll. Tibber geht also nicht. Ich habe daher Awattar ausgewählt. Eigentlich wollte ich das nur nutzen, um im Ladelog realistischere Preise angezeigt zu bekommen. Die Steuerung der Ladezeiten hatte ich ohnehin schon zuvor selbst gelöst.
• Im Main Log wird mir ca. alle 10 Sekunden dieser Fehler eingetragen:

  Code: Alles auswählen

  2024-02-11 16:56:20,898 - {control.ev:333} - {ERROR:MainThread} - Fehler im ev-Modul 5
  Traceback (most recent call last):
    File "/var/www/html/openWB/packages/control/ev.py", line 274, in get_required_current
      if (self.soc_module and self.charge_template.data.chargemode.scheduled_charging.plans[plan_data.num].
  AttributeError: 'NoneType' object has no attribute 'num'
  2024-02-11 16:56:30,470 - {control.ev:333} - {ERROR:MainThread} - Fehler im ev-Modul 5
  Traceback (most recent call last):
    File "/var/www/html/openWB/packages/control/ev.py", line 274, in get_required_current
      if (self.soc_module and self.charge_template.data.chargemode.scheduled_charging.plans[plan_data.num].
  AttributeError: 'NoneType' object has no attribute 'num'

Ich bin jetzt leider auf dem Sprung, melde mich heute Abend wieder.

Thomas aus W hat geschrieben: ↑So Feb 11, 2024 7:52 pm Mir wurde hier erklärt, das Zeitladen im Prinzip wie das "Nachtladen" bei 1.9 zu verstehen sei, dass es also zusätzlich auf den gewählten Lademodus angewendet würde, um beispielsweise ein Vorkonditionieren mit Hausstrom nach Zielladen zu ermöglichen.

Das ist auch so.

Thomas aus W hat geschrieben: ↑So Feb 11, 2024 7:52 pm Wie auch immer, wenn es keine aktiven Pläne für das Zeitladen gibt sollte es nicht das Laden in anderen Modi verhindern.

So soll das auch sein. Ich stelle hier 5 Uhr ZielLaden fertig + 6:30-6:50 Zeitladen für Vorklima ein.
Müsste ich mal testen, ob ein deaktives Zeitladen (in den 2 Var. Zeitladen abgeschalten oder Zeitladen-timef rot=deaktiv) im Bereich des Zielladens dieses blockiert.

Thomas aus W hat geschrieben: ↑So Feb 11, 2024 7:52 pm Die Lösung wird wohl sein, dass ich Zeitladen einfach nicht verwenden und das mit Ziellade-Plänen zu imitieren versuche.

Wie beschrieben funktioniert das in meiner Anwendung oben hervoragend mit kombiniertem Zeitladen.

aiole hat geschrieben: ↑Mo Feb 12, 2024 2:02 pm Wie beschrieben funktioniert das in meiner Anwendung oben hervoragend mit kombiniertem Zeitladen.

Dann ist wohl nur der Infotext (für mich) missverständlich...

bye
TW

Danke @Thomas, die Strukturanpassung hat mein Problem mit dem TriPower Smart Energy gelöst...

Jetzt kommt noch ein Fehler der hier bereits 2x im Forum erwähnt aber nicht wirklich behandelt wurde.

Wenn ich die Konfiguration öffne kommt immer wieder die Fehlermeldung das ein Python Modul nicht installiert werden konnte.



Das Basis System ist ein normal mit dem Raspian Imager auf die SD-Karte geflashstes aktuelles Bullseye vom 5.12.2023.

Thomas aus W hat geschrieben: ↑Mo Feb 12, 2024 2:38 pm

aiole hat geschrieben: ↑Mo Feb 12, 2024 2:02 pm Wie beschrieben funktioniert das in meiner Anwendung oben hervoragend mit kombiniertem Zeitladen.

Dann ist wohl nur der Infotext (für mich) missverständlich...

bye
TW

Der Support ist dankbar, wenn die Hilfstexte von Anwender:innen im Hinblick auf perfektes Verständnis optimiert werden. Überarbeitete Hilfstexte können hier direkt gepostet werden. Das wird dann nochmal geprüft und wenn ok, geht es ins System.

Janohmat hat geschrieben: ↑Mo Feb 12, 2024 2:42 pm Jetzt kommt noch ein Fehler der hier bereits 2x im Forum erwähnt aber nicht wirklich behandelt wurde.

Du bist auf sw2?
Wenn ja, warum nimmst Du nicht das fertige Image aus den Ankündigungen?
https://openwb.de/uploads/openWB-softwa ... 1.1.img.gz

Janohmat hat geschrieben: ↑Mo Feb 12, 2024 2:42 pm Danke @Thomas, die Strukturanpassung hat mein Problem mit dem TriPower Smart Energy gelöst...

Jetzt kommt noch ein Fehler der hier bereits 2x im Forum erwähnt aber nicht wirklich behandelt wurde.

Wenn ich die Konfiguration öffne kommt immer wieder die Fehlermeldung das ein Python Modul nicht installiert werden konnte.



Das Basis System ist ein normal mit dem Raspian Imager auf die SD-Karte geflashstes aktuelles Bullseye vom 5.12.2023.

Code: Alles auswählen

install required python packages with 'pip3'...
Traceback (most recent call last):
  File "/usr/bin/pip3", line 33, in <module>
    sys.exit(load_entry_point('pip==20.3.4', 'console_scripts', 'pip3')())
  File "/usr/bin/pip3", line 25, in importlib_load_entry_point
    return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
    module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/main.py", line 10, in <module>
    from pip._internal.cli.autocompletion import autocomplete
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/autocompletion.py", line 9, in <module>
    from pip._internal.cli.main_parser import create_main_parser
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/main_parser.py", line 7, in <module>
    from pip._internal.cli import cmdoptions
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/cmdoptions.py", line 23, in <module>
    from pip._vendor.packaging.utils import canonicalize_name
  File "/usr/lib/python3/dist-packages/pip/_vendor/__init__.py", line 94, in <module>
    vendored("requests.packages.urllib3.contrib.pyopenssl")
  File "/usr/lib/python3/dist-packages/pip/_vendor/__init__.py", line 36, in vendored
    __import__(modulename, globals(), locals(), level=0)
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 627, in _load_backward_compatible
  File "<frozen zipimport>", line 259, in load_module
  File "/usr/share/python-wheels/urllib3-1.26.5-py2.py3-none-any.whl/urllib3/contrib/pyopenssl.py", line 50, in <module>
  File "/usr/lib/python3/dist-packages/OpenSSL/__init__.py", line 8, in <module>
    from OpenSSL import crypto, SSL
  File "/usr/lib/python3/dist-packages/OpenSSL/crypto.py", line 1556, in <module>
    class X509StoreFlags(object):
  File "/usr/lib/python3/dist-packages/OpenSSL/crypto.py", line 1577, in X509StoreFlags
    CB_ISSUER_CHECK = _lib.X509_V_FLAG_CB_ISSUER_CHECK
AttributeError: module 'lib' has no attribute 'X509_V_FLAG_CB_ISSUER_CHECK'
failed!

64 Bit OS mal probiert?