-
Gesamte Inhalte
1.549 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
150
Alle erstellten Inhalte von rtrbt
-
WARP in Home Assistant via MQTT und HTTP-API
Thema antwortete auf rtrbts sahni in: WARP Charger / Energy Manager
Kurzes Update: Auto Discovery ist in der gestern veröffentlichten Firmware 2.1.1 enthalten. -
WARP Charger mit kwH oder Zeitbegrenzung
Thema antwortete auf rtrbts DER in: WARP Charger / Energy Manager
Ist in 2.1.1 implementiert. -
Firmware: WARP 2.1.1 und WARP2 2.1.1 MQTT-Auto-Discovery für Home Assistant und kompatible System hinzugefügt Zeit- und Energielimits für Ladevorgänge hinzugefügt Core-Dump zu Debug-Report hinzugefügt Höhe des Stromzählergraphen auf mindestens 100 W limitiert Live-Graph in den ersten vier Minuten nach Neustart repariert Falsche Gesamtenergie-Berechnung in PDF-Ladelogs repariert Aufzeichnung von Ladevorgängen bei Stromversorgungsverlust repariert Fehlermeldungen von Texteingabefeldern repariert Platzhaltertext der Passphrase der WLAN-Verbindung repariert Löschen der WLAN-Verbindungs-Passphrase repariert Längenprüfung von Text- und Passworteingabefeldern repariert Robustheit des Bricklet-Flashens repariert Übersetzungen verbessert Klickbare Links für kontrollierte Wallboxen auf der Statusseite hinzugefügt Prüfung auf duplizierte Wallbox-Hostnamen bzw. IPs in der Lastmanagement-Konfiguration hinzugefügt Filter, der mDNS-Antworten, die nicht von WARP Chargern gesendet wurden, hinzugefügt Auflösung von .local-Hostnamen via mDNS-Scan hinzugefügt Veraltete WLAN-Empfangsqualitäts- und IP-Werte entfernt wenn WLAN-Verbindung verloren wird (nur WARP2) Stromlimits für konfigurierbaren Eingang hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.11) Abbruch des Ladeprotokolls nach 60 Sekunden behoben MQTT-Fehlermeldungen verbessert Download: WARP 2.1.1 bzw. WARP2 2.1.1
-
Sehr cool! Das sehen wir uns in nächster Zeit mal an.
-
Warp 1 erkennt Zähler nicht mehr
Thema antwortete auf rtrbts jkrner00 in: WARP Charger / Energy Manager
Tut mir leid, deine Antwort ist irgendwie untergegangen. Damit wir das Problem beheben können, müssen wir erst die Ursache herausfinden. Da eventuell im Ereignis-Log etwas interessantes steht, dass aber von den MQTT-Meldungen zugemüllt wird: Benutzt du als MQTT-Broker ioBroker? Falls ja, deaktiviere bitte einmal die Einstellung "Publish own states on connect" (siehe hier: https://www.iobroker.net/#en/adapters/adapterref/iobroker.mqtt/README.md?iobrokerworkingasmqttbroker) Dann solltest du nicht mehr die ganzen Meldungen im Log bekommen, wenn du die Wallbox neustartest und dann noch einen Debug-Report herunterlädst. -
Modbus PV-Überschuss laden / Allowed charging current
Thema antwortete auf rtrbts Frankstar in: WARP Charger / Energy Manager
Da hast du recht. Hatte ich übersehen, sorry :D Habe das mal editiert, falls jemand den Thread findet und das raus kopiert. -
Modbus PV-Überschuss laden / Allowed charging current
Thema antwortete auf rtrbts Frankstar in: WARP Charger / Energy Manager
Dein Problem ist, dass wir alle Werte als uint32 oder float hinterlegen. Beides ist vier Bytes (also zwei Modbus-Register) lang. Mit Pymodbus kannst du 4 Byte lange Werte z.B. so schreiben und lesen: from pymodbus.client import ModbusTcpClient from pymodbus.payload import BinaryPayloadBuilder, BinaryPayloadDecoder from pymodbus.constants import Endian def uint32_to_regs(value): builder = BinaryPayloadBuilder(wordorder=Endian.Big, byteorder=Endian.Big) builder.add_32bit_uint(value) return builder.to_registers() def float_to_regs(value): builder = BinaryPayloadBuilder(wordorder=Endian.Big, byteorder=Endian.Big) builder.add_32bit_float(value) return builder.to_registers() def regs_to_uint32(response): decoder = BinaryPayloadDecoder.fromRegisters(response.registers, wordorder=Endian.Big, byteorder=Endian.Big) return decoder.decode_32bit_uint() def regs_to_float(response): decoder = BinaryPayloadDecoder.fromRegisters(response.registers, wordorder=Endian.Big, byteorder=Endian.Big) return decoder.decode_32bit_float() client = ModbusTcpClient('warp2-22oH') client.connect() # Setze 12,345 A als Modbus-Ladestrom client.write_registers(1002, uint32_to_regs(12345)) # Lies den Modbus-Ladestrom zurück print(regs_to_uint32(client.read_holding_registers(1002, 2))) # Lies den insgesamt erlaubten Ladestrom (allowed_charging_current) print(regs_to_uint32(client.read_input_registers(1010, 2))) EDIT: int -> uint -
Firmware: WARP Energy Manager 1.0.1 Energiebilanz hinzugefügt LED-Blinken in Magenta bei Konfigurationsfehlern hinzugefügt Aggressives/Konservatives Regelverhalten hinzugefügt. Phasenumschaltungs-Zustand zur Statusseite hinzugefügt Anzeige interner Zustände zur Debug-Ansicht hinzugefügt Core Dump zu Debug-Report hinzugefügt Aussehen der Lademodus-Buttons verbessert Veraltete Statuswerte nach Trennung der WLAN-Verbindung entfernt Übersetzungen verbessert Sichergestellt, dass Mindestladeleistung für Min + PV-Modus nicht weniger als die für einen Ladevorgang notwendige Leistung sein kann Nicht unterstützten SDM72CTM von der Stromzählerseite entfernt Kontrollierte Wallboxen auf Statusseite zu klickbaren Links umgewandelt Sichergestellt, dass keine duplizierten Hosts in Konfiguration kontrollierter Wallboxen akzeptiert werden mDNS-Antworten die nicht von WARP Chargern gesendet wurden gefiltert Zeichnen negativer und großer Leistungswerte behoben Längenprüfung in Text- und Passwortfeldern repariert Häufige Ereignis-Log-Meldungen behoben Fehler-Feedback von Textfeldern repariert Passwort-Platzhaltertext der WLAN-Verbindungsseite repariert Löschen des WLAN-Verbindungspassworts repariert Fehlende Stromzählerwerte auf Stromzähler-Unterseite repariert Download: WARP Energy Manager 1.0.1
-
Noch eine Anmerkung dazu: Über den Kilometerstand musst du selbst Buch führen, der kann von einer Wallbox nicht ausgelesen werden. Bzw. je nach Auto kann dir da EVCC weiterhelfen: https://docs.evcc.io/docs/devices/vehicles EVCC funktioniert mit dem WARP Charger problemlos.
-
Debugging ESP32 (Ethernet) Brick
Thema antwortete auf rtrbts poohnet in: Software, Programmierung und externe Tools
Wenn du Abstürze debuggen willst hast du noch zwei weitere Optionen: Du bekommst du auf der seriellen Konsole beim Crash einen Backtrace, den du mit dem decode-Script (in esp32-firmware/software) dekodieren kannst. Das Script wählt automatisch die zuletzt gebaute ELF-Datei aus um den Backtrace zu dekodieren. Du kannst noch den Inhalt des PC-Registers (das ist der Program Counter, also die Instruktion die gerade ausgeführt wird) vorne an den Backtrace anhängen, dann wirds genauer. Wenn du also z.B. folgenden Backtrace bekommst: Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled. Core 1 register dump: PC : 0x40117aeb PS : 0x00060b30 A0 : 0x800ec077 A1 : 0x3ffc8e50 A2 : 0x3ffb6e74 A3 : 0x00000004 A4 : 0xffffffff A5 : 0x3ffc8dc8 A6 : 0x3ffc8e70 A7 : 0x00000000 A8 : 0x80117ae9 A9 : 0x3ffc8de0 A10 : 0x505a9d89 A11 : 0x505a9d89 A12 : 0x3ffc5608 A13 : 0x3ffb513c A14 : 0x3ffcef1c A15 : 0x3ffc9970 SAR : 0x00000015 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000004 LBEG : 0x4000c46c LEND : 0x4000c477 LCOUNT : 0x00000000 Backtrace: 0x40117ae8:0x3ffc8e50 0x400ec074:0x3ffc8e90 0x40179a1e:0x3ffc9190 dann kannst du den (mit PC-Register) so dekodieren: ./decode 0x40117aeb 0x40117ae8:0x3ffc8e50 0x400ec074:0x3ffc8e90 0x40179a1e:0x3ffc9190 und bekommst dann: Using toolchain-xtensa-esp32@8.4.0+2021r2-patch3 package 0x00000000: ?? ??:0 0x40117ae8: EVSEV2::setup() at /home/erik/Tinkerforge/esp32-firmware/software/src/modules/evse_v2/evse_v2.cpp:400 0x400ec074: setup() at /home/erik/Tinkerforge/esp32-firmware/software/src/main.cpp:244 0x40179a1e: loopTask(void*) at /home/erik/Tinkerforge/esp32-firmware/software/packages/arduino-esp32#warp2-2.0.9_9326b6026102e72489017bcf1c8fa08d0084e30f/cores/esp32/main.cpp:42 evse_v2.cpp Zeile 400 ist bei mir gerade int blah = *((int*)0x04); logger.printfln("%d\n", blah); um den Crash zu provozieren. Option zwei ist, dass der ESP, wenn er crasht, seit kurzem einen Coredump in die entsprechende Partition schreibt. Wenn du das Debug-Modul reinkompilierst, dann kannst du unter warp2-abc/debug/coredump.elf den Coredump runterladen und mit https://github.com/espressif/esp-coredump auseinandernehmen. -
This depends on your Arduino: 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.)
-
Teste am besten mal direkt unter freiem Himmel. Es gibt z.B. beschichtete Fenster durch die GPS nicht gut durchkommt.
-
WARP 1 -> WARP 2 - Teilaufrüstung
Thema antwortete auf rtrbts jensstark in: WARP Charger / Energy Manager
Je nachdem was du mit OCPP tun möchtest, solltest du dir auch ein NFC-Bricklet nachrüsten. Sonst kannst du nur über eine eventuelle App bzw. über den OCPP-Server Ladevorgänge freischalten. -
Debugging ESP32 (Ethernet) Brick
Thema antwortete auf rtrbts poohnet in: Software, Programmierung und externe Tools
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. -
brickv 2.4.23 läuft aus Source nicht mit Python < 3.7
Thema antwortete auf rtrbts remotecontrol in: Allgemeine Diskussionen
Die Prüfung die @photron in der main.py hinzugefügt hatte, fehlte an dieser Stelle. Habe ich gerade gefixt: https://github.com/Tinkerforge/brickv/commit/f80758c09fbe6890e66107ee4f7e95ea75fa7b8c Weitere Stellen wo wir auf sys.flags.dev_mode zugreifen habe ich nicht gefunden, d.h. es sollte bei dir jetzt laufen. -
Frage zur API: charge_tracker/last_charges
Thema antwortete auf rtrbts ocin4 in: WARP Charger / Energy Manager
Bei der last_charges-API fliegt dann der 1. raus und der 2. wird zum 1. usw. Die Nummerierung muss FHEM machen, in der API selbst ist das ein Array aus Objekten, d.h. das ist nicht explizit durchnummeriert. -
WLAN Key-Länge mit FW 2.1.0-63fddc77
Thema antwortete auf rtrbts UweH in: WARP Charger / Energy Manager
Kann ich bestätigen, das Frontend erlaubte wegen einem Validierungsbug nur max. 62 Zeichen. Wird mit 2.1.1 gefixt. -
Warp 1 erkennt Zähler nicht mehr
Thema antwortete auf rtrbts jkrner00 in: WARP Charger / Energy Manager
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? -
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: 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?
-
WARP2 mit neuer Firmwarew 2.1 trackt charges nicht mehr
Thema antwortete auf rtrbts wuesten_fuchs in: WARP Charger / Energy Manager
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? -
WARP2 mit neuer Firmwarew 2.1 trackt charges nicht mehr
Thema antwortete auf rtrbts wuesten_fuchs in: WARP Charger / Energy Manager
Zieh mal einen Debug-Report (unter System->Ereignis-Log). Weißt du noch wann genau du die Ladevorgänge gelöscht hast? Das sollte problemlos gehen. -
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.
-
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