Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.489
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    138

Alle erstellten Inhalte von rtrbt

  1. Wenn du schon ein NFC-Tag zur Ladefreigabe verwendest, dann stoppe den Ladevorgang lieber über die nfc/inject_tag_stop API aus: https://docs.warp-charger.com/docs/mqtt_http/api_reference/nfc#nfc_inject_tag_stop_warp3 Wenn du per MQTT external_current auf 0 setzt, dann musst du auch per MQTT wieder freigeben (oder im Webinterface unter Wallbox -> Ladestatus von Hand die Stromgrenze zurücksetzen) Wenn du mit einer NFC-Tag-Injection über MQTT stoppst, dann kannst du den nächsten Ladevorgang einfach wieder mit deinem Tag starten.
  2. Moin, @MatzeTF und ich haben in den letzten Monaten das Lastmanagment grundlegend überarbeitet. Der Lastmanager kann jetzt: Dynamisches Lastmanagement: Der Lastmanager stellt sicher, dass der Netzanschluss nicht überlastet wird, auch wenn andere (ungesteuerte) Verbraucher den Hausanschluss dynamisch belasten. PV-Überschussladen: Der Lastmanager stellt sicher, dass nur der PV-Überschuss verwendet wird, um Fahrzeuge zu laden. Statisches Lastmanagement: Der Lastmanager stellt sicher, dass die gemeinsame Zuleitung des Wallbox-Verbunds nicht überlastet wird. Und das alles mit bis zu 32 Wallboxen. Insbesondere sollte jetzt auch das PV-Überschussladen mit mehreren Wallboxen deutlich besser funktionieren. Details zur Funktionsweise finden sich hier: https://docs.warp-charger.com/docs/warp_charger/new_charge_management Im Moment funktioniert das neue Lastmanagement nur mit Wallboxen: Es kann nicht auf dem WARP Energy Manager verwendet werden und auch keine Wallboxen über einen WARP Energy Manager Phasenumschalten. Beide Punkte werden wir bis zur fertigen, also nicht-Beta-Veröffentlichung noch fixen. Die Konfiguration sollte für das statische Lastmanagement und das PV-Überschussladen unverändert weiter funktionieren, damit das dynamische Lastmanagement verwendet wird, muss es unter Energiemanagement -> Lastmanagement konfiguriert werden. Falls das Lastmanagement nicht wie erwartet funktioniert, oder seltsame Entscheidungen trifft, können die Informationen der Lastmanagment-Debug-Unterseite hilfreich sein. Dort kann unter anderem ein Lastmanagement-Log heruntergeladen werden, dass aufschlüsselt, was in der letzten ~ Stunde passiert ist. Falls Probleme auftreten können wir diese mit dem Log hoffentlich nachvollziehen. Wir freuen uns auf euer Feedback! warp_firmware-UNSIGNED-NONVERIFYING-NIGHTLY_2_4_1_66a3ba0e_fb2281b0efd8cd6_feature-charge-manager-v2-3_merged.bin warp2_firmware-UNSIGNED-NONVERIFYING-NIGHTLY_2_4_1_66a3b8da_fb2281b0efd8cd6_feature-charge-manager-v2-3_merged.bin warp3_firmware-UNSIGNED-NONVERIFYING-NIGHTLY_2_4_1_66a3b87a_fb2281b0efd8cd6_feature-charge-manager-v2-3_merged.bin
  3. rtrbt

    Veröffentlichungen

    Firmware: WARP Energy Manager 2.1.2 Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: Alpha ESS SMILE, Shelly Pro (3)EM Sungrow-Registertabelle repariert Laden im “schnell”-Modus erlaubt, selbst wenn PV-Überschuss-Zähler noch keine Werte geliefert hat Lastmanagement-Startphase repariert Repariert, dass Webserver für immer gehangen hat, wenn Laden der Energiebilanzdaten fehlgeschlagen ist Hinzugefügt, dass Netzwerkverbindungen vor Neustart geschlossen werden Hinzugefügt, dass manche Stromzählerwerte aus anderen berechnet werden, falls sie nicht vom Zähler gemeldet werden Repariert, dass manche MQTT-Fehler nicht im Ereignis-Log angezeigt wurden Download: WARP Energy Manager 2.1.2
  4. rtrbt

    Veröffentlichungen

    Firmware: WARP 2.4.1, WARP2 2.4.1 und WARP3 2.4.1 Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: Alpha ESS SMILE, Shelly Pro (3)EM Sungrow-Registertabelle repariert Laden im “schnell”-Modus erlaubt, selbst wenn PV-Überschuss-Zähler noch keine Werte geliefert hat Lastmanagement-Startphase repariert Modbus-TCP-Registertabellen-Dokumentation verbessert Repariert, dass Webserver für immer gehangen hat, wenn Laden der Energiebilanzdaten fehlgeschlagen ist Hinzugefügt, dass Netzwerkverbindungen vor Neustart geschlossen werden Überschreiben des Energie-Limits repariert Hinzugefügt, dass manche Stromzählerwerte aus anderen berechnet werden, falls sie nicht vom Zähler gemeldet werden Repariert, dass manche MQTT-Fehler nicht im Ereignis-Log angezeigt wurden Berechnung der Belegungsanzeige des Ladetrackers repariert Titel des Ladelog-PDFs repariert Erzeugung des Ladelog-PDFs beschleunigt Überlauf der Stromzählerwerte behoben (Nur WARP1) CP/PE-Messung verbessert (durch Update auf Ladecontroller-Firmware 2.1.10) Download: WARP 2.4.1 bzw. WARP2 2.4.1 bzw. WARP3 2.4.1
  5. Schalte die Status-LED-Steuerung mal ab. Die ist nur notwendig, wenn du die API benutzt.
  6. Hast du unter Wallbox -> Einstellungen die "Status-LED-Steuerung" aktiviert? Das sollte für Automatisierungsregeln nicht notwendig sein, könnte aber dazu führen, dass die Regel ignoriert wird. Wie genau sieht deine Automatisierungs-Regel aus? Siehst du im Ereignislog "Running rule #[zahl]" wenn du auf das MQTT-Topic schreibst?
  7. Du liest die HTTP-Dokumentation. Wenn du rechts auf "MQTT (mosquitto)" klickst, dann wird dir bei jeder API, bei der du ein _update anhängen musst (das sind fast alle) genau dieser Umstand angezeigt:
  8. Interessant! Mit Random-IDs vom Handy und einer Karte mit fester ID haben wir das gerade auch hinbekommen. Werden wir uns auf jeden Fall mal ansehen.
  9. Wie lange ist eine kurze Zeit? Wir haben das hier mit einem S21 getestet und nach 5 Minuten Random-Tag-Spam funktionierte es noch. Kannst du das bei dir reproduzieren oder ist das nur genau einmal passiert?
  10. Du meinst im Debug-Report? Das WiFi-Passwort (wie auch alle anderen Passwörter usw.) sollte durch null ersetzt sein. Wenn das nicht der Fall ist, sag bitte auf jeden Fall Bescheid, das müssten wir sofort fixen. Das liegt vermutlich daran, dass du einen Stromzähler mit der ID 0 (in der Stromzähler-Konfiguration im Webinterface heißt das generisch "Nummer") hinzugefügt hast. Der wird von der Wallbox als der "interne" Zähler betrachtet und z.B. für den Ladetracker verwendet. Die Wallbox weiß von sich aus nicht, ob sie eine Smart oder Pro ist, sondern wenn ein Zähler mit ID 0 auftaucht, dann betrachtet sie sich selbst als Pro. Damit der Ladetracker jetzt nicht die Daten deines Hausanschlusses aufzeichnet kannst du entweder die Nummer des Zählers auf 1 ändern, oder von Hand https://docs.warp-charger.com/docs/mqtt_http/api_reference/evse#evse_meter_config_warp1 auf 1 schreiben. Dafür gibt es leider noch keine UI. In beiden Fällen solltest du dann noch unter Wallbox -> Einstellungen die Zählerüberwachung deaktivieren, die dürfte sich scharfgeschaltet haben, wenn die Box sich einmal als Pro erkennt. Das ergibt Sinn, du hast das Feature damit ja ausgeschaltet. Wenn du keine NFC-Freigabe willst, aber trotzdem per NFC den Ladestrom kontrollieren, dann musst du das per Automatisierungs-Regel erschlagen. Das ist möglich, aber involviert etwas Bastelei. @poohnet hat einen Fork der WARP-Firmware mit CP-Trennung für WARP1 und die entsprechende Hardware-Modifikation hier: hier: https://github.com/poohnet/esp32-firmware und hier: Die letzte Version des Forks ist aber 2.2.1, d.h. da fehlen dir dann die PV-Überschuss-Features
  11. Zieh bitte einmal einen Debug-Report unter System->Ereignislog und hänge ihn hier an.
  12. Klassiker. Man fixt Bug A und erzeugt damit Bug B. :D Als work-around bis zur nächsten Firmware kannst du erst das Zeitlimit überschreiben (auf z.B. 12 Stunden), dann das gewünschte Energielimit setzen und dann das Zeitlimit wieder auf unbegrenzt setzen. Danke für den Bug-Report!
  13. Prinzipiell kann der Access Point des ESPs deutlich schneller sein. Im Issue, dass Matze verlinkt hat, hatte ich damals ~ 20Mbit/s gemessen, wenn auf dem ESP eine minimalistische Firmware läuft, die nur den Access Point öffnet und sonst nichts tut.
  14. rtrbt

    Veröffentlichungen

    Firmware: WARP Energy Manager 2.1.1 Repariert, dass Ladevorgänge blockiert wurden, falls kein Schütz angeschlossen ist Download: WARP Energy Manager 2.1.1
  15. Wenn du für LAN eine statische IP im 10.0.0.0/24 Netz konfigurierst sollte eine Warnung angezeigt werden, dass das vermutlich nicht funktionieren wird. Wenn du die Adresse der Wallbox per DHCP zuweist, gibt es aber keine Rückmeldung. Ich habe dafür mal ein Issue angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/352
  16. Noch etwas einfacher: Du kannst dir im Webinterface eine Automatisierungsregel anlegen, die bei Drücken des Fronttasters eine MQTT-Nachricht schickt. Dann muss das Script nur noch auf das entsprechende MQTT-Topic subscriben und wenn eine Nachricht ankommt einen Befehl auf die Tesla-API rausschicken.
  17. rtrbt

    Veröffentlichungen

    Firmware: WARP (1,2,3) Fernzugriffs-Alpha Details hier:
  18. There's the problem: Your HAT Brick's firmware is outdated. The easiest way to fix this is to use an older Raspberry Pi (every version up to and including a Pi 4 will work). Plug the HAT on the old Pi, install Brick Daemon there, connect to the Pi with Brick Viewer and update the HAT Firmware to 2.0.4. Then plug the HAT back onto the Pi 5 and boot it, gpioinfo should then report both those lines as unused and Brick Daemon should be able to start. If you don't have another older Pi available, we have to build a patched version of Brick Daemon for you.
  19. Du redest von der ESP32-Firmware? Die hat in der Tat eine Konfigurationspartition mit mehr oder weniger normalem Dateisystem. Du kannst dir z.B. hier abgucken wie man JSON-Daten liest und schreibt (du kannst mit diesem Weg auch beliebigen Text/Binärdaten lesen und schreiben): https://github.com/Tinkerforge/esp32-firmware/blob/dfcc160df3355c46f561ea1a48ecb9c9e173d69a/software/src/config_migrations.cpp#L65 Wenn du dir den Inhalt der Partition ansehen willst, kannst du im software-Ordner (also neben z.B. esp32.ini) eine Datei namens default_wifi.json mit folgenden Inhalt anlegen: { "debug_fs_enable": "true" } und das Debug-Backend-Modul reinkompilieren. Dann kannst dich unter http://esp32-abcd/debug/fs/ durch das Dateisystem klicken. Es gibt noch die einfachere Variante (falls dir JSON reicht), dass du eine API definierst und die als persistentConfig speicherst. Das funktioniert grob wie im Tutorial: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_ESP32_Firmware/Tutorial.html#phase-3-kommunikation-frontend-zu-backend nur dass du statt api.addState und .addCommand stattdessen api.restorePersistentConfig zum Laden aus dem Flash und api.addPersistentConfig zum Registrieren der API verwenden musst. api.addPersistentConfig ist optional, du kannst auch (gerade wenn du dein Setup im Code modifizieren und speichern willst) nur api.restorePersistentConfig zum Laden und api.writeConfig zum Speichern benutzen.
  20. You've placed the package in a directory that apt can't read as the user _apt (apt usually downloads as a separate user for security purposes) See for example here: https://askubuntu.com/a/908825 Since this does not work as _apt, apt retries "downloading" the package as root.
  21. EBUSY could mean that the HAT Bricks device tree overlay did not load correctly (We use the overlay to be able to use gpiochip4 7) Please run gpioinfo and post the output here.
  22. Die zweite CP-Trennung wenn das Auto nicht reagiert ist in WARP2 2.3.0 enthalten. Fehlte aber in den Changelogs, habe ich gerade hinzugefügt. Die Logs sehen wirklich seltsam aus. Der 3 -> 2 Wechsel muss von deinem Auto verursacht werden (wenn die Wallbox, der Energy Manager oder EVCC blockieren würden, dann wäre es ein 3 -> 1 Übergang), es sei denn durch die Test/Beta-Firmwares stehen sich Energy Manager und Wallbox gegenseitig im Weg. Aktualisiere sicherheitshalber mal Wallbox und Energy Manager auf 2.4.0 bzw. 2.1.0. Weißt du noch, ob das Auto nach dem 2->3 Übergang um 10:42:48,215 weitergeladen hat? (Kannst du eventuell noch im Ladetracker sehen) Bzw. als Gegentest: Wenn du das Auto das nächste Mal voll geladen hast (sodass die Wallbox im "Ladebereit"-Zustand, also 2 ist), zieh es mal ab, warte ein paar Sekunden, stecke es wieder an und achte darauf, ob das Schütz nochmal kurz schaltet und dann wieder abschaltet.
  23. rtrbt

    Veröffentlichungen

    Firmware: WARP Energy Manager 2.1.0 SMA Speedwire als Stromzähler-Datenquelle hinzugefügt Modbus TCP als Stromzähler-Datenquelle hinzugefügt Liste unterstützter Stromzähler Unterstützung von MQTTS und MQTT über WS(S) hinzugefügt HTTP-Automatisierungsbedingung hinzugefügt Weitere Zoomstufen für den Plot des Ladeverlaufs hinzugefügt Buttons für Phasenumschaltung zur Statusseite hinzugefügt, wenn externe Steuerung aktiviert ist Modal für WLAN-Scan-Ergebnisse hinzugefügt SunSpec: Unterstützung mehrerer Geräte im selben Registersatz hinzugefügt SunSpec: Unterstützung mehrerer Instanzen des selben Models in einem Gerät hinzugefügt SunSpec: Boot-Scan-Robustheit verbessert SunSpec: Skalierung des Leistungsfaktors repariert SunSpec: Unterstützung für DER-Modelle 701, 713 und 714 hinzugefügt SunSpec: Kompatibilität mit SolarEdge- und Sungrow-Wechselrichtern verbessert SunSpec: Robustheit der Gerätesuche verbessert WiFi Enterprise: EAP-TLS-Verbindungen mit Client-Key repariert DSZ15DZMOD-Unterstützung der veralteten Stromzähler-API repariert Automatische Kanalauswahl des WLAN-Access Points repariert Anzeige aktiver Phasen bei negativem Phasenstrom repariert Min+PV-Lademodus mit umkonfiguriertem Minimalstrom repariert Automatische Skalierung nicht gestapelter Graphen repariert Behoben, dass PV-Lademodus nach einem drei- zu einphasig Wechsel den Ladevorgang gestoppt hat Lastmanagement: Spielraum des Phasenstroms verdoppelt wenn exakt eine Wallbox lädt Modulname zu Ereignislog-Nachrichten hinzugefügt Menüstruktur des Webinterfaces überarbeitet Label/Inhaltsteilung auf Status- und Unterseiten vereinheitlicht Platzhalter eingefügt, wenn Zeit der Echtzeituhr nicht gestellt ist Anzeige deaktivierter Automatisierungsbedingungen und -aktionen hinzugefügt Sichtbarkeit eines leeren Leistungsgraphen repariert Sichergestellt, dass Energiebilanz-Graphfarben bei Neuladen des Webinterfaces gleich bleiben Möglichkeit zum Reaktivieren des 802.11b-Modus für besseren WLAN-Empfang hinzugefügt NTP-Serverkonfiguration über DHCP repariert Behoben, dass auf der Statusseite 0 W als Leistungsaufnahme angezeigt wurde, wenn keine Daten verfügbar sind Behoben, dass MQTT als deaktiviert angezeigt wurde, wenn noch kein Verbindungsversuch erfolgt war Behoben, dass WLAN-Scan nicht als fertig angezeigt wurde, wenn kein WLAN gefunden wurde Automatisches Neuladen des Web Interfaces bei Firmware-Versionsänderung behoben Voreingestellte NTP-Server aktualisiert NTP-Synchronisierungsgeschwindigkeit erhöht Sichergestellt, dass gerade bezogene NTP-Zeit nicht mit möglicherweise schlechterer RTC-Zeit überschrieben wird Robustheit des Web-Servers verbessert Übersetzungen verbessert Unterstützte Länge von HTTP-Request-Headern auf 2 Kilobyte erhöht Download: WARP Energy Manager 2.1.0
  24. Firmware: ESP32 Ethernet Brick 2.0.3 Hier klicken für das (sehr lange) Changelog Download: ESP32 Ethernet Brick
  25. Firmware: ESP32 Brick 2.0.3 Hier klicken für das (sehr lange) Changelog Download: ESP32 Brick
×
×
  • Neu erstellen...