ffreddow

Habe heute Serverseitig versucht genaueres rauszufinden, folgendes hab ich rausgefunden: zwei Geräte erzeugen Requests auf dem Server, die timing-mäßig zu deinem Fehler passen würden. Wenn ich Traffic für die beiden IPs mitschneide kriege ich für die eine ein Gerät, bei dem die WireGuard-Verbindung klappt und bei der anderen ein Gerät, bei welchem der Handshake Serverseitig klappt, aber danach sehe ich keine Keep-Alive-Pakete (sprich die Antwort vom Server kommt nicht durch) Ich vermute, dass du hinter der Ersten steckst, da es bei dir ja ein Gerät gibt, welches funktioniert. Das würde wiederum bedeuten, dass die Ausgehenden Pakete irgendwo verloren gehen. Wenn du mir deinen Internet-Anbieter steckst könnten wir das ganze verifizieren (gerne auch per PN). Du hast bei einer UDM pro doch bestimmt die Möglichkeit Pakete mitzuschneiden, oder? Könntest du mir einen Mitschnitt des UDP-Verkehrs von beiden Boxen mit my.warp-charger.com über 10 Minuten zukommen lassen? Am besten wäre es wenn du auch mitschneiden könntest was aus sicht deines Netzwerkes hinter dem NAT passiert.

Okay, schade. Es gab schonmal einen ähnlichen Fehler, der durch Neustart unserer Infrastruktur gelöst werden konnte. Laut den Logs ist das Problem, dass entweder der Server die WireGuard der Box Pakete nicht sieht oder die Pakete vom Server nicht zurück kommen. Kannst du von der "heilen" Box auch einmal einen Debug-Report ziehen und mir schicken? Seit wann bestehen die Probleme und gab es kurz vorher eine Veränderung an z.B. deinem Router?

Hallo Markus, guck mal bitte nach, ob das Problem immer noch besteht.

@cord Es gab einen Fehler in der Migration vom Authentication zum Users Modul, der nur den Energy-Manager v1 betrifft. Mit der nächsten Firmware ist der Fehler behoben.

Ist gefixt 👍

Moin, das ist nen bekanntes Problem und wird mit der nächsten Firmware gefixt

Okay, danke. Scheinbar bist du der Erste, der die App nutzt um sich zu registrieren 👀 Der Funktionsaufruf für den Download der Datei innerhalb der App fehlt nämlich einfach... (Ich habs verbrochen) Kommt mit der anderen Änderung zusammen.

Moin, stimmt, das nachträgliche Herunterladen existiert aktuell nicht. Da die grundsätzliche Funktionalität der Recovery-Datei schon existiert ist das kein großes Hexenwerk. Liefere ich heute im Tagesverlauf nach. Beim initialen Herunterladen konnte ich bis jetzt noch kein Gerät bei uns finden, bei dem es auch kaputt ist. Welche iPadOS/Safari Version hat dein iPad denn und hast du irgendwelche Plugins installiert?

Moin, das ist in dem Fall ein Server-Problem gewesen. Kurz gesagt haben wir uns beim Umreißen der Infrastruktur zwischen den Jahren Instabilitäten eingetreten. Der Fix kommt heute.

@sfancy , du vermutest richtig. Es gibt noch die Bedingung, dass kein Auto angesteckt sein darf, wenn der Ladelog versendet wird. Das Ladelog am 2. zu versenden war die erste Idee, aber da man z.B. übers Wochende das Auto durchaus auch mal länger angesteckt lassen könnte, haben @rtrbt und ich uns dagegen entschieden. Das ganze sollten wir allerdings besser im Webinterface kommunizieren. Das wird dann wohl mein nächstes 5 Minuten Projekt :)

Mahlzeit zusammen, in den letzten Wochen haben wir an einer zentralen Nutzerverwaltung und einem zentralen Ladetracker gearbeitet. Damit besteht die Möglichkeit, Benutzer und NFC-Tags zentral auf dem Lastmanager anzulegen, Ladevorgänge per Tag beim Lastmanager zu autorisieren, sowie Ladevorgänge zentral auf dem Lastmanager zu tracken. Außerdem haben wir die Latenz des Lastmanagements deutlich gedrückt, wenn ein Auto angeschlossen wird. Konfiguriert werden kann es über die Lastmanager-Konfiguration. Die Nutzer und NFC-Tags werden wie gewohnt (aber nur noch auf dem Lastmanager) hinzugefügt. Bekannte Probleme sind: Die lokale Benutzerfreigabe muss deaktiviert werden Gelöschte Wallboxen mit getrackten Ladungen haben keinen Namen Beim Neustart des Lastmanagers werden alle laufenden Ladungen abgebrochen Der Email-Versand von großen Ladelogs funktioniert unter Umständen nicht Exportierte Ladelogs verraten noch nicht von welcher Wallbox die Ladung stammt Das UI ist noch nicht voll ausgereift Beide Features sind vorerst nur für WARP2 und WARP3 verfügbar. Auf dem Energy Manager werden wir beide Features zeitnah nachreichen. Für WARP1 ist das noch unklar, da gerade das Tracken der Ladevorgänge für mehrere Wallboxen und die damit verbundene Generiung von PDF- und CSV-Ladelogs recht RAM-Intensiv ist. Wir freuen uns auf euer Feedback und wünschen frohe Weihnachten! Edit: Veraltete Firmware-Dateien entfernt.

Hi, aktuell ist jemand mit der selben E-Mail, mit der du hier im Forum registriert bist, beim Fernzugriff registriert. Ich kann leider nicht sehen seit wann. Falls du dein Passwort nicht mehr weißt kannst du es beim Login-Fenster zurücksetzen.

Die Log-Nachrichten deuten darauf hin, dass irgendwas zwischen deiner Box und dem Fernzugriffsserver ist, das UDP-Pakete frisst und hin und wieder durch lässt. Eventuell hilft uns deine Netzwerkstruktur da auf die Sprünge. Was hast du z.B. für einen Router und Internetanbieter, hast du andere Geräte, die viel UDP ins internet quasseln oder sonstige Probleme mit deinem Internet? Ein erster Versuch wäre es eine Port-Weiterleitung für Port 51820/UDP an deine Wallbox einzurichten.

Die Grundfunktionen laufen alle auf der Box selber. Dass sowas wie Day-ahead preise über unsere Server abgefragt werden müssen hängt mit der Lizensierung zusammen. Wir dürfen die Preise zwar bei der Strombörse abfragen, dürfen sie aber nur innerhalb unseres "geschlossenen" Systems weitergeben. Es gab intern bereits die Diskussion, ob wir das ganze konfigurierbar machen sollen (Kunden können ihre eigene Lizenz kaufen und eintragen), haben uns aber aufgrund des Aufwands und des dann doch nur sehr begrenzten Nutzen dagegen entschieden. Und last but not least sind wir immer noch komplett Open-Source, sprich sollte es uns irgendwann nicht mehr geben ist alle Software immer noch auf Github verfügbar. Es müsste sie nur jemand anderes betreiben ;)

Wir haben aktuell Probleme mit dem Fernzugriffsserver. Dementsprechend funktionieren alles, was Anfragen gegen unsere Server machen muss nicht (Fernzugriff, Dynamische Strompreise, Solar-forecast und automatische Firmwareupdates). Wir sind dran und das ganze sollte im laufe des Tages wieder laufen