-
Gesamte Inhalte
1.388 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
127
Posts erstellt von rtrbt
-
-
Wenn du die Phasenumschaltung nachrüsten willst, sieh dir mal
an. Da die Umschaltung mit dem Umbau in der Wallbox hinter dem Zähler passiert, hast du dann auch nicht mehr das Problem, dass der Stromzähler neustartet.
-
On 9/14/2023 at 7:59 PM, dkp_cobra said:
War das so richtig, die Phase 2 und 3 im Eingang einfach abzuklemmen?
Hast du eine WARP1 Pro? Wenn ja, dann verträgt das der eingebaute Stromzähler (SDM72 ohne V2) nicht. Der Zähler startet alle ~ 20 Sekunden neu, wenn man ihn nicht dreiphasig mit Strom versorgt. Falls du einphasig mit Strommessung laden möchtest, kannst du den Stromzähler durch einen SDM630 oder einen SDM72V2 ersetzen, die Software unterstützt beide.
Bei einer WARP1 Smart kannst du das problemlos so machen.
On 9/14/2023 at 7:59 PM, dkp_cobra said:Kann ich die beiden Phasen mit einem Hauptschalter auf der Hutschiene mit den entsprechenden Eingängen der WB verbinden, um zu Beginn des Sommer nächsten Jahres wieder dreiphasig zu Laden?
Ja.
On 9/14/2023 at 7:59 PM, dkp_cobra said:Muss ich vor dem Schalten die WB komplett stromlos machen?
Nein.
On 9/14/2023 at 7:59 PM, dkp_cobra said:Mir ist klar, dass ich die Phasen nicht während des Ladens zu- oder abschalten kann.
Gut. Das kann im schlimmsten Fall (alter Renault Zoe) das Auto zerstören.
-
Hm die Widerstandsmessung kommt da wieder nicht weit genug runter:
Wenn du das nochmal hast, fahr nochmal von 16 bis 6 Ampere ab, eventuell können wir nochmal nachjustieren.
-
Falls sich da auf ioBroker-Seite nichts geändert hat, kannst du dessen MQTT-Broker weiterbenutzen, wenn du "Publish own states on connect" deaktivierst. Siehe z.B. hier:
Mit Mosquitto sollte es aber auf jeden Fall funktionieren.
-
Sehr gut :)
-
Immer gerne. Jetzt sollte auch die Auto-Erkennung des Zählers wieder funktionieren, falls du das noch probieren willst.
-
Ich habe jetzt erst bewusst auf die Bilder von deinem Umbau geguckt. Beim RS485-Bricklet sind die DIP-Schalter falsch gesetzt.
Die musst du auf "Half-Duplex Terminated", also die ersten drei Schalter auf On, der vierte auf Off, so wie hier rechts unten:
Wenn du die Box gerade offen hast: Sieh nochmal nach, ob die Verkabelung zwischen RS485-Bricklet und Zähler richtig ist. Siehe Stromlaufplan hier: https://www.warp-charger.com/documents/WARP_Stromlaufplan.pdf
-
On 9/6/2023 at 2:32 PM, Little_Company said:
Irgendwie scheint es mit der neuen Firmware ein Kommunikationsproblem zum Zähler zu geben.
Dann würde ich erwarten, dass die Fehlerzähler hochzählen.
Ich fürchte du musst dir mal Brick Viewer installieren, damit wir nachsehen können, was wirklich passiert. Anleitung dazu gibt's hier: https://www.tinkerforge.com/de/doc/Software/Brickv.html (Du brauchst nur den Brick Viewer, nicht Brick Daemon)
In @poohnets Firmware ist der Proxy-Modus schon aktiv, d.h. du kannst, wenn du den Brick Viewer installiert hast ihn starten, unter Host die IP oder den Hostnamen der Wallbox eintragen, und dich mit "Connect" verbinden. Du solltest dann u.A. einen Tab für das RS485-Bricklet bekommen. In dem Tab werden die Pakete vom Zähler aufgeführt. Was mich jetzt interessieren würde ist, wenn du noch Auto-Detect (255) aktiv hast, ob dann regelmäßig ein "Read Holding Registers Response" auftaucht und wenn ja was der Data-Wert ist. Wenn du von Auto-Detect auf SDM72 (1) umschaltest, sollten stattdessen "Read Input Registers Response"-Einträge, also das Lesen dern Zählerwerte, auftauchen, weil die Kommunikation dann ja klappt.
Das ganze sieht ungefähr so aus: Ich habe für die Fehler am Anfang den Zähler physisch getrennt. Danach klappt das Lesen des Holding Registers (Ich habe einen SDM630 mit Meter-ID 0070) und die Wallbox fängt an die "normalen" Zählerwerte zu lesen.
-
On 9/6/2023 at 7:26 AM, poohnet said:
warum a) der Zähler nicht mehr automatisch erkannt wird
Das wundert mich auch. Die Erkennung funktioniert ja so, dass wir ein spezifisches Register vom Stromzähler lesen, in dem dessen Typ-ID steht. Es müsste also im Eventlog immer mindestens eine der folgenden Meldungen auftauchen
- SDM72DM detected. (oder anderer typ)
- Found unknown meter type 0x%x. Assuming this is a SDM72DM. (das würde die unbekannte ID ausgeben)
- Meter type override set to SDM72DM. (oder anderer typ)
Wenn keine der Meldungen auftaucht, dann antwortet der Zähler nicht auf den Lese-Request. @Little_Company hattest du garkeine dieser Meldungen als du den type_override noch nicht gesetzt hattest? Wenn du das nochmal testen willst, kannst du die Auto-Erkennung wieder aktivieren. Mit der neuen Firmware:
{"method":"PUT", "url":"/meter/type_override_update", "payload":255}
bzw. mit der alten
{"method":"PUT", "url":"/meter/type_override_update", "payload":"255"}
Da du einen SDM72DM (V1) hast, vermute ich dass du einen hast, der als ID entweder 0x0200 (dann hätte es funktionieren sollen) oder 0x0084 (dann hätte die Found unknown meter type... Nachricht ausgegeben werden sollen).
On 9/6/2023 at 7:26 AM, poohnet said:das "type_override_update" nicht auch in der aktuellen Firmware funktioniert.
Das liegt vermutlich an https://github.com/Tinkerforge/esp32-firmware/commit/c3fa0ab6
Ich hatte da das Problem falsch verstanden (der Payload war davor ein String mit JSON drin, also z.b. mit escapten Anführungszeichen) und seit dem Commt ists direkt genestetes JSON. In eurem Fall also nicht
{"method":"PUT", "url":"/meter/type_override_update", "payload":"1"}
sondern
{"method":"PUT", "url":"/meter/type_override_update", "payload":1}
Nach kurzer Diskussion haben wir uns intern geeinigt, dass Variante 2 in der Tat sinnvoller ist, ich habe die Anleitung auf der Recovery-Seite gerade angepasst und editiere gleich meinen alten Post, falls den nochmal jemand findet.
-
Moin,
Auffällig im Debug-Protokoll ist, dass sich der CP-PE-Widerstand (darüber läuft die Kommunikation mit dem Auto) und auch der PP-PE-Widerstand (der gibt an wie viel Strom das Ladekabel verträgt) beide der Maximalwert (also nicht verbunden) sind. Das kann passieren, wenn der rot markierte Stecker in der Wallbox nicht richtig gesteckt ist:
Mach am besten die Box einmal stromlos und sieh nach, ob der Stecker richtig steckt. Außerdem sollte zwischen der obersten und untersten Klemme des Steckers ein Widerstand gesteckt sein. (Blau im Bild)
- 1
-
Hm, das wird mit EVCC nicht funktionieren. Kurz zusammengefasst: EVCC kann eigentlich nur NFC/RFID-Tags über die Wallbox lesen, aber nicht Tags injecten. Es gibt da noch einen Spezialfall, aber nur für Keba-Wallboxen.
Ich zitiere mal aus der Mail
Quoteim Prinzip benutzt evcc die von der Box übermittelten RFID-Tags nur als zusätzliche Möglichkeit um durch Benutzerinteraktion ("Karte vorhalten") bestimmte vorkonfigurierte Fahrzeuge samt den optional daran hängenden Voreinstellungen aufzurufen.
und
QuoteBei Keba ist die (blöde) Besonderheit, dass die Box die Authentifizierung nur dann behält bzw. die Session startet wenn der Ladevorgang binnen 60 Sekunden mindestens einmal freigegeben und auch tatsächlich gestartet wurde (Status C).
Das ist bei PV-Überschussladen ja nicht unbedingt gegeben. Daher wurde da dieser sehr merkwürdige Workaround eingebaut dass sich evcc mit einer festen Kennung bei jeder Freigabe statt der echten RFID-Kennung anmeldet - als ob man immer diese eine virtuelle Karte davor halten würde.D.h. selbst bei der Keba wird immer nur ein und dieselbe Tag-ID geschickt, egal welches Fahrzeug erkannt wurde.
Wenn du also die Ladefreigabe/SoC-Laden über EVCC und zur Abrechnung pro Fahrzeug/Benutzer verschiedene NFC-IDs an die WARP2 schicken willst, musst du das entweder physisch machen (also das Tag dranhalten wenn du das Auto ansteckst), oder über die APIs mit einem Script, FHEM, o.Ä. steuern.
- 1
-
Ich bemühe mal den kurzen Dienstweg zu den EVCC-Entwicklern.
-
Damit ich das gerade richtig verstehe: Die NFC-Freigabe sollte komplett an EVCC vorbeigehen, wenn du nicht NFC-Tags benutzen willst, um damit für EVCC unterschiedliche Autos zu identifizieren. Oder willst du andersrum von EVCC aus NFC-Tags injecten, damit ein Ladevorgang auf der Wallbox auf einen Benutzer getrackt wird, ohne dass du ein physisches Tag dranhältst?
-
On 8/7/2023 at 5:23 PM, milima said:
nach einiger Zeit (< 1 Minute) reduziert der Energy Manager jedoch "eigenmächtig" auf 6 A, ohne dass sich irgendetwas geändert hätte (Ladezustand, Anforderung von evcc, ...) !!!
Ah dann triffst du den Lastmanagement-Bug, den wir hier:
gefunden haben. Sorry, dass ich da nicht eher drauf gekommen bin. Du bekommst in den nächsten Tagen eine Test-Firmware, die das Problem fixen sollte.
-
Hier die Kalibrierung aus den beiden Protokollen. Die Kalibrierung ist im unteren Bereich sehr stark (bei 6 Ampere muss ich 5 Volt abziehen). Kannst du mit dieser Kalibrierung nochmal die Protokolle erstellen? Dann würde ich das nochmal in unsere magische Kalibrierungs-Exceltabelle werfen, um zu verifizieren, dass die 5 Volt wirklich notwendig sind.
On 8/8/2023 at 7:58 AM, poohnet said:Nur mal so als Idee: Könnte man die Kalibrierung nicht an den User hängen, sodass diese beim Start der Ladung "on-the-fly" geladen wird?
Theoretisch würde das gehen, aber wir sollten hoffentlich nie in die Situation kommen, dass man das braucht.
-
Habe das Problem gefunden und behoben. Fix kommt mit der nächsten Firmware.
On 8/3/2023 at 3:21 PM, gollum said:Wenn man das Stromverteilungsprotokoll aktiviert, ist das Ereignis-Log viel zu klein. Es läuft bei mir schon nach ein paar Minuten über.
Das stimmt. Deshalb ist das Verteilungsprotokoll normalerweise deaktiviert. Da wir inzwischen auch einige andere relativ "gesprächige" Komponenten in der Firmware haben, müssen wir das mal angehen.
-
-
On 8/4/2023 at 2:56 PM, milima said:
Die eigentliche Frage hier ist aber: warum ladet der Fiat bei einem Akkustand von rund 40%, einer "anliegenden" Ladeleistung von 3,7 kW und der Einstellung des Lademodus 5 im Auto nicht mit der maximal angebotenen Leistung???
Das ist leider immer schwierig herauszufinden. Rein technisch ist die ganze Kommunikation zwischen Wallbox und Auto nur, dass die Wallbox vorgibt, wie viel Strom maximal bezogen werden darf. Was das Auto dann wirklich tut ist ihm überlassen.
Noch ein Gedanke: Versuch mal unter Wallbox->Ladeeinstellungen den Boost-Modus zu aktivieren.
-
On 8/7/2023 at 1:43 PM, poohnet said:
SOC 82%, Battery Care aktiv, d. h. Laden bis max. 80%:
- ein Ladevorgang wird gestartet, das Schütz zieht aber nicht an. Nach wenigen Sekunden wechselt der Status kurz auf "Nicht verbunden" und ein neuer Ladevorgang kann gestartet werden. Lässt man EVCC die Steuerung übernehmen, dann hat man nach kurzer Zeit zwei dutzend Ladevorgänge mit 0,000 kWh und ein bis zwei Sekunden Dauer im Ladeprotokoll.
Sieh mal nach, ob du schon die EVSE-Firmware 2.1.8 Beta 4 hast. Die sollte sich im Webinterface als 204.1.8 melden (Bei Beta-Versionen setze ich die Major-Version auf 200 + Betanummer), bzw du kannst in deinem Repo nachsehen in software/src/modules/evse/.
Für die Kalibrierung selbst:
QuoteOptimalerweise startest du unter Wallbox -> Ladestatus -> Ladeprotokoll -> Start ein Ladeprotokoll. Startest dann eine Ladung am Auto mit 16A und gehst (jeweils mit 30 Sekunden Wartezeit) In 1A-Schritten runter bis 6A.
Dann Wallbox -> Ladestatus -> Ladeprotokoll -> Stop+Download und mir das Ladeprotokoll schicken. Dann kann ich das einmal spezifisch für deine Wallbox kalibrieren.
QuoteZusätzlich kannst du das selbe nochmal machen, wenn dein Auto voll (bzw. auf 80% SoC wenn du das Ladeende darauf konfiguriert hast) ist. Dann wird die Kalibrierung besser. Das muss nicht im selben Ladeprotokoll sein, darf es aber.
(grad zusammenkopiert ;) )
On 8/7/2023 at 1:43 PM, poohnet said:Was ändert die Kalibrierung eigentlich genau in der PWM-Kommunikation zwischen Ladecontroller in der Wallbox und Ladeelektronik im Fahrzeug?
(Folgendes ist mein grobes Verständnis. Für Details müsstest du @borg (Software) und @batti (Hardware) fragen )
Die Kalibrierung ändert, wie die Wallbox die zurückgemessene Spannung und damit den Widerstand, der vom Auto angelegt wird, interpretiert. Da gibt es das grundlegende Problem, dass die Wallbox den Widerstand nur messen kann, während das PWM High ist. D.h. bei kleinen Stromvorgaben wird die Messung schlechter.
Es gibt voltage_diff (Differenz), voltage_div (Divisor) und voltage_mul (Multiplikator), die werden auf die CP-PE-Spannung angewandt, siehe z.B. hier: https://github.com/Tinkerforge/evse-bricklet/blob/36ddc94accdd6aae496a6cd115678d0d2a63998b/software/src/ads1118.c#L211C31-L211C31
resistance_2700 und resistance_880 werden auf den aus der Spannung berechneten Widerstand addiert. resistance_880 ist dabei ein Array, dass von 6 bis 32 Ampere in zwei-Ampereschritten verwendet wird, abhängig vom Strom den wir vorgeben (und damit dem PWM mit dem gemessen wird). Ist in der selben Datei weiter unten.
On 8/7/2023 at 1:43 PM, poohnet said:Wie sieht die Vorgehensweise aus, wenn zukünftig evtl. ein weiteres Fahrzeug (das ja ggf. eine andere Kalibrierung benötigt) geladen werden soll?
Bisher haben wir noch jede Kombination aus Fahrzeugen an jeder Wallbox zum Laden bewegen können. Wenn ein anderes Fahrzeug so anders ist, dass es mit der Kalibrierung, die wir dir dann erstellen, nicht funktioniert, gib nochmal Bescheid, man kann dann vermutlich einen Mittelweg finden, der mit beiden funktioniert.
-
On 8/4/2023 at 12:22 PM, milima said:
Lt. evcc wird gerade mit 3,7 kW geladen und daher meint evcc dass das Laden rund 6:38 h dauert. Die Fiat App, die sich offenbar an dem orientiert was der Fiat bekommt oder was tatsächlich geladen wird, meint, dass die Ladung bis zu einem vollen Akku rund 25:13 h dauert. Das ergibt eine Ladestrom von etwa 1,1 kW !!! Das bestätigt auch meine Beobachtung, dass die Ladezeit ein vielfaches höher ist, als vermutet.
Dass EVCC 3,7 kW (230V * 16A = 3680W) anzeigt ist für mich ein Indikator, dass es keine Möglichkeit hat das zu messen. Was Sinn ergibt, weil du eine WARP2 Smart hast, d.h. ohne Zähler. Das heißt EVCC muss davon ausgehen, dass wenn es der Wallbox einen Ladestrom von 16 Ampere vorgibt, diese 16 Ampere auch verbaucht werden. Dass die Information, wie viel Strom das Auto wirklich zieht, fehlt, führt dann dazu, dass EVCC falsch berechnet, wie lange der Ladevorgang dauern wird.
Was mir nicht klar ist, ist warum EVCC nicht aus der Fiat-API auslesen kann, wie viel Strom tatsächlich beim vom Auto gezogen wird.
Alternativ kann man in der Wallbox noch den Stromzähler nachrüsten um sie praktisch von einer WARP2 Smart in eine WARP2 Pro zu verwandeln. Für PV-Überschussladen (unabhängig von den Fahrzeug-APIs) ergibt das meistens Sinn.
On 8/4/2023 at 12:22 PM, milima said:Hat jemand noch Ideen zur Schützproblematik? Wie schon in meinem letzten Post geschrieben schaltet der Schütz anscheinend schon (man hört das "Klack") oder versucht es zumindest, der Energy Manager geht dann aber sofort in den Fehlerzustand Schützfehler" :-(
Oh sorry, hatte den Post davor übersehen. Wenn du das Schütz hörst und das Fenster auf rot (also stromführend) geht, dann funktioniert das Schütz höchst wahrscheinlich. D.h. das Problem ist vermutlich, dass die Schützüberwachung nicht oder nicht richtig angeschlossen ist. Es müssen die "hinteren" Kontakte (23, 24, siehe Bild) an den Eingang 4 des Energy Managers angeschlossen sein.
-
Der zweite Bug entsteht (auch) dadurch, dass die Namensauflösung per mDNS relativ lange dauert. Das ist ein bekanntes Problem. Ein Ansatz das zu lösen wäre, die Pakete, die diese Meldungen auslösen:
Received packet from unknown 192.168.1.75. Is the config complete?
zu akzeptieren. Das hat noch ein paar Fallstricke, steht aber auf der Liste. Aus Ubersichtsgründen habe ich ein eigenes Issue dafür aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/264 (davor war das Teil von #225)
Prinzipiell gebe ich dir aber recht, dass überhaupt schon 20 Sekunden nach Neustart Strom umverteilt wird, wenn noch nicht alle Wallboxen wieder aufgetaucht sind, ist definitiv nicht gut. Habe dafür auch ein Issue aufgemacht:https://github.com/Tinkerforge/esp32-firmware/issues/263 und den Debug-Report anonymisiert angehangen.
Noch eine Sache aus dem Log:
2023-08-01 15:58:19,628 Charge manager watchdog triggered! Received no available current update for 30000 ms. Setting available current to 10000 mA
Der Watchdog hat einmal ausgelöst, danach kommt aber nicht sofort eine Stromumverteilung. D.h. zwischen dem Ablaufen der 30 Sekunden des Watchdogs und der nächsten Stromverteilung (das kann zwischen 0 und 10 Sekunden später passieren) kam dann doch noch ein neuer Stromwert an. Würde ich erstmal auf den WLAN-Empfang schieben. Wobei du einen RSSI-Wert von -61 hast. Das ist nicht so schlecht.
Unabhängig von den anderen Sachen ist das ursprüngliche Problem gut sichtbar:
2023-08-01 15:57:19,494 Redistributing current 2023-08-01 15:57:19,495 1 charger requests current. 19950 mA available. 2023-08-01 15:57:19,495 stage 0: Calculated target for eins (127.0.0.1) of 6000 mA. 13950 mA left. 2023-08-01 15:57:19,505 stage 0: 13950 mA still available. Recalculating targets. 2023-08-01 15:57:19,516 stage 0: Recalculated target for eins (127.0.0.1) of 16000 mA. 3950 mA left. 2023-08-01 15:57:19,526 stage 0: 3950 mA still available. Attempting to wake up chargers that already charged their vehicle once. 2023-08-01 15:57:19,536 stage 2: Unthrottled eins (127.0.0.1) to 16000 mA. 2023-08-01 15:57:20,696 Charger state changed from 1 to 2 2023-08-01 15:57:21,727 Charger state changed from 2 to 3 2023-08-01 15:58:19,628 Charge manager watchdog triggered! Received no available current update for 30000 ms. Setting available current to 10000 mA 2023-08-01 15:59:29,573 Redistributing current 2023-08-01 15:59:29,573 1 charger requests current. 19950 mA available. 2023-08-01 15:59:29,573 stage 0: Calculated target for eins (127.0.0.1) of 6000 mA. 13950 mA left. 2023-08-01 15:59:29,584 stage 0: 13950 mA still available. Recalculating targets. 2023-08-01 15:59:29,594 stage 0: Recalculated target for eins (127.0.0.1) of 6000 mA. 13950 mA left. 2023-08-01 15:59:29,604 stage 0: 13950 mA still available. Attempting to wake up chargers that already charged their vehicle once. 2023-08-01 15:59:29,615 stage 1: Throttled eins (127.0.0.1) to 6000 mA. 2023-08-01 15:59:29,625 stage 1: Throttled a charger. Skipping stage 2 2023-08-01 15:59:29,635 Skipping stage 2
Um 15:57 wird Strom verteilt, das führt dazu, dass die eine Wallbox (habe die in eins und zwei umbenannt) anfängt zu laden. Deshalb startet der 120 Sekunden-Countdown der Startphase. Die erste Stromverteilung danach (15:59) gibt dann wieder nur 6 Ampere frei.
Ich melde mich nochmal, wenn ich mehr weiß. Danke schonmal für die Hilfe bei der Fehlersuche :)
-
Das sollte so funktionieren, ja. Der Energy Manager benutzt das Lastmanagement-Protokoll um die CP-Trennung auszulösen. Das entsprechende Paket wird vom EVSE Common-Modul verarbeitet und das wiederrum ruft EVSE::set_control_pilot_disconnected auf. Da gibst du den Befehl an EVSE CPC weiter soweit ich das sehe -> Sollte klappen.
-
Laut der Logs sieht es in der Tat so aus, als ob das Schütz zum Phasenumschalten entweder nicht richtig angeschlossen oder defekt ist. Eine Sache kannst du noch probieren: Wenn das Schütz umschaltet, sollte das hörbar sein. D.h. du kannst dich neben den Schaltschrank stellen und dann EVCC von ein- auf dreiphasig umschalten lassen und mal lauschen.
Bezüglich des Ladevorgangs: Der Fiat scheint ein etwas seltsames Ladeverhalten zu haben. Ich habe spontan hier: https://www.goingelectric.de/forum/viewtopic.php?p=1806963#p1806963 Leute mit einem ähnlichen Problem gefunden. Da du das SoC-Laden von EVCC benutzt, müsstest du vermutlich mal die EVCC-Entwickler fragen, was da genau los ist: https://github.com/evcc-io/evcc/discussions Sinnvollerweise fixen wir aber erst das Schützproblem ;)
Was ich aus dem goingelectric-Thread rauslese ist, dass der Fiat deutlich weniger Strom zieht, als ihm vorgegeben wird, und die Verlustleistung bei niedrigen Strömen scheint hoch zu sein. Ich vermute jetzt, dass EVCC die Ladeleistung runtergedreht hat, weil die SoC-Ziel-Berechnung sagt, dass noch viele Stunden Zeit sind und du deshalb lange im ineffizienten Bereich geladen hast. Du kannst den Minimalstrom aber konfigurieren: https://docs.evcc.io/docs/reference/configuration/loadpoints/#mincurrent Beim Renault Zoe macht es z.B. keinen Sinn dreiphasig mit weniger als ~ 9A zu laden, weil die Effizienz dann in den Keller geht. Eventuell gibts für den Fiat vergleichbare Erfahrungswerte.
Edit: Habe vergessen den 2. goingelectric-Thread zu verlinken: https://www.goingelectric.de/forum/viewtopic.php?p=1775589#p1775589
-
Die Pinleiste scheint kompatibel zum HAT Brick zu sein. Zumindest die SPI-Pins die wir auf jeden Fall brauchen (19, 21, 23) sind korrekt.
Es kann sein, dass das HAT nicht automatisch detektiert wird. Wenn das der Fall ist, musst du dir eine Konfiguration für den Brick Daemon schreiben, der den CS-Pins für jeden Port korrekt setzt. Das ist hier: https://www.tinkerforge.com/de/doc/Hardware/Bricks/HAT_Brick.html#kompatibilitat-zu-anderen-boards-und-images erklärt.
Das sollte also funktionieren (alle Angaben ohne Gewähr ;) )
Was ich noch gefunden habe: https://wiki.radxa.com/Rock4/hardware/gpio
QuoteSPI
- Pin 19, 21, 23, 24 also route to the pins of SPI flash on board. If the ROCK 4 model has SPI flash soldered on board, the SPI function is not available on GPIO header.
Das scheint aber laut https://wiki.radxa.com/Rockpi4/hardware/spi_flash eher ältere Modelle zu betreffen.
Warp1 + Warp 2 OCPP
in WARP Charger
Geschrieben
Oder statt dem warp-Environment das warp_with_ocpp-Environment kompilieren.