rtrbt

Prinzipiell: So neu, wie die ganze Spezifikation ist, kannst du davon ausgehen, dass Stand heute kaum ein Netzbetreiber schon die Infrastruktur für die Drosselung hat.

On 12/12/2023 at 6:11 AM, merger said:

1) Wie wird das technisch umgesetzt? D.h. wie kommt das Signal zur Drosselung vom EVU in die Wallbox?

Laut https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/BSI_TR-03109-5_231112.html ist das hier die Spec:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03109/TR-03109-5_Kommunikationsadapter.pdf

Das Setup scheint zu sein, dass ein Smart Meter (Gateway) mit "CLS" per TLS redet und als TLS-Proxy dem Netzbetreiber darauf direkt Zugriff gibt. Das CLS ist aber soweit ich das verstehe ein separates Stück Hardware.

(Ich habe noch noch raus was das sein soll, auf der BSI-Seite wird das zu Certified Lotus Specialist expandiert. Die Abkürzung ist anscheinend doppelt belegt :D )

On 12/12/2023 at 6:11 AM, merger said:

2) Kann die WARP2 das auch bzw. sind jetzt verkaufte WARPs darauf bereits vorbereitet?

Das kommt darauf an, wie du das siehst: Laut der Spec übersetzt ein CLS von der standardisierten Schnittstelle über TLS (für die Netzbetreiber) auf etwas spezifisches für die Geräte die gesteuert werden sollen. Da du die WARP2 per OCPP, Modbus TCP, MQTT, HTTP, dem Abschalteingang usw. steuern kannst, würde ich erwarten, dass sich eine CLS findet, die die Wallbox steuern kann. Falls sich da ein Standard etabliert, der eins der Standardprotokolle spricht, werden die Wallboxen damit funktionieren, notfalls über ein Firmware-Update, falls wir da konkret irgendetwas fixen müssen.

 

Hier der versprochene detaillierte Post. (Überspring einfach was du schon weißt).

Kommunikation zwischen Wallbox und Auto

Die ganze Kommunikation zwischen Wallbox und Auto funktioniert wie folgt: Es gibt den Kontakt CP (Control Pilot), an den die Wallbox 12V anlegt. Wenn du ein Auto ansteckst, verbindet das Auto CP und Ground mit einem 2,7kΩ Widerstand, woraufhin die Spannung auf 9V fällt. Auto und Wallbox können diese Spannung messen und sehen deshalb beide (du könntest ja eine Wallbox mit Dose haben), dass das Kabel verbunden ist.

Die Wallbox kann auf CP ein 1kHZ-PWM anlegen und anhand des Duty-Cycle (also des Verhältnisses zwischen der Zeit, die 12V und der Zeit die 0V anliegen) kommunizieren, wie viel Strom das Auto maximal ziehen darf. Wenn kein Strom verfügbar ist (weil z.B. EVCC gerade blockiert in deinem Setup), dann liegt die ganze Zeit 12V an.

Wenn Strom verfügbar ist, also das CP-PWM läuft, dann darf das Auto einen weiteren Widerstand zwischen CP und Ground parallel schalten, sodass insgesamt 880Ω anliegen, die Spannung fällt dann auf 6V. Sobald die Wallbox das sieht, schaltet sie das Schütz und das Auto bekommt Strom.

Mehr dazu hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung

tl;dr: Die Wallbox signalisiert also dem Auto, wie viel Strom maximal zur Verfügung steht, das Auto kann dann auf "Ich möchte laden" wechseln und wenn es das tut, schaltet die Wallbox das Schütz.

Jetzt der Interessante Teil: Wenn das Auto nicht 30 Sekunden, nachdem die Wallbox Strom anbietet, den Widerstand anlegt und damit signalisiert, dass es laden möchte, geht die Wallbox davon aus, dass die Ladeelektronik des Autos im Stand-By ist. Wenn jetzt der "Fahrzeugweckruf" aktiviert ist, trennt die Wallbox CP für 4 Sekunden und verbindet CP danach wieder. Aus Sicht des Autos sieht das so aus, als ob das Ladekabel auf Wallboxseite rausgezogen wurde und nach 4 Sekunden wieder eingesteckt. Wenn CP wieder verbunden wurde, läuft sofort das PWM, also ist aus Sicht des Autos sofort Strom verfügbar. Laut IEC-Spezifikation ist das das Vorgehen, um ein Auto aufzuwecken. Das ist aber in der Spezifikation relativ neu, nur informativ und bezieht sich auf "difficulties encountered with some legacy EVs".

Kommunikation zwischen Energy Manager und Wallbox

Der Energy Manager benutzt das Lastmanagementprotokoll um Wallboxen zu steuern. Das ist eigentlich relativ trivial: Der Energy Manager gibt einer Wallbox sekündlich vor, wie viel Strom sie maximal einem Auto anbieten darf, und außerdem ob CP getrennt oder verbunden sein soll. Der Energy Manager muss CP trennen können, da es ein paar Autos (z.B. alte Zoes) gibt, deren Ladeelektronik kaputt geht, wenn die Wallbox von ein- auf dreiphasig wechselt, während das Auto angeschlossen ist.

Das Vorgehen, wenn der Energy Manager einen Phasenwechsel macht ist also:

• Alle Wallboxen auf 0 Ampere runterregeln
• Warten bis alle Schütze abgeschaltet sind
• CP an allen Wallboxen trennen
• Zwischen ein- und dreiphasig wechseln
• CP an allen Wallboxen verbinden und Strom wieder verteilen

Aus Sicht des Autos ist das dann so, als ob du das Kabel an einer einphasigen Wallbox abgezogen hast und in eine dreiphasige eingesteckt, ohne dabei das andere Ende des Kabels aus dem Auto zu ziehen.

EVCC, Energy Manager und Wallbox

EVCC kann WARP-Wallboxen steuern und über den Energy Manager auf die Phasenumschaltung steuern. Aus Sicht von EVCC wird nur die Wallbox gesteuert (indem der maximale Ladestrom vorgegeben wird) und zusätzlich kann EVCC beim Energy Manager einen Phasenwechsel anfordern. Das ist aber auch alles, was EVCC in dem Aufbau tut. Insbesondere steuert EVCC nicht direkt die CP-Trennung.

Problem bei deinem Aufbau

Das hier ist ein Plot aus dem Debug-Log von oben, mit Energy Manager und aktivem Fahrzeugweckruf. Der charger_state ist 1, wenn ein Auto angeschlossen ist, die Wallbox ihm aber keinen Strom zur Verfügung stellt. Er ist 2, wenn die Wallbox Strom zur Verfügung stellt, das Auto aber nicht laden möchte.

Im Plot siehst du, dass CP einmal bei ~ 230 getrennt wird, das ist die Phasenumschaltung des Energy Managers. CP wird dann wieder verbunden und ab dem Moment stehen dem Auto 8 Ampere zur Verfügung. (Auffällig ist hier, dass das Lastmanagement des Energy Managers nur 8 Ampere zur Verfügung stellt, EVCC aber 16 Ampere)

Das Auto reagiert dann nicht auf den verfügbaren Strom, weshalb nach 30 Sekunden (bei Eintrag 890) die Wallbox von sich aus nochmal CP trennt und wieder verbindet.

Wenn das ganze funktionieren würde, sähe es so aus:

Das ist gerade mit einem der Corsas aufgenommen, Aufbau ist der selbe: EVCC steuert WARP2 und Energy Manager. Hier legt das Auto nach der CP-Trennung (für den Phasenwechsel) den zweiten Widerstand an, fordert also Strom an und das Schütz wird geschaltet (Das ist charger_state 3)

In den Reports, bei denen dein Auto anfängt zu laden, sehen die Daten ähnlich aus.

Was jetzt?

Du könntest noch folgendes versuchen: Eventuell ist das Problem wirklich, dass dein Auto manchmal eine längere CP-Trennung braucht und du diesen Fall (warum auch immer) nur erzeugen kannst, wenn die Phasenumschaltung per Energy Manager im Spiel ist. Du kannst aber die CP-Trennung nicht von Hand steuern, wenn der Energy Manager sie steuert.

Folgender Trick sollte aber funktionieren:

• Stelle nochmal den Zustand her, dass dein Auto nicht lädt, obwohl es sollte
• Ziehe dann am Energy Manager das LAN-Kabel raus. Das führt dazu, dass er nicht mehr Pakete an die Wallbox schicken kann, die CP verbinden oder trennen
• Stelle dann auf der Wallbox das Lastmanagement von "fremdgesteuert" auf "deaktiviert", speichere das und starte nicht neu! Das Webinterface behauptet zwar, dass das erst nach einem Neustart wirkt, diese spezifische Einstellung greift aber sofort.
• Du solltest jetzt wieder über die evse/control_pilot_disconnect-API CP trennen und verbinden können.

Damit kannst du testen, ob eine längere CP-Trennung (z.B. 3 Minuten) in dieser spezifischen Situation hilft. Wenn das der Fall ist, müssen wir die Länge der CP-Trennung konfigurierbar machen, bzw. einen Peugeot-Modus einbauen.

Noch ein anderer Gedanke: Hast du das Problem nur mit dem Peugeot an einer Wallbox oder an beiden?

On 12/6/2023 at 6:48 PM, wolkenschaufler said:

Kann es nicht doch auch an evcc liegen? Ich weiß nicht, was evcc genau alles steuert, aber CP-Trennung ist wohl auch mit dabei.

Würde ich nicht erwarten. Ich habe sicherheitshalber evcc einmal aufgesetzt, testen kann ich das aber erst morgen mit dem Fahrzeug vom Kollegen. Ich melde mich dann nochmal detaillierter.

Sorry, ich schaffe es heute nicht mehr, dir einen detaillierteren Post zu schreiben. Teste bitte nochmal folgendes:

• Lastmanagement auf der Wallbox deaktivieren
• EVCC bzw. externe Steuerung auf der Wallbox deaktivieren
• Manuelle Ladefreigabe aktivieren
• Auto anstecken (es sollte nicht anfangen zu laden)
• Warten bis das Auto eingeschlafen ist
• Ladeprotokoll starten
• folgendes ausführen:

  curl 'http://warp2-Garage/evse/control_pilot_disconnect' -d 'true' && sleep 5 && curl 'http://warp2-Garage/evse/start_charging' -d 'null' && curl 'http://warp2-Garage/evse/control_pilot_disconnect' -d 'false'

  (Damit wird CP getrennt, 5 Sekunden gewartet, der Ladestrom freigegeben und CP verbunden. Du kannst unter Wallbox ->Ladestatus -> Low Level Zustand auch dabei zusehen, wie CP getrennt und dann wieder verbunden wird)

Das sollte äquivalent zu dem sein, was der Energy Manager tut. Wenn das Auto bei diesem Test auch nicht anfängt zu laden, liegt es am Timing aus CP verbinden und dem PWM mit dem wir den Strom vorgeben.

Hm das Timing bei dem Protokoll mit WEM ist sehr interessant. Ich versuche das morgen mal auf meinem Tisch zu erzeugen, und melde mich dann nochmal.

Damit mein Verständnis richtig ist: Du musst, damit das Auto aufwacht nicht von Hand die API benutzen, sondern auf der Wallbox unter Lastmanagement von "Fremdgesteuert" auf "Deaktiviert" umzustellen reicht?

Erstelle bitte von beiden Varianten (also mit Lastmanagement über den WEM und ohne) jeweils ein Ladeprotokoll: Dafür unter Wallbox->Ladestatus bei Ladeprotokoll auf Start klicken, den Tab auflassen (das Protokoll wird im Browser gesammelt) und dann den Ladevorgang starten, bzw. Strom freigeben. Dann sollte das Auto in der einen Variante ja nach ~ 30 Sekunden aufwachen und in der anderen nicht. D.h. wenn du lange genug gewartet hast, dass das Auto aufgewacht ist, bzw. hätte aufwachen sollen, kannst du auf Stop+Download klicken.

In den Ladeprotokollen sollen wir dann sehen, was genau auf CP passiert.

 

Das ist sehr interessant. Hast du die aktuelle Wallbox-Firmware laufen? In Firmware 2.1.2 oder älter gab es das Problem, dass das Lastmanagement die CP-Trennung stört.

On 12/4/2023 at 10:03 AM, Blahhuber said:

Der Hinweis mit Functions Code 4, wäre super wenn die bei der Registe Anzeige in der Wallbox stehen würde. Auch die lese/schreib Folge wäre super.

Guter Punkt. Füge ich gleich ein.

On 12/4/2023 at 10:03 AM, Blahhuber said:

Welche Slave ID wäre noch interessant? SMA will z.b. will 3, andere 255. Welche wollt ihr?

Die ist egal. Die Modbus-TCP-Implementierung ignoriert die Slave-ID komplett.

On 12/4/2023 at 9:38 AM, Blahhuber said:

Oh doch doch, die Keba Register kann ich sogar perfekt schreiben um den Ladestrom vor zugeben oder die Ladung zu starten/stoppen. Das klappt bereits ohne Probleme.

Ah, sorry. Ich meinte z.B. Register 1000 (der Ladezustand). Den zu schreiben ergibt keinen Sinn, deshalb hat das keinen Effekt wenn du das tust.

On 12/4/2023 at 9:38 AM, Blahhuber said:

Eure Register habe ich versucht mit Funktionscode 3 und 4 zu lesen. Es muss also 4 sein, alles klar. Wie schreibt ihr Register? 06 oder 16?

Das sind alles 32-Bit-Werte also brauchst du 16 (Write Multiple Holding Registers). Wenn der Wert, den du schreiben willst nur 16 Bit groß ist, kannst du aber auch 06 benutzen, wenn die anderen 16 Bit (also das andere Register) schon auf 0 steht.

Also wenn du z.B. 6000 (in Hex 0x1770) auf das Holding Register 1003 schreibst (mit 06) dann setzt es den Ladestrom auf 6 Ampere. "Korrekter" wäre aber auf Register 1002 mit Code 16 eine 0x00001770 zu schreiben. Funktionieren sollte beides.

Die Keba-Register sind (obwohl du sie nur lesen, nicht schreiben kannst) Holding Register, die du mit Function Code 3 (Read Multiple Holding Registers) lesen kannst. Bei unserem Registersatz sind Register, die du nur lesen kannst Input Register, die du mit Function Code 4 (Read Input Registers) lesen musst.

Edit: Die Register sind in der Tat 16 Bit lang, aber fast alle Werte sind 32 Bit lang und liegen deshalb in zwei Registern hintereinander. Das ist bei dem Keba-Registersatz aber auch so.

Dafür musst du dir die Firmware nicht bauen, du kannst den CP-Disconnect per API kontrollieren. Den aktuellen Zustand siehst du unter Wallbox -> Ladestatus, Low-Level-Zustand aufklappen, 3. Zeile der GPIO, der letzte in der Zeile (ist links auch beschriftet als CP-Disconnect). Wenn der Pin auf Low steht, ist CP verbunden, wenn er auf High steht, ist CP getrennt.

CP trennen kannst du im einfachsten Fall auf der Kommandozeile mit curl. Zum Trennen:

curl http://warp2-abcd/evse/control_pilot_disconnect -d true

Zum Verbinden:

curl http://warp2-abcd/evse/control_pilot_disconnect -d false

 

Falls du kein curl zur Hand hast, kannst du die Recovery-Seite der Wallbox benutzen: Unter http://warp2-abcd/recovery bei API folgendes zum Trennen eintragen:

{"method": "PUT", "url":"/evse/control_pilot_disconnect", "payload": true}

Zum Verbinden:

{"method": "PUT", "url":"/evse/control_pilot_disconnect", "payload": false}

Und dann auf Call API klicken. Wenn es klappt bekommst du darunter eine 200 angezeigt.

 

Wenn du das testen willst, solltest du davor unter Wallbox -> Ladeeinstellungen den Fahrzeugwegruf deaktivieren damit der Ladecontroller nicht selbst CP-(Dis)connects auslöst während du testest.

Dann ist das auf jeden Fall das Problem: Die Wallbox trennt im Moment für 4 Sekunden, weil die IEC-Spezifikation das so vorgibt. (Fairerweise als Minimum und im Abschnitt "Information on difficulties encountered with some legacy EVs for wake-up after a long period of inactivity (informative)" )

Ich bespreche mal mit meinem Kollegen, wie wir damit umgehen.

Der Corsa scheint das Problem nicht zu haben: Wir haben einem davon heute 6 Stunden lang angeschlossen gehabt und erst danach den Strom freigegeben. Er hat sofort angefangen zu laden.

Nur sicherheitshalber: Hast du unter Wallbox -> Ladeeinstellungen den Fahrzeugweckruf aktiviert? Wenn das nicht aktiv ist, wäre das eine gute Erklärung.

Im Moment ist uns da nichts bekannt. Wir testen morgen nochmal mit einem der Corsas. Eventuell verhalten die sich seit einem Update anders.

Wenn alles richtig verkabelt ist, und der Ladecontroller den Stromzähler findet, solltest du sofort auf der Statusseite den Ladeverlaufsgraphen (am Anfang leer, weil die Wallbox erst anfängt Daten zu sammeln), die aktuelle Leistungsaufnahme und im Menü die Stromzählerunterseite bekommen:

On 11/1/2023 at 11:29 PM, Das-graue-Schaf said:

Ich würde vorschlagen, die ausgelöste Zählerüberwachung in dem Moment zumindest im Log mit aufzunehmen.

Gute Idee, ist erledigt: https://github.com/Tinkerforge/esp32-firmware/commit/08b7d250

Im Moment funktioniert das nicht, weil zwischen Ethernet und WiFi (und auch dem WiFi Access Point und der WiFi Verbindung) nicht geroutet wird. Siehe auch https://github.com/Tinkerforge/esp32-firmware/issues/14

Das primäre Problem, dass der Lastmanager dir nur 6 Ampere zuteilt ist behoben, ja (schon in 2.1.4). Issues 263 und 264 sind leider noch offen.

On 11/1/2023 at 10:35 PM, Enrico said:

Ist ISO 15118 so kompliziert?

Ja. Auch dafür bräuchte es die 248€ Platine von hier:

Kurz zum Vergleich: Die (alte) Kommunikation über IEC 61851 ist im Endeffekt eine PWM-Spannung auf der CP-Leitung zu erzeugen und einen Widerstand zu lesen. ISO 15118 ist ein komplexes Protokoll über CAN-Frames über IPv6 (-> deutlich kompliziertere Software) über Powerline (-> deutlich kompliziertere Hardware) auf der CP-Leitung.

On 11/1/2023 at 9:58 AM, elektron said:

1.) wir mir auf beiden Wallboxen angezeigt, dass das Laden durch das Lastmanagement blockiert ist. Erlaubter Ladestrom: „Blockiert durch Last­manage­ment“.

Solange kein Auto angeschlossen ist, ist das korrekt. Das Lastmanagement teilt einer Wallbox erst Strom zu, wenn sie den auch braucht.

On 11/1/2023 at 9:58 AM, elektron said:

2.) zusätzlich habe ich im Log Meldungen über unbekannte Topics…

Die traditionelle erste Frage: Benutzt du ioBroker? Dessen MQTT-Broker ist nicht standardkonform und macht gerne mal Probleme. Siehe z.B. hier:

 

Moin,

In den letzten Monaten haben wir daran gearbeitet, dass der WARP Energy Manager mit Stromzählern und Wechselrichtern kommunizieren kann, die das SunSpec-Protokoll implementieren. Damit muss bei unterstützten Stromzählern und Wechselrichtern nicht mehr ein zusätzlicher Stromzähler für den Energy Manager verbaut werden. Der Energy Manager kann dazu jetzt bis zu 7 Stromzähler verwalten und einen beliebigen dieser Stromzähler zur Regelung des PV-Überschussladens verwenden.

Changelog (1.0.91 - Beta 2)

• Invalid Address Fehler bei Gerätesuche für SMA-Geräte repariert

Changelog (1.0.92 - Beta 3)

• Sonderbehandlung für falsche Werte bei KOSTAL-Geräten hinzugefügt.
• Detektion von Wechselrichter-Messwerten in der Nacht repariert; betrifft insbesondere SMA-Wechselrichter.
• Performance von SunSpec-Geräten mit float-Modellen verbessert; reduziert das Risiko von Timeouts beim Auslesen.

Changelog (1.0.93 - Beta 4)

• Anzeige der Wechselrichterleistung repariert.
• Anzeige der Phasenströme bei SMA-Wechselrichtern repariert.
• Leseperformance verbessert, insbesondere bei ModBus-RTU-Bridges.

Changelog (1.0.94 - Beta 5)

• Wechselrichterleistung wird jetzt in der Tabelle und im Graph angezeigt.

Unterstützte Stromzähler

Der Energy Manager sollte jetzt Messwerte von allen Geräten auslesen können, die eins der Wechselrichter-Modelle 101 bis 103 bzw. 111 bis 113, oder eins der Stromzähler-Modelle (201 bis 204 bzw. 211 bis 214) anbieten. Eine Liste von zertifizierten Geräten findet sich hier: https://sunspec.org/certified-registry/ (die jeweils unterstützten Modelle werden als "ModBusModels" aufgelistet)

Konfiguration eines SunSpec-Stromzählers

Gegebenenfalls muss SunSpec zuerst beim Stromzähler oder Wechselrichter aktiviert werden!

Unter Energiemanager -> Stromzähler kann ein neuer Stromzähler konfiguriert werden. Aktuell kann die Nummer (von 0 bis 6) des neuen Stromzählers frei gewählt werden. Nach Auswahl der Klasse "SunSpec" können der Hostname oder die IP, sowie gegebenenfalls der Port gewählt werden, auf dem der Wechselrichter oder Stromzähler erreichbar ist. Danach kann eine Gerätesuche gestartet werden. Gefundene Geräte werden aufgelistet, durch Klick auf ein gefundenes Gerät wird es übernommen und kann hinzugefügt werden. Nach Speichern und Neustart sollte der konfigurierte Stromzähler erscheinen:

Geänderte API

Die Unterstützung von mehr als einem Stromzähler hat dazu geführt, dass wir die Stromzähler-APIs grundlegend geändert haben. Wenn die SunSpec-Unterstützung die Beta-Phase verlässt, werden wir (über ein Legacy-API-Modul) die alte Zähler-API nachbilden, in dieser Beta ist die alte API aber noch nicht implementiert. Wenn eine externe Steuerung (EVCC, Node-RED usw.) die Zählerwerte des Energy Managers lesen oder schreiben soll, wird das mit dieser Beta-Firmware NICHT funktionieren. Dann bitte auf der alten Firmware bleiben, bzw. auf die frisch veröffentlichte 1.0.8 aktualisieren.

 

Wir freuen uns wie immer auf euer Feedback, insbesondere interessiert uns:
- Mit welchen Geräten funktioniert die SunSpec-Anbindung (nicht)?
- Tauchen unerwartete Messwerte auf? Ein Beispiel, dass wir bei einem KOSTAL Smart Energy Meter beobachtet haben (Später werden wir für solche Fälle Work-Arounds einbauen):

 

 

 

 

energy_manager_firmware_1_0_94_65578f18_e09f667df6273d1_feature-meters-7_merged.bin

On 10/29/2023 at 9:21 AM, Little_Company said:

gibt es hier schon Neuigkeiten zu den zwei Themen?

Zum zweiten ja. Ich habe gerade Firmware 2.1.5 mit TLS-Zertifikatsverwaltung veröffentlicht. Wenn du das auch in der WARP-on-Steroids-Firmware brauchst, musst du @poohnet nochmal anpingen.

Firmware: WARP 2.1.5 und WARP2 2.1.5

• (Nur WARP2) Verwaltung für TLS-Zertifikate hinzugefügt; eigene Zertifikate können für die OCPP-Verbindung verwendet werden
• Support für Reverse-Proxys verbessert
• Konfiguration des alternativen DNS-Servers repariert
• Anleitung des API-Aufrufs auf der Recovery-Seite repariert
• (Nur WARP2) OCPP-Verbindungsstabilität verbessert
• (Nur WARP2) OCPP-Unterseite, -statusanzeige und -debugausgabe verbessert
• Verlorene MQTT-Subscriptions und Nachrichten nach Verbindungsaufbau repariert
• Sichergestellt, dass Konfigurationen nicht über MQTT durch einen nicht-standardkonformen Broker zurückgesetzt werden
• Sichergestellt, dass API bei gleichzeitigem Zugriff über verschiedene Backends (MQTT, HTTP) konsistent bleibt
• Zuverlässigkeit und Performance des WebSocket-Verbindungsaufbaus verbessert
• Sichergestellt, dass externe Steuerung bei Aktivierung auf freigegeben (32 Ampere) gesetzt wird
• Performance des Flash-Speichers verbessert
• Hinzugefügt, dass Ereignis-Log-Nachrichten sofort angezeigt und im Browser gesammelt werden
• Auto-Scrolling zu Ereignis-Log hinzugefügt
• Problem mit der Größenberechnung von Tabellen in Firefox behoben
• Übersetzungen verbessert
• Sichergestellt, dass Nulllinie nicht außerhalb eines Graphen gezeichnet wird

Download: WARP 2.1.5 bzw. WARP2 2.1.5

Der von dir verlinkte Post bezieht sich auf den DC Brick, nicht das DC Bricklet. Das DC Bricklet musst du immer selbst mit Strom versorgen. Über den 7-Pol-Stecker zwischen Master Brick und DC Bricklet werden nur 3,3V und 5V verbunden.