rtrbt

Kurzes Update dazu: Das Problem scheint ja zu sein, dass der Energy Manager nach einem Neustart blockiert, bis EVCC einmal einen Phasenwechsel anfordert. Das haben wir auf unserer Seite behoben, nach einem Neustart des WEM bleibt die letzte Phaseneinstellung erhalten. Kommt mit Firmware 2.0.2.

Machen wir alles schon: https://github.com/Tinkerforge/evse-bricklet/blob/1892e31a648db0700fc45a944992ddc9f9077730/software/src/ads1118.c#L194

On 1/30/2024 at 2:56 PM, eweri said:

🤢 wann ist die WARP3 verfügbar?

Wir arbeiten dran :D

On 1/30/2024 at 8:47 PM, eweri said:

e-up von 16A runter, aber der e-up hat nur mit maximal 10A geladen (dafür müsste ich dann noch im Auto was änder)

Das ist okay. Wie viel das Auto tatsächlich zieht, beeinflusst die Messung nicht. Relevant ist nur, dass das Auto prinzipiell lädt bzw. für die anderen beiden Debug-Protokolle, dass es voll ist und nicht laden möchte.

An den Energy Manager direkt kannst du von Eastron den SDM630, SDM630-MCT-V2, SDM72-V2, von Eltako den DSZ15DZMOD und von YTL den DEM4A anschließen. Außerdem kannst du alle SunSpec-kompatiblen Zähler über eine Netzwerkverbindung auslesen.

Dann war die Kalibrierung für den e-up vermutlich zu stark. Damit wir dir eine bessere Kalibrierung erstellen können, müsstest du einmal alle relevanten Fälle wie folgt protokollieren:

• 16 A Ladestrom einstellen
• Ladeprotokoll starten
• Auto anschließen
• Warten bis es lädt
• in 1-Ampere-Schritten bis auf 6 A runtergehen, dazwischen immer ~ 20 bis 30 Sekunden warten. Wenn du dich den 6 A näherst, kann es sein, dass du dann das Schütz-Ping-Pong triffst.

Das ganze machst du mit dem e-up wenn er laden möchte, dann nochmal mit dem e-up wenn er voll ist und beides auch mit dem Hyundai. Das sollten also vier Protokolle werden, mit denen wir dir dann (hoffentlich! hat aber bisher immer geklappt) eine Kalibrierung erstellen können, bei der alles funktioniert.

Kein Problem.

energy_manager_firmware_2_0_1_65b77317_7046d2627114a44_merged.bin

Die Änderungen der Beta sind in der Energy Manager Firmware 2.0.0 btw. der Wallbox Firmware 2.2.0 enthalten.

Achtung: Beim Update von der Beta-Firmware auf WEM 2.0.0 muss eventuell die Schützkontrolle neu auf externe Steuerung (EVCC) konfiguriert werden! Beim Update von 1.0.8 auf 2.0.0 passiert das automatisch.

On 1/25/2024 at 6:45 PM, MatzeTF said:

Dann hattest du vorher wahrscheinlich die Beta-Firmware installiert. Danach ist das zu erwarten.

Ich hatte gestern nicht mehr daran gedacht, im Beta-Thread noch einen Hinweis darauf zu posten, sorry.

Benutzt du EVCC mit dem Energy Manager? Dann musst du ggfalls ein paar Tage warten, wir mussten Teile der API ändern, die von EVCC verwendet werden. Habe die Entwickler schon informiert. Falls du irgendetwas eigenes mit der externen Steuerung machst: wem/xyz/energy_manager/external_control_update heißt jetzt wem/xyz/power_manager/external_control_update weil wir das Modul aufgeteilt haben.

On 1/25/2024 at 9:05 PM, andyknownasabu said:

Ich wünsche mir immer noch, ähnlich dem Charger, HomeAssistant MQTT-Autodiscovery für den EnergyManager. Soll ich dafür ein Issue auf GitHub aufmachen oder ist das schon auf eurer Liste?

Steht auf der Liste: https://github.com/Tinkerforge/esp32-firmware/issues/218

Sorry für die späte Antwort, musste erst das Firmware-Release fertig bekommen.

On 1/22/2024 at 9:08 PM, eweri said:

macOS 13.6.3 (22G436) mit Safari Version 17.2.1 (18617.1.17.11.12, 18617) (keine aktiven Erweiterungen oder sonstige Manipulationen)

Ziemlich genau die Version habe ich auch getestet und hier funktionierts. Wir haben aber von einem anderen Kunden ähnliche Probleme gemeldet bekommen mit anderen Browsern und Betriebssystemen. Da muss irgendetwas auf Wallboxseite kaputt sein.

Kurz zur Erklärung, was überhaupt bei dem Ping-Pong passiert: Die Wallbox misst einen Widerstand (CP/PE), der vom Auto angelegt wird. Wenn kein Auto angeschlossen ist, ist das "unendlich", wenn ein Auto angeschlossen ist, aber (noch) keinen Strom anfordert sinds 2700 Ω, wenn das Auto Strom anfordert 880 Ω. Details hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung

Aufgrund dessen, wie die Signalisierung funktioniert, wird der Widerstand immer nur in einem kurzen Zeitfenster gemessen, die Länge davon hängt vom erlaubten Ladestrom ab. Bei 6 A ist die Messung deshalb maximal schlecht: Vor der Kalibrierung hat deine Box immer irgendwas zwischen 1700 und 1800 Ω gemessen, da liegt aber genau die Grenze für die Wallbox. Insgesamt sah das dann so aus:

(Rot mit rechter Achse der Widerstand, Blau mit linker Achse der Ladezustand. 1 ist "Auto will keinen Strom, Schütz nicht geschaltet", 2 ist "Auto will Strom, Schütz geschaltet")

Die Kalibrierung, die wir dir gegeben haben schiebt deshalb den gemessenen Wert etwas nach Unten, er landet dann bei ~ 1300 Ω

On 1/22/2024 at 9:24 PM, eweri said:

Hier die Ergebnisse vom Hyundai vorher und nach der Installation der Kalibrierungsdatei

Das sieht soweit gut aus. Du hast da aber auch 16 A freigegeben, teste sicherheitshalber bei Gelegenheit nochmal mit 6 A.

On 1/22/2024 at 9:53 PM, eweri said:

So ich also noch einmal nach draußen in die feuchte Kälte:

Kabel vom e-up getrennt, wieder ins Haus, Protokoll starten, wieder zum e-up Lade-Timer abgeschaltet, Kabel gesteckt, NFC-Dongle drangehalten, es klackt sofort in der WARP und im e-up, und es klackt sofort wieder. Es lädt nicht. Irgend wie alles komisch ich halte noch einmal den Dongle an die WARP, es klackt wieder, diesmal lädt der e-up mit 2,7kW was ca. 5,6A entspricht. Eigentlich sollte der e-up aber mit 5A laden (nachträgliche Korrektur: 10A sind wohl richtiger, siehe Beitrag unten).

Wenn man sich im Energieverbrauch vom Volkszähler das ansieht, dann war der erste Klack wirklich nur mit 2,3kW und der zweite Klack hat dann erst 2,7kW gemacht. 

Ist jetzt evcc das Problem? Ich steige nicht so ganz mehr durch.

Ich glaube, da hattest du einfach Pech mit dem NFC-Tag: Im Debug-Report sehe ich, dass genau als das Auto anfangen wollte zu laden, die Nutzerfreigabe blockiert hat:

Der Ladevorgang lief kurz, dann hast du vermutlich das Tag nochmal drangehalten, das stoppte den Ladevorgang und später hast du wieder freigegeben und es wurde weitergeladen. Während des ganzen Ladevorgangs hat EVCC auf 6 A limitiert. Das ist das Minimum, was die Wallbox dem Auto kommunizieren kann. D.h. wenn du im Auto 5 A einstellst, muss die Wallbox trotzdem 6 A erlauben und das Auto zieht dann halt weniger.

On 1/22/2024 at 10:12 PM, eweri said:

Wenn die 60% erreicht sind, wechselt die Lade-Steuerung wieder auf die Zeitsteuerung und die sagt "5A, 80% SoC und bitte um 6:50 Uhr fertig". Am Tage habe ich "32A, 80% SoC und bitte um 17 Uhr fertig" das in Verbindung mit evcc "Min+PV" sollte mir am Tag das Laden mit PV-Überschuss ermöglichen. 

Mache ich einen Denkfehler?

Nein, das sollte soweit funktionieren. EVCC gibt dir bei Min+PV ja mindestens 6 A + was an Überschuss da ist und das Auto sollte dann alles verwenden, wenn du es auf 32 A gestellt hast.

On 1/24/2024 at 10:36 PM, eweri said:

Heute Abend habe ich den e-up angesteckt und jetzt lädt er mit 5A komplett ohne Ping-Pong.

D.h. jetzt ist alles gut? :D

Danke!

Teste mal die Kalibrierungsdatei im Anhang. Die kannst du unter Wallbox -> Ladecontroller hochladen (Low-Level-Zustand aufklappen, dann ganz unten unter Kalibrierung) Falls du damit den e-up mit 6 Ampere laden kannst, versuch bitte auch nochmal den Hyundai.

Abgesehen davon würde ich gerne dem Ladeprotokoll-Problem mit Safari nachgehen wollen. Mit welcher Safari-Version hast du das probiert? Und auf was für einem System?

calibration.json

The pin numbers have changed for the Pi 5. Try this instead:.

bricklet.group0.spidev = /dev/spidev0.0

bricklet.group0.cs0.driver = gpio
bricklet.group0.cs0.name = gpio422
bricklet.group0.cs0.num = 422

bricklet.group0.cs1.driver = gpio
bricklet.group0.cs1.name = gpio421
bricklet.group0.cs1.num = 421

bricklet.group0.cs2.driver = gpio
bricklet.group0.cs2.name = gpio424
bricklet.group0.cs2.num = 424

bricklet.group0.cs3.driver = gpio
bricklet.group0.cs3.name = gpio425
bricklet.group0.cs3.num = 425

bricklet.group0.cs4.driver = gpio
bricklet.group0.cs4.name = gpio426
bricklet.group0.cs4.num = 426

bricklet.group0.cs5.driver = gpio
bricklet.group0.cs5.name = gpio423
bricklet.group0.cs5.num = 423

#bricklet.group0.cs6.driver = gpio
#bricklet.group0.cs6.name = gpio406
#bricklet.group0.cs6.num = 406

bricklet.group0.cs7.driver = gpio
bricklet.group0.cs7.name = gpio405
bricklet.group0.cs7.num = 405

bricklet.group0.cs8.driver = gpio
bricklet.group0.cs8.name = gpio404
bricklet.group0.cs8.num = 404

Port G is disabled with this config, because the pin for port G is already marked as in use by Raspberry Pi OS.

For this to work, you also have to enable the SPI device manually with raspi-config (Interface Options -> SPI) and then restart.

If Brick Daemon starts with this config, please check again that the HAT firmware is up to date with Brick Viewer. Also open the HAT Bricks tab to check whether the HAT is stuck in bootloader mode. Brick Viewer will then show only this:

If the HAT is stuck in bootloader mode, reflash the HAT and restart the Pi. Then I would assume that Brick Daemons output contains the following lines:

2024-01-22 15:19:08.678489 <I> <bricklet.c:304> Found supported HAT product_id 0x084e in device tree, using default HAT Brick config
2024-01-22 15:19:08.678495 <I> <bricklet.c:341> Found Bricklet port A (spidev: /dev/spidev0.0, driver: gpio, name: gpio422, num: 422)
2024-01-22 15:19:08.678530 <I> <bricklet_stack_linux.c:87> Using spidev backend for Bricklets (unsupported suffix 5 after 'Raspberry Pi' in /proc/device-tree/model)
2024-01-22 15:19:08.679837 <I> <bricklet.c:341> Found Bricklet port B (spidev: /dev/spidev0.0, driver: gpio, name: gpio421, num: 421)
2024-01-22 15:19:08.680329 <I> <bricklet.c:341> Found Bricklet port C (spidev: /dev/spidev0.0, driver: gpio, name: gpio424, num: 424)
2024-01-22 15:19:08.680708 <I> <bricklet.c:341> Found Bricklet port D (spidev: /dev/spidev0.0, driver: gpio, name: gpio425, num: 425)
2024-01-22 15:19:08.681120 <I> <bricklet.c:341> Found Bricklet port E (spidev: /dev/spidev0.0, driver: gpio, name: gpio426, num: 426)
2024-01-22 15:19:08.681975 <I> <bricklet.c:341> Found Bricklet port F (spidev: /dev/spidev0.0, driver: gpio, name: gpio423, num: 423)
2024-01-22 15:19:08.682363 <I> <bricklet.c:341> Found Bricklet port G (spidev: /dev/spidev0.0, driver: gpio, name: gpio406, num: 406)
2024-01-22 15:19:08.682811 <I> <bricklet.c:341> Found Bricklet port H (spidev: /dev/spidev0.0, driver: gpio, name: gpio405, num: 405)
2024-01-22 15:19:08.683247 <I> <bricklet.c:341> Found Bricklet port I (spidev: /dev/spidev0.0, driver: gpio, name: gpio404, num: 404)

If you get "Found supported HAT..." the HAT and all ports should work again-

On 1/22/2024 at 11:22 AM, LPD said:

2024-01-22 11:14:31.411173 <E> <socket.c:244> Could not bind IPv4 server socket to '0.0.0.0' resolved from '0.0.0.0' on port 4223: EADDRINUSE (98)

Da läuft vermutlich noch eine brickd-Instanz (eventuell als service). Du kannst dir die Logs aber auch in /var/log/brickd.log ansehen

Das Problem ist vermutlich, dass EVCC die externe Steuerung zwar benutzt, aber nicht einstellt, dass Ladevorgänge blockiert sein sollen, wenn die Wallbox komplett neustartet (wie z.B. nach einem Stromausfall). Im Webinterface der Wallbox gibt es dafür im Moment keine Einstellung, aber du kannst das von Hand machen: Gehe auf http://warp2-abcd/recovery (warp2-abcd durch den Namen deiner Wallbox ersetzen) und trage da im Abschnitt API in das obere Textfeld folgendes ein:

{"method":"PUT", "url":"/evse/external_defaults_update", "payload":{"current": 0,"clear_on_disconnect": null}}

Dann klicke auf "Call API" und dann sollte im unteren Textfeld eine 200 erscheinen.

Ab dann ist bei einem kompletten Neustart die Wallbox blockiert, bis EVCC über die externe Steuerung das Laden freigibt.

Das ist sehr interessant. Anscheinend benutzt Raspberry Pi OS/Debian seit kurzen 16K Pages auf dem Raspberry Pi 5 und damit kann diverse Software nicht umgehen: https://github.com/raspberrypi/bookworm-feedback/issues/107

Mir ist spontan nicht klar, warum bei meinen Tests mit dem Pi 5 alles geklappt hatte und du da jetzt reinläufst, da müssen wir nochmal draufschauen. Ein paar Fragen dazu:

• Hast du Raspberry Pi OS oder ein "echtes" Debian von hier: https://raspi.debian.net/ installiert?
• Hast du das Betriebssystem frisch für den Pi 5 installiert oder eine ältere Installation  für den Pi 5 weiter verwendet?

Als einfachen Fix für dich: Laut https://github.com/raspberrypi/bookworm-feedback/issues/107#issuecomment-1773810662 kannst du auf einen Kernel, der 4K Pages verwendet, wechseln, indem du in /boot/config.txt folgendes einträgst:

kernel=kernel8.img

Damit sollten die Probleme weg sein.

Try

extern Dimmer dimmer;

and then

void set_iao_out(uint16_t voltage)
{
    tf_industrial_analog_out_v2_set_voltage(&dimmer.iao, voltage);
}

instead.

This should work because all modules are instanciated in the generated file src/modules.cpp.

Was du angehangen hast ist ein Ladeprotokoll, aber aus irgendeinem Grund fehlt der relevante Teil in der Mitte. Hattest du den Browser zwischenzeitlich geschlossen bzw. hatte das Webinterface die Verbindung verloren o.Ä.? Das Protokoll wird in dem Browser-Tab aufgesammelt, in dem du Start klickst.

To use the HAT Brick with a Raspberry Pi 5, you'll have to update the HAT's firmware to 2.0.4 and install Brick Daemon 2.4.5 on the Pi. Updating the HAT Firmware with only a Pi 5 is possible but difficult. Can you temporarily plug the HAT on an older Pi, install Brick Daemon there and update the HAT Firmware with Brick Viewer?

Problem 1 sollte hiermit gelöst sein (kommt in der nächsten Firmware):

On 1/14/2024 at 7:21 AM, wuesten_fuchs said:

Und Zusatzfrage: könnten vielleicht die 0-Ladevorgänge einfach "vergessen" werden?

Dafür habe ich ein Issue aufgemacht. https://github.com/Tinkerforge/esp32-firmware/issues/311

Mit der Firmware im Anhang kannst du die CP-Trennungszeit einstellen. Zumindest für die CP-Trennung, die der WEM durchführt um die Phasen zu wechseln. Es gibt eine neue API energy_manager/cp_reconnect_delay, mit der du die Zeit, die CP getrennt ist, erhöhen kannst. Standardmäßig steht das auf 0, also ist CP nur getrennt solange wie es dauert die Phasen zu wechseln. Du kannst aber bis zu 255 (Sekunden) Verzögerung setzen, z.B. so für 30 Sekunden:

curl http://wem-abcd/energy_manager/cp_reconnect_delay -d 30 

Wenn du die Zeit setzt, musst du nicht neustarten, aber benutze die API lieber nicht während gerade ein Phasenwechsel läuft.

Abgesehen von der Änderung sollte die Firmware identisch zu WEM 1.0.8 sein.

energy_manager_firmware_1_0_8_65a153e2_720dd21df1e5f58__merged.bin

On 1/11/2024 at 2:23 PM, fridolin11 said:

Ist meine Angabe bei "First Input Number" korrekt? Ich würde gerne wie nach Anleitung bei Addresse 200 die Messwerte auslesen, und so wie ich die Tinkerforge Dokumentation verstanden habe hat das Input Register den Prefix 3.

Da ist Modbus leider etwas verwirrend: Es gibt Registernummern, die bei 1 beginnen und Registeradressen, die bei 0 beginnen. Also z.B. das Register mit der Adresse 200 hat die Registernummer 201. Viele Hersteller bringen das auch in den Anleitungen durcheinander.

Außerdem gibt es die Präfixe, die im Endeffekt den Typ des Registers angeben (Weshalb die oft weggelassen werden):

• 0 für Coils (les- und schreibbare 1-Bit-Werte)
• 1 für Discrete Inputs (nur lesbare 1-Bit-Werte)
• 3 für Input Registers (nur lesbare 16-Bit-Werte)
• 4 für Holding Registers (les- und schreibbare 16-Bit-Werte)

Iin deinem Fall kann es also sein, dass du nicht bei 300200 anfangen musst zu lesen, sondern bei 300199 oder 300201.

Um zu testen, ob die Kommunikation prinzipiell funktioniert, kannst du auch mit "Read Holding Registers" das Register 401100 (oder 401099 oder 401101) lesen. Da solltest du eine 1 zurückbekommen, weil dort die Slave-Adresse steht.

Nochmal für mein Verständnis:

Normalerweise funktioniert es mit Energy Manager nicht, und du siehst, dass er der Wallbox immer erst 8 A zuteilt, statt den erwarteten 16 A. Das ist erstmal unerwartet, dazu haben wir sber kein Energy Manager Log mit aktivem Stromverteilungsprotokoll (Im Log unten die Einträge ab "Redistributing current")

In deinen Logs vom 13.12. hattest du aber den Fall, dass sofort 16 A zugewiesen wurden, das Auto lädt aber trotzdem nicht. Da bleibt die Frage, ob das ein einmaliger Effekt war, oder ob völlig egal ist, ob der WEM 8 oder 16 A zuteilt. Im Log sieht das dann so aus:

2023-12-13 16:38:25,601  Redistributing current
2023-12-13 16:38:25,602      1 charger requests current. 16000 mA available.
2023-12-13 16:38:25,602      stage 0: Calculated target for warp2-Garage (warp2-Garage.local) of 8000 mA. 8000 mA left.
2023-12-13 16:38:25,612      stage 0: 8000 mA still available. Recalculating targets.
2023-12-13 16:38:25,623      stage 0: Recalculated target for warp2-Garage (warp2-Garage.local) of 16000 mA. 0 mA left.
2023-12-13 16:38:25,634      stage 2: Unthrottled warp2-Garage (warp2-Garage.local) to 16000 mA.

Man sieht, dass erst 8 A zugeteilt werden, dann aber sofort auf 16 A erhöht wird. Die 8 A werden auch nicht zur Wallbox geschickt, sondern erst das, was in stage 1 oder 2 berechnet wird.

Kannst du nochmal versuchen mit aktivem Stromverteilungsprotokoll (das sollte dauerhaft aktiv sein wenn du es nicht per curl wieder deaktiviert hast) zu erzeugen, dass der WEM nur 8 A zuteilt?

Moin,

Als vorzeitiges Weihnachtsgeschenk findet Ihr im Anhang jeweils eine Beta-Version der WARP(2) Charger Firmware 2.2.0 und eine Beta-Version der WARP Energy Manager Firmware 2.0.0 mit folgenden Änderungen:

(genauere Dokumentation folgt mit den nicht-Beta-Firmwares im neuen Jahr)

API des Energy Managers geändert

An der API des Energy Managers mussten wir einige Änderungen vornehmen, da bisher Regeln ähnlich zur Automatisierung (siehe nächster Punkt) in energy_manager/config gespeichert wurden.

Automatisierung

Im Menüpunkt Wallbox -> Automatisierung, bzw. Energy Manager -> Automatisierung können bis zu 14 Regeln konfiguriert werden, die festlegen, wie Wallbox oder Energy Manager auf bestimmte Ereignisse reagieren. Es kann beispielsweise auf einen der Schalteingänge, eine MQTT-Nachricht, ein NFC-Tag usw. reagiert werden und, falls eins der Ereignisse eintritt, können verschiedene Aktionen ausgelöst werden.

Hier ein paar Beispiele:

Verbessere Stromzählerbehandlung

Wie schon in der SunSpec-Beta beschreiben, haben wir in den vergangenen Monaten die Behandlung von Stromzählern umgestellt

Der Energy Manager kann jetzt Werte von bis zu 7 Stromzählern auslesen, die Wallboxen bis zu 2 Stromzähler. Beide Geräte können Stromzähler per SunSpec auslesen, außerdem haben wir einen anpassbaren API-Zähler hinzugefügt.

Die alte API, die nur mit einem Stromzähler arbeiten kann, unterstützen wir weiterhin, damit bestehende Software weiter funktioniert. Die alte API liest immer den ersten konfigurierten Stromzähler.

Das schreiben von Stromzählerwerten über die alte API ist weiterhin möglich, bei Wallboxen muss aber zunächst ein API-Zähler auf der ersten Position angelegt werden, der beispielsweise die SDM630-Vorlage verwenden kann.

Weitere Änderungen

- Unterstützung für WPA Enterprise EAP-TLS, EAP-PEAP und EAP-TTLS hinzugefügt
- (nur WARP2/WEM) Unterstützung für Eltako DSZ15DZMOD und YTL DEM4A hinzugefügt
- Unterstützung für zurücksetzbare Import/Export-Energie-Werte hinzugefügt
- Auf Import-Energie für Ladetracker, usw gewechselt. Der Wechsel wird durchgeführt, wenn alle getrackten Ladevorgänge gelöscht werden
- (nur WARP2/WEM) Unterstützung für bis zu 32 gesteuerte Wallboxen hinzugefügt
- (nur WARP2) Unterstützung für bis zu 32 NFC-Tags und Benutzer hinzugefügt
- API zum Neustarten der Zeit-/Energielimits hinzugefügt
- Warnung im Ereignislog hinzugefügt, wenn Stromzähler hängt
- Warnung im Ereignislog hinzugefügt, wenn LAN- und WLAN-Verbindung parallel benutzt werden
- (nur WARP2) OCPP-Transaktions-ID zu gesendeten Stromzählerwerten hinzugefügt
- Übersetzungen verbessert
- Behandung von Lastmanagement-Paket-Bursts verbessert
- Performance beim Senden großer MQTT-Datenmengen verbessert
- OCPP-UI verbesser
- Robustheit und Geschwindigkeit des WLAN-Access-Point, während eine WLAN-Verbindung aufgebaut wird, verbessert
- Fehlerrückmeldung im Webinterface verbessert
- (nur WARP2) DC-Fehlerstromschutz-Statusanzeige verbessert. Unterstützung für X804 hinzugefügt. (EVSE Bricklet firmware 2.2.0)
- (nur WARP2) Diodenerkennung verbessert (EVSE Bricklet firmware 2.2.0)
- (nur WARP2) Anzeige von Schütz- und PE-Fehlern aufgeteilt
- Hinweis auf aktives Capslock bei Passworteingabefeldern hinzugefügt
- Unterstützung von TLS-Versionen älter als 1.2 entfernt
- Hinzugefügt, dass WLAN-Access-Point als Fallback 5 Minuten aktiv bleibt, wenn innerhalb der ersten 30 Sekunden nach Start keine Netzwerkverbindung aufgebaut wurde
- Sichergestellt, dass sich zum WLAN-AP mit dem besten Empfangswert verbunden wird
- Sichergestellt, dass nur funktionierende Subnetzmasken für WLAN-Access-Point konfiguriert werden können
- Sichergestellt, dass Lastmanager erst Strom verteilt, wenn alle gesteuerten Wallboxen erreichbar sind
- RFID-Tag-Registers im Keba-Emulationsmodus repariert, wenn kein Stromzähler verfügbar ist
- Sichergestellt, dass Webinterface nicht nicht existierende IDs referenziert
- Änderung von TLS-Zertifikaten repariert
- Hinzugefügt, dass Zuordnung von NFC-Tags zu Nutzern beim Neustart repariert wird
- Sichergestellt, dass der Zurück-Button des Browsers immer funktioniert
- Tastatureingabe in Datumseingabefeldern repariert
- Wertebereich des Ladestroms in der MQTT-Auto-Discovery repariert

energy_manager_firmware_1_0_95_65847481_merged.bin warp2_firmware_2_1_90_6584744a_merged.bin warp_firmware_2_1_90_658473e6_merged.bin