Ladestation für Elektrofahrzeuge (OCPP-Protokoll)

[Sescandell]

Die Option zum Auswählen von Geräten funktioniert, danke für den Tipp @pierre-gilles, ich bin darüber hinweggegangen. Es ist ein Vereinfacher! Aber es bleibt ein nicht optimaler und nicht einfacher Benutzerpfad. Denn im Grunde muss der Benutzer:

1. Die URL in seiner Anwendung ändern
2. Zu Entdeckung gehen und den Terminal zu Gladys hinzufügen. Aber der Terminal befindet sich in einem „instabilen“ Zustand. Er kann mit Gladys kommunizieren, aber nicht mehr mit der Cloud-Bridge.
3. Zurück zur Konfiguration gehen, um den Terminal auszuwählen und eine URL hinzuzufügen: aber in einer Schnittstelle, die nicht direkt mit dem Gerät verknüpft ist
4. Um eine pro Terminal konfigurierte URL zu sehen, muss man in das Gerät oder die Entdeckung gehen, wo man die Parameter pushen kann (was ich derzeit tue)

Es funktioniert, es ist cool. Aber es ist nicht das Einfachste. Außerdem stelle ich mir vor, dass der Benutzer morgen die Option hat: „Ja, ich möchte die ursprüngliche Cloud verwenden“ oder „Nein, alles bei Gladys lassen“. Und möglicherweise eine etwas weitergehende Konfigurationsschnittstelle pro Terminal.

Für eine V1 können wir uns mit der aktuellen Funktionsweise zufriedengeben. Aber eine etwas weitergehende Verwaltungsfähigkeit der Konfigurationen pro Gerät (Konfigurationen, die auf der Seite des Plugins verwaltet werden, das die Funktionalität bereitstellt) würde meiner Meinung nach neue Szenarien freischalten können.

Um mit der externen Integration von OCPP fortzufahren, benötige ich jetzt den Merge des PR, der die Kategorie CHARGING_STATION und die zugehörigen Typen einführt. Was fehlt noch auf deiner Seite, um mit diesem PR voranzukommen?

Danke,

[Sescandell]

@pierre-gilles Es gibt einen Fehler im externen Integrationsbereich, wenn der Modus „Geräte auswählen“ verwendet wird. Die Validierung funktioniert nicht. Dieser Code berücksichtigt Geräte nicht korrekt, verwendet immer ein leeres Array und verhindert die tatsächliche Nutzung der hier vorgeschlagenen Option (ich hatte das Update auf meiner Schnittstelle nicht versucht):

// externalIntegration.validateConfigValue.js:36-41
case 'select': {
  const validValues = (field.options || []).map((option) => option.value);
  if (!validValues.includes(value)) {
    throw new Error422(`config.${key}: must be one of ${validValues.join(', ')}`);

[pierre-gilles]

Danke für das Feedback, das ist in diesem PR behoben:

Support dynamic options for select/multi_select config fields (#2779)

@Sescandell

Um mit der externen Integration von OCPP fortzufahren, benötige ich jetzt den Merge des PR, der die Kategorie LADESTATION und die zugehörigen Typen einführt.

Das ist auch gemerged

[Sescandell]

Super cool !!! Danke

Jetzt kann ich die V1 abschließen! Ich erledige das und dann reden wir später über diese Konfigurationsgeschichten

Danke

[Sescandell]

Ein neues Feedback: Es wäre interessant zu können, festzulegen, ob man diesen Button tatsächlich anzeigen möchte oder nicht (heute wird er automatisch angezeigt, wenn ich einen Port definiert habe):

In meinem Fall macht der Button so jedoch keinen Sinn. Was mich interessieren würde, wäre stattdessen die Möglichkeit, die Nachricht darüber anzupassen, um auf dieser Anzeige auf die Gladys-URL zugreifen zu können. Könnte das SDK die « getHost() »-Methode bereitstellen?

Übrigens ein kleines Display-Problem mit dem Selektor hier:

[Sescandell]

Außerdem, was die Integration betrifft, ist die V1 verfügbar (sobald GLadys aktualisiert ist):

Ich denke, das könnte eine V1 werden.

[mutmut]

Exzellente Arbeit @Sescandell

Ich habe aktuell eine Tesla Wallbox Gen3 und schaue, welches Protokoll sie verwendet, da ich die Informationen bisher über HA (ohne Steuerung) abrufe. Falls ich deine Integration teste.

Ich schaue auch, ob ich sie austausche und diese hier von DEPOW bekomme, die OCPP-kompatibel ist (und ich sehe, dass der Preis gerade erst um 200€ gesenkt wurde!).

[Sescandell]

Ich liebe direkt in die Komplexität mit einer Multi-Connector-Verwaltung!

Ich habe mich in meinem vorherigen Beitrag falsch ausgedrückt: Ich habe die v1 noch nicht veröffentlicht: Es ist ein Update für Gladys erforderlich.

Meine größte „Sorge bei dem Thema“ ist der Mangel an verschiedenen Tests. Ich habe eine Autel Charge zu Hause. Mono-Connector. Theoretisch ist der Code für Multi-Connector ausgelegt. Aber ich habe nicht getestet. Ich konnte den ocpp2.0.1 auch nicht in der Praxis testen. Meine Ladestation ist auf 1.6 (es gibt eine Option 2.0, ich muss sehen, ob es funktioniert)

Deshalb bin ich an anderen Testern interessiert.

Wenn du eine Gladys-Instanz hast, die auf Master läuft und du keine Angst hast… Das interessiert mich!

Bevor wir uns kopfüber in die Tesla stürzen, interessieren mich Screenshots, um zu sehen, was du konfigurieren kannst (es ist der Einstellungsbereich, der mich interessiert und die Idee eines ocpp- oder csms-Servers). Wenn du das parat hast, interessiert mich das.

Danke

[mutmut]

Für die Gen3 ist OCPP tot, Claude hat mir ein paar Worte dazu gesagt

Gute und schlechte Nachricht: Man kann tatsächlich viele Informationen vom Gen 3 abrufen, aber überhaupt nicht über OCPP, und die Steuerung bleibt sehr begrenzt. Hier sind die Details.

1. OCPP am Wall Connector Gen 3: nicht unterstützt

Im Gegensatz zu dem, was man hoffen könnte, unterstützt nur der Tesla Universal Wall Connector (nur in den USA) OCPP; die Gen 3 und Gen 3 MID unterstützen es nicht und können sich nicht mit einem OCPP-Server verbinden. Dies wird von mehreren Drittanbieter-Plattformen bestätigt, die die OCPP-Integration verwalten (Plugchoice, Charge HQ): Charge HQ weist explizit darauf hin, dass kein Tesla-Wall-Lader (weder stationär noch mobil) derzeit OCPP unterstützt. PlugchoiceChargeHQ

Es gibt zwar Gerüchte in der Community (insbesondere rund um die App Monta), die behaupten, einen Gen 3 über OCPP verbinden zu können, aber dies sind inoffizielle und nicht zuverlässige Bastellösungen — die dokumentierte Position bleibt „nicht unterstützt“ für den Gen 3. Daher ist das OCPP-Protokoll für deine Ladestation auszuschließen.

2. Wie erhält Home Assistant dann die Informationen?

Überhaupt nicht über OCPP: Die Ladestation stellt lokal, in deinem Wi-Fi-Netzwerk, eine offiziell nicht dokumentierte HTTP REST API bereit (seit 2020 von der Community reverse-engineered). Sie antwortet ohne Authentifizierung auf Endpunkte wie http://<IP_der_Ladestation>/api/1/vitals, /api/1/wifi_status, /api/1/lifetime und /api/1/version. Tesla Motors Club

Der Endpunkt /api/1/vitals ist der reichhaltigste: Spannungen und Ströme pro Phase, Leistung, interne Temperaturen, Ladezustand, Daten der aktuellen Sitzung usw., einfach über einen Browser oder curl zugänglich und gibt ein vollständiges JSON-Objekt zurück. Tesla Motors Club

Die offizielle Integration « Tesla Wall Connector » von Home Assistant Core stützt sich genau darauf:

• verfügbar seit HA 2021.12, automatische Erkennung über das lokale Netzwerk möglich, sie stellt Entitäten wie die Gesamtenergie und die Energie der aktuellen Ladesitzung bereit. Home Assistant
• Seine « IoT-Klasse » ist « Lokale Abfrage » — also keine Abhängigkeit von der Tesla-Cloud, alles geschieht durch regelmäßiges Abfragen der lokalen IP der Ladestation. Home Assistant
• Technisch basiert sie auf einer kleinen dedizierten Python-Bibliothek, « tesla-wall-connector », die für den lokalen Verbrauch und die Integration mit Home Assistant entwickelt wurde und eine asynchrone API um diese Endpunkte herum bereitstellt.

Du kannst das übrigens selbst testen, ohne etwas zu installieren: Finde die lokale IP deiner Ladestation (Router oder Hostname wie TeslaWallConnector_XXXXXX.localdomain) und öffne http://IP/api/1/vitals in einem Browser.

3. Und die Steuerung (Start/Stop, Ampere)?

Da ist nichts möglich — diese lokale API ist strikt lesend.

Also im Moment kann ich nichts testen, aber ich verfolge das Thema ganz genau

[mutmut]

@Sescandell

Ich liebe es direkt in die Komplexität mit einer Multi-Connector-Verwaltung!

Manchmal lasse ich mich zu sehr mitreißen

[pierre-gilles]

Hallo @Sescandell,

Danke, diese Rückmeldungen sind super nützlich, ich nehme sie der Reihe nach auf.

Der « Öffnen »-Button: Du hast recht, das ist ein blinder Fleck. Dieser Link wurde für den Fall Frigate gedacht, bei dem ein veröffentlichtes Port eine zu öffnende Weboberfläche bedeutet. Dein Fall ist der erste, bei dem das veröffentlichte Port ein Endpunkt für Maschinen (deine Terminals) und nicht für einen Browser ist, und der Button leitet den Benutzer daher auf eine Fehlseite weiter. Die richtige Antwort ist ein Flag in der Portdeklaration im Manifest, um anzugeben: « Dieses Port ist nicht navigierbar, zeige keinen Link an ». Das ist eine kleine additive Änderung, ich werde sie zur Spezifikation hinzufügen und dann implementieren.

Das getHost(): Der Bedarf ist klar und ich möchte ihn abdecken, aber nicht in dieser Form, und ich erkläre warum. Dein Container kann die Adresse von Gladys nicht kennen, wie sie vom Terminal im LAN gesehen wird. Auf Serverseite kann man nur die Sicht vom Container (die Gateway der Brücke, den internen Alias…) auflösen, und Gladys selbst kennt seine eigene LAN-IP nicht zuverlässig (Multi-Interfaces, Reverse-Proxy, VPN…). Ein getHost() in der SDK würde daher oft einen falschen Wert zurückgeben, und ich bevorzuge keine API, die lügt.

Derjenige, der die richtige Adresse kennt, ist der Browser des Benutzers, der sich im LAN befindet. Es ist übrigens schon so, wie der « Öffnen »-Link aufgebaut ist. Der Ansatz, den ich verfolge, sind Platzhalter in den deklarativen Texten des Manifests, die vom Frontend bei der Anzeige aufgelöst werden: ein Block section, der zum Beispiel {{gladys_host}} und {{port:ocpp}} enthält, und der Benutzer sieht eine vollständige und kopierbare URL wie ws://192.168.1.50:32768. Das würde nebenbei den ersten Schritt deines 4-Schritte-Prozesses lösen: Er bleibt manuell, wird aber geführt. Einziger Nachteil, der bereits angenommen und bereits für den « Öffnen »-Link gültig ist: Wenn der Benutzer über einen Gladys Plus-Tunnel oder einen Reverse-Proxy navigiert, wird der angezeigte Hostname nicht die LAN-IP sein.

Das Anzeigedefizit des Selektors: Gut beobachtet, ich schaue mir das an!

[Sescandell]

Die V1 ist veröffentlicht.
Sie ist in ihren Fähigkeiten begrenzt: Sie kann derzeit nur Daten lesen, und zwar nur in der Version 1.6 von OCPP (das einzige Gerät, das ich für Tests zur Verfügung habe).

Getestet wurde nur an einem Typ von Ladestation (eine Autel Charge).

Ich werde mich in einem zweiten Schritt mit der Version 2.0.1 des Protokolls beschäftigen (Ende August)
Was Aktionen angeht… das wird sich zeigen, das hängt vielleicht von den Ladestationen ab. Wir werden auch versuchen, uns damit zu beschäftigen.

Ich bin offen für alle Arten von zusätzlichen Tests.

[pierre-gilles]

Top @Sescandell

Ich verlasse jetzt das Thema, da ich nicht mehr benötigt werde.

Falls dir Teile im Core für die weitere Entwicklung fehlen, zögere nicht, Demande de fonctionnalités zu erstellen, und ich werde sie mir ansehen!

Danke für die Entwicklung

[Mastho]

Hallo @Sescandell und danke für deine Arbeit an dieser Integration!

Ich habe auch eine Autel-Ladestation zu Hause und habe versucht, sie zu verbinden, aber ohne Erfolg. Wenn ich die Adresse von Gladys hinzufüge, durchläuft sie die drei Konfigurationsschritte und bleibt beim Verbindungstest im letzten Schritt stecken. Ich finde die Ladestation auch nicht im Tab „Entdeckung“ während und nach der Cloud-Konfiguration.

Hast du mehr Infos zum Hinzufügeprozess?

Nochmals danke!

[Sescandell]

Hallo,

Welche URL gibst du in deiner Anwendung ein?

Bei mir ist es: ws://:/

Der Port befindet sich hier (er wird bei dir anders sein):

Die ID meines Terminals hat bei mir das Format AEXXXXXXXXXXXXXXXX, wobei XXXXXXXXXXXXXXXX Zahlen und Buchstaben sind (ich habe sie aus den Einstellungen daneben).

Wie ist dein Netzwerkkontext? Bist du sicher, dass der Port in deinem Netzwerk von einer anderen Maschine aus erreichbar ist? Besonders, wenn du eine Firewall auf der Maschine hast, die Gladys ausführt, muss sichergestellt werden, dass der entsprechende Port geöffnet ist.

[Mastho]

Hallo,

Ich habe die im Konfigurations-Tab angegebene URL eingegeben, die den angegebenen Port korrekt enthält.

Bei mir: ws://plus.gladysassistant.com:43133/

Tatsächlich habe ich die Portfreigabe auf der Gladys-Maschine nicht überprüft.

Ich werde das beim nächsten Mal, wenn ich um Weihnachten herum zu Hause bin, überprüfen

Danke für deine schnelle Rückmeldung!

[Sescandell]

Das „Problem“ sollte hier liegen: Du solltest keine URL wie .gladysassistant.com eingeben, sondern die IP-Adresse deiner Gladys-Box in deinem lokalen Netzwerk. Normalerweise sind dein Router und deine Smart-Home-Box im selben lokalen Netzwerk.
Ist das der Fall?

[Mastho]

Ich dachte, das läuft über Gladys Plus, als ich diese URL in der Beschreibung gesehen habe.

Tatsächlich sollte es mit der IP besser funktionieren, da sie alle im selben Netzwerk sind.

Ich halte dich bei meinem nächsten Test auf dem Laufenden.

Danke für deine Hilfe!