ffreddow

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! warp2_firmware_2_8_16_69495ab3_4a571754474b8b8_feature-central-user-management-6_merged.bin warp3_firmware_2_8_16_694959d6_4a571754474b8b8_feature-central-user-management-6_merged.bin

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

Moin, wir haben in der aktuellen Firmware Version ein Problem, dass einige Dinge, die Internet erfordern nicht mehr funktionieren wenn der Ping höher als 50ms ist. Das Problem wird in der nächsten Firmware gefixt. Kannst du einmal einen Debug Report ziehen und mir schicken (Gerne per PN)?

Moin, ich kann mich dunkel erinnern, dass ich nen ähnliches Problem in den Anfängen des Fernzugriffs hatte. Beim draufstarren grade sind mir aber keine besonders großen Header von der Wallbox aufgefallen. Passiert das schon beim laden vom Webinterface oder nur wenn du eine bestimmte Aktion ausführst? Edit: Ich kann scheinbar nicht richtig lesen. @photron hat mich darauf hingewiesen, dass das Problem darin liegt, dass die Wallboxen und Energy Manager aktuell nur einen 2k Buffer für die Header haben. Ein fix dafür ist möglich, aber relativ Zeitaufwendig. Eine Möglichkeit wäre einen reverse Proxy einzurichten und damit die auf unserer Seite nicht benötigten Header zu entfernen.

Interessant, 51821 wird in jedem Fall benutzt wenn eine Verbindung über den Fernzurgiff aufgebaut wird. Vielleicht ist dein Router/ISP auch einfach sehr aggresiv, was das schließen von UDP "Verbindungen" (technisch gesehen gibt es die nicht) angeht. Über die Management Verbindung werden nur alle paar Sekunden Pakete hin und her geschickt um das "Loch" in der Firewall offen zu halten. Auf den anderen Ports herrscht viel mehr Verkehr, deshalb werden die eventuell nicht geschlossen. Welchen Router und ISP nutzt du, wenn ich fragen darf?

@Ben77 sorry, ich hatte mich verlesen. Du hattest nach port 51820 TCP gefragt, der wird nicht benutzt. War das nen Tippfehler von dir oder hat das Freigeben von 51820 TCP tatsächlich ein Problem gelöst?

Genau, die Box muss auf 51820 - 51825 UDP raus können. 51820 ist für die Management Verbindung über die die Box aufgefordert wird Verbindungen auf zu machen und die restlichen ports sind für die bis zu fünf Verbindungen, die wir gleichzeitig erlauben. Normalerweise macht WireGuard das Hole-punching von selber, nur wenn man ausgehenden traffic explizit verbietet sollte es da zu problemen kommen. Die Ports müssen dauerhaft erlaubt sein, aber es muss kein Portmapping gemacht werden.

Das heißt der fix, den ich gestern eingebaut habe funktioniert erstmal grundlegend. Manchmal muss sich erst jemand beschweren ;) Kannst du mal die App in den debug modus bringen (Nutzer->Lokale einstellungen-> Debug modus) und wenn es dir zu lange dauert den PCAP-Log speichern (Der Knopf, der unter der Darstellung des Webinterface auftaucht) und mir per PN schicken? Bitte in Sitzungen von denen du einen PCAP-Log erstellst keine Passwörter o.ä. eingeben, da dabei der rohe unverschlüsselte Datenverkehr mitgeschnitten wird und die dementsprechend da drin auftauchen würden. Die funktion haben wir absichtlich deaktiviert, weil wir uns dadurch regelmäßig unbeabsichtigt die Verbindungen geschlossen haben. Da ist und wohl nen Link durch die Lappen gegangen. Normalerweise wollen wir alle externen Links aus der App raus halten, damit sowas nicht passiert. Das ist allerdings etwas, was erst durch ein Firmware-Update gefixt werden kann, da das Webinterface von der Wallbox geladen wird.

Dass die Verbindung neu geladen wird nachdem die App aus dem Hintergrund wieder kommt ist gewollt. Wir hatten Probleme mit Apps, die sporadisch tot waren als sie aus dem Hintergrund kamen und die gesamte App einmal neu zu laden war das einzige was erstmal Abhilfe geschaffen hat. Deinen Usecase hatten scheinbar weder ich noch jemand anderes, der die App bis jetzt genutzt hat. Trotzdem ist das etwas was funktionieren darf und ich werde nochmal Zeit in die Suche nach einer alternative zur einfachen Hau-Drauf-Lösung stecken müssen. Ein Bug dem selben Effekt ist uns bekannt und ist seit kurzem gefixt. Wann hattest du das Problem denn das letzte mal?

Moin, danke für den Hinweis! Wir haben das Problem auch schon bei der Android App festgestellt und versuchen aktuell es zuverlässig zu reproduzieren. War das Menü schon weg bevor du dich zur Wallbox verbunden hast? Und hast du dich direkt davor in der App eigeloggt? Edit: Haben das Problem gefunden und behoben. Kann sein, dass du die App einmal komplett schließen und wieder neu öffnen musst.

Hattest du den Fernzugriff auf der Box schonmal eingerichtet? Habe eben nen Bug gefixt, bei dem sowas passiert wenn man die Box aus dem Fernzugriff nimmt und wieder hinzufügt ohnen neuzustarten. Du meinst das Passwort der Nutzer lokal auf der Wallbox? Wir hatten irgenwann mal nen Autologin für die App diskutiert und es dann aber erstmal beiseite gelegt, weil es doch die ein oder andere Fußangel mit sich gebracht hat. Vielleicht muss man das nochmal aus der Schublade holen.

Moin, vermutlich wird das daran liegen. Der Fernzugriff ist was die Netzwerkqualität angeht leider recht sensibel. Ich gehe mal davon aus, dass der reine Verbindungsaufbau klappt, aber das laden des Webinterfaces ziemlich lange dauert. Wie lange hast denn gewartet? Eventuell wäre es auch eine Idee die Animation zu wechseln wenn der Verbindungsaufbau erfolgreich war und das Webinterface geladen wird. Erkennen, dass man sich im Heimnetzwerk befindet ist schwierig bis unmöglich, da jedes Heimnetz anders aussieht. Man könnte eventuell versuchen den auf der Wallbox konfigurierten Hostnamen lokal aufzulösen. Ich rieche aber schon Probleme wenn man sich in öffentlichen Netzen befindet, da muss ich mit den Kollegen mal drüber quatschen wenn die aus dem Urlaub wieder da sind.

E-Mail-Adressen sind komplizierter, als sie aussehen: Grundsätzlich sind sie Case-Sensitiv, ABER sie können case-insensitiv verglichen werden, was wir auch tun (aBc@c.de ist aus Sicht des Servers das gleiche wie abc@c.de). Dass wir diese Konvertierung machen müssen hab ich beim schreiben der Account-Synchronisierung und der Tests übersehen/vergessen, was dazu führt, dass der Server in deinem Fall dachte, dass er den Nutzer nicht kennt und die Wallbox hat ihn darauf hin rausgeschmissen. Vor dem Update hat es keinen Unterschied gemacht, da die Account-Synchronisierung noch nicht existierte. Danke für die Rückmeldung mit dem Workaround, das hat mir einiges an Sucherei erspart 😅 TL;DR: Es sollte auch weiterhin funktionieren, ist aber einfach auf unserer Seite kaputt.

Moin, das ist natürlich gelinde gesagt äußerst unschön. Ich konnte zu deiner Wallbox auch keinen zugeordneten Nutzer auf dem Server finden. Hab sie jetzt vom Server entfernt, versuch bitte mal den fernzugriff zu deaktivieren, dann neustarten und nochmal wieder hinzufügen. Werde mich derweil auf die Suche nach der Ursache begeben.

Der Knopf taucht erst auf wenn der Slot blockiert

Moin, wir sind noch auf einige Bugs speziell mit/in der App gestoßen, die das ganze Verzögert haben. Aktuell laufen wieder Tests, wenn diese erfolgreich sind gehts weiter.

Eine richtige Nutzerverwaltung im Webinterface der Wallbox wird schwiering, da wir dafür erst Role Based Access Control auf der Wallbox selber implementieren müssten. Eine Nutzerverwaltung für den Fernzugriff ist geplant, ergibt aber erst wirklich Sinn sobald mehrere Nutzer Fernzugriff auf eine Box haben. Was genau meinst du mit Standorte? Einfach ein Freitext-Feld zum notieren des Standortes? Normalerweise bewegt sich so eine Wallbox in ihrem Leben ja nicht ganz viel (Und falls doch wüsste ich gerne was du damit machst ;) ) Meinst du damit zum Anmelden der Wallbox beim Fernzugriff? Falls nein: Bei Jemandem, der die Wallbox ohne OCPP per API übers Internet steuern will würde ich jetzt einfach mal vorraussetzen, dass er weiß wie man den Nutzerkonfigurierbaren Wireguard-Zugang konfigurieren kann. Falls Ja: Für das Einrichten sobald es mehrere Fernzugriffsnutzer für eine Box gibt ist es tatsächlich eine gute Idee Einmalcodes zum Einrichten zu generieren. Bei aktuell einem Nutzer bietet es aus meiner Sicht wenig bis keinen Mehrwert, da sich intern sowieso jede Wallbox individuelle Zugangsdaten mit dem Server aushandelt und das Passwort nicht auf der Box gespeichert wird. Der Zugriff mit mehreren Nutzern auf eine Box sollte allerdings nicht mehr lange auf sich warten lassen, da das ein oder andere interne Projekt daran hängt und es dementsprechend eine recht hohe Priorität hat.

Das war so weit erwartet, da es (wie im Changelog im ersten Post beschrieben) brechende Änderungen gab. Vielleicht nochmal als kleiner Disclaimer, da es im Post nicht explizit drin steht (passe ich an): Der Fernzugriff sollte während er noch nicht in einer "offiziellen" Firmware veröffentlicht ist auf keinen Fall als einziger Zugang zur Wallbox benutzt werden, da es immer wieder zu brechenden Änderungen kommen kann (auch wenn wir versuchen das zu vermeiden). Das Hört sich doch super an! Dann hing der PDF-Bug wirklich wie erwartet mit den allgemeinen Safari-Problemen zusammen.

Das update ist ausgerollt

Wir haben in der Version, die aktuell auf dem Server ist nen Bug durch den Daten von Safari nicht richtig verarbeitet werden. Das Update mit dem Fix wird heute im laufe des Tages ausgerollt. Versuch es dann bitte nochmal mit Safari. Bitte beachte auch, dass du die Firmware der Wallbox ebenfalls updaten musst!