openWB Forum

installierte Version: master 2024-02-16 17:06:47 +0100 [9589e3426]

In der Loggrafik werden die Smarthome-Daten falsch angezeigt (Standard- und Color-Theme).
Vergleich der Darstellung 1.9 vs. 2.1:
Die zu Grunde liegenden Daten im Log scheinen aber korrekt: die Summe stimmt auch nicht: Logs aus 1.9 und 2.1 im Anhang.

bye
TW

Hallo zusammen1

1.) Ist es gewollt, dass sich während des Ladens an einem Ladepunkt über die Weboberfläche ein anderes Fahrzeug auswählen lässt (Aufgefallen bei Master 2024-02-16 17:06:47 +0100 [9589e3426])? Früher war das gesperrt und IMO sollte es auch so sein, dass nach Beginn des Ladevorgangs bis zum Abstecken kein anderes Fzg. ausgewählt werden kann.

2.) Apropos sperren: Ist es eigentlich für die Einstellungs-Seite wieder eine Passwortsperre geplant?

3.) Und noch eine Verständnisfrage:
Warum ist die Phasen-Vorgabe eigentlich immer "1" wenn bei der Ladepunkt-Konfiguration angegeben ist dass die WB auf 3 Phasen angeschlossen ist und keine autom. Phasenumschaltung hat? heidanei

Habe dazu leider nichts in der Suche gefunden.

Im main.log wird mir die Version angezeigt, im Frontend allerdings mehr als kryptisch. Wie gelangt man im Benutzer-Frontend an die "lesbare" Versionsbezeichnung, ohne das main.log zu durchforsten?

weichi hat geschrieben: ↑Sa Feb 17, 2024 1:53 pm
Wie gelangt man im Benutzer-Frontend an die "lesbare" Versionsbezeichnung, ohne das main.log zu durchforsten?

http://IP/openWB/web/display/

Da beim Status

Ich habe ein Problem mit dem RSE-Kontakt, der löst immer wieder eigenständig aus.
Ich habe an den RSE Kontakt 1 schonmal ein Kabel angeschlossen, in Vorbereitung auf die Steuerung der Wallbox.
Wenn der Kontakt geschlossen wird, wird die Ladung korrekt gestoppt, soweit so gut.
Jedoch löst der Kontakt auch immer wieder zwischendurch aus, ohne dass der Kontakt geschlossen ist.
Das Kabel ist zwar recht lang, ich habe aber eine geschirmtes CAT7 Kabel hierfür verwendet.
Im main.log ist nur zu erkennen, dass der RSE Kontakt immer wieder kurz auf True geht.
Wie kann ich hierfür mehr Details liefern?

EDIT:
Ich mach dazu mal lieber einen Supportfall auf, das ist ja kein Softwarethema.

Probiere bitte zuerst mit kurzem Kabel.

aiole hat geschrieben: ↑Sa Feb 17, 2024 6:39 pm Probiere bitte zuerst mit kurzem Kabel.

Wenn ich nur innerhalb der Box ein kurzes Kabel anschliesse, klappt das natürlich.
Die openWB hängt aber nicht im Hauswirtschaftsraum, daher komme ich ohne längeres Kabel da nicht hin.

EDIT:
Ich mach dazu mal lieber einen Supportfall auf, das ist ja kein Softwarethema.

Thomas aus W hat geschrieben: ↑Di Feb 13, 2024 11:33 am

martinbrokate@web.de hat geschrieben: ↑Di Feb 13, 2024 11:18 am Wäre es möglich hier die Regelung der Ladekurve noch zu optimieren?

Ich würde mal die Regelgeschwindigkeit runter drehen...
Einstellung-Regelgeschwindigkeit-Bildschirmfoto_2024-02-13_12-31-11.png

bye
TW

hatte heute mit "langsam" geladen, da war es schon besser, aber nicht weg.
Das Problem ist wohl schon länger da, wie ich heute gesehen habe:
https://forum.openwb.de/viewtopic.php?p=102752#p102752

LenaK hat geschrieben: ↑Mo Feb 05, 2024 9:14 am Ich habe das Logging für das Ladelog in eine extra Datei gepackt. Das dies nur temporär ist, kann diese nur über <ip>/openWB/ramdisk/chargelog.log aufgerufen werden. Bitte auf Loglevel Details stellen und nochmal testen. Falls das Loglevel auf Details stand, bitte das Log posten.

Ich konnte es jetzt mal testen - In dem Log sehe ich diese Einträge:

2024-02-18 10:34:44,810 - imported_at_plugtime 1065998.05
2024-02-18 10:34:44,812 - imported_at_mode_switch 1065998.05
2024-02-18 11:00:02,634 - reference ReferenceTime.START, reference_time 1708248921.266665, cp.data.set.log.imported_since_mode_switch 4125.969999999972, cp.data.set.log.timestamp_start_charging 1708248921.266665
2024-02-18 11:00:02,635 - energy_source_entry {'timestamp': 1708248901, 'date': '10:35', 'cp': {'cp1': {'imported': 1065998.05, 'exported': 0, 'energy_imported': 4.126, 'energy_exported': 0.0}, 'all': {'imported': 1065998.05, 'exported': 0, 'energy_imported': 4.126, 'energy_exported': 0.0, 'energy_imported_grid': 0.0, 'energy_imported_pv': 0.0, 'energy_imported_bat': 0.0, 'energy_imported_cp': 0.0}}, 'ev': {'ev0': {'soc': 0}, 'ev1': {'soc': 0}, 'ev2': {'soc': 0}}, 'counter': {'counter3': {'imported': 0, 'exported': 0, 'grid': True, 'energy_imported': 0.0, 'energy_exported': 0.0}}, 'pv': {'all': {'exported': 0, 'energy_imported': 0.0, 'energy_exported': 0.0}}, 'bat': {'all': {'imported': 0, 'exported': 0, 'soc': 0, 'energy_imported': 0.0, 'energy_exported': 0.0}}, 'sh': {}, 'hc': {'all': {'imported': 641805.2221324816, 'energy_imported': 0.252, 'energy_exported': 0.0, 'energy_imported_grid': 0.0, 'energy_imported_pv': 0.0, 'energy_imported_bat': 0.0, 'energy_imported_cp': 0.0}}, 'energy_source': {'grid': 0, 'pv': 0, 'bat': 0, 'cp': 0}}
2024-02-18 11:00:02,635 - power source {'grid': 0, 'pv': 0, 'bat': 0, 'cp': 0}
2024-02-18 11:00:02,635 - charged_energy 4125.969999999972
2024-02-18 11:00:02,636 - Ladepreis für die letzte Stunde: 0.0€ Speicher (0%), 0.0€ Netz (0%), 0.0€ Pv (0%)
2024-02-18 11:00:02,636 - current costs 0.0, total costs 0.0


Die letzten beiden Zeilen scheinen auf das Problem zu deuten. Hier scheint es zum einen ein Problem mit dem Zeichensatz (Umlaute) zu geben und auch in den Zahlen stehen etwas seltsame Zeichen. Wobei das vermutlich ein angehängtes € sein soll.
Wo kommen die Zahlen her? Kann ich da was anpassen / prüfen?
Der Strompreis iwird von der OpenWB auch von Tibber abgeholt und zumindest korrekt angezeigt. Auch der Start nach Strompreis passt. Von daher ist die Frage, auf welchen Weg der Preis von dem Tibber Modul und dem Modul für Anzeige und Ladungsstart in die Berechnung (Log, MQTT) kommt und an welcher Stelle hier der Inhalt verloren geht.

Sehe gerade das per MQTT auch Kosten von 0 gesendet werden:
openWB/set/chargepoint/1/set/log, Payload: {'chargemode_log_entry': 'instant_charging', 'costs': 0.0, 'imported_at_mode_switch': 1065998.05, 'imported_at_plugtime': 1065998.05, 'imported_since_mode_switch': 24250.0, 'imported_since_plugged': 24250.0, 'range_charged': 136.2359550561798, 'time_charged': '2:27', 'timestamp_start_charging': 1708248921.266665, 'ev': 1, 'prio': False, 'rfid': None}

Bei der Gelegenheit vielleicht auch ein Hinweis auf die Meldungen im Update Log:


2.1.3-Beta.1: 2.1.3 Beta 1
bugfix: {"1.99.002":"1.99.002: Alpha 2","1.99.003":"1.99.003: Alpha 3","1.99.004":"1.99.004: Alpha 4","1.99.100":"1.99.100: Beta 1","1.99.100.1":"1.99.100.1: Beta.2-RC1","1.99.101.0":"1.99.101.0: Beta 2","1.99.102.0":"1.99.102.0: Beta 3","1.99.103.0":"1.99.103.0: Beta 4","1.99.RC1.0":"1.99.RC1.0: Release Candidate 1","1.99.RC2.0":"1.99.RC2.0: Release Candidate 2","2.0.0":"2.0.0: Release 2.0.0","2.1.0":"2.1.0: 2.1.0 Release","2.1.1":"2.1.1: 2.1.1 Release","2.1.1-Beta.1":"2.1.1-Beta.1: 2.1.1 Beta 1","2.1.1-Beta.2":"2.1.1-Beta.2: 2.1.1 Beta 2","2.1.1-Beta.3":"2.1.1-Beta.3: 2.1.1 Beta 3","2.1.2":"2.1.2: 2.1.2 Release","2.1.2-Beta.1":"2.1.2-Beta.1: 2.1.2 Beta 1","2.1.2-Beta.2":"2.1.2-Beta.2: 2.1.2 Beta 2","2.1.2-Beta.3":"2.1.2-Beta.3: 2.1.2 Beta 3","2.1.2-Beta.4":"2.1.2-Beta.4: 2.1.2 Beta 4","2.1.2-Patch.1":"2.1.2-Patch.1: 2.1.2 Release Patch 1","2.1.3-Beta.1":"2.1.3-Beta.1: 2.1.3 Beta 1"}
checking commit for origin/aiohttp-3.9.0...fatal: mehrdeutiges Argument 'origin/aiohttp-3.9.0': unbekannter Commit oder Pfad existiert nicht
im Arbeitsverzeichnis
Benutzen Sie '--', um Pfade und Commits zu trennen, ähnlich wie:
'git <Befehl> [<Commit>...] -- [<Datei>...]'

tags in branch:
fatal: missgebildeter Objektname origin/aiohttp-3.9.0

aiohttp-3.9.0: {}
checking commit for origin/cryptography-41.0.6...fatal: mehrdeutiges Argument 'origin/cryptography-41.0.6': unbekannter Commit oder Pfad existiert nicht
im Arbeitsverzeichnis
Benutzen Sie '--', um Pfade und Commits zu trennen, ähnlich wie:
'git <Befehl> [<Commit>...] -- [<Datei>...]'

tags in branch:
fatal: missgebildeter Objektname origin/cryptography-41.0.6



Ich weiß nicht ob das was mit dem Problem zu tun hat, aber die Meldung ist mir schon öfter aufgefallen.