Support: Kia

[openWB]

Warum ist das eigentlich nur über die openWB Pro möglich? Sind das hardwaretechnische Gründe oder eher marketingtechnische? Könnte man das evtl. durch eine Zusatzplatine auch für die openWB 2 realisieren? Oder bräuchte z. B. das Ladekabel eine zusätzliche Ader?

Es ist rein hardwarebedingt. Die EVSE ist eine gänzlich andere. Der verbaute Raspberry dann überflüssig.
Heißt mittels Zusatzplatine ist das nicht möglich.
Das Ladekabel bleibt identisch.

Kurzum:
openWB series 2 bietet PWM gesteuerte Ladung
openWB Pro bietet PWM gesteuerte Ladung als auch einen PLC Chip um HighLevelCommunication abzubilden.
Das erfolgt eine Kommunikation über Netzwerk. Die Basis für Fahrzeugerkennung, SoC Auslesung und natürlich auch für bidirektionales Laden.

Wer openWB kennt weiß das wir das nicht aus Marketinggründen verbauen aber nicht "freischalten" würden.

[caran17]

Warum ist das eigentlich nur über die openWB Pro möglich? Sind das hardwaretechnische Gründe oder eher marketingtechnische? Könnte man das evtl. durch eine Zusatzplatine auch für die openWB 2 realisieren? Oder bräuchte z. B. das Ladekabel eine zusätzliche Ader?

Es ist rein hardwarebedingt. Die EVSE ist eine gänzlich andere. Der verbaute Raspberry dann überflüssig.
Heißt mittels Zusatzplatine ist das nicht möglich.
Das Ladekabel bleibt identisch.

Kurzum:
openWB series 2 bietet PWM gesteuerte Ladung
openWB Pro bietet PWM gesteuerte Ladung als auch einen PLC Chip um HighLevelCommunication abzubilden.
Das erfolgt eine Kommunikation über Netzwerk. Die Basis für Fahrzeugerkennung, SoC Auslesung und natürlich auch für bidirektionales Laden.

Wer openWB kennt weiß das wir das nicht aus Marketinggründen verbauen aber nicht "freischalten" würden.

Danke für die Klarstellung. War auch nur ein Gedanke. Tatsächlich hat HansR ja nicht ganz unrecht, wenn der Soc nicht ausgelesen werden kann, ist ein Großteil der Funktionen nicht nutzbar. Die Möglichkeit, eine HA Entität direkt "anzuzapfen", wäre daher wirklich ein Fortschritt.

[openWB]

Die Möglichkeit, eine HA Entität direkt "anzuzapfen", wäre daher wirklich ein Fortschritt.

Wäre = ist.
Ist in der Alpha 2.1.9

[christoph.wegener]

Und das funktioniert hier ganz prima bisher, vielen Dank nochmals!

BTW: Ist geplant die "Range"

Code: Alles auswählen

{DEBUG:fetch soc_ev1} - Raw data CarState(soc=68.0, range=None, soc_timestamp=1761907622)

auch noch abfragbar zu machen? Das wäre ja noch eine nette Ergänzung mEn.

Die Möglichkeit, eine HA Entität direkt "anzuzapfen", wäre daher wirklich ein Fortschritt.

Wäre = ist.
Ist in der Alpha 2.1.9

[HansR]

Blöde Frage, den Hyundai SoC per EVCC anzeigen zu lassen geht auch?

[aiole]

Blöde Frage, den Hyundai SoC per EVCC anzeigen zu lassen geht auch?

Sollte gehen, da EVCC den SoC dann abholt und openWB beistellt.

[christoph.wegener]

Grundsätzlich sicher, ja, die Frage wäre aber auch hier, wie die mit dem Problem des Google-Captcha umgehen.

Blöde Frage, den Hyundai SoC per EVCC anzeigen zu lassen geht auch?

[caran17]

Wäre = ist.
Ist in der Alpha 2.1.9

Für mich doch eher "Wäre", da ich die openWB "produktiv" einsetze und daher auf dem Release-Zweig bin und auch bleiben möchte.

Daher bin ich aktuell dabei, die Variante "HA pusht Werte per MQTT an openWB" zu verfeinern. Falls es jemanden interessiert, das HA-YAML-Script, welches die Werte für Fahrzeug 0 "korrekt" pusht, sieht so aus (Danke KI):

Code: Alles auswählen

sequence:
  - data:
      topic: openWB/set/mqtt/vehicle/0/get/soc
      payload: "{{ states('sensor.kona_ev_battery_level') }}"
      qos: 1
    action: mqtt.publish
  - data:
      topic: openWB/set/mqtt/vehicle/0/get/range
      payload: "{{ states('sensor.kona_total_driving_range') }}"
      qos: 1
    action: mqtt.publish
  - data:
      topic: openWB/set/mqtt/vehicle/0/get/soc_timestamp
      payload: >-
        {{ as_timestamp(states.sensor.kona_ev_battery_level.last_changed) | int
        }}
      qos: 1
    action: mqtt.publish
alias: Kona SOC push values via MQTT
description: ""

Das funktioniert, allerdings würde es in meinem Fall nur zum mosquitto-Broker in HA gepusht, daher musste ich noch die vorher bereits vorhandene mosquitto-Konfiguration anpassen, damit das auch an die openWB geht. Die sieht komplett jetzt so aus:

Code: Alles auswählen

#
# bridge to openWB Wallbox
#
connection openwb2
local_clientid openwb2.mosquitto

address openwb.fritz.box:1883

# Sensors Controller
topic openWB/system/ip_address in
topic openWB/system/version in
topic openWB/system/lastlivevaluesJson in

# Sensors per Chargepoint
topic openWB/chargepoint/4/get/# in
topic openWB/chargepoint/4/config in

# SOC
topic openWB/set/mqtt/vehicle/# out

Eine Sache wundert mich allerdings, vielleicht mag mich da jemand aufklären: In der Fahrzeug-Konfiguration in der openWB habe ich ja jetzt MQTT als SoC-Modul gewählt. Trotzdem muss ich noch das Aktualisierungsintervall für die Fahtrzeugdaten angeben. Das Gute an MQTT ist doch gerade, dass man auch pushen kann, daher soll die openWB natürlich jedes Mal aktualisieren, wenn sie neue Werte bekommt (sie zieht soich diese in dem Fall ja nicht). Warum muss ich trotzdem ein Intervall festlegen? Wie kann ich mir das technisch vorstellen?

[openWB]

Die openWB hat ein Intervall, unabhngig in das MQTT json oder irgendwas ist.

Möchtest du das umgehen musstest das manuelle eingeben simulieren. Ist auch hier im Forum mal beschrieben worden.

[caran17]

Die openWB hat ein Intervall, unabhngig in das MQTT json oder irgendwas ist.

Möchtest du das umgehen musstest das manuelle eingeben simulieren. Ist auch hier im Forum mal beschrieben worden.

Ich möchte noch nichts umgehen, ich möchte es erstmal nur verstehen, um zu wissen, was ich dort eintragen sollte. Ich stelle es mir eigentlich so vor: die openWB subscribed sich auf die topics, die dann eben von HA gesendet werden. Die Werte sind ja in den Moment, in dem HA sie sendet, im openWB Broker vorhanden. Was bewirkt also dieses Intervall der openWB? Ist es vielleicht so, dass die openWB die Werte aus MQTT erstmal nur entgegennimmt und erst zu den Intervallzeitpunkten verarbeitet?