the_muck

danke, das hats einfacher gemacht! Klappt nun wie gewollt... Wenn man die Logic hinter den Slots verstanden hat macht es auch etwas Sinn :D. Danke für die schnelle Rückmeldung!

Okay, Ihr bereitet ja die Meldung "erlaubter Ladestrom" auf. Da steht ja drin was Gerade blockiert. Mir fehlt gerade die Idee wie ich es extern aufbereiten könnte das klar ist ob die Box über NFC oder EVCC Blockiert ist.

Hallo, Die statusanzeige hat ja die Mögichkeiten... Warte auf Freigaben, Ladebreit, Lädt... unter erlaubter Ladestrom wird angezeigt ob durch Externe Steuerung oder NFC Tag der Strom Blockiert ist. Ist es das, steht da "Warte auf Freigabe" im Status. Dadurch ist keine Unterscheidung im Status möglich ob die Box über den NFC Tag Freigeschaltet ist weil beides als Freigabe interpretiert wird. IMHO würde es mehr Sinn machen wenn der Box Status über NFC auf Ladebereit wechselt. Wenn NFC OK, und EVCC Blockiert. Der Status der Box ist dann ja Ladebereit? Warum das gehampel... wir haben ein eigenes Tool zum einsammeln des Ladetrackings und die user können sich über die Webseite auch in die Box einchecken. Dazu gibt es ein Terminal wo man den Checkin erledigen kann, der button ändert seine Farbe als Rückmeldung ob der Checkin erfolgreich war. Ich denke aber es hat irgendwie seinen Grund warum das mit dem Status so ist :D. Kommt man denn an die Info aus dem Feld erlaubter Ladestrom? über die API/MQTT? Danke und Grüße Malte

Moin, mit den mitgelieferten Karten und tag_type 2 klappt das bei mir wunderbar! Ich schau nach dem inject auch noch nach ob das erfolgreich war... Prüfe auf tagid und lastseen.

Danke noch mal für die Unterstützung und den Support! Jetzt können wir uns das gehampel mit den Ladekarten sparen und buchen uns über die Weboberfläche auf die WB. War etwas gefummel das auch mit EVCC zu verknüppeln aber jetzt läuft es.

Super Dankeschön.

Was mir aufgefallen ist, es wäre sehr nett wenn man mit der API so arbeitet, das eindeutig wird welche ID Zu welchem Benutzer zur welchem NFC Tag gehört. Das ist irgendwie Umständliche in der Wallbox GUI das heraus zu finden weil nirgends die ID erscheint. Man kann annehmen das es auf der Benutzer Seite nach IDs geht, okay. Aber irgendwie finde ich das mühsam...

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.

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 😊

Hallo, kann man den Warp2 so einrichten das ich den Ladevorgang (mit Benutzer tracking) nicht nur über NFC sondern auch über Externe Steuerung Starten kann. Die Idee ist auf einem NodeRed Dachboard einfach die Benutzer anzuzeigen und über einen Start button kann man auswählen zu welchen Benutzer der Warp2 intern buchen soll.

Moin, und danke. ich hab da wohl an der falschen stelle geschaut :/ https://www.warp-charger.com/warp2.html und hier ganz unten ist wohl die richtige FW.

Doofe Frage... die Firmware gibt hier: https://github.com/Tinkerforge/warp-charger/tree/master/firmwares Schnappe ich mir die letzte FW lade sie hoch bekomme ich :"Aktualisierung fehlgeschlagen Firmware-Datei passt nicht zu diesem Wallbox-Typ" Aktuell habe ich FW: 2.0.7-62a1f99c

Hallo in die Runde, ich habe ihr eine Wallbox von tinkerforge und würde jetzt gerne mit den Modulen eine kleinen Heizstabregelung mit Schwingungspaketsteuerung bauen. Fronius Ohmpilot und my-pv arbeiten dabei IMHO mit einem Thyristor-Leistungssteller auf einer Phase und die beiden anderen Phasen werden über "Relays" zugeschaltet. Meine Idee ist es für eine Phase so einen Steller zu verwenden, oder ähnliche Geräte. https://www.chiemtronic.de/produkte/t-drive-1ph-compact-maxi/ und die 2 Phasen über Einfache 16A Relais zu schalten. Der Stellgrad soll einfach in 0-100% über MQTT kommen. ESP32 Ethernet Brick Industrial Analog Out Bricklet 2.0 Industrial Dual AC Relay Bricklet ESP32 Power Supply Mit den Komponenten sollte ich da ja eigentlich hinkommen? Bis dato hatte ich mit dem ESP32 nur Berührung in Kombination mit der Arduino Umgebung. Müsste mich da wohl einarbeiten.

Gibt es dazu eigentlich irgendwo was offizielles. Würde ja bedeuten das wen ein LS auslöst das Ladegerät auch beschädigt werden kann. Ich finde in den Montagehandbüchern auch nicht das Allpolig trennende LS verbaut werden müssen.

Vielleicht verstehe ich euer Setup nicht. Aber bei uns hängt keine der 5 WB an der Hauptverteilung des Netzzuganges, in jedem fall hängt eine Unterverteilung dazwischen. In 3 von den 5 Unterverteilung ist der Platz schon arg begrenzt. Man bedenke das da fast ein ganzes Feld bei drauf geht für die Umschaltung + LS, das muss man auch erstmal haben... So löblich es ist dem Elektriker Platz zu geben, die Nachteile der Dezentralen Anbindung überwiegen da gerade für mich... andere bekommen das ja auch unter. Ich gehe mal davon aus das der WARP Energy Manager an den Hauptanschluss soll.