Rückmeldungen openWB software 2.1.6 Alpha 1

[LenaK]

2.1.6-Alpha.1, 2024-09-26 09:53:45 +0200 [a6e5b30e0]
Logfile: https://paste.openwb.de/19Ym4wfZkqg4G1B

Anbei Bild vom Ladevorgang von heute. Logfile ist erst irgendwann später auf Details gestellt worden, als mir auffiel, dass wieder das Auto geladen wird, obwohl min. SoC des Speichers noch nicht erreicht ist. Ich würde gerne wissen, was ich da noch falsch konfiguriert haben kann, dass er trotz noch nicht erreichtem min. SoC von 35 % des Speichers das Auto schon lädt. Minimaler Dauerstrom ist auf "Aus" konfiguriert. Laden mit Überschuss ist auf "Mindest-SoC des Speichers" konfiguriert. "Ladeleistung für Speicher reservieren" = Ja, "Reserve Ladeleistung" = 0,2 kW, "Einschaltschwelle" = 1,5 kW.

Nach meinem Verständnis sollte er dann doch immer erst den Speicher auf min. SoC laden, bevor Überschuss ins Auto geht?

Kann das mit der EInschaltschwelle zu tun haben? Die sollte doch IMO aber min. SoC berücksichtigen. Das kann aber denke ich auch nicht der Grund sein, denn neulich war es so, dass bei PV-Überschuss = 0 ein Ladevorgang, der bei noch PV-Überschuss began, weiter lief bei Unterschreitung des min. SoC des Speichers bis soll SoC des Kfz. Dazu habe ich aber kein Log.

Hilfetext: Ladeleistung für Speicher reservieren
Wird der Mindest-SoC des Speichers nicht erreicht, wird der Speicher mit der hier eingestellte Leistung geladen. Mit dem verbleibenden Überschuss werden die Fahrzeuge geladen.

Wenn das Fahrzeug unterhalb des Mindest-SoC des Speichers nicht geladen werden soll, dort die maximale Ladeleistung des Speichers eintragen, dann wird nur ins Auto geladen, was der Speicher nicht mehr aufnehmen kann.

[Elchkopp]

Ich bin aktuell mit der generellen Ladekurve bzw. der Laderegelung nicht so wirklich zufrieden: sie ist für meine Begriffe viel zu zackig. Das ist besonders bei unserem Tesla Model 3 ausgeprägt, aber auch bei unserem Cupra Born zu beobachten, wenn auch bei weitem nicht so ausgeprägt, was aber auch mit der Tatsache zu tun haben mag, dass der Tesla nur relativ große Stromsprünge mitmacht (~1A), der Cupra etwas feiner agiert. Aber es ist fast immer ein hin- und her.

Das ganze sieht so aus:

Screenshot 2024-09-29 115312.png

(119.11 KiB) Noch nie heruntergeladen

Dazu mal Log-Auszüge aus den entsprechenden Bereichen (Cupra und Tesla):
https://paste.openwb.de/RCVOfV2RxK3nWn2 (Cupra)
https://paste.openwb.de/jRIwsj66srDqUza (Tesla)

Der Tesla ist nur am hin- und herregeln, obwohl die restlichen Parameter wie "Hausverbrauch" eigentlich ziemlich ruhig verlaufen. Ich habe das mal auf der Statuseite verfolgt: es ist so, dass zuerst die oWB den Vorgabestrom rauf- bzw. runterregelt und dann das Auto nachzieht. Und das im Wechsel. Es geht also aus meiner Sicht von der Software aus.

Ich bekomme es nur nicht abgestellt. Ich habe im Fahrzeugprofil ja kaum Parameter, die das beeinflussen könnten. Und alles weitere ändert ja das globale Verhalten.

Gestern war auch wieder ein sehr unruhiger Tag:

Screenshot 2024-09-29 152230.png

(120.27 KiB) Noch nie heruntergeladen

Bspw. um 15:18:51 Uhr und nachfolgend. Da gibt es auf einmal einen kleinen Einbruch - ohne erkennbaren Grund für mich. Entsprechend ist die Batterieladung des Hausspeichers auch immer am pendeln.

Dazu mal der Log-Auszug mit dem besagten Zeitraum:
https://paste.openwb.de/QDsSXMu5agzKbhc

Verwendete Version: 2.1.6-Alpha.1 [2024-09-26 09:53:45 +0200 [a6e5b30e0]]

Ich habe im Fahrzeugprofil des Tesla auch schon testhalber die erlaubte Abweichung der Stromstärke von 1A auf 2A erhöht - ohne Auswirkungen. Gestern hatte ich den Regelbereich von "Einspeisung" auf Individuell mit Minimum -0,3 und Maximum 0 verändert. Auch ohne wirklichen Effekt - zumal der ja global ist.

Wenn ihr mich fragen würdet, würde ich sagen, das war "früher" noch nicht so - bin ja schon seit der Beta2-Phase dabei.

Oder sieht das sogar nur bei mir so aus? Wäre für jeden Rat oder Hinweis dankbar.

[Mailoh]

Ist beim Model 3 auch bei mit der Fall und zwar seit Version (134b827ae), welche ich am 19.9. aufgespielt habe.
Davor war es definitiv eine schöne glatte Linie. Voriges Update am 27.8. durchgeführt, danach war noch alles in Ordnung.
Ich habe es hier schon vor einigen Tagen gepostet, aufgrund des schlechten Wetters konnte ich leider keine Logs ziehen, somit wohl auch keine Antwort erhalten.
Ich habe jetzt versucht dieses an den Support zu leiten, eventuell ist dort etwas zu erkennen, die Wellen waren wieder nur kurzzeitig vorhanden.
Hier noch einmal ein Screenshot vom "Problem".....der Ladestrom sackt auch immer ziemlich exakt auf 10,6 kW ab.

Bildschirmfoto 2024-09-20 um 12.03.28.png

(140.59 KiB) Noch nie heruntergeladen

[mrinas]

Ich hab' hier zwei Shell MiniPM G3 verbaut, diese lassen sich mit dem Shelly Modul derzeit leider nicht auslesen.
Es scheint mir dass der Parser für die Statusmeldungen noch nicht für MiniPM G3 angepasst wurde. Ich hab' Änderungen im Bat.py gefunden, aber auch diese funktionieren nicht - so wie ich das sehe wird hier zwingend dreiphasig erwartet, was bei mir aber nicht der Fall ist.

(Zudem scheint der Code fürs Auslesen der Shellys für Inverter, Counter und Batterie redundant, womöglich wäre es geschickter hier eine Api.py zu haben und dort einmal zentral alles zu machen?)

Code: Alles auswählen

2024-10-02 08:55:30,887 - {root:75} - {INFO:MainThread} - # ***Start*** 
2024-10-02 08:55:30,997 - {modules.common.component_context:54} - {DEBUG:device4} - Update Komponenten ['EnergyMeter 1.0']
2024-10-02 08:55:30,999 - {modules.common.component_context:54} - {DEBUG:device8} - Update Komponenten ['Pumpe']
2024-10-02 08:55:31,007 - {urllib3.connectionpool:227} - {DEBUG:device8} - Starting new HTTP connection (1): 192.168.178.81:80
2024-10-02 08:55:31,009 - {modules.devices.sma_sunny_boy.device:72} - {DEBUG:device15} - Start device reading {'component22': <modules.devices.sma_sunny_boy.inverter.SmaSunnyBoyInverter object at 0x73df2a30>}
2024-10-02 08:55:31,010 - {modules.devices.sma_sunny_boy.device:72} - {DEBUG:device16} - Start device reading {'component23': <modules.devices.sma_sunny_boy.inverter.SmaSunnyBoyInverter object at 0x6fbd33d0>}
2024-10-02 08:55:31,011 - {modules.common.component_context:54} - {DEBUG:device15} - Update Komponenten ['WR Garage']
2024-10-02 08:55:31,011 - {modules.devices.sma_sunny_boy.device:72} - {DEBUG:device17} - Start device reading {'component24': <modules.devices.sma_sunny_boy.inverter.SmaSunnyBoyInverter object at 0x6fbd37c0>, 'component25': <modules.devices.sma_sunny_boy.bat_smart_energy.SunnyBoySmartEnergyBat object at 0x6fbc6ec8>}
2024-10-02 08:55:31,012 - {modules.common.component_context:54} - {DEBUG:device16} - Update Komponenten ['WR Haus']
2024-10-02 08:55:31,013 - {modules.devices.virtual.device:40} - {DEBUG:device18} - Start device reading{'component28': <modules.devices.virtual.counter.VirtualCounter object at 0x6fbc6ca0>}
2024-10-02 08:55:31,013 - {modules.common.component_context:25} - {DEBUG:device19} - Update Komponente ['Waschmaschine']
2024-10-02 08:55:31,014 - {modules.common.component_context:25} - {DEBUG:device20} - Update Komponente ['Trockner']
2024-10-02 08:55:31,015 - {modules.common.component_context:54} - {DEBUG:device17} - Update Komponenten ['PV STP6.0', 'Batterie STP6.0']
2024-10-02 08:55:31,016 - {modules.common.component_context:25} - {DEBUG:set values cp26} - Update Komponente ['Ladepunkt']
2024-10-02 08:55:31,016 - {modules.common.component_context:25} - {DEBUG:device15} - Update Komponente ['WR Garage']
2024-10-02 08:55:31,017 - {modules.common.component_context:25} - {DEBUG:device18} - Update Komponente ['UV Garage']
2024-10-02 08:55:31,021 - {modules.common.component_context:25} - {DEBUG:device16} - Update Komponente ['WR Haus']
2024-10-02 08:55:31,025 - {urllib3.connectionpool:227} - {DEBUG:device20} - Starting new HTTP connection (1): 192.168.178.135:80
2024-10-02 08:55:31,026 - {modules.common.component_context:25} - {DEBUG:set values cp27} - Update Komponente ['Ladepunkt']
2024-10-02 08:55:31,030 - {urllib3.connectionpool:227} - {DEBUG:device19} - Starting new HTTP connection (1): 192.168.178.128:80
2024-10-02 08:55:31,033 - {modules.common.component_context:25} - {DEBUG:device17} - Update Komponente ['PV STP6.0']
2024-10-02 08:55:31,034 - {modules.common.simcount._simcount:42} - {DEBUG:device18} - Previous state: SimCounterState(timestamp=1727852120.9138665, power=0, imported=0.0, exported=0)
2024-10-02 08:55:31,044 - {modules.common.simcount._calculate:11} - {DEBUG:device18} - time passed: 0.00281126, power1: 0, power2: 0
2024-10-02 08:55:31,042 - {urllib3.connectionpool:227} - {DEBUG:set values cp27} - Starting new HTTP connection (1): 192.168.178.207:80
2024-10-02 08:55:31,045 - {modules.common.simcount._calculate:27} - {DEBUG:device18} - power did not change sign. Total energy: 0
2024-10-02 08:55:31,049 - {modules.common.simcount._simcount:65} - {DEBUG:device18} - imported: 0 Wh, exported: 0 Wh, new state: SimCounterState(timestamp=1727852131.0344057, power=0, imported=0.0, exported=0)
2024-10-02 08:55:31,050 - {modules.common.store._api:26} - {DEBUG:device18} - Raw data CounterState(currents=[0.0, 0.0, 0.0], powers=[0.0, 0.0, 0.0], voltages=[230.0, 230.0, 230.0], power_factors=[0.0, 0.0, 0.0], imported=0.0, exported=0, power=0, frequency=50)
2024-10-02 08:55:31,069 - {urllib3.connectionpool:452} - {DEBUG:set values cp27} - http://192.168.178.207:80 "GET /connect.php HTTP/1.1" 200 455
2024-10-02 08:55:31,071 - {modules.common.req:32} - {DEBUG:set values cp27} - Get-Response: {"date":"2024:10:02-08:55:31","timestamp":1727852131,"powers":[0,0,0],"power_all":0,"currents":[0,0,0],"voltages":[227.51,228.35,225.16],"frequency":50.055,"imported":1645965,"exported":403,"plug_state":false,"charge_state":false,"phases_actual":0,"phases_target":1,"phases_in_use":1,"offered_current":0,"evse_signaling":"basic","v2g_ready":0,"soc_value":null,"soc_timestamp":null,"vehicle_id":null,"rfid_tag":null,"rfid_timestamp":null,"serial":"830892"}
2024-10-02 08:55:31,073 - {modules.common.store._api:26} - {DEBUG:set values cp27} - Raw data ChargepointState(currents=[0, 0, 0], powers=[0, 0, 0], voltages=[227.51, 228.35, 225.16], frequency=50.055, imported=1645965, exported=403, power=0, serial_number=830892, phases_in_use=1, charge_state=False, plug_state=False, rfid=None, rfid_timestamp=None, power_factors=[0.0, 0.0, 0.0], soc=None, soc_timestamp=None, evse_current=0, vehicle_id=None)
2024-10-02 08:55:31,075 - {urllib3.connectionpool:452} - {DEBUG:device19} - http://192.168.178.128:80 "GET /rpc/Shelly.GetStatus HTTP/1.1" 200 734
2024-10-02 08:55:31,081 - {urllib3.connectionpool:452} - {DEBUG:device20} - http://192.168.178.135:80 "GET /rpc/Shelly.GetStatus HTTP/1.1" 200 736
2024-10-02 08:55:31,083 - {modules.common.req:32} - {DEBUG:device19} - Get-Response: {"ble":{},"bthome":{"errors":["observer_disabled"]},"cloud":{"connected":true},"mqtt":{"connected":false},"pm1:0":{"id":0, "voltage":229.5, "current":0.000, "apower":0.0 ,"freq":50.1,"aenergy":{"total":3195.880,"by_minute":[0.000,0.000,0.000],"minute_ts":1727852100},"ret_aenergy":{"total":0.000,"by_minute":[0.000,0.000,0.000],"minute_ts":1727852100}},"sys":{"mac":"ECDA3BC7416C","restart_required":false,"time":"08:55","unixtime":1727852131,"uptime":299986,"ram_size":260472,"ram_free":94092,"fs_size":1048576,"fs_free":618496,"cfg_rev":14,"kvs_rev":5,"schedule_rev":0,"webhook_rev":0,"available_updates":{},"reset_reason":3},"wifi":{"sta_ip":"192.168.178.128","status":"got ip","ssid":"mrhome","rssi":-53},"ws":{"connected":false}}
2024-10-02 08:55:31,086 - {modules.common.req:32} - {DEBUG:device20} - Get-Response: {"ble":{},"bthome":{"errors":["bluetooth_disabled"]},"cloud":{"connected":true},"mqtt":{"connected":false},"pm1:0":{"id":0, "voltage":227.1, "current":0.000, "apower":0.0 ,"freq":50.1,"aenergy":{"total":3023.693,"by_minute":[0.000,0.000,0.000],"minute_ts":1727852100},"ret_aenergy":{"total":0.000,"by_minute":[0.000,0.000,0.000],"minute_ts":1727852100}},"sys":{"mac":"ECDA3BC6E60C","restart_required":false,"time":"08:55","unixtime":1727852131,"uptime":298502,"ram_size":260824,"ram_free":138372,"fs_size":1048576,"fs_free":618496,"cfg_rev":14,"kvs_rev":6,"schedule_rev":0,"webhook_rev":0,"available_updates":{},"reset_reason":3},"wifi":{"sta_ip":"192.168.178.135","status":"got ip","ssid":"mrhome","rssi":-52},"ws":{"connected":false}}
2024-10-02 08:55:31,090 - {modules.devices.shelly.counter:69} - {ERROR:device19} - unsupported shelly device?
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/devices/shelly/counter.py", line 51, in update
    voltages = [status['em:0'][f'{i}_voltage'] for i in 'abc']
  File "/var/www/html/openWB/packages/modules/devices/shelly/counter.py", line 51, in <listcomp>
    voltages = [status['em:0'][f'{i}_voltage'] for i in 'abc']
KeyError: 'em:0'
2024-10-02 08:55:31,094 - {modules.devices.shelly.counter:69} - {ERROR:device20} - unsupported shelly device?
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/devices/shelly/counter.py", line 51, in update
    voltages = [status['em:0'][f'{i}_voltage'] for i in 'abc']
  File "/var/www/html/openWB/packages/modules/devices/shelly/counter.py", line 51, in <listcomp>
    voltages = [status['em:0'][f'{i}_voltage'] for i in 'abc']
KeyError: 'em:0'
2024-10-02 08:55:31,122 - {modules.devices.sma_sunny_boy.inverter:78} - {DEBUG:device15} - WR 192.168.178.204: InverterState(currents=[0.0, 0.0, 0.0], power=-72, exported=9218804, dc_power=-132)

So sieht mein Json vom Shelly aus:

Code: Alles auswählen

{
    "ble": {},
    "bthome": {
        "errors": [
            "observer_disabled"
        ]
    },
    "cloud": {
        "connected": true
    },
    "mqtt": {
        "connected": false
    },
    "pm1:0": {
        "id": 0,
        "voltage": 230.9,
        "current": 0,
        "apower": 0,
        "freq": 50,
        "aenergy": {
            "total": 3195.88,
            "by_minute": [
                0,
                0,
                0
            ],
            "minute_ts": 1727857620
        },
        "ret_aenergy": {
            "total": 0,
            "by_minute": [
                0,
                0,
                0
            ],
            "minute_ts": 1727857620
        }
    },
    "sys": {
        "mac": "ECDA3BC7416C",
        "restart_required": false,
        "time": "10:27",
        "unixtime": 1727857637,
        "uptime": 305492,
        "ram_size": 260360,
        "ram_free": 89972,
        "fs_size": 1048576,
        "fs_free": 618496,
        "cfg_rev": 14,
        "kvs_rev": 5,
        "schedule_rev": 0,
        "webhook_rev": 0,
        "available_updates": {},
        "reset_reason": 3
    },
    "wifi": {
        "sta_ip": "192.168.178.128",
        "status": "got ip",
        "ssid": "mrhome",
        "rssi": -53
    },
    "ws": {
        "connected": false
    }
}

Ich laufe aktuell auf der letzten release Version, kann das Problem aber auch mit dem aktuellen Alpha nachstellen.

Derweil werde ich die mal mit dem generischen Json-Modul einbinden, das scheint zu klappen. Schön wäre wenn ich später aufs Shelly Modul umsteigen könnte.
Leider komm' ich aktuell nicht dazu mir das selber mal anzuschauen.

[flea]

master - Stand 2024-09-26 09:53:45 +0200 [a6e5b30e0]
Die Victron-Komponenten funktionieren nicht mehr. Statusmeldung:

Code: Alles auswählen

Modulmeldung:
<class 'TypeError'> ('update() takes 1 positional argument but 2 were given',)

Des Weiteren lassen sich die neuen Zusatzinfos zu den Komponenten für den Systembericht nicht speichern (sind danach immer leer).

+1

Wobei der Speicher im Widget korrekt angezeigt wird mit Daten, aber nicht die Summe der Speicher nicht mehr (ist seit 2.1.6, bei 2.1.5 RC2 war es noch i.O.):
.

Bildschirmfoto 2024-10-02 um 17.21.18.png (58.91 KiB) 653 mal betrachtet

.
Im Übersichtswidget erscheint dann gar keine Anzeige zum Speicher, weder SOC noch in der Grafik:
.

Bildschirmfoto 2024-10-02 um 17.29.00.png (86.4 KiB) 653 mal betrachtet

.
In der Statusübersicht erscheint der Fehler von @aiole für die Victron-Speicher auch direkt in der Ansicht:
.

Bildschirmfoto 2024-10-02 um 17.33.56.png

(112.82 KiB) Noch nie heruntergeladen

.
.

Code: Alles auswählen

2024-10-02 17:20:08,245 - {modules.loadvars:75} - {ERROR:MainThread} - Fehler im loadvars-Modul bei Element {'type': 'bat', 'id': 5}
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 69, in _update_values_of_level
    component = get_component_obj_by_id(element["id"], not_finished_threads)
  File "/var/www/html/openWB/packages/modules/common/utils/component_parser.py", line 32, in get_component_obj_by_id
    if module_data[f"{type_to_topic_mapping(type)}{id}"].data.get.fault_state == 2:
KeyError: 'bat5'

[ChrisChros]

Hallo zusammen,

ich habe bei mir in meinem Standard Ladepunkt-Profil die Option "Sperre nach Abstecken" aktiviert und zudem die entsprechenden ID-Tags eingetragen um die WB wieder zu entsperren.

Bildschirmfoto 2024-10-03 um 11.45.40.png

(129.99 KiB) Noch nie heruntergeladen

Woran kann ich nun im WebInterface erkennen ob die WB gesperrt ist? Bei mir wird da nichts angezeigt. Muss ich dazu noch andere Sachen konfigurieren?

Bildschirmfoto 2024-10-03 um 11.47.17.png

(510.74 KiB) Noch nie heruntergeladen

Genutzt wird der aktuelle Master 2.1.6-Alpha.1 2024-10-02 10:24:47 +0000 [00ba14565]

Gruß Chris

[aiole]

Genauer Softwarestand mit Datumsangabe und Github-Codierung ist die Mindestangabe, die man bereitstellen muss.
Normalerweise sollte auf der main der Sperrschalter rot sein.

Ich verwende keine Standard-Profile und lege sowohl für LP als auch bei Fahrzeuge immer separate Profile an (bei Fahrzeugen nutze ich dann meist das Standard-Ladeprofil mit Stop-Funktion = "Standard nach Abstecken"-Schalter statt der LP-Sperre).

Ich würde es testweise mal mit neuen Profilen probieren.

[ChrisChros]

Das standard Profil wird auch nicht wirklich genutzt, es wird nur aktiviert wenn kein Fahrzeug angesteckt ist. Für mein Auto habe ich ein eigenes Profil in dem dann ich die Option "Standard nach Abstecken" aktiviert habe.

Bildschirmfoto 2024-10-03 um 12.14.01.png

(149.9 KiB) Noch nie heruntergeladen

Das standard Profil steht dann auf Stop und sollte nach meinem Verständnis auch gesperrt sein.

[aiole]

Die LP-Sperre ist separat und hat nichts mit dem Fahrzeug-Profil zu tun.

Ich nutze es wie du, verzichte aber auf die LP-Sperre. Durch das Stop im Standard-Fahrzeug auf welches beim aktivierten "Standard nach Abstecken" zurückgefallen wird, wird im Prinzip das gleiche wie bei Sperre erreicht.

Sperre ist eher etwas für Leute, die noch LP-orientiert arbeiten (meist nur 1 Fahrzeug). Dort wird die WB mit tag oder GUI-Button "gesperrt".

ps
LP = Ladepunkt

[Klausiy123]

Screenshot_20241005_101403_Firefox.jpg

(356.09 KiB) Noch nie heruntergeladen

Moin, ich hab ein Problem mit den Fahrzeugen, ich hab einmal "neues Fahrzeug" und einmal zusätzlich "Standard-Fahrzeug" welche sich nicht aufklappen aber auch nicht löschen lassen. Das muss nicht unbedingt mit der aktuellen Alpha zusammen hängen. Wie bekomme ich die wieder weg? Danke.