Differences

This shows you the differences between two versions of the page.

--- ladeloesung [2026/02/01 18:12] – [Standard Ladelösung] andi
+++ ladeloesung [2026/02/01 22:44] (current) – [Elektrisch] admin
@@ Line 12: / Line 12: @@
 {{:charger_original.png?400|}}
   * Die Ladegeräte sind durch ein Datenkabel mit dem BMS verbunden. Protokoll ist unbekannt. Ladevorgang scheint Kollaboration zwischen BMS und Ladegerät (z.B. Steuerung der Strombegrenzung). Ladegerät wird nur aktiviert bei vorhandener Datenverbindung (und deaktiviert, wenn die Datenverbindung getrennt wird).
-  * Wenn nicht aktiv, ist das Ladekabel mechanisch getrennt (Relaiskontakt)
+  * Wenn nicht aktiv, ist das Ladekabel mechanisch getrennt (normally open Relaiskontakt).
   * Der Ladeprozess wird automatisch gestartet (BMS ein, Ladegerät verbunden) und endet immer bei 100%.
   * Wenn volle Batterie eingesteckt bleibt, wird wahrscheinlich eine Erhaltungsladung gemacht (TBV. wie? periodisch? Zwischendurch auch getrennt?)
@@ Line 44: / Line 44: @@
+===== Architektur =====
+==== Elektrisch ====
+Steuerung ist in die Einheit eingebaut und hat folgende elektrische Funktionen:
+{{:charger_steuerung.png?400|}}
+**Aktivierung/Deaktivierung Ladevorgang**
+  * **Charger Schalter:** Damit kann das Ladegerät von der Steckdose getrennt werden. Unter der Annahme, dass dabei das Relais im Ladekabel aufgeht.
+  * **BMS Comm (Nur Trennung RX):** Bewirkt ebenfalls das Öffnen des Relais im Ladekabel (kontrollierter, als einfach die Speisung abzuklemmen?).
+**Erkennung/Verfolgung des Ladezustands**
+  * **Ohne Unterstützung**: basiert alleine auf Zeitschaltung und Informationen von Bediener.
+  * **BMS Comm (Trennung RX, abhören RX, allenfalls Übernahme TX):** Mit reverse engineering des Protokolls, könnten Batterieinfos vom BMS abgehört/abgefragt werden. Auch Informationen zum Ladevorgang sollten hier verfügbar sein.
+  * **Spannungsmessung:** Alternativer Weg, zu Batteriespannungs-Infos zu kommen ohne Protokoll-Analyse. Nachteil: Eigene Messung kann divergieren von BMS-Messung.
+--> HW Design sollte evtl. alle Möglichkeiten vorsehen.
+==== Bedienung ====
+=== UI Lokal ===
+== Controls ==
+Controls für Request sollten zustandsfrei sein, also zum Beispiel 3 Taster (Full, Storage, Abort).
+== Anzeigen ==
+LEDs? Welche Zustände sind nötig? Ladestand ist auf den BMS Displays verfügbar, also braucht es vielleicht nur die Unterscheidung der Zustände gemäss Diagramm unten.
+=== Remote ===
+== Vernetzung ==
+WIFI Modul? (Anfrage bei Roger hängig bezüglich Leerrohren zw. Clubhaus und Hangar für Installation Access Point in Hangar)
+== API ==
+Eine RESTful API würde sich anbieten. Absetzen von Requests sowie Anzeige von Zustand, evtl. Ladestand und Logs.
+Komplexere Funktionalitäten (Scheduling/Einbindung Reservationssystem) würden dann komplett auf Intranet implementiert.
+==== Software ====
+Die Steuerung kann Ladeprozesse unabhängig und selbstständig zu Ende führen. Zum starten eines Ladeprozesses braucht es einen Request - entweder von einem lokalen UI oder von remote.
+{{:sm_request.png?400|}}
+Das Zustandsdiagramm zeigt, wie die Steuerung auf Requests reagiert (grüne Pfeile) und wie sie den Ladevorgang zu Ende führt (schwarzer Pfeil). Dieses Design kann nicht zwischen lokalen und remote-Requests unterscheiden. Die entsprechenden Kontrolleinheiten (UI oder remote) müssen selber stateless sein, und dürfen nur einzelne Requests absenden. Insbesondere darf die Remote-Applikation nicht versuchen, einen lokal abgebrochenen Prozess wieder zu starten.