openwb/core

openWB

Die Software steht unter der GPLv3 Lizenz. Weiterhin ist eine kommerzielle Nutzung nur nach Rücksprache und durch schriftlicher Zustimmung der openWB GmbH & Co. KG erlaubt.

Install ...

core's Issues

Konfigurationsabschluss PV-Komponente

Nach Abschluss der Konfiguration einer PV-Komponente erwarte ich, dass das im MQTT-Topic "openWB/pv/config/configured" hinterlegt wird. Meine Installation weigert sich aber.

Soweit ich das im Code überblicke, sollte das Umsetzen des Konfigurationsstatus in der Datei "packages/main.py" erledigt werden. Die interessante Funktion ist wohl "handler_with_control_interval".

In Zeile 55 werden die Konfigurationsdaten überprüft:

loadvars.get_virtual_values()

Letztendlich wird die Funktion "calc_power_for_all_components" aus der Datei "packages/control/pv.py" gerufen. Hier wird in Zeile 48 auch der Konfigurationsstaus gesetzt:

self.data["config"]["configured"] = True

Danach werden in der Datei "packages/main.py" in Zeile 58 die Werte in "self.data" wieder mit den Daten aus dem Broker überschrieben.

prep.copy_module_data()

Theoretisch wird der Konfigurationsstatus dann in "packages/main.py" Zeile 70 als Teil der Funktion "prep.setup_algorithm" veröffentlich. Hier wird dann aber nur veröffentlicht, was dem Broker schon bekannt war.

prep.setup_algorithm()

Ich sehen folgende Möglichkeiten:

1. Ich habe etwas übersehen.
2. Der Konfigurationsstatus könnte innerhalb der Funktion "calc_power_for_all_components" veröffentlich werden
3. Beim Lesen der Broker-Daten ist an der genannten Stelle der Datei "packages/main.py" das Lesen des Konfigurationsstatus zu übergehen.

Ansonsten hat der Code für die PV-Komponente sehr große Ähnlichkeit mit dem der Speicher-Komponente. Dort sehe ich das gleiche Problem, kann aus aber wegen des fehlenden Speichers in meiner Installation nicht direkt prüfen.

Virtuelle IP der Installation ist identisch mit einer echten openWB 192.168.193.5

Ich denke die Meisten, die testen haben auch eine echte Hardware in ihrem Netz haben. Um nicht nacharbeiten zu müssen, wäre es sinnvoll, wenn hier im Default eine andere IP verwendet würde.

z.B. 192.168.193.250
Dann ist man aus dem ganzen Bereich der Kits raus.
VG
Det

Automatische Phasenumschaltung wird nicht ausgeführt

Ich hatte das Verhalten auch schon kurz um Forum beschrieben: https://openwb.de/forum/viewtopic.php?p=79999#p79999

Im Log kann man aber ganz gut nachvollziehen, was wirklich passiert. Das konnte ich auch so mit dem Simulator nachstellen und debuggen

Zuerst scheint alles zu funktionieren:

2023-02-07 10:33:11,164 - {control.chargepoint:701} - {DEBUG:MainThread} - EV-Phasenzahl beschränkt die nutzbaren Phasen auf 3
2023-02-07 10:33:11,167 - {control.chargepoint:692} - {DEBUG:MainThread} - Phasenzahl Lademodus: 1
2023-02-07 10:33:11,169 - {control.chargepoint:867} - {DEBUG:MainThread} - LP 2, EV: Standard-Fahrzeug (EV-Nr.0): Theoretisch benötigter Strom 6A, Lademodus pv_charging, Submodus: Chargemode.PV_CHARGING, Phasen: 1, Priorität: False, max. Ist-Strom: 15.73

2023-02-07 10:33:11,192 - {control.algorithm.algorithm:26} - {DEBUG:MainThread} - # Algorithmus
2023-02-07 10:33:11,193 - {control.ev:517} - {DEBUG:MainThread} - Phasenumschaltung kann nun durchgeführt werden.
2023-02-07 10:33:11,210 - {control.process:22} - {DEBUG:MainThread} - # Ladung starten.
2023-02-07 10:33:11,212 - {control.chargelog:52} - {DEBUG:MainThread} - imported_since_mode_switch 4468.989999999991 counter 221468.99
2023-02-07 10:33:11,220 - {control.phase_switch:37} - {DEBUG:MainThread} - Thread zur Phasenumschaltung an LP2 gestartet.
2023-02-07 10:33:11,222 - {control.chargepoint:623} - {DEBUG:MainThread} - start phase switch phases_to_use 1control_parameter phases 3
2023-02-07 10:33:11,223 - {control.chargepoint:354} - {INFO:MainThread} - LP 2: Umschaltung von 1 auf 3 Phasen.
2023-02-07 10:33:11,226 - {control.process:106} - {INFO:MainThread} - LP2: set current 0 A

In der nächsten Runde wird jetzt die Umschaltung vorbereitet:

2023-02-07 10:33:20,588 - {root:61} - {INFO:MainThread} - # ***Start*** 
2023-02-07 10:33:20,963 - {control.chargepoint:701} - {DEBUG:MainThread} - EV-Phasenzahl beschränkt die nutzbaren Phasen auf 3
2023-02-07 10:33:20,964 - {control.chargepoint:689} - {DEBUG:MainThread} - Umschaltung wird durchgeführt, Phasenzahl nicht ändern 3
2023-02-07 10:33:20,964 - {control.chargepoint:692} - {DEBUG:MainThread} - Phasenzahl Lademodus: 3
2023-02-07 10:33:20,967 - {control.chargepoint:867} - {DEBUG:MainThread} - LP 2, EV: Standard-Fahrzeug (EV-Nr.0): Theoretisch benötigter Strom 6A, Lademodus pv_charging, Submodus: Chargemode.PV_CHARGING, Phasen: 3, Priorität: False, max. Ist-Strom: 0.0

2023-02-07 10:33:20,987 - {control.algorithm.algorithm:26} - {DEBUG:MainThread} - # Algorithmus
2023-02-07 10:33:21,002 - {control.process:22} - {DEBUG:MainThread} - # Ladung starten.
2023-02-07 10:33:21,010 - {control.chargepoint:582} - {DEBUG:MainThread} - phase switch running
2023-02-07 10:33:21,011 - {control.process:106} - {INFO:MainThread} - LP2: set current 0 A

Nach dem Log phase switch running wird in Chargepoint.initiate_phase_switch() charging_ev.data.control_parameter.timestamp_perform_phase_switch = None gesetzt. Soweit ich das verstehe, schließt das die Phasenumschaltung für die Logik ab. Die Ladung läuft aber noch nicht. Daher wird dann beim nächsten Intervall neu geprüft:

2023-02-07 10:33:30,401 - {root:61} - {INFO:MainThread} - # ***Start*** 
2023-02-07 10:33:30,713 - {control.chargepoint:701} - {DEBUG:MainThread} - EV-Phasenzahl beschränkt die nutzbaren Phasen auf 3
2023-02-07 10:33:30,715 - {control.chargepoint:692} - {DEBUG:MainThread} - Phasenzahl Lademodus: 1
2023-02-07 10:33:30,717 - {control.chargepoint:867} - {DEBUG:MainThread} - LP 2, EV: Standard-Fahrzeug (EV-Nr.0): Theoretisch benötigter Strom 6A, Lademodus pv_charging, Submodus: Chargemode.PV_CHARGING, Phasen: 1, Priorität: False, max. Ist-Strom: 0.0

2023-02-07 10:33:30,741 - {control.algorithm.algorithm:26} - {DEBUG:MainThread} - # Algorithmus
2023-02-07 10:33:30,751 - {control.chargepoint:354} - {INFO:MainThread} - LP 2: Die Ladung wird gestartet, sobald nach 30s die Einschaltverzögerung abgelaufen ist. 
2023-02-07 10:33:30,759 - {control.process:22} - {DEBUG:MainThread} - # Ladung starten.
2023-02-07 10:33:30,762 - {soc.modules.common.component_context:24} - {DEBUG:cp2} - Update Komponente ['Ladepunkt']
2023-02-07 10:33:30,764 - {control.phase_switch:37} - {DEBUG:MainThread} - Thread zur Phasenumschaltung an LP2 gestartet.
2023-02-07 10:33:30,766 - {control.chargepoint:623} - {DEBUG:MainThread} - start phase switch phases_to_use 3control_parameter phases 1
2023-02-07 10:33:30,767 - {control.chargepoint:354} - {INFO:MainThread} - LP 2: Umschaltung von 3 auf 1 Phase.
2023-02-07 10:33:30,769 - {control.process:106} - {INFO:MainThread} - LP2: set current 0 A

Der Algorithmus entscheidet jetzt aber start phase switch phases_to_use 3control_parameter phases 1. Das passiert in Chargepoint.get_phases_by_selected_chargemode(). Die Logik sieht keine aktive Umschaltung mehr, es wird aber (noch) nicht geladen. Daher wird geprüft:

(not charging_ev.ev_template.data.prevent_phase_switch or
 self.data.set.log.imported_since_plugged == 0) and
 self.data.config.auto_phase_switch_hw)

Die Umschaltung ist nicht verboten, es wurde aber bereits (einphasig) geladen und die passende HW ist vorhanden, also wird hier hart auf einphasig gestellt. Diese Bedingungen funktionieren beim Zurückschalten auf einphasiges Laden bzw. wenn das Laden überhaupt beginnt. Beim Umschalten auf dreiphasiges Laden muss aber die eingestellte Phasenzahl beibehalten werden.

Leider sehe ich hier nicht, wie man erkennen könnte, dass die Phasenumschaltung erst noch wirklich abgeschlossen werden muss.

EVU: Ohne currents-Werte keine Steuerung und Exceptions

EVU: Wenn keine currents-Werte kommen, steuert die OpenWB nicht und schreibt Exceptions in der algorith.py ins mainlog.
Zumindest für den Usecase eines Stromzählers mit optischer Schnittstelle ist für viele Zählertypen nicht möglich, die Werte der einzelne Phasen abzufragen.
Grundsätzlich ist das auch nicht gesetzlich erforderlich. Die einzelne WB nach KfW-Kritierien darf auch "dumm" einphasig oder dreiphasig laden.
OpenWB bietet m.W. drei "Netzsicherheitsfeatures":

1. Netzfrequenz-Auswertung
2. Schieflastbeachtung
3. Maximaler Strom je Phase

Es gibt nun verschiedene Lösungsmöglichkeiten:
a) Ist keine Phasenstrom-Info vorhanden, werden Fehler im main.log geschrieben und ein Status angezeigt
b) Die Beachtung des maximalen Phasenstroms lässt sich - wie die Schieflastbeachtung - abschalten.
Vorschlag für das Sollverhalten:
Die 3 o.a. Kriterien werden alle einzeln auswählbar. Sind 2) und/oder 3) aktiv, ist das Fehler der Netzströme ein Fehler. Sind 2) und 3) nicht aktiv, erfolgt keine Fehlermeldung.

Anlegen / Löschen von Ladepunkten

Leider bleiben auch von den Ladepunkten Einträge im Mosquitto, wenn sie wieder gelöscht werden.
Bei Add eines Ladepunktes ip_evse wird der folgende Fehler geworfen.

Es ist ein interner Fehler aufgetreten: Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/command.py", line 108, in on_message
    func(connection_id, payload)
  File "/var/www/html/openWB/packages/helpermodules/command.py", line 164, in addChargepoint
    module = importlib.import_module("."+payload["data"]["type"]+".chargepoint_module", "modules")
  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 "/var/www/html/openWB/packages/modules/ip_evse/chargepoint_module.py", line 10, in <module>
    from packages.modules.common.component_state import ChargepointState
ModuleNotFoundError: No module named 'packages'

Sungrow implementation not working

Since beginning of June Sungrow implementation is not working due to two untested and unverified commits in openWB core (2.0) and 1.9 nightly software.
Several tests were carried out without success of fixing this. Several remarks were made.

Bugfix for this issue is also pretty easy, delete this 2 commits and bring back the old implementation of version 1.9.300 stable then Sungrow will run again.

Commits: 21384e3
e4f753f

Reference to forum:

https://openwb.de/forum/viewtopic.php?p=87703#p87703
https://openwb.de/forum/viewtopic.php?p=87694#p87694
https://openwb.de/forum/viewtopic.php?p=87707#p87707

The author of the changes is also not responding on this issue and as already discussed here, he seems even not capable of proper testing of PRs https://openwb.de/forum/viewtopic.php?t=6920&start=20

SyntaxError in data.py, annotated name can't be global

Tried to get openWB from git-master running on raspi3 with debian buster (python version 3.7.3). Unfortunately, there seems to be a problem in data.py:

Okt 01 21:37:52 raspberrypi systemd[1]: Started "Regelung openWB 2.0".
Okt 01 21:37:52 raspberrypi main.py[12325]: Traceback (most recent call last):
Okt 01 21:37:52 raspberrypi main.py[12325]: File "/var/www/html/openWB/packages/main.py", line 12, in
Okt 01 21:37:52 raspberrypi main.py[12325]: from helpermodules.measurement_logging.update_daily_yields import update_daily_yields
Okt 01 21:37:52 raspberrypi main.py[12325]: File "/var/www/html/openWB/packages/helpermodules/measurement_logging/update_daily_yields.py", line 4, in <module
Okt 01 21:37:52 raspberrypi main.py[12325]: from control import data
Okt 01 21:37:52 raspberrypi main.py[12325]: File "/var/www/html/openWB/packages/control/data.py", line 514
Okt 01 21:37:52 raspberrypi main.py[12325]: data: Data
Okt 01 21:37:52 raspberrypi main.py[12325]: ^
Okt 01 21:37:52 raspberrypi main.py[12325]: SyntaxError: annotated name 'data' can't be global

Konfiguration MeterId in einer Fronius Komponente

Beim Anlegen eines Fronius Systems wird die MeterId eines Smartmeter oder S0-Zählers abgefragt. Unabhängig davon, dass diese Konfiguration noch direkt im Zähler eingebunden werden muss, scheint die Prüfung des Wertes auf 0 oder 1 falsch.

Laut Fronius Solar API Kapitel 3.8 – GetMeterRealtimeData request ist die MeterId/DeviceId als positive Zahl definiert: 0..65535.

Bei meiner Installation hat der Smartmeter z.B. aufgrund einiger anfänglicher Probleme/Tests mit S0-Zählern letztendlich die ID 2 bekommen.

Ich schlage vor, die Werteprüfung entsprechend anzupassen.

Editing manual SOC > 0% on main web page gives inconsistent results

After the user has set an initial SOC (e. g. 15%) on the main web page, the displayed SOC will increase as charging progresses, e. g. up to 45%. At any time, the user can edit the SOC again. The pop-up dialog will show the current value, e. g. 45%, and the user will be able to decrease or increase it with the + and - buttons, e. g. to 48% as this is what the car reports. Afterwards, the value the user entered will not be used to change the current value, but the initial one the user had entered earlier, i. e. the initial SOC of 15% will be replaced. Hence, the displayed value will change to 48%-15%+45%-15%=63%. This is both unexpected and confusing. The user will expect the estimated SOC to be updated to the value of 48% because that’s what he entered.

Fehler im Werte-Loggingmodul

2022-01-11 16:39:56,296 - {/packages/helpermodules/measurement_log.py:268} - ERROR - Fehler im Werte-Loggingmodul
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/measurement_log.py", line 232, in update_daily_yields
    daily_yield = data.data.pv_data[pv].data["get"]["counter"] - \
KeyError: 'pv1'

Konfiguriert ist bei mir ein JSON PV Modul mit ID: 5 und ein JSON EVU mit ID:4

EVU Kit Flex mit SDM630 fehlende Daten

Ich habe seit heute einen PE11 und einen SDM72 (analog SDM630) für meine WP in Betrieb. Um zu testen habe ich den SDM auch in der 2.0 Alpha als 2. EVU Modul eingestellt. Analog auch auf meinen 1.9 Entwicklungssystem als EVU flex Kit.

Bei der 1.9 kommen alle Daten für alle Phasen an, also Spannung, Stromstärke, Leistung und Power Faktor. Die Summierten Werte Gesamtleistung, Bezug, Einspeisung (ist natürlich 0, da nur bezogen wird), Frequenz und Schieflast sind ebenfalls vorhanden und korrekt.

In der 2.0 Alpha kommt bei den Phasenwerten nur die Spannung einer Phase (0,0,230.14) Strom (0,0,0) ist falsch, Leistung (0,0,0) ist ebenfalls falsch, Leistungsfaktor ist komplett leer. Import, Leistug Netzfrequenz passen.

Die 2.0Alpha Version ist aktuell (git pull hat keine Änderungen gezeigt)

VG
Det

Frontend EVU Anzeige steht auf fix 600W

Im Status (und im Hausverbrauch auf der Startseite) ist ersichtlich, dass andere Leistung abgefordert wird.

PSA SoC wird abgerufen und gespeichert, ist aber in der UI nicht zu sehen.

Ich hab' jetzt mal das PSA Modul konfiguriert um die manuelle Berechnung testen zu können.

PSA Abruf passt, SoC und Reichweite wird gespeichert.

2023-10-21 16:33:43,747 - {modules.vehicles.psa.api:120} - {INFO:fetch soc_ev15} - psa.fetch_soc: soc=48%, range=112, timestamp=2023-10-21T13:16:17Z 2023-10-21 16:33:43,767 - {modules.common.configurable_vehicle:61} - {DEBUG:fetch soc_ev15} - Requested start soc from api: CarState(soc=48, range=112, soc_timestamp=2023-10-21T13:16:17Z)% 2023-10-21 16:33:43,774 - {modules.common.store._api:26} - {DEBUG:fetch soc_ev15} - Raw data CarState(soc=CarState(soc=48, range=112, soc_timestamp=2023-10-21T13:16:17Z), range=None, soc_timestamp=None) 2023-10-21 16:33:43,803 - {modules.common.store._api:30} - {INFO:store soc_ev15} - Saving CarState(soc=CarState(soc=48, range=112, soc_timestamp=2023-10-21T13:16:17Z), range=None, soc_timestamp=None)

Tauchen im Broker auf - aber nur im calculated_soc_state, nicht im soc vom Fahrzeug selbst:

Und in der UI sehe ich auch keinen SoC:

bin auf diesem Build: 2023-10-20 12:07:01 +0200 [9cf8db3]

JSON Modul Probleme

2022-05-29 14:36:17,075 - {soc.modules.common.fault_state:37} - ERROR - Json Zähler: FaultState FaultStateLevel.ERROR, FaultStr <class 'AttributeError'> 'Device' object has no attribute 'domain', Traceback:
Traceback (most recent call last):
File "/var/www/html/openWB/packages/modules/json/device.py", line 66, in update
response = req.get_http_session().get(self.domain, timeout=5)
AttributeError: 'Device' object has no attribute 'domain'

2022-05-29 14:36:17,081 - {soc.modules.common.fault_state:37} - ERROR - Json Wechselrichter: FaultState FaultStateLevel.ERROR, FaultStr <class 'AttributeError'> 'Device' object has no attribute 'domain', Traceback:
Traceback (most recent call last):
File "/var/www/html/openWB/packages/modules/json/device.py", line 66, in update
response = req.get_http_session().get(self.domain, timeout=5)
AttributeError: 'Device' object has no attribute 'domain'

Vermute hier müssen die Anpassungen aus openWB 1.9 auch noch nachgezogen werden.
VG
Det

Range Electric für SOC Ermittlung vorsehen

In der 1.9 wurde es bereits mehrfach angesprochen, dass die SoC Ermittlung oft auch einen Range in Kilometern übergeben kann.
Bitte in der V2.0 vorsehen, dass dieser Wert ebenfalls aufgenommen werden kann und im Frontend dargestellt werden kann. Eine Store Klasse für Car sehe ich, alledings aktuell nur mit SoC. Wert.

Manueller SoC - wird auf den Wert vor dem letzten Ladevorgang zurückgesetzt, sobald am nächsten Tag PV-Ertrag wieder startet

SW 2.1.1 beta2, Series 2 DUO

Manueller SoC: ...siehe auch: https://openwb.de/forum/viewtopic.php?p=92745#p92745

Der SoC springt auf den Wert vor der letzten Ladung zurück...die Ladung ist im Ladelog zu sehen....laut Timeline dann, wenn die PV wieder Erzeugung bringt (der PV-Ertrag steht im UI des "nachts" übrigens auf "-0")
Es passiert aber nur bei dem LP, bei dem auch am Vortag mit PV geladen wurde...am LP2 - gestern Auto auch angesteckt und SOC eingestellt, aber nicht geladen - blieb der SOC konstant.

Hauptseite - Werte neben den Schiebereglern werden nicht dargestellt

In den Einstellungen zum PV Lademodus sind die Schieberegler für min Stromstärke, SoC etc. auf den konfigurierten Wert eingestellt, jedoch wird der Wert daneben nicht dargestellt sondern nur '--'.

Daten der Monatsausertung deutlich zu gering

Ich hab' mir eben mal die Monatsauswertung für November angesehen, da stimmt etwas mit dem Graph nicht. Die Monatssummen kommen hin, rd. 300kWh habe ich an einem Ladepunkt bereits geladen.

Allerdings sehe ich diese Energiemengen überhaupt gar nicht im Chart:

So sieht der Monat im Sunnyportal aus:

Andere Monate sind ähnlich falsch, im Oktober geht die Skala gleich nur bis 2,8kWh:

Kann euch gern die Rohdaten, CSVs oder Logs liefern wenn etwas benötigt wird.

SOC Module HowTo Token Store/Modul Parameter Store

Hallo zusammen,
für diverse SoC Files müssen ja Tokens nach der Authentifizierung abgespeichert werden, um mit diesen Token dann den entsprechenden API Request zu machen. Gibt es schon einen Plan, wie und wo diese Token gespeichert werden sollen?
In den Broker, oder als File? An welcher Stelle im Filesystem sollen die liegen?
Eine weitere Frage ist, wo und wie die Parameter eines SoC Modules nach der Konfiguration gespeichert werden.
Beim Soc_EQ z.B. sind das Client und Secret und die VIN des Fahrzeugs, sowie die Callback URL, die aufgerufen wird, um die Tokens in der openWB zu persistieren.

VG
Det

SoC wird nicht gespeichert, womöglich timeout

Tesla SoC wird zuverlässig abgerufen und taucht im Log auf, allerdings fehlt die letzte Meldung zum speichern des CarState wenn das Auto zuerst aufgeweckt werden muss.
Ist das Auto vor dem Abruf wach wird alles gespeichert.

#1029 (comment)

SoC wird gespeichert:
2023-07-07 11:14:03,795 - {modules.common.store._api:26} - {DEBUG:soc_ev3} - Raw data CarState(soc=77.0, range=373.8335886, soc_timestamp=)
2023-07-07 11:14:03,818 - {modules.common.store._api:30} - {INFO:soc_ev3} - Saving CarState(soc=77.0, range=373.8335886, soc_timestamp=)

SoC wird nicht gespeichert:
2023-07-07 11:11:27,002 - {modules.common.store._api:26} - {DEBUG:soc_ev3} - Raw data CarState(soc=77.0, range=373.8335886, soc_timestamp=)

Speicher Daten bleiben nach Löschen noch aktiv

@LKuemmel: Hi Lena, ich habe gestern noch ein JSON Bat Modul eingerichtet, und auch wieder gelöscht. Es bleibt unter openWB/bat/get noch der Power und der SoC bestehen. Auf dem Frontend sind die Daten daher auch noch sichtbar.
Kannst du dir das bitte anschauen?
Im Status ist der Speicher nicht angezeigt.

VG
Det

Die Einschränkung der Nutzung für kommerzielle Zwecke widerspricht den Lizenzbedingen der GPL.

Die Einschränkung der Nutzung für kommerzielle Zwecke in der Readme:

Weiterhin ist eine kommerzielle Nutzung nur nach Rücksprache und durch schriftlicher Zustimmung der openWB GmbH & Co. KG erlaubt.

widerspricht den Lizenzbedingen der GPL.
Siehe GPL FAQ https://www.gnu.org/licenses/gpl-faq.en.html#NoMilitary

I'd like to license my code under the GPL, but I'd also like to make it clear that it can't be used for military and/or commercial uses. Can I do this? (#NoMilitary)

No, because those two goals contradict each other. The GNU GPL is designed specifically to prevent the addition of further restrictions. GPLv3 allows a very limited set of them, in section 7, but any other added restriction can be removed by the user.

More generally, a license that limits who can use a program, or for what, is not a free software license.

Hausverbrauch wird falsch berechnet

Passend zu meinem Eintrag im Forum https://openwb.de/forum/viewtopic.php?p=79349#p79349 habe ich mal geschaut, voran es liegen könnte.

Das Problem scheint die Berechnung in CounterAll.calc_daily_yield_home_consumption() in counter_all.py zu sein:

            if len(data.data.pv_data) > 1:
                pv = data.data.pv_all_data.data.get.daily_exported
            else:
                pv = 0
            if len(data.data.bat_data) > 1:
                bat_imported = data.data.bat_all_data.data.get.daily_imported
                bat_exported = data.data.bat_all_data.data.get.daily_exported
            else:
                bat_imported = 0
                bat_exported = 0
            if len(data.data.cp_data) > 1:
                cp_imported = data.data.cp_all_data.data.get.daily_imported
                cp_exported = data.data.cp_all_data.data.get.daily_exported
            else:
                cp_imported, cp_exported = 0, 0

Hier wird immer geprüft, ob es mehr als einen Element in den Dictionaries gibt. Für PV ist dort z.B. bei mir nur der eine konkrete Eintrag: {'pv0': <control.pv.Pv object at 0xffff4be8ab50>}.

Kann es sein, dass hier der Eintrag all wegoptimiert wurde?
Wenn meine Annahme stimmt, müssten die Prüfungen auf > 0 geändert werden.

Einen Verweis auf all habe ich so weit nur noch in measurement_log_test.py gefunden. Das passt zu meiner Vermutung, ist ja "nur" ein (alter) Test.

Weiterhin gibt es einige Stellen, wo speziell geprüft wird, ob die Keys in den Dictionaries nur mit den Komponentenprefixen beginnen. Wenn es all nicht mehr gibt, braucht man das auch nicht mehr prüfen, z.B. in pv_all.py PvAll.calc_power_for_all_components().

Wenn mir jemand meine Annahmen bestätigt, kann ich auch einen passenden PR erstellen.

Abhängigkeit "systemctl" fehlt

Moin, moin,

bei einem Versuch openWB2 auf einem debian:bullseye zu installieren, habe ich festgestellt, dass hier ein Package fehlt:

core/openwb-install.sh

Line 15 in f4e2846

apt-get -q -y install vim bc apache2 php php-gd php-curl php-xml php-json libapache2-mod-php jq git mosquitto mosquitto-clients socat python3-pip sshpass sudo

Ich musste systemctl vor dem Start der Installation manuell installieren.

Grüße,
Jens

SMB Backup: Dateien werde nicht abgelegt

Hallo zusammen, dass samba Modul scheint noch nicht so ganz zu funktionieren.
Ich habe einen Share auf einen QNAP angegeben, User, Passwort. Leider bleibt das Share leer.

Probiert habe ich:
//IP/Share/Folder
//IP/Share
\\IP\Share\Folder
\\IP\Share

Leider fehlt hier ein Wikieintrag zu.

Auf der openwb unter http://IP/openWB/data/backup/ wird immer eine frische Datei erzeugt.
Da das Modul wenig bis keine Logs ausspuckt bis auf das eine, kann ich es nur beschreiben.
SMB.SMBConnection:104} - {INFO:cloud backup} - Authentication with remote machine "SERVER" for user "xxx" will be using NTLM v2 authentication (with extended security)
Hier verwundert mich der Name meiner "remote maschine". Wurde hier eventuell die IP ignoriert.
QNAP protokoliert keinerlei Verbindungsversuche von meiner openwb

Die Verbindung via Explorer ist kein Problem, Schreibrechte hat der User auch:

Ladung wird nach Erreichen des Zeitladen-Limits nicht sofort gestoppt

Situation: Es ist ein Zeitladefenster mit Limit (z.b. SoC) konfiguriert, Lademodus PV mit 1p/3p Umschaltung. Zeitfenster ist aktiv, Ladevorgang wird gestartet. Kein PV Überschuss vorhanden.

Problem: Nach Erreichen des konfigurierten Limits (SoC) wird der Ladevorgang nicht sofort beendet. Viel mehr wird der Ladestrom auf 6A reduziert und weiter geladen. Lt. Statusmeldung wird der Ladevorgang nach erreichen der Abschaltschwelle von 180s gestoppt. Tatsächlich wird jedoch bis zum Erreichen der 1p/3p Umschaltung gewartet, die Umschaltung von 3p auf 1p durchgeführt, Ladevorgang weiterhin mit 6A. Jetzt greift die Abschaltschwelle und der Ladevorgang wird dann nach 180s beendet.

Erwartetes verhalten: Konfiguriertes Limit wird erreicht, da kein Überschuss vorhanden wir der Ladevorgang sofort beendet.

[main.log](https://github.com/openWB/core/files/10333562/main.log)

SoC wird beim Anstecken nicht aktualisiert

Kürzlich wurde ja das aktualisieren des SoC beim Anstecken nachgerüstet. Leider klappt das nicht immer zuverlässig, mal gehts und mal nicht, bin mir noch nicht sicher woran das hängt.

Ich hab' das eben mal reproduziert und einen Logauschnitt erfasst.
main.log

Manual SOC resets to initial SOC after target has been reached

In manual SOC mode, the user entered an initial SOC of e. g. 15%. After the SOC has reached its target value, e. g. 80% the SOC displayed is reset to the initial value, e. g. 15%, after the polling delay for non-charging state (default is 720 minutes) has passed. This is both incorrect and confusing. Charging will restart from this incorrect value.

Lastmanagement mit PV-Anlage

Kann die Seite Lastmanagement bitte noch mit einem weiteren Beispiel mit PV-Anlage (und ggf. Speicher) erweitert werden?

Es geht um folgende Seite:
https://github.com/openWB/core/wiki/Lastmanagement-und-kaskadierte-Z%C3%A4hler

Aktuell abe ich meine PV-Anlage so konfiguriert:

Ich bin mir aber nicht sicher, ob das so richtig ist und ich die PV-Anlage an der richtigen Stelle in der Struktur eingeklinkt habe.

Gruß und besten Dank für einen Tipp oder eine Aktualisierung der Seite (werden sicher noch mehr Personen mit dieser Frage existieren).

SMA Module noch nicht zu konfigurieren?

Mit einem der letzten Updates (package for sma smarthome manager) scheinen ja die Module für die SMA Welt hinzugekommen zu sein. Leider finde ich diese in der Modulkonfiguration noch nicht, sonst hätte ich das gern mal auf meiner Testinstallation in Betrieb genommen.

Ist das so zu erwarten oder sollte ich die SMA Komponenten als EVU und PV schon auswählen können?

Ausgabe der Werte von Kostal Plenticore inkonsistent

Für eine sinnvolle Berechnung der Kostal-Werte muß die Batterie parallel zum Hybrid-WR in der Struktur angelegt werden (entgegen der Anleitung im Wiki). Andernfalls wird der Hausverbrauch genau wie die PV-Leistung um die Batterieladeleistung erhöht.

Die hat jedoch zur Folge, daß bei Entladung der Batterie eine PV-Leistung angezeigt wird, die nicht vorhanden ist (hier in der Nacht):

Die Entladeleistung der Batterie findet sich als PV-Leistung des Wechselrichters.

Seltsamerweise stimmt die Darstellung im Hauptfenster in dieser Konfiguration:

Wenn ich den Speicher verschachtelt unterhalb des Wechselrichters anordne, wie das Wiki es für Hybridwechselrichter angibt, wird die Speicherladung auf die AC-Ausgabe des WRs aufgeschlagen, das Ergebnis als PV-Ertrag ausgegeben und der angezeigte Hausverbrauch erhöht sich um den Wert der Speicherladung (Bild umfaßt die Umkonfiguration):

Ich habe bemerkt, daß es eine rege Diskussion zum Plenticore gibt:
snaptec/openWB#2440 (comment)

Logging

Hallo openWB Team,
Ich finde das Logging in der main.log etwas unübersichtlich. Die Info, aus welcher Zeile im log.py der Fehler geworfen wird ist meiner Meinung nach nicht sehr hilfreich und macht die Zeile nur breit. Dagegen bleibt der Hinweis, an welcher Stelle im Code der Fehler geworfen wird, verborgen. Ich vermute, bei einer direkten Verwendung der Python Loggers Klasse wäre das nicht so.

VG
Det

enable WiFi

enable WiFi / WLAN again.
Default to wired Ethernet (and DHCP), have WiFi as sub-menu for specialists.

Geräte mit mehreren Zählertypen (Fronius)

Bisher habe ich gesehen, dass es nur beim Fronius WR unterschiedliche Zählertypen gibt: counter_s0 und counter_sm.
Bei anderen Geräten wird der Zähler immer als Typ counter definiert.

In der weiteren Logik wird damit unterschiedlich umgegangen, einmal wird geprüft, ob im Typ das Wort counter enthalten ist, aber es wird auch nur auf counter geprüft. Dadurch kann man zwar einen Fronius -Zähler konfigurieren, aber er taucht dann nicht auf der Einstiegsseite auf und wird auch nicht beim Status ausgeführt. In der Konfiguration ist er aber vorhanden und es werden Daten abgefragt

Weitere Sonderfälle sind eventuell cp_counter und evu_counter.

Die Frage ist also, soll es unterschiedliche Typenbezeichnungen geben, oder müssen Geräte mit mehreren Zählern, WRs und Speichern umgehen können, wenn die sich nicht direkt am Gerätetyp unterscheiden lassen?

enable fixed-IP setup

Enable setup of
fixed-IPv4 address, Gateway, Router, DNS, NTP, Netmask.
Default to DHCP, detailed setup as "specialist feature" in e.g. sub-menu

Inkonsistente MQTT Topic-Namen

Die Topic-Namen sollten vereinheitlicht werden, also entweder Singular oder Plural. Die Statusseite liefert momentan nicht alle bekannten Werte. In den Statusklassen werden vorzugsweise Pluralbegriffe verwendet, die MQTT-Topics folgen eher Singular-Begriffen. Besonders current und power_factor werden inkonsistent verwendet.

_chargepoint.py

pub_to_broker("openWB/set/chargepoint/" + str(self.num) + "/get/voltage", state.voltages, 2)
pub_to_broker("openWB/set/chargepoint/" + str(self.num) + "/get/current", state.currents, 2)
pub_to_broker("openWB/set/chargepoint/" + str(self.num) + "/get/power_factor", state.power_factors, 2)

_counter.py

pub_to_broker("openWB/set/counter/" + str(self.num) + "/get/voltage", counter_state.voltages, 2)
pub_to_broker("openWB/set/counter/" + str(self.num) + "/get/current", counter_state.currents, 2)
pub_to_broker("openWB/set/counter/" + str(self.num) + "/get/power_phase", counter_state.powers, 2)
pub_to_broker("openWB/set/counter/" + str(self.num) + "/get/power_factors", counter_state.power_factors, 2)

_inverter.py

pub_to_broker("openWB/set/pv/" + str(self.num) + "/get/currents", inverter_state.currents, 1)

Status.vue

'openWB/counter/' + counter.id + '/get/voltage'

'openWB/counter/' + counter.id + '/get/current'

'openWB/counter/' + counter.id + '/get/power_phase'

'openWB/counter/' + counter.id + '/get/power_factor'

ValueError: time data '10/18/2023, 12:07' does not match format '%m/%d/%Y, %H:%M:%S'

Habe heute folgenden Fehler bekommen (aktuelles master)

2023-10-18 12:07:50,865 - {helpermodules.timecheck:345} - {ERROR:MainThread} - Fehler im System-Modul Traceback (most recent call last): File "/var/www/html/openWB/packages/helpermodules/timecheck.py", line 341, in get_difference end = datetime.datetime.strptime(timestamp_end, "%m/%d/%Y, %H:%M:%S") File "/usr/lib/python3.9/_strptime.py", line 568, in _strptime_datetime tt, fraction, gmtoff_fraction = _strptime(data_string, format) File "/usr/lib/python3.9/_strptime.py", line 349, in _strptime raise ValueError("time data %r does not match format %r" % ValueError: time data '10/18/2023, 12:07' does not match format '%m/%d/%Y, %H:%M:%S' 2023-10-18 12:07:50,876 - {helpermodules.timecheck:320} - {ERROR:MainThread} - Fehler im System-Modul Traceback (most recent call last):

Das Ergebnis sind fehlende Zeiten in der Ladeübersicht

EVU Flex Kit SDM630 kein Export/Import

Hallo Lena, ich glaube durch die Änderung counter/counters ist was schief gegangen. Ich sehe in der aktuellen Version keine Import Werte mehr. In meinem EVU Kit Flex mit SDM630.

VG
Det

Fehler im Lastmanagement Modul

Ich bekomme einen Fehler im Lastmanagement Modul. Referenziert wird der Zähler 4 (mein VZLogger per JSON). Kann es sein, dass es hier auf Grund von fehlenden Einzelphasen eine Meldung gibt?

Ich versuch mal noch mehr raus zu finden.

2022-01-11 15:54:19,677 - {/packages/control/counter.py:370} - ERROR - Fehler in der Zähler-Klasse von 4
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/counter.py", line 367, in put_stats
    Pub().pub("openWB/set/counter/0/set/consumption_left", self.data["set"]["consumption_left"])
KeyError: 'consumption_left'
2022-01-11 15:54:29,653 - {/packages/control/loadmanagement.py:261} - ERROR - Fehler im Lastmanagement-Modul
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/loadmanagement.py", line 252, in _check_max_power
    consumption_left = data.data.counter_data[evu_counter].data[
KeyError: 'consumption_left'
2022-01-11 15:54:29,664 - {/packages/control/counter.py:370} - ERROR - Fehler in der Zähler-Klasse von 4
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/counter.py", line 367, in put_stats
    Pub().pub("openWB/set/counter/0/set/consumption_left", self.data["set"]["consumption_left"])
KeyError: 'consumption_left'

VG
Det

tests für counter_test.py schlagen in VSCode fehl?

Mir ist eben aufgefallen dass einige tests in counter_test.py bei mir in VSCode fehlschlagen, hat jemand eine Idee woran das liegen kann?
Die automatiserten Tests in den PRs laufen ja durch, kann also kein Problem mit dem Code sein. bin auf dem aktuellen Master (c4a0d32).

`/var/www/html/openWB/packages/control/counter_test.py::test_switch_on_threshold_reached[Einschaltschwelle wurde unterschritten, Timer zur\xfccksetzen] failed: params = Params(name='Einschaltschwelle wurde unterschritten, Timer zurücksetzen', feed_in_limit=False, reserved_surplus=1500, ... während der Einschaltverzögerung unterschritten.', expected_timestamp_switch_on_off=None, expected_reserved_surplus=0)
caplog = <_pytest.logging.LogCaptureFixture object at 0x7fab10fb8b50>
general_data_fixture = None
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7fab1101bb80>

@pytest.mark.parametrize("params", cases, ids=[c.name for c in cases])
def test_switch_on_threshold_reached(params: Params, caplog, general_data_fixture, monkeypatch):
    # setup
    c = Counter(0)
    c.data.set.reserved_surplus = params.reserved_surplus
    cp = Chargepoint(0, None)
    ev = Ev(0)
    cp.data.control_parameter.phases = 1
    cp.data.control_parameter.state = params.state
    cp.data.control_parameter.timestamp_switch_on_off = params.timestamp_switch_on_off
    ev.data.charge_template = ChargeTemplate(0)
    ev.data.charge_template.data.chargemode.pv_charging.feed_in_limit = params.feed_in_limit
    cp.data.set.charging_ev_data = ev
    mock_calc_switch_on_power = Mock(return_value=[params.surplus, params.threshold])
    monkeypatch.setattr(Counter, "calc_switch_on_power", mock_calc_switch_on_power)

    # execution
    c.switch_on_threshold_reached(cp)

    # evaluation
    assert c.data.set.reserved_surplus == params.expected_reserved_surplus

  assert params.expected_msg is None or params.expected_msg in caplog.text

E AssertionError: assert ('Einschaltschwelle während der Einschaltverzögerung unterschritten.' is None or 'Einschaltschwelle während der Einschaltverzögerung unterschritten.' in '')
E + where 'Einschaltschwelle während der Einschaltverzögerung unterschritten.' = Params(name='Einschaltschwelle wurde unterschritten, Timer zurücksetzen', feed_in_limit=False, reserved_surplus=1500, ... während der Einschaltverzögerung unterschritten.', expected_timestamp_switch_on_off=None, expected_reserved_surplus=0).expected_msg
E + and 'Einschaltschwelle während der Einschaltverzögerung unterschritten.' = Params(name='Einschaltschwelle wurde unterschritten, Timer zurücksetzen', feed_in_limit=False, reserved_surplus=1500, ... während der Einschaltverzögerung unterschritten.', expected_timestamp_switch_on_off=None, expected_reserved_surplus=0).expected_msg
E + and '' = <_pytest.logging.LogCaptureFixture object at 0x7fab10fb8b50>.text

packages/control/counter_test.py:146: AssertionError`

'ChargepointState' object has no attribute

bei einem der letzten Updates hat sich ein Fehler eingeschlichen. Auf der Startseite erscheint der Fehler
<class 'AttributeError'> 'ChargepointState' object has no attribute 'read_tag'
beim Ladepunkt und das Logfile sagt:

2022-10-16 13:42:40,844 - {soc.modules.common.fault_state:40} - ERROR - Ladepunkt: FaultState FaultStateLevel.ERROR, FaultStr <class 'AttributeError'> 'ChargepointState' object has no attribute 'read_tag', Traceback: Traceback (most recent call last): File "/var/www/html/openWB/packages/modules/common/store/_api.py", line 37, in update_values component.store.update() File "/var/www/html/openWB/packages/modules/common/store/_api.py", line 31, in update self.delegate.update() File "/var/www/html/openWB/packages/modules/common/store/_chargepoint.py", line 40, in update pub_to_broker("openWB/set/chargepoint/" + str(self.num) + "/get/read_tag", self.state.read_tag) AttributeError: 'ChargepointState' object has no attribute 'read_tag'

Fehler in JSON Modulen

Die Ermittlung der Werte mit den JQ Filtern funktioniert, allerdings wird ein Fehler beim Payload geworfen, was vermutlich dazu führt, dass die MQTT Topics nicht gefüllt werden. Die Zählerstände für EVU und PV werden korrekt ausgelesen. Bei EVU wird auch die aktuelle Leistung im Status und im Graphen angezeigt.
Bei PV wird der Wert der Leistung weder in Status noch im Graph angezeigt.

2021-12-28 12:37:41,796 - {/var/www/html/openWB/packages/helpermodules/log.py:38} - ERROR - Payload ungueltig: Topic openWB/set/pv/2/get/power, Payload -857.0 sollte ein In t sein. 2021-12-28 12:37:41,810 - {/var/www/html/openWB/packages/helpermodules/log.py:38} - ERROR - Unbekanntes set-Topic: openWB/set/pv/2/get/currents, [0, 0, 0] 2021-12-28 12:37:46,485 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - MQTT-Ladepunkte müssen nicht ausgelesen werden. 2021-12-28 12:37:46,486 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - Start device reading {'component1': <modules.json.counter.JsonCounter object at 0x72440bc8>, 'component2': <modules.json.inverter.JsonInverter object at 0x72440d78>} 2021-12-28 12:37:49,487 - {/var/www/html/openWB/packages/helpermodules/log.py:38} - ERROR - Thread-4401 konnte nicht innerhalb des Timeouts die Werte abfragen, die abgefrag ten Werte werden nicht in der Regelung verwendet. 2021-12-28 12:37:49,491 - {/var/www/html/openWB/packages/helpermodules/log.py:47} - ERROR - Fehler im allgemeinen PV-Modul fuer pv2 Traceback (most recent call last): File "/var/www/html/openWB/packages/control/pv.py", line 38, in calc_power_for_all_components self.data["get"]["power"] += data.data.pv_data[module].data["get"]["power"] KeyError: 'power' 2021-12-28 12:37:49,666 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - Antwort auf http://raspi3.fritz.box:8081: { "version": "0.8.0", "generator": "vz logger", "data": [ { "uuid": "8cf75360-d429-11eb-9433-7b3df3e62eb7", "last": 1640691468952, "interval": -1, "protocol": "sml", "tuples": [ [ 1640691466954, 6500821.90000000 04 ] ] }, { "uuid": "01aae160-d42a-11eb-b856-6363747dc3d8", "last": 1640691468952, "interval": -1, "protocol": "sml", "tuples": [ [ 1640691466954, 7289848.2000000002 ] ] }, { "uuid": "1d3ac010-d42a-11eb-ae8f-4799bf1e45fd", "last": 1640691468952, "interval": -1, "protocol": "sml", "tuples": [ [ 1640691466954, 18989925.400000002 ] ] }, { "uuid" : "3193e720-d42a-11eb-8461-cf883a763221", "last": 1640691468952, "interval": -1, "protocol": "sml", "tuples": [ [ 1640691466954, 1679310.5 ] ] }, { "uuid": "0265cf40-d42b-1 1eb-b7e7-3ff66060fa6b", "last": 1640691468952, "interval": -1, "protocol": "sml", "tuples": [ [ 1640691466954, -170 ] ] }, { "uuid": "e0f95960-d42a-11eb-bb4a-05a2a3f49d4f", "last": 1640691468952, "interval": -1, "protocol": "sml", "tuples": [ [ 1640691466954, 13790670.200000001 ] ] }, { "uuid": "aa5aac00-d42a-11eb-b608-d568343b9bdc", "last": 1640691468952, "interval": -1, "protocol": "sml", "tuples": [ [ 1640691466954, 20669236 ] ] }, { "uuid": "b2138ca0-d42b-11eb-ad2b-4338d0cd21d5", "last": 1640691468819, "int erval": -1, "protocol": "sml", "tuples": [ [ 1640691466827, 1510.3000000000002 ] ] }, { "uuid": "c5501860-1b10-11ec-b4f4-f33be250f5db", "last": 1640691468819, "interval": - 1, "protocol": "sml", "tuples": [ [ 1640691466827, 26323077.900000002 ] ] }, { "uuid": "8ae19880-d42b-11eb-8e73-15f0bf1b0d58", "last": 1640691468819, "interval": -1, "proto col": "sml", "tuples": [ [ 1640691466827, -859 ] ] }, { "uuid": "47cc29e0-8f20-11eb-835c-79ab7da12345", "last": 1640691468221, "interval": 5, "protocol": "exec", "tuples": [ [ 1640691468221, 360 ] ] } ] } 2021-12-28 12:37:49,667 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - Komponente Json Zähler auslesen. 2021-12-28 12:37:50,430 - {/var/www/html/openWB/packages/helpermodules/log.py:32} - INFO - # ***Start*** 2021-12-28 12:37:50,431 - {/var/www/html/openWB/packages/helpermodules/log.py:47} - ERROR - Fehler in der allgemeinen Ladepunkt-Klasse fuer Ladepunkt cp0 Traceback (most recent call last): File "/var/www/html/openWB/packages/control/chargepoint.py", line 100, in get_power_counter_all counter_all = counter_all + chargepoint.data["get"]["counter"] KeyError: 'counter' 2021-12-28 12:37:50,799 - {/var/www/html/openWB/packages/helpermodules/log.py:32} - INFO - LP 0: Keine Ladung, da kein Auto angesteckt ist. 2021-12-28 12:37:50,801 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - Kein PV-Modul konfiguriert. 2021-12-28 12:37:50,803 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - all {'get': {'power': 0}, 'config': {'configured': False}, 'set': {'charging_power_left': 0, 'switch_on_soc_reached': 0, 'hybrid_system_detected': False}} 2021-12-28 12:37:50,805 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - all {'get': {'daily_yield': 0, 'power_all': 0, 'counter_all': 0}} 2021-12-28 12:37:50,806 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - cp0 {'set': {'charging_ev': -1, 'charging_ev_prev': -1, 'autolock_state': 0, 'current': 0, 'energy_to_charge': 0, 'plug_time': '0', 'rfid': 0, 'manual_lock': False, 'log': {'co unter_at_plugtime': 0, 'timestamp_start_charging': '0', 'counter_at_mode_switch': 0, 'charged_since_mode_switch': 0, 'charged_since_plugged_counter': 0, 'range_charged': 0, 'time_charged': '00:00', 'chargemode_log_entry': '_'}}, 'get': {'read_tag': {'tag': '0', 'timestamp': '0'}, 'daily_yield': 0, 'plug_state': False, 'charge_state': False, ' power_all': 0, 'connected_vehicle': {'soc_config': {}, 'soc': {'range': 0, 'range_unit': 'km'}, 'info': {'id': 0, 'name': 'Standard-Fahrzeug'}, 'config': {'charge_template' : 0, 'ev_template': 0, 'chargemode': 'stop', 'priority': False, 'current_plan': '', 'average_consumption': 17}}, 'state_str': 'Keine Ladung, da kein Auto angesteckt ist.'}, 'config': {'name': 'Standard-Ladepunkt', 'ev': 0, 'template': 0, 'connected_phases': 3, 'phase_1': 0, 'auto_phase_switch_hw': False, 'control_pilot_interruption_hw': False , 'id': 0, 'connection_module': {'type': 'mqtt', 'configuration': {}}, 'power_module': {}}} 2021-12-28 12:37:50,806 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - cpt0 {'name': 'Standard Ladepunkt-Vorlage', 'autolock': {'wait_for_charging_end': False, 'active': False, 'plans': {}}, 'rfid_enabling': False, 'valid_tags': []} 2021-12-28 12:37:50,806 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - all {'set': {'loadmanagement_active': False, 'loadmanagement_available': True, 'home_consumption': 4795, 'invalid_home_consumption': 1, 'daily_yield_home_consumption': 0}, 'get ': {'hierarchy': [{'id': 'counter1', 'children': []}, {'id': 'cp0', 'children': []}]}}

HTTP Counter modules.common.simcount._calculate <class 'TypeError'> '<' not supported between instances of 'float' and 'NoneType'

Hello,

I tried to add a http Counter to grab the SDM630 from my ioBroker via simple api.
However, in the openwb logs i find the correct value (466.85 in this case) the http counter should show, but it comes with an error which prevents the value from beeing shown in the webinterface.

2023-04-29 14:30:50,076 - {urllib3.connectionpool:452} - {DEBUG:device8} - http://192.168.40.6:8087 "GET /getPlainValue/modbus.1.inputRegisters.30053_Total_system_power HTTP/1.1" 200 6
2023-04-29 14:30:50,078 - {modules.common.req:11} - {DEBUG:device8} - Get-Response: 466.85
2023-04-29 14:30:50,078 - {modules.common.simcount._simcount:38} - {DEBUG:device8} - Previous state: SimCounterState(timestamp=1682769020.4472444, power=None, imported=0, exported=0)
2023-04-29 14:30:50,083 - {modules.common.fault_state:40} - {ERROR:device8} - HTTP Zähler: FaultState FaultStateLevel.ERROR, FaultStr modules.common.simcount._calculate <class 'TypeError'> '<' not supported between instances of 'float' and 'NoneType', Traceback:
Traceback (most recent call last):
File "/var/www/html/openWB/packages/modules/common/fault_state.py", line 99, in wrapper
return delegate(*args, **kwargs)
File "/var/www/html/openWB/packages/modules/common/simcount/_calculate.py", line 14, in calculate_import_export
power_low = min(power1, power2)
TypeError: '<' not supported between instances of 'float' and 'NoneType'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 24, in call
self.__updater(component)
File "/var/www/html/openWB/packages/modules/devices/http/device.py", line 37, in
component_updater=IndependentComponentUpdater(lambda component: component.update(session))
File "/var/www/html/openWB/packages/modules/devices/http/counter.py", line 38, in update
imported, exported = self.sim_counter.sim_count(power)

Version Number is 2023-04-27 09:33:19 +0200 [bc50ee7]

second Victron energy meter wrong registers

Hello,
if a second Victron energy meter is configured (for example for a heatpump) it gets the Victron ID 31.
The registers for ID 31 start at 3900 instead of 2600.
That meter causes errors in the cerbo gx and will not work.

Stefan

MQTT-PV-WR-Werte: Unterschiedliche Topics in Doku und Code

Beim Einrichten eines MQTT-Wechselrichters heisst es in der Beschreibung:

openWB/set/pv/1/power
PV-Leistung in Watt, ohne Nachkommastellen (Integer), nur negativ!
openWB/set/pv/1/counter
Erzeugte Energie in Wh, mit Nachkommastellen (Float), nur positiv

Erwartet werden stattdessen die Topics openWB/set/pv/1/get/power und openWB/set/pv/1/get/counter

Die Hinweisseite sollte korrigiert werden, allerdings ist im Repository nur generierter Code (web/settings/js/3.js)

Fehler im Rfid-Modul

2023-10-18 12:33:57,982 - {modules.internal_chargepoint_handler.rfid:138} - {ERROR:Internal Chargepoint} - Fehler im Rfid-Modul
Traceback (most recent call last):
File "/var/www/html/openWB/packages/modules/internal_chargepoint_handler/rfid.py", line 124, in _read_events
async for event in device.async_read_loop():
File "/usr/lib/python3.9/asyncio/coroutines.py", line 127, in coro
res = yield from res
File "/home/openwb/.local/lib/python3.9/site-packages/evdev/eventio_async.py", line 98, in next_batch_ready
future.set_result(next(self.current_batch))
File "/home/openwb/.local/lib/python3.9/site-packages/evdev/eventio.py", line 71, in read
events = _input.device_read_many(self.fd)
OSError: [Errno 19] No such device

Der RFID Reader ist keine openWB Hardware, hat bis jetzt aber immer funktioniert. USB RFID als HID.

GitHub Desktop kann nicht mehr Clonen

Tutorial: Erstkonfiguration.md
Tutorial: Konfiguration Geräte und Komponenten.md

Seit die beiden Tutorial-Dateien im DOCS Zweig sind kann man das Repro nicht mehr
mit GitHub Desktop clonen.
Github Desktop stolper über den ":" im Namen .
Nach Entfernen der Dateien klappt das Clonen mit GitHub Desktop wieder.
(Probiert in eigenem Fork)

SoC Modul kann nicht gespeichert werden

@LKuemmel ich habe leider nach wie vor Probleme mit dem Speichern der SoC Module in der Fahrzeugkonfiguration. Zum klappt bei neu angelegten Fahrzeugen die Karte nach wie vor nicht aus, soc_module/config wird fürs neue Fahrzeug nicht angelegt. Zudem wird das neu angelegte Fahrzeug nicht sofort angezeigt sondern die Seite muss neu geladen werden.

Wenn ich dieses Topic mit einem leeren Array anlege klappt die Kachel auf und ich kann ein SoC Modul auswählen, allerdings schlägt speichern fehl, im UI verschwindet das ausgewählte Modul auch wieder.

vue konsolen log:
192.168.178.99-1649277205494.log

Zeitladen findet sich nicht im Ladeprotokoll?

Ich nutz' Zeitladen um nachts das Auto auf den notwendigen Ladestand zu bringen. Hier ist mir heute aufgefallen dass die Ladevorgänge vom Zeitladen nicht im Ladeprotokoll zu finden sind, kann das sein?

Z.b. der Ladevorgang von heute Nacht (14.11.):

Im Ladeprotokoll ist nichts zu finden. Das Auto ist immer noch angesteckt, das Zeitfenster ist aber bereits verstrichen (1:00-6:30). Auch von früheren Ladevorgängen ist nichts zu finden, jedoch wurde ein nächtlicher Ladevorgang wohl dem PV Laden zugeschlagen. Ich bekomm' definitiv keine 26kWh vom 6.11. 19:37 bis 7.11. 10:27 von meinen ~7kWp auf dem Dach.

Mögliche Division durch 0 in core/packages/modules/devices/kostal_plenticore /device.py

Ich hoffe, ich verstehe das richtig:

In core/packages/modules/devices/kostal_plenticore /device.py findet sich Zeile 46-50:
# Wird die Batterie entladen, werden die Wandlungsverluste anteilig an der DC-Leistung auf PV # und Batterie verteilt. Dazu muss der Divisor Total_DC_power != 0 sein. power_gross = dc_in - bat_state.power pv_state = InverterState(power=dc_in / power_gross * inverter_state.power, exported=inverter_state.exported)

Wenn dc_in (Die Summer der vom WR gelieferten DC-Leistungen) >=0 ist und exakt gleich groß wie bat_state.power (Ladeleistung der Batterie), kommt es zur Division durch 0 in Zeile 49.

Dieser Zustand legt einen Hausverbrauch von 0 nahe, den man in der Tat auch erreichen kann, wenn man noch ein Balkonkraftwerk am Start hat.