rtrbt

Moin Henning,

Das Problem scheint nichts mit den Sonderzeichen zutun zu haben, sondern nur mit kaputter Fehlerbehandlung beim Abschalten des APs, wenn die WLAN-Verbindung hergestellt wurde. Teste mal bitte die angehangene Firmware, da sollte der Bug behoben sein.

Grüße,
Erik

warp2_firmware_1_0_1_615c5b77_merged.bin

Moin Christoph,

Hast du die Wallbox bei der Installation der Zuleitung und dem Anschluss des LAN-Kabels jeweils ohne die Frontplatte betrieben? Das wäre die beste Erklärung warum die Konfiguration verloren gegangen ist. Zur Erklärung:

Bei WARP 1 war es so, dass einer der Buttons auf dem ESP selbst einen Factory Reset (lies: ein Formatieren der Konfigurationspartition) auslöst. Das klappt bei WARP 2 so nicht, weil auf dem selben Signal wie der Button der Ethernet-Takt liegt. Deshalb hatte ich als Alternative dazu eingebaut, dass wenn man die Wallbox bestromt und der Taster in der Frontplatte gedrückt ist, der Reset ausgeführt wird.

Das führt jetzt dazu (ganz ehrlich: da habe ich einfach nicht dran gedacht), dass der Reset ausgelöst wird, wenn du die Wallbox ohne die Frontplatte betreibst.

Für die nächste Firmware-Version setzen wir den Factory Reset anders um, voraussichtlich muss man dann den ESP aus der (unbestromten!) Wallbox ausbauen, an einen PC anschließen und den Reset per Brick Viewer machen. Ist komplizierter, aber im Normallfall sollte der Reset ja unnötig sein.

Danke für's melden!
Erik

Moin Alex,

11 hours ago, Alex 75 said:

Kann man eigentlich (ohne große Umprogrammierungen etc.) anstelle des SDM630 auch einen Shelly 3EM in der Warp oder in der Unterverteilung verwenden und die Werte über das WLAN auslesen und funktioniert dann noch das Warp 2 Lastmanagement?

Warp 2 unterstützt nur den SDM630. Das Lastmanagement funktioniert aber ohne Zähler, da es nur Maximalströme vorgibt, ob das Fahrzeug diesen Strom dann auch zieht ist ein anderes Problem. D.h. wenn du anderweitig den Shelly 3EM in deine Unterverteilung baust und in dein WLAN bekommst, müsste das funktionieren.

11 hours ago, Alex 75 said:

Kann das Lastmanagement der Warp 2 auch Fremdwallboxen wie die cfos steuern, so dass der Hausanschluss nur mit maximal 34kW belastet wird?

Stand jetzt nicht.

Ich hatte mir das Thema OCPP vor ein paar Monaten angesehen, habe es aber aufgrund der Komplexität erstmal hinten angestellt. OCPP-Unterstützung (dann voraussichtlich OCPP 1.6 JSON) wird irgendwann kommen, ich kann dir aber nicht versprechen wann. (Nur dass es dieses Jahr nichts mehr wird, das Jahr ist ja nicht mehr lang, die TODO-Liste aber schon ;) )

Aufgrund dessen wie OCPP funktioniert, sind die Wallboxen dann aber nur "Clients", werden also von einem OCPP-Server gesteuert, den du dann auch bräuchtest. Das ist aber bei den cfos-Boxen genauso soweit ich das spontan gelesen habe.

On 9/29/2021 at 10:02 AM, ThomasH said:

Habe ich es jetzt richtig verstanden dass die Verbesserungen beim Ladecontroller in der 1.2.4 eigentlich schon drin wären (zumindest für die VW ID)?

Korrekt.

On 9/29/2021 at 10:02 AM, ThomasH said:

Wird es dann so sein dass mit 1.2.5 sowohl der neue Web Server als auch die Verbesserung beim Ladecontroller inkludiert wären?

Das wird voraussichtlich die 1.3.0, aber ja darin sind sowohl die aktuelle Ladecontroller-Firmware, als auch der neue Web-Server und das Lastmanagement.

Moin Henning,

Das ist auf jeden Fall ein Bug. Spontan wäre meine einzige Idee, dass das Konfigurieren des Access Points nicht klappt, aber aus irgendeinem Grund der AP trotzdem geöffnet wird. Lade von der Wallbox bitte den Debug-Report und das Ereignis-Log runter (beide unter System->Ereignis-Log) und hänge sie hier an, eventuell findet sich da etwas.

Grüße,
Erik

Moin Patrick,

Mir ist absolut unklar, warum deine Box in den Zustand gekommen ist. Zur Erklärung: Username und Passwort, sowie ein Flag ob der Login aktiviert ist, werden im Flash der Wallbox gespeichert. Das Firmware-Update ändert an diesen Daten nichts. Selbst wenn jetzt z.B. das Speichern der Datei schiefgegangen ist, würde die Wallbox die Standardeinstellungen laden, bei denen der Login natürlich aus ist.

Damit du erstmal wieder auf die Wallbox zugreifen kannst, müsstest du die Einstellungen zurücksetzen.

On 9/24/2021 at 4:51 PM, Sinus76 said:

Ein Rücksetzen per Stromlos & Taste bringt keine Besserung.

Das ist wie man WARP 2 zurücksetzt, bei WARP 1 musst du die Frontplatte abnehmen und den IO0-Button 10 Sekunden gedrückt halten. Siehe hier: https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf (Seite 10)

Das ist interessant, weil es bedeutet, dass sowohl Ladecontroller, als auch der ESP, der das Webinterface hostet, noch liefen. Vermutlich war die Kommunikation zwischen beiden gestört. Ich versuche weiterhin mal das hier zu reproduzieren, bin aber wie gesagt die nächsten zwei Wochen im Urlaub, dauert also etwas.

Moin,

Das sieht nach dem klassischen VW-Ladeproblem aus: Wenn das Auto von "Ich bin hier" auf "Ich will laden" umschaltet, springt der Widerstandsmesswert kurz extrem hoch, was die Wallbox als "Das Auto ist nicht mehr angeschlossen" interpretiert. Wir haben in der Firmware 1.2.3 dafür den ID.3-Modus eingebaut, der auf die Änderung träger reagiert.

Welche Firmware hast du laufen? Falls es nicht 1.2.4 ist, teste mit der aktuellen nochmal (Findest du hier). Wenn das Problem dann immer noch auftritt, erstell bitte nochmal ein Ladelog. Du musst die Konfigurationen übrigens nicht rauslöschen: Passwörter können über das Webinterface nicht ausgelesen werden, d.h. du leakst höchstens deinen WLAN-Namen und den Hostnamen der Box (die kannst du natürlich gerne löschen, aber alles, was mit evse/ anfängt könnte hilfreich zum Debuggen sein ;) )

Grüße,
Erik

Kurze Bestandsaufnahme:

52 minutes ago, Jhonny said:

Heute lud das Auto nicht mehr, weil die wallbox laut web Interface keine Verbindung hatte

Damit meinst du, dass die Wallbox auf der das Lastmanagement läuft, die zweite Wallbox nicht mehr erreichen konnte. An welcher von beiden hattest du das Auto angeschlossen? (Das Lastmanagement schaltet sicherheitshalber alle Boxen ab, wenn eine nicht erreicht werden kann) Warst du auch auf dem Webinterface der anderen Box? War da etwas suspekt, hast du eventuell Ereignis-Logs?

54 minutes ago, Jhonny said:

Irgendwas kam allerdings an, da die Status Led anging.

Das heißt, dass der Ladecontroller selbst noch lebt und nur der ESP32 auf dem das Webinterface läuft Probleme macht (oder die Kommunikation zwischen den beiden oder zwischen den Wallboxen)

56 minutes ago, Jhonny said:

Ich habe daraufhin die wallbox vom Strom getrennt und wieder aktiviert, dann ging es wieder.

Dann können wir schonmal Netzwerkprobleme ausschließen (es sei denn die Wallbox selbst hat nicht bemerkt dass sie nicht mehr im WLAN ist o.Ä.)

58 minutes ago, Jhonny said:

Das Verhalten konnte an meinen beiden Warp Pro nachstellen.

Mir ist unklar, was du damit meinst. Hast du es mehr als einmal geschafft, dass das Lastmanagement blockiert und es ist egal welche Box du neustartest, damit es wieder funktioniert?

59 minutes ago, Jhonny said:

Läuft mit der Zeit irgendein Speicher voll und daher arbeitet die ab nicht mehr ordentlich?

Hoffentlich nicht ;) Ich halte ein reines Speicherleck für unwahrscheinlich, da würde es bei dir nicht > einen Monat problemlos laufen, soviel RAM hat der ESP nicht.

Falls du das Problem nochmal erzeugen kannst würde mich folgendes interessieren:

• Kannst du das Webinterface beider Wallboxen noch erreichen?
• Falls ja: Ein Ereignis-Log und einen Debug-Report beider Wallboxen (im Debug-Report ist u.A. auch der aktuelle Zustand des Lastmanagers)
• Wie lange bleibt der Zustand so? Reicht es eine Box neuzustarten damit es wieder funktioniert?

Wir haben hier einen Lastmanagement-Verbund aus vier Wallboxen, der lief aber meines Wissens noch nie länger als zwei bis drei Wochen, weil man immer irgendwelche Dinge testet. Ich bin aber nächste und übernächste Woche im Urlaub und habe meinem Kollegen mal bescheid gesagt, dass er aufpassen soll, dass niemand die Boxen neustartet. Ich habe mir die aktuelle RAM-Auslastung der vier Boxen notiert, für den Fall, dass es wirklich ein Speicherleck ist. Eventuell wissen wir dann Anfang Oktober mehr.

Moin Thomas,

Teste bitte mal die Lastmanagement-Beta. Ich habe ein paar Fälle gehabt, bei denen sich der (alte) Webserver und der MQTT-Client auf den Füßen standen. MIt dem neuen Webserver sind die Probleme dann verschwunden. Achtung: Falls du den Login des Webinterfaces aktiviert hast, musst du u.U. deinen Browser nach dem Update neu starten, die Beta unterstützt den Loginprozess nicht.

Die Getter zu benutzen ist die einfachste Variante, du könntest aber alternativ auch die Callback-Frequenz runterdrehen auf etwas, dass du auf dem ESP verarbeiten kannst. Das hätte den Vorteil, dass weniger Traffic erzeugt wird. (Der Unterschied ist aber im Vergleich zu Stacks über USB nicht so stark). Da die Temperatur typischerweise eher träge ist solltest du mit z.B. 50 ms Callback-Interval noch gut hinkommen.

Aus Sicht der Wallbox sind Schlüsselschalter, Taster und dein Relais alle identisch. Da der Taster einen Ladeabbruch auslöst, beginnt die Wallbox nicht wieder mit dem Laden, bis du das Auto abgezogen und wieder angesteckt hast. Das Auto ist nachdem du den Taster loslässt ja noch angeschlossen. Die Wallbox ignoriert dann Auto-Start bis auf irgendeine Weise (dazu gleich mehr) eine Ladung beginnt oder du das Auto abziehst und wieder ansteckst. Du kannst das auch im Webinterface beobachten: Auf der Ladecontroller-Unterseite springt die Ladefreigabe von "Automatisch" auf "Manuell", wenn du den Taster drückst und loslässt.

Anstatt dass du das Auto abziehst, kannst du auch über das Webinterface eine Ladung starten: Sobald die Ladefreigabe auf manuell steht und das Auto noch angeschlossen ist, solltest du auf der Status-Seite "Start" drücken können.

Wenn du das automatisieren willst (z.b. über die selbe Steuerung die dein Relais schaltet?) kannst du die HTTP- oder MQTT-API verwenden und evse/start_charging aufrufen.

You are using the STM32F0-HAL? It looks like the HAL only initializes the SPI peripherals that are configured to be used. So if you only use SPI0_INSTANCE or SPI1_INSTANCE in your port configuration, the other one should be left unmodified.

Das Industrial PTC Bricklet ist neuer als die letzte Bindings-Beta. Wirf mal die beiden Dateien im Anhang in den bindings-Ordner.

bricklet_industrial_ptc.c bricklet_industrial_ptc.h

On 8/28/2021 at 1:53 PM, alestrix said:

Das heißt Ladestart würde - wenn sich die Theorie in der Praxis bestätigen sollte - per NFC Tag (wird über MQTT auch die Tag-ID übertragen?) erfolgen und der Ladestopp per Taster? Wäre für meine Zwecke vollkommen ausreichend.

So wird es funktionieren, ja. Die Tag-IDs bekommst du auch per MQTT, aber (noch) nicht die Kopplung welches Tag gerade jetzt den Ladestart ausgelöst hat.

On 8/28/2021 at 1:53 PM, alestrix said:

EDIT: Noch besser wäre, wenn ich die durch NFC getriggerte lokale Freischaltung deaktivieren könnte und der Warp nur eine MQTT Nachricht mit der Tag-ID erzeugen würde. Dann könnte sich daraufhin das externe Lademanagement um den Ladestart kümmern.

Das geht auch, es wird (voraussichtlich ;) ) die API nfc/seen_tags geben, wo Tag-Typ, -ID und die Zeit wann es zuletzt erkannt wurde, enthalten sind.

Moin Stefan,

Das ist kein Problem, wundert mich warum ich das nicht schon gemacht hatte. Ich setze es mal auf die TODO-Liste. Habe gerade keine funktionsfähige Umgebung um das Binding zu bauen, sonst hätte ich das gleich gemacht.

Bindings: Rust 2.0.19

• Fix compilation issues caused by yanked dependency
• Add set/get_display_driver functions and DISPLAY_DRIVER constants to E-Paper 296x128 Bricklet API
• Add simple_get_tag_id function and NFC_BRICKLET_MODE_SIMPLE constant to NFC Bricklet API

Download: Rust

Bindings: Rust 2.0.19

• Kompilierfehler durch zurückgezogene Abhängigkeit behoben
• set/get_display_driver-Funktionen und DISPLAY_DRIVER-Konstante zu E-Paper 296x128 Bricklet API hinzugefügt
• simple_get_tag_id-Funktion und NFC_BRICKLET_MODE_SIMPLE-Konstante zu NFC Bricklet API hinzugefügt.

Download: Rust

Moin Niels,

12 hours ago, ngblume said:

Ist hier überhaupt eine direkte Nutzung in HomeAssist möglich, da ja hier basierend auf dem "identifier" eine Aufteilung auf verschiedene Entities erfolgen müsste?

Mit etwas Bastelei sollte das gehen. Habe spontan das hier gefunden:

https://community.home-assistant.io/t/multi-sensor-using-same-mqtt-topic/172552/3

Der Teil mit dem "data demultiplexer" sieht nützlich aus.

12 hours ago, ngblume said:

Und wäre es nicht für Tinkerforge sinnvoller, unterhalb des Bricklets und der Aufteilung nach Station oder Sensor noch nach den Identifiern aufzuteilen? Bspw. "tinkerforge/callback/outdoor_weather_bricklet/Er2/sensor_data/214/" für den Sensor mit der Identifier "214" aus obigen Beispieldaten ?

In diesem Fall wäre es sinnvoller, aber so funktionieren die Bindings nicht. Die Bindings mappen 1:1 auf die Python-API und in der sind die Sensor-IDs ein Rückgabewert. Das ist immer das Problem bei "generischen" MQTT-Bindings, wenn es ein reines HA-Binding wäre, sähe das anders aus.

12 hours ago, ngblume said:

Wie kann ich den Daemon mit diesem CMD-File als Service starten, sodass ich keine blockierte Konsole habe?

Hast du die Bindings auf dem Pi als Debian-Paket installiert? Falls ja kannst du deine cmdline-Datei nach /etc/tinkerforge_mqtt.cmdline packen bzw. mit der Datei zusammenlegen.

Falls du die Bindings von Hand heruntergeladen hast kannst du die .service-Datei aus dem Zip bearbeiten und  --cmdline-file daemon-cmd-args einfügen.

Hm kaputte Jumperkabel hatte ich bei der Binding-Entwicklung auch. (Mein Aufbau sah übrigens sehr ähnlich aus ;) )

Wegen der Robustheit solltest du die Ports, die du nicht benutzt wieder in die Konfiguration aufnehmen, zumindest wenn du Bricklets angeschlossen hast: Das HAT hat Trennerchips, die sicherstellen, dass SPI nur an das selektierte Bricklet geht. Wenn du dann die Enable-Leitung der Chips floating lässt (das ist einfach das Chip-Select-Signal) könnten sich komische Effekte ergeben.

Außer dem Zähler brauchst du noch die entsprechenden Kabel. Statt dem Klemmenblock in der Smart kann dann der Zähler eingebaut werden. Wir planen in nächster Zeit die ganzen internen Kabel usw. als Ersatzteile zu verkaufen. Siehe hier:

13 hours ago, stif said:

Mit welchem Commit läuft dein NodeMCU? Im Commit Simplified main.cpp and updated hal-arduino-esp32 habe ich den getDeviceInfo Aufruf schon in die loop gegeben, damit ich regelmäßige Kommunikation habe..

Mit genau dem Commit, ja.

Jetzt verstehe ich aber die Verwirrung: getDeviceInfo() ruft tf_hal_get_device_info auf, das erzeugt aber keine Kommunikation, sondern fragt nur die Informationen ab, die der HAL ganz am Anfang gesammelt hat. Was in tf_hal_create bzw. tf_hal_common_prepare (was von _create aufgerufen wird) passiert, ist dass der HAL an allen verfügbaren Ports abfragt, welche Devices angeschlossen sind. Mit tf_hal_get_device_info kannst du die abgefragten Daten dann auslesen.

Wenn du permanent Kommunikation auf allen Ports erzeugen willst, kannst du entweder tf_hal_callback_tick verwenden, dann ist es aber nur unidirektional, weil die Bricklets vermutlich nichts antworten werden (es sei denn du hast eins der Bricklets mit nicht deaktivierbaren Callbacks die auslösen z.B. ein RGB LED Button den du immer mal drückst) oder du baust dir etwas in die Richtung:

TF_Unknown unknown;

for(int i = 0; i < port_count; ++i) {
    tf_unknown_create(&unknown, "1", hal, (uint8_t)i, 0);

    int rc = tf_unknown_get_identity(&unknown, nullptr, nullptr, nullptr, nullptr, nullptr, nullptr);
    
    tf_unknown_destroy(&unknown);
}

(ungefähr geklaut aus tf_hal_common_prepare)

Das gute am Unknown Bricklet ist, dass es einen Konstruktor hat, bei dem du explizit den Port angeben kannst. UID "1" ist Broadcast.

13 hours ago, stif said:

Ausserdem habe ich die Bricklet Includes weggegeben, damit das Programm so einfach wie möglich ist und nur via SPI die Device Infos abgefragt werden.

Bzw sind die Bricklet Inludes notwendig, damit die Bricklets im getDeviceInfo antworten können? Das würde zumindest erklären, warum sich nur 1 Device (HAT?) gemeldet hat, wie die Kommunikation kurzfristig funktioniert hat.

Nein die includes brauchst du nur, wenn du mit dem Bricklet kommunizieren willst, der HAL verwendet intern nur bricklet_unknown und includet das selbst.

13 hours ago, stif said:

Und wie hast du das Programm gebaut und hochgeladen? Mit einem eigenem Makefile, oder über PlatformIO? 

Mit PlatformIO:

pio run -e esp32-poe -t upload -t monitor

Das benutze ich sowieso für die Wallbox-Firmware (falls du spionieren willst: https://github.com/Tinkerforge/warp-charger/tree/master/software)

Wenn das HAT bei dir aufschlägt, funktioniert die Kommunikation prinzipiell. Siehst du auf der seriellen Konsole dann auch folgendes?

Found device XYZ of type 112 at port E

Ich habe den Code so wie du ihn hast mal mit einem NodeMCU getestet. Musste dafür nur im HAL den MISO_PIN von 16 auf 12 setzen. Damit funktioniert es aber. Die Bilder sind die Anfrage der Bindings, mit dem sie abfragen was an dem Port angeschlossen ist und die Antwort des One Wire Bricklets. Wenn das funktioniert müsstest du die Ausgabe auf der seriellen Konsole sehen:

Hello World!
Found device GGU of type 2123 at port A
Get Device Info:
 {"devices": [ {"UID":"GGU", "DID":2123, "port":"A"}]}

So wie dein Code da steht, gibt es nur kurz Kommunikation, wenn du die Bindings startest, du könntest aber in die Loop noch tf_hal_callback_tick aufrufen, dann prüfen die Bindings permanent, ob die Bricklets Daten schicken wollen.

Der Bus sollte mit 1,4 MHz laufen. Alles bis 2 MHz verstehen die Bricklets.

Edit: Bilder als Anhang, damit man sie auch lesen kann.

Edit2: Das Forum wehrt sich. Klickst du hier: https://imgur.com/a/6mQ0OYF

Liest du SPI zwischen dem ESP und dem HAT oder zwischen HAT und Bricklet?

Noch eine Sache die mir auffällt: Dein Beispiel schreibt Daten per SPI an einen Slave, vom Logic-Analyzer-Bild her ist das Pinmapping

D0 MISO
D1 MOSI
D2 CLK
D3 CS

Jetzt sehe ich da aber Daten auf MISO, nicht auf MOSI. Das scheint falsch herum zu sein. Oder hast du das nur in Sigrok falsch zugeordnet?

Die Verkabelung sieht soweit ich das erkennen konnte richtig aus. Falls du einen Saleae Logic Analyzer hast kannst du dir unseren HLA ansehen:

https://www.tinkerforge.com/de/doc/Low_Level_Protocols/Saleae_High_Level_Analyzer.html

Ich habe nochmal in deinen HAL gesehen: Es fehlt auf jeden Fall die Zeile

hal->hspi = SPIClass(HSPI);

vor

hal->hspi.begin(CLK_PIN, MISO_PIN, MOSI_PIN);

Ich bin mir gerade nicht mehr sicher, ob der SPIClass-Konstruktor außer dem Pin-Mapping noch mehr tut, eventuell war die Zeile wichtig ;)