Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.388
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Posts erstellt von rtrbt

  1. This depends on your Arduino:

    Quote

    Serial communication on pins TX/RX uses TTL logic levels (5V or 3.3V depending on the board).

    Our Bricklet supports 3.3V TTL levels on the pin header and RS232 signal levels on the D-Sub 9 connector (note that those are differential signals, so for example +12V and -12V).

    The communication should work if you use an Arduino with a 3.3V TTL level. Those are typically the ones that have an ARM based micro controller (for example the MKR family), not the AVR based ones (like the Uno etc.)

  2. Die ESP-Firmware selbst debuggen wir auch nur über das Logging. Die JTAG-Pins sind in der Tat nicht rausgeführt, wenn ich mich richtig erinnere (bin nicht der Hardware-Entwickler) lag das daran, dass wir vor allem beim Ethernet-Brick zu wenig GPIOs hatten.

    Für die Kommunikation zwischen Brick und Bricklet kannst du entweder ein Bricklet-Kabel schlachten oder zwei Breakout Bricklets zusammenlöten https://www.tinkerforge.com/de/shop/breakout-bricklet.html und mit einem Logic Analyzer mitlesen. Wir haben intern eine neuere Variante für die 7-Pol-Bricklets, meines Wissens verkaufen wir die aber nicht.

  3. Es muss bei dir auf jeden Fall noch ein Problem mit der Zählerkommunikation geben. Das Log ist voll von Nachrichten der Form

    2023-03-02 21:56:29,726  Request 157: Exception code -1

    Das ist jeweils eine Modbus-Anfrage an den Zähler, die in einen Timeout läuft, d.h. der Zähler hat aus Sicht des RS485-Bricklets nicht oder nicht schnell genug geantwortet.

    Da manche Nachrichten aber durchkommen: Sind die Schiebeschalter auf dem RS485-Bricklet richtig eingestellt? Vielleicht ist das ein Terminierungsproblem?

  4. Mach in deinem Firefox bitte einmal die Browser-Konsole auf (Rechtsklick auf irgendeiner Seite -> Konsole), füg unten

     navigator.languages

    ein und drück auf Enter. Was bekommst du da als Sprach-Array zurück? Ich habe hier auch Firefox 110 auf Linux, fast identische Spracheinstellungen (Deutsch, Englisch, Englisch (US)) und bekomme folgendes:

    image.png

    Das Webinterface geht diese Liste durch, betrachtet von jedem Eintrag jeweils nur die ersten zwei Buchstaben und wenn die "de" sind, bekommst du die deutsche Seite.

    Edit: An dem Code haben wir auch seit Juli 2022 nichts geändert. Weißt du noch welche Firmware du vor der 2.1.0 auf der Wallbox hattest?

  5. 27 minutes ago, wuesten_fuchs said:

    Ich habe das Firmware-Update (dadurch Reboot) und Auslesen/Löschen (dadurch wieder Reboot) gestern abend gemacht, während das Auto bereits angesteckt war (das Laden wird dann erst 22:00 per externem Kommando gestartet). Vielleicht liegt es daran, d.h. die Box hat die Info über das Anstecken vom Auto durch den Reboot verloren und dadurch den Ladevorgang nicht aufgezeichnet.

    Das ist gut möglich. Eigentlich sollte die Wallbox dir verbieten, dass du die Firmware aktualisierst, wenn ein Auto angeschlossen ist. Hast du das über /recovery gemacht?

  6. Sinnvoll ist das schon. Die Umsetzung ist aber kompliziert. Wir speichern die Ladevorgänge sehr kompakt (siehe hier für's Format). Den Strompreis mit zu speichern würde bedeuten, das wir die Größe eines Eintrags auf 32 Byte erhöhen müssen, das ist im Flash kein Problem, aber das Erzeugen der Ladelogs wird dadurch langsamer weil doppelt soviele Daten geladen werden müssen.

    Fazit: Ich denk mal drüber nach, kann und will aber nichts versprechen.

    • Thanks 1
  7. Firmware: WARP 2.1.0 und WARP2 2.1.0

    • In den nächsten Tagen folgt ein Blogpost über die neuen Firmwares.
    • (nur WARP2) OCPP-Unterstützung hinzugefügt (OCPPJ 1.6 Core und Smart Charging Profile)
    • PDF-Export für Ladetracker hinzugefügt
    • CSV-Export des Ladetrackers in "Excel-Kompatibel" und "nach RFC4180" aufgeteilt
    • Menüstruktur des Webinterfaces neu organisiert
    • Ladecontroller-Unterseite in Ladestaus und Ladeeinstellungen unterteilt
    • Auto-Start in manuelle Ladefreigabe umbenannt und in Ladeeinstellungen verschoben
    • Lastmanagement-Protokoll durch neue, vorwärts-kompatible Version ersetzt Alle Wallboxen eines Lastmanagement-Verbunds müssen auf Firmware 2.1.0 oder höher aktualisiert werden!
    • Implementierung des Stromzähler-Graphen ausgetauscht
    • Übersetzungen verbessert
    • Watchdog als Schutz gegen hängende Firmware hinzugefügt
    • Behoben, dass WLAN-Verbindungskonfiguration nicht gespeichert werden konnte, wenn nur das gewählte Netzwerk geändert wurde
    • Behoben, dass Zahländerungen nicht angewandt wurden, wenn per Enter-Druck im Zahl-Eingabefeld gespeichert wurde
    • Enter-Druck in Modalfenstern repariert
    • Prüfung auf reservierte, Broad- und Multicast-IPs in Lastmanager-Konfiguration hinzugefügt
    • Behoben, dass Lastmanagement-Fehlerdauer nicht anstieg, wenn keine gesteuerte Wallbox antwortet
    • Behoben, dass Start- und End-Datumsauswahl nicht die Zeitzone des Nutzers berücksichtigt hat
    • Labelbreite auf der Statusseite auf kleinen Bildschirmen angepasst
    • Standard-NTP-Server für höhere Zuverlässigkeit geändert
    • Behandlung der RTC-Zeit im Fehlerfall repariert
    • "Charged Energy"-Register im Keba-Emulationsmodus repariert
    • API-Fehlermeldungen verbessert
    • Ermöglicht, dass mehr als eine API-Fehlermeldung geschickt werden kann
    • Validierung der Benutzerkonfiguration repariert
    • Behoben, dass NFC-Tag ausgewählt werden musste, wenn exakt ein Tag erkannt wurde
    • Behoben, dass immer Login-Seite angezeigt wurde, falls beim Prüfen des Anmeldestatus ein Timeout auftrat
    • Behoben, dass Benutzerkonfiguration bzw. -API bis zu einem Neustart gesperrt wurde
    • Verschränkte Stromgrenzenbeschränkungen in der Lastmanager-Konfiguration behoben
    • WLAN-Verbindungsaufbau beschleunigt
    • Boost-Modus hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.6 (WARP1) bzw. 2.1.9 (WARP2))
    • (nur WARP2) Fahrzeug-Weckruf hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.9)
    • (nur WARP2) CP-Trennungs-API finalisiert (durch Update auf Ladecontroller-Firmware 2.1.9)
    • Sichergestellt, dass Schütz nicht unter Last geschaltet wird, wenn das Fahrzeug den Ladevorgang stoppt (durch Update auf Ladecontroller-Firmware 2.1.6 (WARP1) bzw. 2.1.9 (WARP2))
    • (nur WARP2) Behoben, dass bei einer Notabschaltung wegen DC-Fehler zusätzlich ein Schützfehler gemeldet wurde (durch Update auf Ladecontroller-Firmware 2.1.10)
    • (nur WARP2) Behoben, dass Stromzählereinstellungen kontinuierlich geschrieben wurden (durch Update auf Ladecontroller-Firmware 2.1.10)
    • (nur WARP2) Ausgabe des letzten Stromzählerwerts repariert (durch Update auf Ladecontroller-Firmware 2.1.10)

    Download: WARP 2.1.0 bzw. WARP2 2.1.0

  8. DIrekt über dem Low-Level-Zustand kannst du ein Ladeprotokoll ziehen. Mach das mal wie folgt und poste es hier:

    1. Bei Ladeprotokoll auf Start klicken. Browser-Fenster nicht schließen!
    2. Auto anstecken
    3. ggfalls. NFC-Tag an die Box halten usw.
    4. ~ 30 Sekunden warten (damit das Auto eine Chance hat anzufangen zu laden)
    5. Auf Stop + Download klicken

     

  9. Nachträglich ändern geht über einen Trick zumindest während der Ladevorgang läuft: Du kannst den Ladevorgang mit dem ersten Tag stoppen und dann mit einem anderen Tag wieder starten (das geht auch über die API mit nfc/inject_tag_start und _stop). Wenn du also eine Auto-Erkennung hast, dann könntest du drei Tags benutzen. Eins zum Erkennen des Autos und sobald du weißt, welches Auto lädt, eins der beiden anderen Tags. Die Reihenfolge ist dann

    1. Auto anstecken
    2. Ladevorgang mit Tag 1 ("unbekanntes Auto") freigeben
    3. Auf die Auto-Erkennung warten
    4. Ladevorgang mit Tag 1 stoppen
    5. Ladevorgang mit Tag 2 oder Tag 3 (je nachdem was die Auto-Erkennung sagt) starten
×
×
  • Neu erstellen...