poohnet

Danke euch, ich probier‘s dann erstmal mit der API. Bestellung ist raus 😊

Alles klar, dann werde ich erstmal die Smart bestellen, das vorhandene Ladekabel weiterverwenden und die Zählerwerte wie gehabt per API bereitstellen. Letzte Frage: Gibt es einen (rechtlichen?) Grund, dass die Pro jetzt ein Sichtfenster für den Zähler hat? Oder zeigt der Iskra außer Zählerstand, akt. Leistung etc. irgendwelche weiteren sinnvollen Daten an? AKA macht es Sinn, die Smart - falls eurerseits möglich - direkt mit Sichtfenster zu nehmen, sodass der Iskra ggf. später nachgerüstet werden kann?

Danke @borg , ja, an diesen Hack kann ich mich aufgrund meiner Tests mit einem Powerline-Adapter noch gut erinnern... Wenn ich zunächst auf V2G/V2H verzichten kann (keines unserer aktuellen Autos kann das über AC), würde denn zumindest das Auslesen des SoC funktionieren, wenn ich die Zählerwerte weiterhin per API bereitstelle? Falls nein, wäre die WARP4 auch kompatibel mit dem vorhandenen SDM630 oder muss es zwingend der Iskra sein?

Moin zusammen, ich eröffne dann mal die Fragerunde zur WARP4 🙃 Welche technischen Unterschiede (außer Stromzähler) gibt es zwischen der Smart und Pro-Variante? Laut Informationen auf warp-charger.com ist ein Auslesen des SOC sowie evtl. späteres bidirektionales Laden ja nur mit Pro möglich, obwohl auch Smart schon das ISO15118-Modul enthält. Kann ich der Smart weiterhin die Zählerdaten per API zur Verfügung stellen und habe damit dann alle Pro-Features? Besten Dank und Gruß Thomas

Eine Möglichkeit wäre der Austausch des ESP32-Bricks gegen den ESP32-Ethernet-Brick sowie die Anpassung der Firmware, d. h. der Umbau auf "WARP1-on-Steroids". Damit konnte ich bisher alle Features der WARP2 und 3 ein- und nachbauen 🙂 s. https://www.tinkerunity.org/topic/11542-warp-on-steroids-u-zugeh%C3%B6rige-firmware/ Gruß Thomas

Seitdem ich die ersten Tests gemacht (und wahrscheinlich die Nerven unserer Nachbarn arg strapaziert 😂) habe, liegt der Dongle ungenutzt in der Schublade. Aber besten Dank für den Hinweis, dann teste ich das nochmal mit der aktuellen Firmware...

@meierchen006 , ich habe noch einen WiCAN in der Schublade liegen, den ich nicht nutzen kann, weil bei meinem ID.4 reproduzierbar die Alarmanlage losgeht, wenn der Wagen abgeschlossen ist und auf den OBD-Bus zugegriffen wird. 🚨 Bei Interesse gerne PM…

Die Teile gibt's alle im Shop und hier im Forum haben bereits einige User erfolgreich ein Update durchgeführt. Eine Alternative wäre evtl. "WARP-on-Steroids". Als WARP-User "der ersten Stunde" habe ich meine WARP1 in den letzten Jahren immer wieder etwas umgebaut und erweitert, insbesondere den ESP32-Brick durch den leistungsstärkeren ESP32-Ethernet-Brick (den auch die WARP2 hat) ersetzt und die Firmware entsprechend angepasst. Der aufwändigste Schritt hierbei war eigentlich das "Umlöten" einer Steckerleiste vom alten auf den neuen Brick. https://www.tinkerunity.org/topic/11542-warp-on-steroids-u-zugehörige-firmware/ Gruß Thomas

Hi @MatzeTF , sorry, aber ich hätte doch noch mal eine kurze Verständnisfrage: Sehe ich es richtig, dass ein Rollback auf die vorherige Firmware nur dann durchgeführt wird, wenn der Crash innerhalb der ersten sieben Minuten stattfindet, aber nicht mehr, wenn die Bootpartition einmal als gut markiert wurde? Ich war jetzt nämlich doch wieder in einer echten "Boot-Loop" gefangen, nachdem ich das EEBus-Modul (inkl. der letzten Korrektur) eingebunden, aber erst etwa eine halbe Stunde später aktiviert habe: 0,018 | | **** TINKERFORGE WARP2 CHARGER V2.8.17+697CDC99 **** 0,018 | | Last reset reason was: Software reset due to exception/panic (4) Found device 2t8ndc of type 9002 at port A Found device SSm of type 2159 at port F 0,345 | coredump | Task 'loopTask' caused exception 28: LoadProhibited Backtrace: 0x40105a38 0x4014417d 0x4014437a 0x40117ae1 0x40225932 0x403482a6 0,507 | fs | Mounted data partition. 159744 of 3538944 bytes (4.5 %) used 0,682 | api | WARP2 Charger config version: 2.8.4 (warp) 0,691 | esp32_eth_brick | ESP32 Ethernet Brick UID: XSS Found device 2t8ndc of type 9002 at port A Found device SSm of type 2159 at port F 1,076 | device_module | Phase Switcher Bricklet found. Enabling Phase Switcher support. 1,115 | ntp | Set timezone to Europe/Berlin 1,296 | wifi | Connecting to WiFi E (1371) mqtt_client: Client has not connected 1,439 | firmware_update | Firmware is signed by: poohnet 1,462 | firmware_update | Partitions: app0 (valid, 2.8.17+6978b0a9), app1 (valid, running, 2.8.17+697cdc99) 1,551 | meters | Meter 0: Meter declared 76 (73) values 1,590 | meters | Meter 1: Meter declared 66 (60) values 1,769 | charge_tracker | Found 6 records: first is 1, last is 6 1,802 | charge_tracker | Last charge record size is 2464 (77, 0) 2,140 | device_module | No NFC Bricklet found. Disabling NFC support. 2,630 | web_server | Starting multi-port server with 2 ports 2,672 | network | mDNS responder started 2,993 | power_manager | External phase switching API enabled, starting with 1p 3,134 | eebus | EV connected: 0, previous: 0 3,135 | api | State evse/phases_connected not found. Known states are: 3,146 | | info/modules, 3,146 | | event_log/boot_id, 3,156 | | info/features, 3,156 | | info/version, 3,167 | | rtc/time, 3,167 | | rtc/config_modified, ... 4,146 | | ocpp/configuration, 4,146 | | eebus/config_modified, 4,156 | | eebus/config, 4,167 | | eebus/state, 4,167 | | eebus/usecases, Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled. Core 1 register dump: PC : 0x40105a3b PS : 0x00060030 A0 : 0x80144180 A1 : 0x3ffe6b90 A2 : 0x00000000 A3 : 0x3f429719 A4 : 0x00000000 A5 : 0x3faa2ed8 A6 : 0x3ffb72a0 A7 : 0x3faa2ed8 A8 : 0x8011927c A9 : 0x3ffe6b30 A10 : 0x00000041 A11 : 0x3f45bc21 A12 : 0x00000000 A13 : 0x3f41047b A14 : 0x3ffe6b6c A15 : 0x3ffbbb9c SAR : 0x0000001d EXCCAUSE: 0x0000001c EXCVADDR: 0x00000000 LBEG : 0x40219d34 LEND : 0x40219d3c LCOUNT : 0x00000000 Backtrace: 0x40105a38:0x3ffe6b90 0x4014417d:0x3ffe6bb0 0x4014437a:0x3ffe6bf0 0x40117ae1:0x3ffe6c40 0x40225932:0x3ffe6ca0 0x403482a6:0x3ffe6cc0 ELF file SHA256: 559d43311 Rebooting... In einem solchen Fall gibt's wahrscheinlich keine "Selbstheilung", oder? Danke und Gruß Thomas P. S. Den Crash an sich braucht ihr nicht zu analysieren, der liegt daran, dass es den State "evse/phases_connected" (noch) nicht im EVSE v1 Modul gibt...

Moin @MatzeTF , ich schon wieder 🙈 Ihr hattet im Betatest für die Batteriesteuerung bislang noch keinen SMA SunnyBoy Smart Energy, d. h. einen der kleinen, einphasigen Hybridwechselrichter mit ennexOS, oder? Ich habe die aktuelle Beta-Firmware bislang zwar noch nicht getestet, nach meinen bisherigen Tests mit Node-RED (und auch den wenigen Beiträgen hier: https://www.photovoltaikforum.com/thread/231398-sma-sbse-4-0-einpasiger-hybrid-%C3%BCber-modbus-steuern/) funktioniert das aber wohl nicht mehr über die bekannten Modbus-Register 40793ff. Stattdessen muss man das interne Energiemanagement des WRs deaktivieren und kann (bzw. muss) die Ladesteuerung dann selbst über die Register 41467 und 41469 übernehmen. Sagt einfach Bescheid, wenn ich diesbezüglich etwas testen soll oder anderweitig unterstützen kann... Gruß Thomas

Ja, stimmt schon, das Problem ist wohl schon sehr speziell. Evtl. löst es sich ja mit irgendeinem Update des Pis von selbst wieder, denn ich kann mich nicht daran erinnern, dass es in der Vergangenheit so schon mal aufgetreten wäre. Andererseits war die Wallbox (wenn ich sie denn mal ausgeschaltet hatte) immer deutlich länger als zwei Minuten getrennt. Als abschließenden Test habe ich das Szenario gerade nochmal mit einer alten FRITZ!Box als AP durchgespielt. Wie erwartet hat sich auch meine WARP nach dem Neustart direkt wieder verbunden. Ich denke, damit wäre der Raspberry Pi / WPA Supplicant als Täter eindeutig identifiziert 🚓

Ja, schicke ich dir heute Abend. EDIT: Das hier ist eigentlich der relevante Block - mehr steht im Log im relevanten Zeitraum nicht drin: Jan 28 19:57:27 raspi wpa_supplicant[527]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78 Jan 28 19:57:27 raspi wpa_supplicant[527]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78 Jan 28 20:22:44 raspi wpa_supplicant[527]: wlan0: AP-STA-DISCONNECTED a8:03:2a:32:84:78 Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78 Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78Crash kurz nach 19:57:27 WARP gegen 20:21 ausgeschaltet WARP gegen 20:23 wieder eingeschaltet (nachdem die "AP-STA-DISCONNECTED"-Meldung im Log stand) erfolgreiche Verbindung 20:23:35 Deshalb die Idee des Exponential Backoff, d. h. Retry nach 4, 8, 16, 32, ... Sekunden. Damit würden kurzzeitige Verbindungsabbrüche weiterhin relativ schnell behoben und auch bei mir wäre die Verbindung spätestens bei 128 Sekunden (in Summe also unter fünf Minuten) wieder aufgebaut worden, da dann zwei Minuten zwischen den Verbindungsversuchen gelegen und der Pi die "Stale"-Verbindung gelöscht hätte. Ich kann mir das WiFi-Modul aber gerne auch selbst mal anschauen...

Nein, erst wenn ich die WARP für etwa anderthalb Minuten stromlos schalte, wird die Verbindung gelöscht. Ich habe jetzt noch nicht ins WiFi-Modul reingeschaut, aber heißt das, dass die Retry-Logik im Fehlerfall von der Bibliothek selbst übernommen wird? Ansonsten könnte ggf. ja ein Exponential Backoff helfen. Im Log sieht man zwar, dass die Abstände zwischen den Verbindungsversuchen nach einiger Zeit etwas größer werden, allerdings nicht so groß, dass der Pi die Connection löscht. Da hängen tatsächlich nur zwei Bricklets dran - EVSE und der (selbstgebaute) Phase-Switcher. Und im Normalbetrieb läuft die WARP damit absolut problemlos, d. h. keine Verbindungsaussetzer, Ladeprobleme o. ä. Genau diese Probleme spornen mich an, eine Lösung, zumindest aber eine plausible Ursache zu finden. Den Dank gebe ich aber gerne auch zurück, denn ohne deine Unterstützung bzw. den Austausch hier wären wir sicherlich nicht so weit gekommen 😊

Die Gretchenfrage ist jetzt aber, warum es funktioniert, wenn ich die Wallbox kurz stromlos schalte. Die Antwort: Es funktioniert momentan nicht, d. h. nach einem harten Reset verbindet sie sich auch erstmal nicht mehr. Anscheinend gibt es da aktuell einen Bug im WLAN-Treiber, der mich auf eine völlig falsche Fährte gebracht hat. Das hat früher definitiv mal (besser) funktioniert. EDIT: Ganz unschuldig ist die WARP aber wohl doch nicht, denn anscheinend verhindern die ständigen Verbindungsversuche, dass die Verbindung AP-seitig geschlossen werden kann. Erst durch ein Abschalten der Stromversorgung für etwa anderthalb Minuten wurde die Verbindung dann gelöscht - und danach konnte die WLAN-Verbindung auf Anhieb wieder hergestellt werden: Jan 28 19:57:27 raspi wpa_supplicant[527]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78 Jan 28 19:57:27 raspi wpa_supplicant[527]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78 Jan 28 20:22:44 raspi wpa_supplicant[527]: wlan0: AP-STA-DISCONNECTED a8:03:2a:32:84:78 Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78 Jan 28 20:23:35 raspi wpa_supplicant[527]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78 Puh, war das eine schwere Geburt... 🥵

Fünf bis zehn Sekunden waren's bestimmt, aber auch 30 Sekunden helfen leider nicht. Nach einem Blick in die Logs des Raspberry Pis und ein paar Tests habe ich jetzt aber auch eine neue Theorie - bitte korrigiere mich, falls das Blödsinn sein sollte... Nach einem Neustart des Pis verbindet sich die WARP problemlos mit dem AP: Jan 28 19:26:41 raspi wpa_supplicant[2099170]: Successfully initialized wpa_supplicant Jan 28 19:26:52 raspi wpa_supplicant[2099170]: nl80211: kernel reports: Registration to specific type not supported Jan 28 19:26:55 raspi wpa_supplicant[2099170]: Note: nl80211 driver interface is not designed to be used with ap_scan=2; this can result in connection failures Jan 28 19:26:55 raspi wpa_supplicant[2099170]: wlan0: interface state UNINITIALIZED->ENABLED Jan 28 19:26:55 raspi wpa_supplicant[2099170]: wlan0: AP-ENABLED Jan 28 19:26:55 raspi wpa_supplicant[2099170]: wlan0: CTRL-EVENT-CONNECTED - Connection to e4:5f:01:04:d4:08 completed [id=0 id_str=] Jan 28 19:27:02 raspi wpa_supplicant[2099170]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Jan 28 19:27:02 raspi wpa_supplicant[2099170]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78 Jan 28 19:27:02 raspi wpa_supplicant[2099170]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78Dann die (kaputte) Firmware eingespielt - WARP meldet sich korrekt vom AP ab und nach dem Neustart (aber vor dem Crash) dann auch wieder an: Jan 28 19:30:00 raspi wpa_supplicant[2099170]: wlan0: AP-STA-DISCONNECTED a8:03:2a:32:84:78 Jan 28 19:30:05 raspi wpa_supplicant[2099170]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Jan 28 19:30:06 raspi wpa_supplicant[2099170]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78 Jan 28 19:30:06 raspi wpa_supplicant[2099170]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78Durch den WARP-Crash bleibt die Session Pi-seitig anscheinend aber bestehen, sodass sich die WARP nicht mehr authentifizieren kann: 7,860 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 11,265 | wifi | Connecting to WiFi, BSSID lock enabled 17,688 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 21,269 | wifi | Connecting to WiFi, BSSID lock enabled 27,692 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2)Nach fünf Minuten habe ich den "wpa_supplicant" Dienst neugestartet und kurze Zeit später hat sich die WARP dann kurz verbunden, wieder abgemeldet und dann erfolgreich verbunden: an 28 19:36:00 raspi wpa_supplicant[2100852]: Successfully initialized wpa_supplicant Jan 28 19:36:11 raspi wpa_supplicant[2100852]: nl80211: kernel reports: Registration to specific type not supported Jan 28 19:36:14 raspi wpa_supplicant[2100852]: Note: nl80211 driver interface is not designed to be used with ap_scan=2; this can result in connection failures Jan 28 19:36:14 raspi wpa_supplicant[2100852]: wlan0: interface state UNINITIALIZED->ENABLED Jan 28 19:36:14 raspi wpa_supplicant[2100852]: wlan0: AP-ENABLED Jan 28 19:36:14 raspi wpa_supplicant[2100852]: wlan0: CTRL-EVENT-CONNECTED - Connection to e4:5f:01:04:d4:08 completed [id=0 id_str=] Jan 28 19:36:20 raspi wpa_supplicant[2100852]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Jan 28 19:36:20 raspi wpa_supplicant[2100852]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78 Jan 28 19:36:20 raspi wpa_supplicant[2100852]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78 Jan 28 19:36:24 raspi wpa_supplicant[2100852]: wlan0: AP-STA-DISCONNECTED a8:03:2a:32:84:78 Jan 28 19:36:50 raspi wpa_supplicant[2100852]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Jan 28 19:36:50 raspi wpa_supplicant[2100852]: wlan0: AP-STA-CONNECTED a8:03:2a:32:84:78 Jan 28 19:36:50 raspi wpa_supplicant[2100852]: wlan0: EAPOL-4WAY-HS-COMPLETED a8:03:2a:32:84:78 338,174 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_AUTH_EXPIRE) (2) 361,135 | uptime_tracker | Wrote last uptime to flash 361,330 | wifi | Connecting to WiFi, BSSID lock enabled 364,199 | wifi | Connected to WiFi: b+g+n ch.13 HT20 WPS [DE ] -68dBm, BSSID E4:5F:01:XX:XX:XX 368,160 | wifi | Lost IP. Forcing disconnect and reconnect of WiFi 368,168 | wifi | Failed to connect to WiFi: Unknown reason (WIFI_REASON_ASSOC_LEAVE) (8) 391,335 | wifi | Connecting to WiFi, BSSID lock enabled 394,209 | wifi | Connected to WiFi: b+g+n ch.13 HT20 WPS [DE ] -75dBm, BSSID E4:5F:01:XX:XX:XX 394,734 | wifi | Got IP address: 192.168.110.213/24, GW 192.168.110.1 396,031 | network | Network connected (WiFi) Es scheint also so zu sein, dass ein Crash nach dem Aufbau der WLAN-Verbindung zumindest den AP eines Raspberry Pis durcheinander bringen kann. Macht das Sinn? Oder wie würdest du das interpretieren?