ISO 15118 - openWB pro wirklich erforderlich?

[aiole]

Detailfragen gehören zwar besser in einen extra thread, deshalb nur kurz:

Der "direkte" SoC bei der Pro/Pro+ wird beim Modus "PWM mit Fahrzeugerkennung" nur 1x beim Anstecken geholt. Ein fortwährender Abgleich ist dort technisch nicht möglich, was deine Idee mit Automatik-Fahrzeugwahl erschwert.

Im Modus "15118" geht das dann und den bieten Pro/Pro+ auch. Braucht aber passendes (modernes) EV.

Kann denn der Wican nicht auch die MAC-Adresse des EV auslesen? Dann wären SoC und MAC 2 unterschiedliche und klar getrennte Funktionen, die sich sauber auch in Multi-Fahrzeuginstallationen nutzen lassen. Alternativ jedem EV einen RFID-Tag geben und man hat die klare Zuordnung. RFID-Reader gibt's für jede openWB (außer Satellit) kostengünstig zum Nachrüsten.

[openWB]

@mattberlin

warum lässt du den WiCan, der ja in jedem Fahrzeug steckt, nicht auch gleich das entsprechende Profil laden?
Er kommuniziert doch eh schon mit der openWB.

[mattberlin]

Der "direkte" SoC bei der Pro/Pro+ wird beim Modus "PWM mit Fahrzeugerkennung" nur 1x beim Anstecken geholt. Ein fortwährender Abgleich ist dort technisch nicht möglich, was deine Idee mit Automatik-Fahrzeugwahl erschwert.

Wichtige Anmerkung:
Mein Vorschlag mit der Fahrzeugerkennung im vorvorletzten Post bezieht sich nicht auf die Verwendung einer openWB Pro/Pro+, sondern um die Verwendung einer normalen openWB in Verbindung mit einer SoC-Zuführung - sei es via Hersteller-Cloud oder z.B. WiCAN.

Kann denn der Wican nicht auch die MAC-Adresse des EV auslesen? Dann wären SoC und MAC 2 unterschiedliche und klar getrennte Funktionen

Das weiß ich leider nicht. Vielleicht weiß das ja @ChristophR. Allerdings ist es ja durchaus denkbar, dass beide Fahrzeuge in WLAN-Reichweite sind und somit beide Fahrzeuge ihren SoC in ihr jeweiliges Fahrzeugprofil in die openWB schreiben.

@mattberlin

warum lässt du den WiCan, der ja in jedem Fahrzeug steckt, nicht auch gleich das entsprechende Profil laden?
Er kommuniziert doch eh schon mit der openWB.

Das Einwählen ins WLAN und somit die Übertragung an die openWB impliziert ja nicht, dass das Fahrzeug dann auch angesteckt wird. Es kann ja ein beliebiges Fahrzeug zwischenzeitig angesteckt werden.


Von daher bin ich der Auffassung, dass es wichtig wäre, dann die openWB das richtige Fahrzeug selektiert auf Basis dessen, was nach dem Laden passiert, also schauen bei welchem Auto sich der SoC erhöht.

Im Modus "15118" geht das dann und den bieten Pro/Pro+ auch. Braucht aber passendes (modernes) EV.

Gut zu wissen. Das wäre dann ja z.B. bei VW MEB der Fall.

[openWB]

Von daher bin ich der Auffassung, dass es wichtig wäre, dann die openWB das richtige Fahrzeug selektiert auf Basis dessen, was nach dem Laden passiert, also schauen bei welchem Auto sich der SoC erhöht.

Der Wiican sieht doch das geladen wird und kann dann das Profil selektieren!?
Ich würde es nicht vom wlan abhängig machen.

[aiole]

Im Modus "15118" geht das dann und den bieten Pro/Pro+ auch. Braucht aber passendes (modernes) EV.

Gut zu wissen. Das wäre dann ja z.B. bei VW MEB der Fall.

Kann ich nicht sagen, aber VW tat sich bis dato mit guter Umsetzung von Ladestandards eher schwer (PV-Einschlafen ...). BMW's NEUE Klasse sollte dort innovativ sein, zumal sie bis jetzt mit hoher Ladezuverlässigkeit punkteten.

Letztlich muss man es austesten. Dank Firmware-/Software-update-Optionen auf Fahrzeug- und WB-Seite kann dort immer optimiert werden.

[mattberlin]

Kann ich nicht sagen, aber VW tat sich bis dato mit guter Umsetzung von Ladestandards eher schwer (PV-Einschlafen ...).

Damit habe ich kleine Probleme - es nicht einmal CP-Unterbrechung aktiv.

Von daher bin ich der Auffassung, dass es wichtig wäre, dann die openWB das richtige Fahrzeug selektiert auf Basis dessen, was nach dem Laden passiert, also schauen bei welchem Auto sich der SoC erhöht.

Der Wiican sieht doch das geladen wird und kann dann das Profil selektieren!?
Ich würde es nicht vom wlan abhängig machen.

Diesen Ansatz unterstütze ich nicht, denn:
1) Mit dem WiCAN kann man nur bestimmte Werte von CAN ins Register der openWB schreiben. Solche Logiken, dass auf Basis, was gerade passiert, der WiCAN etwas selektiert, kann er (meines Wissens) nicht.

2) Selbst wenn 1. ginge, so ist es für die allermeisten viel zu kompliziert. Es liegt doch im Erstreben von openWB, alles möglichst simpel und DAU-tauglich zu machen. Hiermit wird ja z.B. auch begründet, dass die Speichersteuerung so simpel gehalten wird und wenig Anpassungen zu lässt.

3) Das von mir vorgeschlagene Feature soll ja mehrere SoC-Zuführungen erlauben

sei es via Hersteller-Cloud oder z.B. WiCAN.

4) Das von mir vorgeschlagene Feature soll auch erkennen, wenn ein Gast-Fahrzeug geladen wird, d.h. von BEV 1 und BEV 2 gibt es keine SoC-Erhäöhung, und dann entsprechend das Gast-Fahrzeug-Profil laden.

Dieses sinnvolle Feature lässt sich nur sinnvoll in der openWB umsetzen.

[aiole]

Dein Ansatz in Ehren, aber um SoC-Veränderungen zu detektieren, braucht es eine gewisse Zeit.
Was ist z.B., wenn noch kein SoC-Anstieg gegeben ist (oder der SoC-Server kurz offline ist) und man in diesem Zeitraum wieder ab- oder umsteckt. Wo sollen dann die (wenigen) geladenen Wh zugordnet werden?

Ich denke, dass die korrekte Fahrzeugzuordnung elementar ist und von Anbeginn "stehen" muss. Fehlzuordnungen kann man mit diesem Verfahren m.E. nicht zu 100% ausschließen. Die wären dann auch falsch geloggt, was zu Abrechnungsproblermen führen kann, was gerade bei der openWB-Dienstwagenabrechnung fatal wäre.

Ist wie früher an der Tanke - man weiß vor der Befüllung genau, in welches Kfz man die Stinkebrühe reinkippt (braucht nur nicht mehr zw. Diesel und Benzin unterscheiden ).

[Gero]

Gerade an der Tanke kontrolliert ja keiner, ob da der Golf oder der BMW am Ende des Schlauchs steht. (Ich weiss bis zum heutigen Tage nicht, warum bei Sprit das geht, was bei Strom nicht möglich sein soll.)

Und wenn man mal was nicht zuordnen kann, weil die Cloud mal gerade nicht reagiert oder der Ladevorgang vor einer Änderung des SoC beendet wird, nimmt man halt das eingestellte Fahrzeug. Ist das falsch, so wäre es auch bei einem längeren Ladevorgang falsch zugeordnet. So ist das halt. Heute ist‘s ja auch nicht unfehlbar und vom Benutzer abhängig.

[openWB]

Die meisten Konfigurationen die ich so sehe erfordern erstmal die Auswahl eines Fahrzeuges um überhaupt ein Laden zu ermöglichen.
Ansonsten müsste das Standardprofil ja Sofort Laden sein um im Zweifel dann auf xy zu switchen.
Auch blöd wenn das Standardfahrzeug z.B. eine Phasenumschaltung erlaubt, das danach zu wählende aber wieder nicht.
Das spätere switchen stellt auch z.B. bei der Nutzung von OCPP ein Problem dar. Hier ist bei der start transcation schon die ID zu übermitteln.

Eine Logik dahingehend fällt mir auf Anhieb nicht ein.

Über die Pro ist das natürlich der bequemste Weg.
Ich stecke im WiCan nicht drinnen, aber wenn er doch SoC senden kann, kann er doch sicherlich auch anstecken / laden delektieren und das Fahrzeug übermitteln!?
Die Problematik ist ja vermutlich eher wenn 2 Fahrzeuge sich einen Ladepunkt teilen, richtig?

[mattberlin]

Dein Ansatz in Ehren, aber um SoC-Veränderungen zu detektieren, braucht es eine gewisse Zeit.
Was ist z.B., wenn noch kein SoC-Anstieg gegeben ist (oder der SoC-Server kurz offline ist) und man in diesem Zeitraum wieder ab- oder umsteckt. Wo sollen dann die (wenigen) geladenen Wh zugordnet werden?

Wenn man wild umeinander steckt, kann es da schon mal zu Fehlerkennungen kommen. Das ist dann aber immer noch besser, als wenn grundsätzlich für längere Zeit das falsche Auto gewählt ist.
Zudem könnte man ja auch vorsehen, dass man in der Ladestatistik Ladevorgänge noch zu einem anderen Auto verschieben kann.

Auch blöd wenn das Standardfahrzeug z.B. eine Phasenumschaltung erlaubt, das danach zu wählende aber wieder nicht.

Ja, solche komischen Autos gibt es und diese stellen, nach meiner Wahrnehmung, eine Ausnahme dar. Gibt es eine Fahrzeugprofil für so eine komische Karre, dann kann halt die vorgeschlagene Funktion nicht (sinnvoll) verwendet werden.^

Ich stecke im WiCan nicht drinnen, aber wenn er doch SoC senden kann, kann er doch sicherlich auch anstecken / laden delektieren und das Fahrzeug übermitteln!?
Die Problematik ist ja vermutlich eher wenn 2 Fahrzeuge sich einen Ladepunkt teilen, richtig?

Richtig, es geht um 2 Kisten, die sich einen LP teilen. Ich bin zu sehr ein DAU, um den WiCAN genau genug zu kennen. Aber ich kann mir vorstellen, dass der Status "gesteckt" abgefragt werden kann.
Das wäre dann womöglich das bessere Entscheidungskriterium als auf einen SoC-Verlauf zu achten.
Aber dass der WiCAN dann das Profil in der openWB ändern kann, wage ich zu bezweifeln. Aber die openWB könnte das ja dann tun