Ladetracking Backup und Globale NFC Freischaltung

[the_muck]

Hallo, 

Wir haben insgesamt 5 Warp2 und es werden wohl noch mehr. Was uns aktuell fehlt ist eine Backup Strategie der einzelnen ladetracker und das zusammenführen der Daten der einzelnen Boxen über den Definierten NFC Tag. Dazu wäre es super wenn die Boxen in einer Art globalen Datenbank sich die Freigabe holt damit wir nicht die Benutzer in jeder Box einzeln anlegen müssen. Aber auch das die Tracker immer den NFC Tag zur Auswertung mit schleppen.  

Ich bekomme die letzte 30 Einträge ohne NFC Tag über die API, kann aber den aktuellen Ladevorgang mit Tag identifizieren wenn ich die API richtig interpretiere. Wenn die IDs dann aber nicht zum NFC Tag passen wird's ne krumme Geschichte.

 

Vielleicht habe ich hab was übersehen und da gibt's schon was 😊

[MatzeTF]

Eine zentrale NFC-Freigabe und Einsammeln von Ladeprotokollen stehen beide auf unserer Wunschliste, existieren aber leider noch nicht.

Zum automatischen Einrichten von Nutzern und NFC-Tags auf neuen Wallboxen habe ich hier schon mal ein einfaches Script gepostet. Das kann man aber nur für ganz neue Wallboxen benutzen, auf denen noch nie ein Benutzer eingerichtet war.

Wenn du nur ein Backup von allen Ladevorgängen haben möchtest, kannst du automatisiert das Ladeprotokoll als PDF runterladen. Wenn du sowieso auf Höhe der API unterwegs bist, kannst du einfach von jeden Wallbox regelmäßig http://warp2-abc/charge_tracker/pdf runterladen. Das PDF ist natürlich nicht maschinenlesbar. Maschinenlesbar über die API gibt es das Ladeprotokoll aktuell nur als Binärblob, den du selber umrechnen müsstest. Dokumentation davon hier.

[the_muck]

Danke für den Tipp mit der API ich habe mal mit KI ein Tool zusammen gestrickt... Das funktioniert als Trockenübung mit zwei boxen erstmal soweit. Wenn man nun die WB dazu bewegt ne anfrage über den NFC Tag zu schicken und ob die WB einem user zugeteilt ist könnte darüber ja die Identifizierung starten :D. 

 

# Programmzusammenfassung: Wallbox Charge Log Viewer

## 1. Programmfunktionalität

Diese Anwendung ist ein Web-basiertes Tool (entwickelt mit Flask in Python) zur Erfassung, Verwaltung und Anzeige von Ladevorgängen von Elektrofahrzeug-Ladestationen (Hosts/Wallboxen).

**Hauptfunktionen:**

*   **Datenerfassung:**
    *   Ruft Ladedaten (Charge Logs) von konfigurierten Hosts über deren IP-Adresse ab.
    *   Speichert die abgerufenen Ladedaten in einer lokalen SQLite-Datenbank.
    *   Ermöglicht manuellen und automatisierten (geplanten) Datenabruf.

*   **Datenanzeige und -auswertung:**
    *   **Benutzerbezogene Ansicht:** Zeigt Ladevorgänge gefiltert nach "tatsächlichen Benutzern" an.
        *   Ermöglicht Filterung nach Jahr und optional nach Monat innerhalb eines Jahres.
        *   Berechnet die Gesamtmenge der geladenen Energie (kWh) pro Benutzer basierend auf den Filtereinstellungen.
        *   Bietet eine Funktion zur Berechnung der Kosten basierend auf einem anpassbaren kWh-Preis (diese Kosten werden auch in der Weboberfläche angezeigt).
        *   Ermöglicht den Export der benutzerbezogenen Ladeübersicht als PDF-Datei und als CSV-Datei, jeweils unter Berücksichtigung der aktiven Filter. Die CSV-Datei enthält ebenfalls eine Spalte mit den berechneten Kosten pro Ladevorgang, basierend auf dem zum Zeitpunkt des Exports in der Weboberfläche eingegebenen kWh-Preis.
    *   **Hostbezogene Ansicht:** Zeigt Ladevorgänge für einen einzelnen, ausgewählten Host oder für alle Hosts kombiniert an.
        *   Zeigt den zugeordneten "tatsächlichen Benutzer" an, falls ein Mapping existiert.
        *   Zeigt die Gesamtmenge der geladenen Energie (kWh) für die jeweilige Ansicht.

*   **Benutzer- und Host-Verwaltung (Konfiguration):**
    *   **Hosts Verwalten:** Hinzufügen, Bearbeiten (Name, IP-Adresse) und Löschen von Hosts (Ladestationen).
    *   **Benutzer Verwalten:** Hinzufügen, Bearbeiten (Benutzername, NFC-Tag) und Löschen von "tatsächlichen Benutzern".
    *   **Benutzer-Host-Mappings:** Zuordnung von "tatsächlichen Benutzern" zu lokalen Benutzer-IDs auf spezifischen Hosts. Dies ermöglicht die korrekte Zuordnung von Ladevorgängen zu den tatsächlichen Personen.

*   **Automatisierte Aufgaben (Scheduler):**
    *   **Geplanter Datenabruf:** Konfiguration von automatischen Abrufen der Ladedaten von allen Hosts (täglich, wöchentlich, monatlich zu einer bestimmten Uhrzeit).
    *   **Geplante Datensicherung:** Konfiguration von automatischen Sicherungen der SQLite-Datenbank (täglich, wöchentlich, monatlich zu einer bestimmten Uhrzeit) auf einen angegebenen (Netzwerk-)Pfad.
    *   Die Konfigurationen für diese geplanten Aufgaben werden persistent in der Datenbank gespeichert und überleben Anwendungsneustarts.
    *   Manuelles Auslösen und Entfernen der geplanten Aufgaben ist über die Weboberfläche möglich.

*   **API-Endpunkte:**
    *   `/api/user_by_nfc/<nfc_tag_id>`: Gibt Benutzerdetails (ID, Name, NFC-Tag) und die zugeordneten Hosts für einen gegebenen NFC-Tag zurück.
    *   `/api/check_access_by_nfc/<nfc_tag_id>`: Überprüft, ob ein Benutzer mit dem gegebenen NFC-Tag Zugriffsberechtigung für einen Host hat, basierend auf der anfragenden IP-Adresse.

*   **Datenbank:**
    *   Verwendet eine SQLite-Datenbank (`charge_logs.db`) zur Speicherung aller relevanten Daten.

## 2. Datenbankstruktur (`charge_logs.db`)

Die Datenbank besteht aus den folgenden Haupttabellen:

*   **`charge_logs`**: Speichert die einzelnen Ladevorgänge.
    *   `id` (INTEGER, PRIMARY KEY, AUTOINCREMENT): Eindeutige ID des Ladevorgangs.
    *   `host_name` (TEXT, NOT NULL): Name des Hosts (Ladestation), von dem der Log stammt.
    *   `timestamp_unix` (INTEGER): Zeitstempel des Ladevorgangsbeginns (Unix-Timestamp).
    *   `timestamp_readable` (TEXT): Menschenlesbarer Zeitstempel des Ladevorgangsbeginns.
    *   `kwh_start` (REAL): Zählerstand (kWh) zu Beginn des Ladevorgangs.
    *   `user_id` (INTEGER): Lokale Benutzer-ID auf dem Host.
    *   `duration_seconds` (INTEGER): Dauer des Ladevorgangs in Sekunden.
    *   `kwh_end` (REAL): Zählerstand (kWh) am Ende des Ladevorgangs.
    *   `charge_amount_kwh` (REAL): Geladene Energiemenge (kWh).
    *   `UNIQUE(host_name, timestamp_unix, user_id, kwh_start)`: Stellt sicher, dass jeder Ladebucheintrag pro Host, Zeit, Benutzer und Startwert eindeutig ist.

*   **`hosts`**: Speichert Informationen über die konfigurierten Hosts (Ladestationen).
    *   `id` (INTEGER, PRIMARY KEY, AUTOINCREMENT): Eindeutige ID des Hosts.
    *   `name` (TEXT, UNIQUE, NOT NULL): Eindeutiger Name des Hosts.
    *   `ip_address` (TEXT, NOT NULL): IP-Adresse des Hosts.

*   **`actual_users`**: Speichert die "tatsächlichen Benutzer" der Anwendung.
    *   `id` (INTEGER, PRIMARY KEY, AUTOINCREMENT): Eindeutige ID des Benutzers.
    *   `actual_user_name` (TEXT, UNIQUE, NOT NULL): Eindeutiger Name des Benutzers.
    *   `nfc_tag` (TEXT): Zugehöriger NFC-Tag des Benutzers (optional).

*   **`user_host_mappings`**: Verknüpft "tatsächliche Benutzer" mit lokalen Benutzer-IDs auf spezifischen Hosts.
    *   `id` (INTEGER, PRIMARY KEY, AUTOINCREMENT): Eindeutige ID des Mappings.
    *   `actual_user_id` (INTEGER, NOT NULL, FOREIGN KEY REFERENCES `actual_users(id)` ON DELETE CASCADE): ID des tatsächlichen Benutzers.
    *   `host_id` (INTEGER, NOT NULL, FOREIGN KEY REFERENCES `hosts(id)` ON DELETE CASCADE): ID des Hosts.
    *   `local_user_id` (INTEGER, NOT NULL): Die Benutzer-ID, die dieser tatsächliche Benutzer auf dem spezifischen Host hat.
    *   `UNIQUE (actual_user_id, host_id, local_user_id)`: Stellt die Eindeutigkeit der Mapping-Kombination sicher.

*   **`apscheduler_jobs`**: (Wird automatisch von APScheduler erstellt und verwaltet)
    *   Speichert die Konfigurationen der geplanten Aufgaben (Datenabruf, Datensicherung). Die genaue Struktur wird von APScheduler und SQLAlchemyJobStore definiert.

**Beziehungen:**
*   Ein `actual_user` kann mehrere `user_host_mappings` haben (z.B. für verschiedene Hosts oder verschiedene lokale IDs auf demselben Host, obwohl letzteres unüblich sein sollte).
*   Ein `host` kann in mehreren `user_host_mappings` vorkommen.
*   `charge_logs` sind über `host_name` und `user_id` (lokale ID) mit den Mappings und somit indirekt mit `actual_users` verbunden.
*   Fremdschlüssel mit `ON DELETE CASCADE` sorgen dafür, dass beim Löschen eines Benutzers oder Hosts auch dessen zugehörige Mappings entfernt werden.

Für uns jetzt ganz praktisch das wir einfach zur Abrechnung gleich alle Daten haben und für Jahr Monat ne PDF / CSV erstellen. Das Spart schon etwas Arbeit, und finde ich aktuell sehr viel übersichtlicher. 

bearbeitet June 4, 2025 at 20:47 von the_muck