Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.391
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Posts erstellt von rtrbt

  1. Moin,

    EVCC kann Ladungen derzeit noch nicht Nutzern zuordnen, Gedanken zur Implementierung gibt es aber bereits: https://github.com/evcc-io/evcc/discussions/3190

    Die Nutzerzuordnung läuft aber derzeit nur über NFC (bzw. über gefakte NFC-Tags über die API, das benutzt EVCC dann auch). Da die WARP1 Smart kein NFC-Bricklet hat (du kannst dir aber eins nachrüsten ;) ), kannst du erstmal keine Ladungen zu Nutzern zuordnen. Da wird es künftig aber sicherlich irgendeine Lösung geben. Habe dafür mal ein Issue aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/133

    • Like 1
  2. Hm da liest man seine eigenen Posts und merkt dass man Schwachsinn geschrieben hat. Bei WARP1 kann man das Bricklet schlecht an die Seitenwand kleben, da ist der Berührschutz im Weg. Wenn das Bricklet hinter dem Deckel ist, z.B. oben oder unten links, dann kann es ganz gut NFC-Tags lesen, die von oben bzw. unten an die Wallbox gehalten werden. Am besten machst du das Bricklet erst einmal temporär fest und probierst, ob die Tags gefunden werden. Das geht nach einem Neustart der Wallbox ohne Konfiguration, die LED in der Frontplatte blinkt mit dem "Tag nicht bekannt"-Muster wenn du irgendwelche Tags dranhältst.

  3. 13 hours ago, int5749 said:

    Die interne Abdeckplatte habe ich noch nicht gefunden, aber eigentlich braucht es diese doch gar nicht, beim Einbau eines Zählers? Es würde doch ausreichen aus dem Kunststoff die entsprechende Stelle rauszu"fräsen"? Denn wasserdicht ist die doch auch nicht, oder?

    Das stimmt die Platte gibt es im Shop (noch?) nicht. Wenn du keine Lust auf Sägen hast kannst du, falls du Zähler und Bricklet bei uns bestellst, Bescheid sagen, dann legen wir dir eine Platte mit ins Paket.

  4. 17 hours ago, kmfrank said:

    Ein anderes Mal war der Akku voll. Gegen Abend plötzlich das buffen der Wallbox. Sie begann plötzlich der Ladevorgang erneut, was aber nicht gewünscht war. Leider kann ich den genauen Zustand der Wallbox nicht mehr sagen. Derzeit möchte ich kein automatisches starten der Ladung, weil ich händisch PV-Überschussladen tätige. Habe aber keine Lust den Golf nach der Ladung extra abzustecken. Gibt es eine passende Einstellung für meinen Wunsch?

    Da hat dein Golf von sich aus entschieden, wieder zu laden. Alle Freigaben die die Wallbox macht (also z.B. Lastmanagement, NFC, Auto-Start usw.) bleiben freigegeben, bis entweder das Auto abgezogen wird oder die Freigabe widerrufen wird. D.h. wenn du händisch PV-Überschussladen machst, dann musst du auch händisch wenn die Sonne nicht mehr scheint die Freigabe wieder wegnehmen, eben durch Tag nochmal an die Box halten, im Webinterface auf Stop klicken, über die API usw.

    Sieh dir mal EVCC an, damit kannst du PV-Überschussladen automatisieren.

  5. 16 hours ago, kmfrank said:

    meine Warp 1 zählt zeitmäßig den Ladevorgang solange der Stecker im Auto steckt. Ist das so gewollt?

    Das ist soweit beabsichtigt, ja. Die Ladezeit ist eher die Standzeit. Es könnte ja bzw. ist dir auch passiert, dass dein Fahrzeug Stunden nachdem der Akku voll war sich wieder soweit entladen hat, dass es wieder Strom ziehen wollte. Das wird auf den selben Ladevorgang aufgezeichnet.

    Deshalb endet der Ladevorgang erst wenn du das Fahrzeug abziehst, oder (falls du die NFC-Freigabe benutzt) wenn du mit dem selben Tag, dass den Ladevorgang erlaubt hat diesen beendest. Analog benutzen wir als Ladestart für die Aufzeichnung entweder den Zeitpunkt an dem das Fahrzeug angesteckt wurde (ohne NFC-Freigabe) bzw. den Zeitpunkt an dem ein Tag den Ladevorgang erlaubt hat (mit NFC-Freigabe).

  6. On 4/11/2022 at 2:21 PM, gintonicgamer said:

    So, ich habe den Fehler gefunden. Meine Fritzbox war warum auch immer auf WPA2 only eingestellt. Der Warp möchte aber WPA3. oh man... sorry es lag an mir. 

    Konnte die Wallbox früher WPA2? 

    Das ist interessant, auch mit den Infos aus diesem Thread.

     

    Ich hatte für die 2.0.0 (ohne Beta) und entsprechend auch die 2.0.1 kurzerhand noch WPA3-Unterstützung mit reinkompiliert. Mich wundert vor allem, dass die Unterstützung in den Betas nicht enthalten war, d.h. wenn da etwas klemmt dürfte es eigentlich nicht davor aufgetreten sein.

    Ich habe aber gestern im privaten Umfeld mitbekommen, dass Fritzboxen wohl Probleme beim WPA2+WPA3-Modus haben. Siehe hier: https://bbs.archlinux.org/viewtopic.php?id=273651 und https://lists.infradead.org/pipermail/hostap/2022-February/040209.html

    Es ist wohl so, dass die Fritzboxen sich nicht an die Spezifikation halten, laut https://lists.infradead.org/pipermail/hostap/2022-February/040212.html und dass die Probleme teilweise auch im WPA2-Only-Modus auftreten: https://bugzilla.opensuse.org/show_bug.cgi?id=1195395#c40

    Wenn ich die aufgelaufenen Sachen aus meiner Urlaubswoche aufgeholt habe teste ich auf jeden Fall nochmal alle Varianten durch. Es bleibt spannend ;)

  7. On 4/8/2022 at 4:58 PM, jensstark said:

    Spannend wäre die Frage, ob man den ESP32 gegen den -LAN tauschen könnte...

    Theoretisch geht das. Es gibt aber zwei Probleme:
    1. Der Platz: Die LAN-Buchse des Ethernet Bricks ist höher, deshalb kannst du ihn nicht auf den Berührschutz in einer WARP1 schrauben, außerdem musst du für das LAN-Kabel ein Loch ins Gehäuse bohren. Je nach persönlichem Anspruch an rumfliegende Platinen ist das eventuell machbar.

    2. Die Firmware: Die WARP1-Firmware unterstützt kein Ethernet, die WARP2-Firmware nicht den "alten" Ladecontroller der in der WARP1 verbaut ist. Du kannst dir aber eine Firmware kompilieren, mit der das funktionieren müsste. Dazu musst du dir das Firmware-Git klonen und dann in der platformio.ini das WARP-Environment so ändern, dass du bei den Backend-Modulen statt ESP32 Brick ESP32 Ethernet Brick benutzt und zusätzlich das Ethernet-Backend- und -Frontend-Modul reinbaust. (Das kannst du dir am WARP2 Environment weiter unten abschauen)

    Das ist alles nicht offiziell unterstützt und auf eigene Gefahr. Falls du dir das aber hacken willst und dabei Firmware-Probleme findest, gib gerne Bescheid.

  8. 23 hours ago, michael99 said:

    Wie immer muss ich erst ras und de, Teil sagen, wo es sich einloggen soll. Völlig Unverständlich das Problem.

    Ich verstehe nicht, was du mir damit sagen willst.

    23 hours ago, michael99 said:

    dann

        $url = "Request method for this URI is not handled by server";
        $filestatus = file_put_contents('warp/warp.txt','ein');

    Fehler

    Request method for this URI is not handled by server

    Hatten wir schon, warumm immer noch? Das kann woch wohl nicht Wahr sein!

    Ich fürchte etwas mehr Kontext musst du schon bieten, damit man dir helfen kann. Programmierst du gegen die API oder machst du direkt Dinge im Browser, so wie du es in deinem anderen Thread geschrieben hattest? Wenn du ein Programm schreibst in welcher Sprache? Warum weist du Fehlermeldungen der Wallbox auf eine Variable zu?

  9. Ah, ja Handys machen da Probleme, da z.B. bei Android die NFC-ID rotiert wird. Siehe z.B. hier:

    Weißt du was für einen Tag-Typen dein Handy emuliert? Bekommst du über den 8266 immer die selbe ID?  Falls ja würde mich der Code bzw das genaue NFC-Modul interessieren, dass du da einsetzt, vielleicht könnte man sich für die Wallbox da abschauen wie man stabile IDs ausliest.

  10. Ups nein, das ist nur verquer formuliert. Bisher war es so, dass wenn du auf der WiFi-Verbindungsseite bereits eine Verbindung konfiguriert hattest und dann eine andere konfiguriert hast, in jedem Fall eine Passphrase eingegeben werden musste. Die Änderung ist, dass wenn die alte und neue SSID gleich sind (du also z.B. zu einem anderen AP/Repeater des selben Netzes wechselst) du jetzt nicht mehr die Passphrase neu eingeben musst.

    • Like 1
  11. Firmware: WARP 2.0.0 und WARP2 2.0.0

    • Blogpost mit Details zu den umfangreichen Änderungen
    • API-Änderungen; möglicherweise sind Anpassungen an Software die mit der Wallbox interagiert notwendig!
    • Ladetracker hinzugefügt; ordnet Ladevorgänge Benutzern zu und zeichnet diese persistent auf
    • Download eines Logs der aufgezeichneten Ladungen hinzugefügt
    • Benutzerverwaltung hinzugefügt; NFC-Tags werden jetzt Benutzern zugeordnet
    • Netzwerk-Zeitsynchronisierung hinzugefügt
    • Ladestromgrenzen aufgeteilt um NFC und andere Steuerungsmöglichkeiten zu entkoppeln (durch Update auf Ladecontroller-Firmware 2.1.0 (WARP) bzw. 2.1.2 (WARP2))
    • Netzwerk-Abschnitt hinzugefügt; alle Netzwerk-Interfaces verwenden jetzt den selben Hostnamen
    • Konfigurierbares Sendeintervall für MQTT hinzugefügt
    • Editierbaren Wallboxnamen hinzugefügt
    • Unterstützung des Browser-Verlaufs hinzugefügt
    • Eingabefeld des Ladestroms verbessert
    • Übersetzungen verbessert
    • Webinterface-Details verbessert
    • Warnung hinzugefügt, wenn WLAN-Access-Point deaktiviert werden soll
    • Hinweis zu Lastmanager-Watchdog hinzugefügt
    • WebSocket-Verbindungsverlust durch falsches Ping-Frame-Handling repariert
    • Browser-Caching repariert
    • Anzeige der Ladecontroller-Version repariert
    • WebSocket-Verbindungen durch SSL-Proxies repariert
    • Logik der Fehleranzeige im Webinterface repariert
    • Repariert, dass Passphrase bei Verbindung zu anderem Access Point mit selber SSID nicht verlangt wird
    • Sporadisches Fehlen des Ereignis-Logs repariert

    Download: WARP 2.0.0 bzw. WARP2 2.0.0

    • Thanks 3
×
×
  • Neu erstellen...