poohnet

Sehr gerne - es freut mich, wenn man hin und wieder auch mal etwas zurückgeben kann. Schließlich werde ich als „Firmware-Hacker“ von euch allen ja schon seit Jahren jederzeit erstklassig unterstützt! … und wenn ich mir die diversen Entwicklungsbranches anschaue, dann freue ich mich schon darauf, bald noch mehr testen zu können 🙃

Vielen Dank für die detaillierte Analyse und Rückmeldung, @MatzeTF. Wieder ein kleines „Krabbeltierchen“ eliminiert… 😂

Ok, das sind definitiv alles valide Argumente, die vermutlich auf fast jedes IoT-Device zutreffen. UniFi hat übrigens einen extra „IoT-Modus“, in dem u. a. das entsprechende WLAN nur im 2.4 GHz-Band ausgestrahlt wird, vielleicht teste ich die diversen Settings auch mal…

Tja, wenn ich das wüsste… Ich bin auf jeden Fall gespannt, was eure Tests ergeben. Sollte sich das Problem nicht reproduzieren lassen, dann hätte ich auch kein Problem damit, den jetzigen Fix nur in meinem Fork vorzunehmen. Nur aus Neugier: Welches ursprüngliche Problem löst(e) das explizite Setzen auf HT20? Na ja, immer ein Kabel mit sich rumzutragen ist auch keine Lösung 😂

Im Log steht immer noch HT20, mein UniFi AP hat im 2.4 GHz Band aber auch nur 20 MHz Kanäle aktiv. EDIT: Auf meinem „richtigen“ WARP-Charger erhalte ich beim Reboot übrigens die Fehlermeldung „Setting HT20 for AP failed: 258“…

@photron hatte mir letztes Jahr zwar ein paar Infos dazu zukommen lassen, ganz trivial war das dann aber doch nicht. Letztendlich hat's jetzt aber funktioniert 🙂 0,011 | | **** TINKERFORGE WARP CHARGER V2.7.7+67FBD1BA **** 0,012 | | 332K RAM SYSTEM 296588 HEAP BYTES FREE 0,022 | | READY. 0,023 | | Last reset reason was: Software reset via esp_restart. 0,432 | fs | Mounted data partition. 81920 of 3538944 bytes (2.3 %) used 0,585 | api | WARP Charger config version: 2.6.6 (warp) 0,590 | esp32_brick | ESP32 Brick UID: SMH 0,931 | device_module | No EVSE Bricklet found. Disabling EVSE support. 0,979 | ntp | Set timezone to Europe/Berlin 1,101 | wifi | Starting scan to select unoccupied channel for soft AP 1,193 | firmware_update | Firmware is signed by: poohnet 1,196 | firmware_update | Partitions: app0 (valid, 2.7.7+67fbc33b), app1 (pending-verify, running, 2.7.7+67fbd1ba)

Klar, kein Problem. "WIFI_BW_HT40" funktioniert, d. h. der Funktionsaufruf an sich ist nicht das Problem. Schiebt man den Funktionsaufruf wieder in "Wifi::setup()", dann funktioniert's auch "WIFI_BW_HT20".

Aber gerne doch 🙃 Ich habe mal ein paar Debug-Prints in "meters_sma_speedwire" eingebaut und anscheinend wird das Problem durch diesen Codeblock in der Methode "Wifi::apply_sta_config_and_connect()" verursacht: // We don't need the additional speed of HT40 and it only causes more errors. esp_err_t err = esp_wifi_set_bandwidth(WIFI_IF_STA, WIFI_BW_HT20); if (err != ESP_OK) { logger.printfln("Setting HT20 for station failed: %s (%i)", esp_err_to_name(err), err); } Mit diesem Code sieht das Eventlog so aus: 0,011 | | **** TINKERFORGE WARP CHARGER V2.7.7+67FB7ED6 **** 0,012 | | 333K RAM SYSTEM 297136 HEAP BYTES FREE 0,022 | | READY. 0,023 | | Last reset reason was: Software reset via esp_restart. 0,398 | fs | Mounted data partition. 81920 of 3538944 bytes (2.3 %) used 0,516 | api | WARP Charger config version: 2.6.6 (warp) 0,520 | esp32_brick | ESP32 Brick UID: SMH 0,859 | device_module | No EVSE Bricklet found. Disabling EVSE support. 0,891 | ntp | Set timezone to Europe/Berlin 0,984 | wifi | Starting scan to select unoccupied channel for soft AP 1,044 | firmware_update | Firmware is not signed 1,048 | firmware_update | Partitions: app0 (pending-verify, running, 2.7.7+67fb7ed6), app1 (new, 2.7.7+67fb7de5) 1,104 | meters_sma_swire | Meter 1: Joined multicast group 239.12.255.254:9522 1,106 | meters | Meter 1: Meter declared 66 (60) values 1,202 | charge_tracker | Found 1 record: first is 1, last is 1 1,223 | charge_tracker | Last charge record size is 0 (0, 0) 1,481 | network | mDNS responder started 1,528 | mqtt | Recv buf is 4096 bytes. automation/config_update requires 4225. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection! 1,664 | wifi | Connecting to 'HMW-IoT' 1,668 | device_name | This is warp-SMH (warp-SMH), a WARP Charger Smart w/o EVSE 1,678 | wifi | Selecting channel 1 for soft AP 1,856 | wifi | Soft AP started 1,857 | | SSID: warp-SMH 1,857 | | MAC address: 40:F5:20:5B:38:15 1,868 | | IP address: 10.0.0.1 4,159 | require_meter | Energy meter stuck or unreachable! Blocking charging. 5,498 | wifi | Connected to 'HMW-IoT', ch.6 11bgn HT20 [DE ] -68dBm, BSSID BA:FB:E4:4A:29:E6 6,514 | wifi | Got IP address: 192.168.110.151/24. Own MAC address: 40:F5:20:5B:38:14 6,694 | network | Network connected (WiFi) 7,721 | mqtt | Connected to broker at mqtt://192.168.100.8:1883. 7,722 | mqtt | Recv buf is 4096 bytes. automation/config_update requires 4225. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection! 2025-04-13 11:08:47,187 | ntp | NTP synchronized at 19,055 2025-04-13 11:09:31,395 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:09:31,396 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:10:11,494 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:10:11,495 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:10:51,093 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:10:51,094 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:11:31,207 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:11:31,208 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:12:11,305 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:12:11,306 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:12:51,418 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:12:51,419 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 2025-04-13 11:13:11,726 | meters_sma_swire | Meter 1: Received Speedwire packet 2025-04-13 11:13:11,727 | meters_sma_swire | Meter 1: Read length: 58, Data length: 0 ohne so: 0,011 | | **** TINKERFORGE WARP CHARGER V2.7.7+67FB7CB6 **** 0,012 | | 333K RAM SYSTEM 297136 HEAP BYTES FREE 0,022 | | READY. 0,023 | | Last reset reason was: Software reset via esp_restart. 0,397 | fs | Mounted data partition. 81920 of 3538944 bytes (2.3 %) used 0,518 | api | WARP Charger config version: 2.6.6 (warp) 0,522 | esp32_brick | ESP32 Brick UID: SMH 0,862 | device_module | No EVSE Bricklet found. Disabling EVSE support. 0,894 | ntp | Set timezone to Europe/Berlin 0,989 | wifi | Starting scan to select unoccupied channel for soft AP 1,050 | firmware_update | Firmware is not signed 1,054 | firmware_update | Partitions: app0 (pending-verify, running, 2.7.7+67fb7cb6), app1 (new, 2.7.7+67fb7c14) 1,111 | meters_sma_swire | Meter 1: Joined multicast group 239.12.255.254:9522 1,113 | meters | Meter 1: Meter declared 66 (60) values 1,209 | charge_tracker | Found 1 record: first is 1, last is 1 1,230 | charge_tracker | Last charge record size is 0 (0, 0) 1,481 | network | mDNS responder started 1,528 | mqtt | Recv buf is 4096 bytes. automation/config_update requires 4225. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection! 1,661 | wifi | Connecting to 'HMW-IoT' 1,664 | device_name | This is warp-SMH (warp-SMH), a WARP Charger Smart w/o EVSE 1,675 | wifi | Selecting channel 1 for soft AP 1,853 | wifi | Soft AP started 1,854 | | SSID: warp-SMH 1,854 | | MAC address: 40:F5:20:5B:38:15 1,865 | | IP address: 10.0.0.1 4,165 | require_meter | Energy meter stuck or unreachable! Blocking charging. 5,502 | wifi | Connected to 'HMW-IoT', ch.6 11bgn HT20 [DE ] -65dBm, BSSID BA:FB:E4:4A:29:E6 6,517 | wifi | Got IP address: 192.168.110.151/24. Own MAC address: 40:F5:20:5B:38:14 6,700 | network | Network connected (WiFi) 7,719 | meters_sma_swire | Meter 1: Received Speedwire packet 7,720 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 7,731 | meters_sma_swire | Meter 1: Read 608 bytes 7,732 | meters_sma_swire | Meter 1: Power import: 30.200001, Power export: 0.000000 7,745 | mqtt | Connected to broker at mqtt://192.168.100.8:1883. 7,746 | mqtt | Recv buf is 4096 bytes. automation/config_update requires 4225. Bump MQTT_RECV_BUFFER_SIZE! Updates on this topic might break the MQTT connection! 8,744 | meters_sma_swire | Meter 1: Received Speedwire packet 8,744 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 8,755 | meters_sma_swire | Meter 1: Read 608 bytes 8,755 | meters_sma_swire | Meter 1: Power import: 0.000000, Power export: 11.700000 9,957 | meters_sma_swire | Meter 1: Received Speedwire packet 9,958 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 9,968 | meters_sma_swire | Meter 1: Read 608 bytes 9,969 | meters_sma_swire | Meter 1: Power import: 0.000000, Power export: 0.400000 10,980 | meters_sma_swire | Meter 1: Received Speedwire packet 10,981 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 10,991 | meters_sma_swire | Meter 1: Read 608 bytes 10,992 | meters_sma_swire | Meter 1: Power import: 0.000000, Power export: 2.300000 12,003 | meters_sma_swire | Meter 1: Received Speedwire packet 12,004 | meters_sma_swire | Meter 1: Read length: 608, Data length: 578 12,014 | meters_sma_swire | Meter 1: Read 608 bytes 12,015 | meters_sma_swire | Meter 1: Power import: 0.000000, Power export: 4.400000

Das ist der "Übeltäter": > git bisect good 92bf9493e129fb10731fa8e36ef6ee0f694c45a8 is the first bad commit commit 92bf9493e129fb10731fa8e36ef6ee0f694c45a8 Author: Mattias Schäffersmann <…> Date: Mon Mar 31 20:35:55 2025 +0200 wifi: Fix AP bandwidth and missing BSSID in state - Now that the AP isn't started during the setup when fallback mode is enabled, the bandwidth must be set right before opening the AP. - The AP's BSSID cannot be retrieved during setup for the same reason. - Set the bandwidth for STA right before connecting as well. Issues introduced in 6b8a6ca. software/src/modules/wifi/wifi.cpp | 45 ++++++++++++++++++++++---------------- 1 file changed, 26 insertions(+), 19 deletions(-) Mache ich ein revert auf diesen Commit, dann bekomme ich wieder Werte - sowohl in der WARP1-Konfiguration als auch mit meinem Fork: Vielleicht wichtig: Meine WARP ist per WLAN verbunden (im gleichen VLAN wie die SMA-Komponenten). Testet ihr evtl. nur noch per LAN?

Genau da bin ich gerade dran - die originale WARP1-Konfiguration ohne meine Anpassungen 🙃

Kurzer Zwischenstand: Das Problem scheint nichts mit den letzten Commits im Modul "meters_sma_speedwire" zu tun zu haben, denn mit bdb94657f bekomme ich noch Werte, mit upstream/master nicht mehr. Sehr mysteriös...

Nach der Übernahme in euren master und dem ersten Refactoring hat das Modul auf jeden Fall noch korrekt funktioniert, ich kann jetzt aber leider nicht mit Gewissheit sagen, ab wann es kaputt gegangen ist. Wenn ihr das Problem aber nicht nachvollziehen könnt, dann kann ich gerne mal ein „bisect“ probieren und den Commit identifizieren. Ja, definitiv. Es gibt noch einen zweiten Zähler, der weiterhin per Node-RED ausgelesen wird - und dann ist da noch der SMA Data Manager, der ebenfalls beide Zähler per Modbus-TCP abfragt (wobei der WARP-Zähler ggf. ja auch nicht direkt sondern über WARP ausgelesen werden könnte). Blöde Frage, liest das Template alle Werte einzeln oder blockweise? In Node-RED habe ich nämlich immer 20 Register auf einmal gelesen, in einen Puffer geschrieben und die Leistungswerte sekündlich, den Rest alle zehn Sekunden an den API-Zähler geschickt. Schon passiert 😂 Das steht noch auf meiner TODO-Liste.

Hallo zusammen, nach knapp fünf Monaten habe ich meinem "WARP-on-Steroids" nun nochmal einen aktuelle Firmwarestand verpasst und die gute Nachricht ist, dass beide Autos weiterhin richtig laden und auch meine Anpassungen noch funktionieren. 🙂 Ein paar kleinere Probleme sind mir allerdings aufgefallen: Mein SMA Sunny Home Manager 2.0 liefert nun keine Werte mehr, im Debug-Trace stehen unter "__begin_meters_swire__" aber zumindest die Abfragen drin; hier habe ich die Vermutung, dass dies mit den jüngsten Anpassungen im Modul "meters_sma_speedwire" zu tun hat, denn mit meinem ursprünglichen Modul auf einem zweiten ESP32-Brick erhalte ich alle Werte. Weiterhin gibt es ja jetzt ein Template für den SDM630 TCP und erfreut habe ich festgestellt, dass dies mit meinem (von einer auf einem Raspberry Pi laufenden Modbus-TCP/IP-Bridge angebundenen) SM630v2 funktioniert. Allerdings scheint das Abfrageintervall etwas zu groß zu sein, denn der Leistungsgraph wird gestrichelt gezeichnet. Bislang habe ich die Daten per Node-RED ausgelesen, gepuffert und sekündlich über die API bereitgestellt, da wurde der Graph durchgängig gezeichnet. Last but not least: Gibt es einen Grund dafür, dass man beim Solar Forecast mit einer unsignierten Firmware nur eure Demodaten bekommt? #if !BUILD_IS_SIGNED() #define SOLAR_FORECAST_USE_TEST_DATA #endif Wie immer besten Dank und viele Grüße Thomas warp2-XSS-Debug-Report-2025-04-12T14-07-43-914.txt

n‘ Abend @MatzeTF, funktioniert das auch für eine selbstgebaute Firmware und - falls ja - welche Version wird wiederhergestellt? Die alte, ebenfalls selbstgebaute? In der Vergangenheit musste ich mich nämlich das ein oder andere Mal mit dem Laptop zur Wallbox begeben… 😂

n‘ Abend @MatzeTF, falls es euch hilft, könnt ihr euch gerne nochmal an meinem Fork bedienen - den Strompreis per MQTT zu setzen und jede Ladung mit dem zu Beginn gültigen Preis zu speichern, habe ich vor einiger Zeit mal implementiert 🙃 Gruß Thomas

Ja, das tue ich. Auch wenn ich mich in den letzten Monaten hier im Forum etwas rar gemacht habe, halte ich meinen Fork eigentlich immer relativ aktuell - und meine WARP1 on Steroids funktioniert immer noch 1a 🙂 Also gerne einfach melden, falls Bedarf an einer angepassten Firmware besteht… Gruß Thomas

Schau dir mal das WiCAN-Modul an, das könntest du in deine Automatisierung einbauen. Ich habe mal etwas damit rumgespielt (und wollte eigentlich auch ein Modul für die WARP implementieren), der Nachteil ist aber, dass bei meinem ID.4 die Alarmanlage losgeht, wenn der Wagen ein paar Minuten abgeschlossen ist und auf den CAN-Bus zugegriffen wird. 🚨 SOC-Abfrage an sich (und noch vieles mehr) ist damit aber problemlos möglich… https://www.meatpi.com/products/wican Gruß Thomas

Ausschließen kann ich das sicherlich nicht, aber meine Anpassungen sind eigentlich seit dem Frühjahr unverändert und das Problem tritt erst seit ein paar Wochen auf, d. h. nachdem ich meine Forks rebased habe. Ich werde die Anpassung in der EVSE-Firmware testweise mal reverten und schauen, ob das Problem dann evtl. weg ist. Andere Frage: Ist es richtig, dass beim EVSE 2.0-Bricklet keine fahrzeugspezifische Kalibrierung mehr erforderlich ist? Falls ja, wo sind diesbezüglich die Unterschiede zum ursprünglichen EVSE-Bricklet? Gruß Thomas

Moin @MatzeTF, sorry, ich hatte irgendwie übersehen, dass du schon längst geantwortet hast 🙈 Anbei die beiden Ladeprotokolle von letztem Sonntag... Protokoll 1 1415 Uhr: Auto verbunden 1425 Uhr: Ladung über EVCC gestartet (und Umschaltung auf 3-phasiges Laden) 1432 Uhr: Ladung über das Auto beendet und Stecker gezogen --> Status wechselt von 3 auf 2 und bleibt im Webinterface "Verbunden" 1433 Uhr: Auto wieder verbunden --> Ladung wird direkt wieder gestartet, Status wechselt von 2 auf 3 Protokoll 2 1500 Uhr: Ladung über EVCC beendet --> Status wechselt von 3 auf 1 1500 Uhr: Stecker gezogen --> Status wechselt von 1 auf 0 Gruß Thomas warp2-XSS-EVSE-Ladeprotokoll-2024-10-13T14-33-24-005.txt warp2-XSS-EVSE-Ladeprotokoll-2024-10-13T15-01-02-184.txt

Moin, ich kann da leider nicht weiterhelfen bzw. testen, da ich einen RCD Typ B in der Unterverteilung habe und das Fehlerstromschutzmodul bei der letzten Umbauaktion ausgebaut habe. Anfangs hatte meine WARP1 aber das umgekehrte Problem, d. h. das Modul hat den RCD sporadisch ausgelöst, unabhängig davon, ob gerade geladen wurde oder nicht. Vielleicht ist das Modul bei dir auch defekt? Gruß Thomas

Moin zusammen, vor kurzem habe ich meinen Fork nochmal auf den aktuellen Stand gebracht und jetzt habe ich das Problem, dass meine WARP1 on Steroids auch nach dem Trennen des Autos im Zustand "Verbunden" bleibt, wenn ich die Ladung nicht zuerst in EVCC beende, d. h. Auto verbinden (0 --> 1) Ladung per EVCC starten (1 --> 2 --> 3) Auto entriegeln --> Ladung wird durch Auto pausiert Auto trennen --> Schütze öffnen (3 --> 1), der Status in WARP und EVCC bleibt aber "Verbunden" erst wenn ich die Ladung auch in EVCC beende, erfolgt der Übergang 1 --> 0 2024-10-05 12:03:30,435 | users | Charger state changed from 0 to 1 2024-10-05 12:04:50,460 | users | Charger state changed from 1 to 2 2024-10-05 12:04:50,719 | charge_tracker | Tracked start of charge. 2024-10-05 12:04:52,815 | users | Charger state changed from 2 to 3 2024-10-05 13:18:22,944 | evse_common | 8639 mA is allowed, but actual current is 7951 mA. Setting boost current to 120 mA. 2024-10-05 13:18:52,945 | evse_common | 10000 mA is allowed, but actual current is 9393 mA. Setting boost current to 240 mA. 2024-10-05 13:19:22,958 | evse_common | 10000 mA is allowed, but actual current is 9735 mA. Setting boost current to 360 mA. 2024-10-05 13:19:52,970 | evse_common | 10000 mA is allowed, but actual current is 9824 mA. Setting boost current to 480 mA. 2024-10-05 13:20:22,981 | evse_common | 16000 mA is allowed, but actual current is 15751 mA. Setting boost current to 600 mA. 2024-10-05 13:47:47,447 | users | Charger state changed from 3 to 1 2024-10-05 14:02:03,822 | users | Charger state changed from 1 to 0 2024-10-05 14:02:03,917 | charge_tracker | Tracked end of charge. Beende ich die Ladung zuerst in EVCC, dann gibt es beim beim Trennen direkt den erwarteten Übergang 1 --> 0. Habt ihr evtl. noch eine "jungfräuliche" WARP1 mit Standardfirmware und könnt das Szenario bei Gelegenheit mal durchspielen? Ich will nicht ausschließen, dass das Problem mit einer meiner zahlreichen Änderungen zusammenhängt, allerdings ist es in der Vergangenheit so bislang noch nicht aufgetreten. Bei Bedarf kann ich gerne auch einen Debug-Report erzeugen... Besten Dank und Gruß Thomas

Moin zusammen, in den letzten Monaten habe ich hier im Forum zwar weiterhin viel mitgelesen, mich ansonsten aber eher rar gemacht - einerseits mangels Zeit, andererseits aber auch, weil meine "WARP1 on Steroids" (der Begriff gefällt mir immer noch 😁) einfach funktioniert und unsere E-Autos absolut problemlos lädt! In der Tat ist es so, dass man beim Rebasen alle paar Wochen in (mindestens) einen Mergekonflikt rennt bzw. sich die Firmware nicht mehr bauen lässt, weil man z. B. vergessen hat, eine kleine Anpassung aus der warp2.ini nachzuziehen. Trotzdem möchte auch ich hier nochmals "DANKE" sagen, dass ihr auch das EVSE-Bricklet v1 weiter pflegt und verbessert! Ich bin gespannt, welche weiteren Features demnächst noch kommen werden... Gruß Thomas

Moin Alex, Das habe ich auch nicht selbst gemacht, d. h. ich habe die Platine von JLCPCB fertigen lassen. Da man immer mindestens drei bestellen muss, habe ich noch eine übrig, die ich dir bei Bedarf gerne zum Selbstkostenpreis zuschicken kann… Gruß Thomas

Moin @alestrix, ja, ich habe meine WARP1 tatsächlich bereits mehrfach umgebaut und diverse Erweiterungen vorgenommen: ESP32-Bricklet durch ESP32-Ethernet-Bricklet ersetzt CP-Trennung für die Phasenumschaltung über WARP Energy Manager nachgerüstet (den zugehörigen Thread hat @rtrbt ja schon verlinkt) interne Phasenumschaltung der WARP3 nachgebaut sowie weitere softwareseitige Anpassungen (Ladeprotokoll, dynamischer Boost, ...) Mit etwas technischem Sachverstand sind solche Umbauten mehr oder weniger problemlos möglich, wie zahlreiche andere Projekte hier im Forum ja auch zeigen. Allerdings sollte man schon wissen, was man tut, um nicht versehentlich die Ladeelektronik des Autos (oder schlimmer noch, sich selbst) zu grillen. Zumindest die letzte veröffentliche Version. Intern aktualisiere ich meinen Fork halbwegs regelmäßig mit dem Tinkerforge-Repo und seit Anfang der Woche läuft bei mir die 2.4.0 🙃 Sofern gewünscht kann ich gerne weitere Details nennen... Gruß Thomas

Die einfachste Frage traue ich mich fast nicht zu stellen: Du hast das MQTT-Topic in der EVCC-Config aber schon auf das der WARP3 geändert?! Tritt der Verbindungsabbruch zum Broker sofort auf oder erst später? Im Log liegt zwischen den beiden Meldungen mehr als eine halbe Stunde… Gruß Thomas