Feedback Beta 1

[LutzB]

Zu 1.: Ja, da anderer Bereich
Zu 2.: Kommt später mal. Hatten wir intern schon andiskutiert.

[tobox]

Da mir diese Überschwinger beim Laden mehrerer Autos nicht geheuer waren, und da auch die Verteilung der Ladeleistungen auf die Autos ziemlich zufällig war, hab ich mal ein Python-Script geschrieben, welches die 32A gerecht auf die Ladenden Autos aufteilt.

Feedback willkommen!

Inbesondere bei den MQTT-Topics war ich mir oft nicht sicher, ob die von mir verwendeten auch die richtigen/besten sind.

Code: Alles auswählen

import random
import time

from paho.mqtt import client as mqtt_client

broker = 'openwb.adwin.de'
port = 1883
topic = "python/mqtt"
# generate client ID with pub prefix randomly
client_id = f'python-mqtt-{random.randint(0, 1000)}'

power = {}
power['openWB/chargepoint/1/get/power'] = 0
power['openWB/chargepoint/2/get/power'] = 0
power['openWB/chargepoint/3/get/power'] = 0
power['openWB/chargepoint/4/get/power'] = 0
oldchargecount = 5

def connect_mqtt():
    def on_connect(client, userdata, flags, rc):
        if rc == 0:
            print("Connected to MQTT Broker!")
        else:
            print("Failed to connect, return code %d\n", rc)

    client = mqtt_client.Client(client_id)
    client.on_connect = on_connect
    client.connect(broker, port)
    return client

def subscribe(client: mqtt_client):
    def on_message(client, userdata, msg):
        global power
        global oldchargecount
        #print(f"Received `{msg.payload.decode()}` from `{msg.topic}` topic")
        power[msg.topic] = msg.payload.decode()
        newchargecount = 0
        for pwr in power:
            if float(power[pwr]) > 0:
                newchargecount += 1
        if newchargecount != oldchargecount:
            print(f"Parallele Ladungen geändert von {oldchargecount} auf {newchargecount}")
            maxcurrent = 32
            if newchargecount > 1:
                maxcurrent = 16
            if newchargecount > 2:
                maxcurrent = 11
            if newchargecount > 3:
                maxcurrent = 8

            print(f'Setting all Loadpoints to {maxcurrent}')
            for i in range(1,5):
                #print(f'openWB/set/vehicle/template/charge_template/{i}/chargemode/instant_charging/current = {maxcurrent}')
                result = client.publish(f'openWB/set/vehicle/template/charge_template/{i}/chargemode/instant_charging/current', maxcurrent)

            oldchargecount = newchargecount

    client.subscribe('openWB/chargepoint/1/get/power')
    client.subscribe('openWB/chargepoint/2/get/power')
    client.subscribe('openWB/chargepoint/3/get/power')
    client.subscribe('openWB/chargepoint/4/get/power')
    client.on_message = on_message


def run():
    client = connect_mqtt()
    subscribe(client)
    client.loop_forever()

if __name__ == '__main__':
    run()

[rleidner]

Ich bekomme seit einiger Zeit im Abstand von 20 min solche Fehler in soc.log:

Code: Alles auswählen

2022-12-07 14:25:20,406 - {soc.modules.update_soc:57} - {ERROR:update_soc} - Fehler im Main-Modul
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/update_soc.py", line 44, in _get_threads
    soc_update_data = self._get_soc_update_data(ev.num)
  File "/var/www/html/openWB/packages/modules/update_soc.py", line 66, in _get_soc_update_data
    cp_data = copy.deepcopy(data.data.cp_data)
  File "/usr/lib/python3.9/copy.py", line 146, in deepcopy
    y = copier(x, memo)
  File "/usr/lib/python3.9/copy.py", line 229, in _deepcopy_dict
    for key, value in x.items():
RuntimeError: dictionary changed size during iteration

Es scheint mit der Vorbereitung der SOC-Abrufe zusammenzuhängen.
Ich habe 3 Fahrzeuge konfiguriert:
VW -ID.3 mit VWId SOC-Modul
smart mit http SOC-Modul
Testfahrzeug - kein SOC-Modul

Auch nach Restart kommt das recht regelmässig.

Woran kann das liegen?

[jub]

Untenstehende Problembeschreibung ist auf die OpenWB pro zurückzuführen, scheint sich aufgehängt zu haben, bzw die Kommunikation zwischen Zähler und Board hat nicht gepasst (kein Telefonhörer im Display)- die zeigte eine konstante Ladeleistung an (9,3 kW), openWB hat das übernommen, aber mit 0 A angezeigt. Ganz nachvollziehbar ist mir die Sache noch nicht: in der Monatsauswertung sehe ich 9 kWh Verbrauch (das hat die OpenWB Pro fälschlich geliefert), in der Tagesauswertung sinds die 400 W vom virtuellen Zähler.

Ich schau mal, ob das wieder Auftritt - scheint aber eher die OpenWB pro zu betreffen.

lg


+++++++++++++++++++++++
Ich habe seit 4.12.2022 (leider kann ich die Softwareversion nicht mehr nachvollziehen, dürfte aber die aktuelle von diesem Tag sein) im Ladeprotokoll zwar eine Ladedauer, aber keine Energie (dementsprechend auch keine Kostenanzeige). Die Tages- und Monatsauswertungen zeigen auch keine Ladung mehr an, aber dem 4.12. Der konstante Verbrauch durch den virtuellen Zähler sehe ich und die Software ist auch auf dem aktuellen Stand (aktuell 2022-12-08 10:11:32 +0100 [a268185b]...)

[hannesrh]

Modul: VehicleSocBmw
Der Wert für den SOC aktualisiert sich nicht automatisch. Per Hand in der GUI durch Click auf Update bekomme ich die aktuellen Werte, nicht aber ohne eine manuelle Aktion. Im Soc.log ist nichts zu finden, keine Information im Log, Log ist komplett leer.

[rleidner]

Modul: VehicleSocBmw
Der Wert für den SOC aktualisiert sich nicht automatisch. Per Hand in der GUI durch Click auf Update bekomme ich die aktuellen Werte, nicht aber ohne eine manuelle Aktion. Im Soc.log ist nichts zu finden, keine Information im Log, Log ist komplett leer.

Wartest Du auch lang genug?
Die SOC-Abruf-Intervalle sind momentan nicht über das UI änderbar, nur per MQTT.
StandardIntervalle:

Code: Alles auswählen

{
    "request_interval_charging": 5,
    "request_interval_not_charging": 720,
    "request_only_plugged": false
  }

Diese Werte sind Minuten, d.h. nicht ladend 12 Stunden.

[mrinas]

Wobei SoC Abfrage beim Anstecken bei mir nun zuverlässig funktioniert. Könntest Du auch mal testen, abstecken, 15s warten, anstecken, kontrollieren ob SoC abgefragt wurde.

[hannesrh]

Modul: VehicleSocBmw
Der Wert für den SOC aktualisiert sich nicht automatisch. Per Hand in der GUI durch Click auf Update bekomme ich die aktuellen Werte, nicht aber ohne eine manuelle Aktion. Im Soc.log ist nichts zu finden, keine Information im Log, Log ist komplett leer.

Wartest Du auch lang genug?
Die SOC-Abruf-Intervalle sind momentan nicht über das UI änderbar, nur per MQTT.
StandardIntervalle:

Code: Alles auswählen

{
    "request_interval_charging": 5,
    "request_interval_not_charging": 720,
    "request_only_plugged": false
  }

Diese Werte sind Minuten, d.h. nicht ladend 12 Stunden.

OK, solange habe ich nicht gewartet. Ich vergleiche das Verhalten mit einer 1.9er Version. Bei dieser Version wird der SOC laufend aktualisiert, unabhängig vom Zustand. Wir sind z.B. gerade nochmal mit dem Auto gefahren. Die OpenWB2 zeigt 75% an, die OpenWB1 72%. Wenn ich auf Update klicke kommt bei der openWB2 auch 72%. Ich fand es bei der OpenWB1 angenehm, dass ich mich auf die Anzeige verlassen konnte. Es ist auch so, dass der Wert in der BMW Cloud ein paar Minuten hinterher läuft. Wenn ich z.B. die Lademengenbegrenzung auf 70% eingestelle, dann stoppt das Laden wenn in der Cloud z.B. 72% erreicht sind, da die Cloud aber hinterherhinkt sind es am Ende tatsächlich 75%. Das zeigt dann die openWB1 auch an, die OpenWB2 bleibt bei 72% stehen. Ich würde laufend aktualisieren und keinen Unterschied zwischen den Status machen.

[mrinas]

Ich denke es wird sicher bald eine Konfigurationsoption hierfür geben, je nach Fahrzeug gibt es hier unterschiede. Tesla z.b. muss aufgeweckt werden um einen aktuellen SoC Abrufen zu können, das möchte man nicht permanent machen das dass Auto im Wach-Zustand rd. 200-300W benötigt und erst nach rd. 15min wieder einschläft.

[rleidner]

Wenn die owb 2.0 den korrekten Plug- und Charge Status nicht hat, wird das längere not_charching_interval benutzt,
also im Standard 12 Stunden.

Ich sende per NodeRed die aktuellen Daten der owb1 permanent in die owb2 und es wird sauber aktualisiert.

Wie bereits erwähnt sind die Intervalle aktuell im UI nicht änderbar, aber per mqtt, z.B. mit diesem Script.
Die Nummer des ev_template (hier 3) anpassen, auf dem owb2-System ausführen!

Code: Alles auswählen

#!/bin/bash
tmpFile=/tmp/int.tmp
mosquitto_sub -C 1 -t openWB/vehicle/template/ev_template/3 | jq > $tmpFile

int_ch=`cat $tmpFile | grep interval_charging | awk -F":" '{print $2}' | awk -F"," '{print $1}' | tr -d " "`
int_no_ch=`cat $tmpFile | grep interval_not_charging | awk -F":" '{print $2}' | awk -F"," '{print $1}' | tr -d " "`
echo "interval_charging: $int_ch, enter new value"
read i1
echo "interval_not_charging: $int_no_ch, enter new value"
read i2

new=`sed "
/interval_charging/s/:.*,/:$i1,/
/interval_not_charging/s/:.*,/:$i2,/
" < $tmpFile`
echo "new settings:"
echo $new | jq
echo "publish(Y)?"
read a
if [ "$a" = "Y" ]
then
    mosquitto_pub -t openWB/set/vehicle/template/ev_template/3 -m "$new"
fi
if [ $? -eq 0 ]
then
    echo "publish successful"
else
    echo "publish failed"
fi