feature: SPIPortManager to allow use of CMT radio and Huawei charger at the same time

[AndreasBoehm]

backport 'SPIPortManager' from skippermeisters fork: skippermeister@a642c9d

Ongoing discussion: #1132 (comment)

fixes: #605

Tests:

• ESP32 with NRF24 and CMT2300a
• ESP32 with NRF24 and Huawei CAN
• ESP32 with CMT2300a and Huawei CAN
• ESP32-S3 with NRF24 and CMT2300a
• ESP32-S3 with NRF24 and Huawei CAN
• ESP32-S3 with CMT2300a and Huawei CAN
  - [ ] ESP32-C3 with NRF24 and CMT2300a
  - [ ] ESP32-C3 with NRF24 and Huawei CAN
  - [ ] ESP32-C3 with CMT2300a and Huawei CAN

SPI# to SPI ID and SPI_HOST mapping

ESP32

SPI #	SPI ID	SPI_HOST
2	2	1
3	3	2

ESP32-S3

SPI #	SPI ID	SPI_HOST
2	0	1
3	1	2

ESP32-C3

SPI #	SPI ID	SPI_HOST
2	0	1

[skippermeister]

@AndreasBoehm
Schau dir noch einmal meine letzte Änderung von heute an fix: SPIPortmanager for ESP32S3 more generic (2.Test). Ich habe das aus meiner Sicht besser lesbar gemacht. Und ich habe den Paramatertyp für die spi_host Nummer auf spi_host_device_t geändert. Das ist der typedef aus der driver/spi_master.h. Diesen Typ verwendet der SPI Treiber.

[AndreasBoehm]

Danke, hab ich so übernommen.
Ich hab die mapping Tabelle nochmal überarbeitet und verwende jetzt SOC_SPI_PERIPH_NUM um zu ermitteln wie viele SPIs vorhanden sind.

[skippermeister]

hab ich übernommen

[AndreasBoehm]

@darksideofthemoon1712
@Manos1966

Hier gibts das build zum ausprobieren ob CMT2300a und Huawei charger nun zusammen funktionieren. Da ich keinen Huawei charger habe konnte ich bisher nur testen ob NRF24 und CMT2300a weiterhin gleichzeitig funktionieren.

[Manos1966]

Hallo @AndreasBoehm ich habe eine Frage weil langsam die Zahl der freien GPIOs fuer mein MCP2515 Board gering wird.... ein paar von den urspruenglich gedachten GPIOs werden jetzt von CMT2300a benutzt.

• kann ich ein paar von den GPIO 36,39,34,35 (oben Links) fuer das MCP2515 Board nutzen? (sind nur Input)?
• Und bei GPIO 9,19,11 (unten links) und GPIO 6,7,8 (unten rechts)? (SPI Bus fuer Flash Memory - "Do not use")?

[AndreasBoehm]

@Manos1966 sorry, da kann ich dir leider nicht helfen. Ich nutze ein Fusion Board und bin in den Technischen Details eines ESP32 noch nicht wirklich tief drin.

[mager33]

* kann ich ein paar von den GPIO 36,39,34,35 (oben Links) fuer das MCP2515 Board nutzen? (sind nur Input)?

* Und bei GPIO 9,19,11 (unten links) und GPIO 6,7,8 (unten rechts)? (SPI Bus fuer Flash Memory - "Do not use")?

"do not use" meint tatsächlich "do not use". Die anderen GPIO die input-only sind kannst Du eben nur als Eingang nutzen, NICHT als Ausgang. Damit keil CLK/CS oder MOSI, nur MISO.

[Manos1966]

Hallo @AndreasBoehm

Hier gibts das build zum ausprobieren ob CMT2300a und Huawei charger nun zusammen funktionieren. Da ich keinen Huawei charger habe konnte ich bisher nur testen ob NRF24 und CMT2300a weiterhin gleichzeitig funktionieren.

I habe die opendtu-onbattery-generic_esp32_4mb_no_ota.factory.bin auf mein "Huawei ESP32 Setup" geflascht
(ESP32-WROOM-32D mit VE.Direkt, NRF24, Huawei CAN MCP2515)

Es funktioniert nicht:
Ohne CMT2300 PIN-Mapping, alles laeuft OK
Wenn ich aber ein PIN-Mapping mit CMT2300 aktiviere, dann geht der ESP32 in einen Neustart-Loop.

Initialize Hoymiles interface...
[SPIPortManager] SPI2 now in use by 'NRF24'
NRF: Connection successful
[SPIPortManager] SPI2 already in use by 'NRF24'
[SPIPortManager] SPI3 now in use by 'CMT2300A'
E (461) spi: spi_bus_initialize(755): invalid host_id
ESP_ERROR_CHECK failed: esp_err_t 0x102 (ESP_ERR_INVALID_ARG) at 0x4008fa94
file: "lib/CMT2300a/cmt_spi3.c" line 40
func: cmt_spi3_init
expression: spi_bus_initialize(spi_host, &buscfg, SPI_DMA_DISABLED)
abort() was called at PC 0x4008fa97 on core 1

Bootlog here: https://pastebin.com/ynEdi389

UPDATE: Ich sollte vielleicht erst OHNE NRF24 probieren? 🤔

[AndreasBoehm]

@Manos1966 Danke fürs testen. Ich hab eine Berechnung falsch durchgeführt, deswegen ging es nicht. Hab ich behoben und auf einem ESP32 mit CMT2300a ausprobiert. Du kannst gerne direkt CMT2300a und NRF24 gemeinsam nutzen. CMT + NRF + Huawei wird aber nicht klappen, dafür hat der ESP32 und ESP32-S3 nicht genug SPIs.

Neues build ist hier zu finden.

[Manos1966]

Danke @AndreasBoehm
sieht viel besser jetzt (ohne NRF24+ angeschlossen) 😅

Boot normal, CMT & Huawei laufen parallel 👍
z.Zeit noch nicht angeschlossen an Wechselrichter & Huawei.
Wechselrichter im Bild ist eine fiktive HMS Nummer. Morgen kommt mein HMS-600, danach kann ich mit einem echten HMS testen. Huawei schliesse ich spaeter an...

Boot log here https://pastebin.com/EaqY3akk

Initialize Hoymiles interface...
[SPIPortManager] SPI2 now in use by 'CMT2300A'
CMT: Connection successful
Setting country mode...
Setting CMT target frequency...
Setting radio PA level...
CMT TX power set to 0 dBm
Setting DTU serial...
Setting poll interval...
Setting verbosity...
Initialize Huawei AC charger interface...
Huawei AC-charger miso = 12, mosi = 13, clk = 26, irq = 25, cs = 15, power_pin = 17
[SPIPortManager] SPI2 already in use by 'CMT2300A'
[SPIPortManager] SPI3 now in use by 'Huawei CAN'
Entering Configuration Mode Successful!
Setting Baudrate Successful!
Starting to Set Mask!
Setting Mask Successful!
Starting to Set Filter!
Setting Filter Successful!
Starting to Set Mask!
Setting Mask Successful!
[HuaweiCanClass::init] MCP2515 Initialized Successfully!

[skippermeister]

Das sieht doch perfekt aus.

Hinweis: Meine nächste Entwicklung wird die Integration eines Longan SeeedStudio I2C to MCP2515 Moduls für den zweiten CAN Bus Port sein. das Modul habe ich bereits. Damit würde das HUAWEI Netzteil über I2C angeschlossen und zusammen mit NRF24 und CMT2300A und einer Pylontech oder Bytes angeschlossen über CAN funktionieren.
Ich werde die Software Funktion in meinem Fork entwickeln und testen. Wenn Du möchtest, kannst Du dann die Anpassung in die original openDTU-onBattery Version übernehmen.

Das Longan SeeedStudio Modul (es gibt mehrere Versionen) besteht aus einem
ATMEGA168+MCP2515 CAN Bus Controller+MCP2551 CAN Bus Transceiver (Achtung gemäß Specs nur 5V
oder
ATMEGA168+MCP2515 CAN Bus Controller+MCP2562 CAN Bus Transceiver (benötigt 3.3 und 5V)
oder
ATMEGA168+MCP2515 CAN Bus Controller+SN65HVD230 CAN Bus Transceiver (benötigt nur 3.3V)

Die beiden letzten wären meine Empfehlung.

Es kann direkt an den 3.3 Volt GPIO Pins des ESP32/ESP32-S3 angeschlossen werden und wird über I2C angesprochen.

[Manos1966]

@AndreasBoehm
Erwartungsgemäß, angeschlossen am Huawei R4850G2 ueber CANbus funktioniert ohne Probleme, daher:

• ESP32 with CMT2300a and Huawei CAN 🥂

[Manos1966]

Alle ESP32 Varianten getestet und sie funktionieren!
(Frage: @AndreasBoehm Wie erstellst du diese Tabelle?)

• ESP32 with NRF24 and CMT2300a
• ESP32 with NRF24 and Huawei CAN
• ESP32 with CMT2300a and Huawei CAN

[AndreasBoehm]

Danke @Manos1966 !

das geht so
‘- [ ] Text’

aus den Eckigen Klammern wird dann die Checkbox

[darksideofthemoon1712]

Hallo Zusammen, hab das PR auf einem esp32S3 gestestet. CMT2300a geht auch wenn Huawei in der Pinmapping konfiguriert ist.
Macht aber Probleme wenn der MCP2515 angeschlossen ist. Display habe ich auf pin15 und 16. wahrscheinlich muss ich für den MCP2515 andere GPIO benutzen. Habe jetzt die die mir Skippermeister vorgeschlagen hat.
"huawei": {
"miso": 38,
"mosi": 35,
"clk": 36,
"irq": 47,
"cs": 37,
"power": 38

[skippermeister]

@darksideofthemoon1712
Hast Du nur den CMT2300A und den MCP2515 für das HUAWEI Netzteil aktiviert?
Und NRF24 ist nicht konfiguriert bzw. ist nicht aktiviert ?
Hinweis: NRF24+CMT2300A+HUAWEI geht nicht gleichzeitig, das wären 3x SPI Bus.
Was für eine Batterie bzw. BMS hast Du?
Wie sieht Dein genaues Setup aus? Welche Geräte sind konfiguriert ?
Ich kann leider auf meinem Setup CMT2300A + MCP2515 nicht testen. Ich habe kein HMS Wechselrichter und kein HUAWEI.
Was für Probleme gibt es?
Hast Du ein log erstellt?

[darksideofthemoon1712]

Hallo Skippermeister,
funktioniert natürlich, wenn man alles richtig eintippt. Hatte einen Fehler im Pinmapping.
Danke.

[darksideofthemoon1712]

@Manos1966
ich hatte CMT2300,Huawei,Display konfiguriert. Sah alles gut aus. Als ich nun das MCP2515 angeschlossen habe, war auch nur noch eine Bootschleife. Oder ist das normal wenn kein 4850G2 angeschlossen ist?

[Manos1966]

Oder ist das normal

Normal ist es nicht.
Hast du ein NRF24 auch angeschlossen? Mit -1 als GPIO Zuordnung? 😉
Mach ein zweites PinOutProfil, loesche jegliche Referenz zu NRF24 und probiere es erneut.

Und wenn das nicht hilft, schliesse deinen ESP32 am PC und mache ein BOOT.LOG (eigentlich kannst du direkt auf der Konsole sehen was passiert beim booten...)
https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Wie-man-nach-L%C3%B6sungen-sucht%2C-Fragen-stellt%2C-Probleme-meldet#42-logdatei-w%C3%A4hrend-des-bootvorgangs-erstellen

Mein Bootlog ist hier:
#1144 (comment)

[darksideofthemoon1712]

ich habe alles außer CMT,Display, Huawei auf -1 gesetzt. Einen NRF habe ich gar nicht.

[Manos1966]

ich habe alles außer CMT,Display, Huawei auf -1 gesetzt. Einen NRF habe ich gar nicht.

Dann machst du etwas komplett falsch!

Du kannst wie folgt testen:

• Aktuelle (offizielle) Firmware installieren 2024.06.03
• CMT auf -1 stellen

Pruefen ob dein MCP2515 funktioniert

Hast du dein MCP2515 modifiziert wie hier beschrieben? (oder ist es ein Joy-IT SBC-CAN01 ?)
https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Huawei-AC-PSU#canbus-communication-with-opendtu

Since the ESP generally operates at 3.3V power level, these boards also need to be modified in order to output a 5V signal. This can be done by cutting through a circuit path at the back of the board, as documented in this discussion (more details here). Please be careful not to scratch the surrounding area, otherwise you risk a short circuit to ground.

[skippermeister]

Ich habe bei meinen Tests einen sehr merkwürdigen Fehler mit einem ESP32-S3 mit USB Port. Sobald ich ein CMT und oder NRF24 VE.Direct und dem CAN0 Bus aktiviere, rebootet der ESP32-S3 grundsätzlich in der Funktion twai_driver_install(). Das Problem liegt an der Verfügbarkeit der Interrupts im Level 1. Ich musste in der Initialisierung folgenden Parameter
g_config.intr_flags = ESP_INTR_FLAG_LEVEL2;
vor
twai_driver_install(&g_config, &t_config, &f_config);
einbauen.
Damit wird der Interrupt für den internen CAN0 Bus vom Level 1 auf Level 2 umgestellt.

Falls mit einem ESP32-S3 CMT und/oder NRF24 + CAN0 Bus + VE.Direct das gleiche Problem häufiger auftritt, dann sollten wir die Modifikation ins Modul BatteryCanReceiver.cpp eingepflegen.
Ich kann noch nicht sagen, ob dies nur beim ESP32-S3 mit USB Port auftritt. Mit diesem Board aber reproduzierbar.

In Meinem fork habe ich das bereits implementiert und hochgeladen. Ein Release ist noch nicht erstellt.

[Manos1966]

Hallo @skippermeister

Ich habe
Firmware Version / Git Hash: g63367ba
Firmware Branch: helgeerbe/OpenDTU-OnBattery/pr1144-202408111858
PIO Environment: generic_esp32s3 (Version ohne USB)
auf meine ESP32-S3 mit NRF24+CMT2300A+CANbus+Victron installiert (MCP2515 entfernt)

Als ich Victron auf GPIO1 und GPIO2 definiert hatte, gab es Probleme
Jetzt habe ich auf GPIO37 und GPIO 38 umgestellt und merke keine Probleme.
(ich habe die ESP32-S3 noch nicht an Wechselrichtern,Victron und Pylontech angeschlossen um sicher zu sein, aber so weit, so gut)

[schlimmchen]

Das Problem liegt an der Verfügbarkeit der Interrupts im Level 1.

@skippermeister Was tut das und hat das etwas mit dem SPI Port Manager zu tun?

Somit fehlen uns nur noch tests mit einem ESP32-C3, kennst du jemanden den wir fragen können @schlimmchen?

@AndreasBoehm Der eine User, der einen ESP32-C3 einsetzt, der wird sich dann schon melden, wenn es mit dem ESP32-C3 nicht klappt 🤷‍♂️

[skippermeister]

@schlimmchen
Das Interrupt Problem tritt bei meinen Test nur auf meinem ESP32-S3 mit USB Port auf.
Ich hatte lange den Grund des permanenten reboot analysiert. Ich hatte CAN0+NRF24+VE.Direct oder CAN0+CMT+VE.Direct oder CAN0+NRF24+CMT+VE.Direct aktiviert. Immer wenn der CAN0 initialisiert wurde, hat der ESP-S3 rebootet. Sobald ich die Ve.Direct oder NRF24 oder CMT deaktiviert hatte, bootete der ESP einwandfrei. Auch wenn ich die Interrupts des CMT deaktiviert hatte bootete der ESP-S3 sauber.
Der USB benötigt mindestens einen Interrupt im Level 1. Der CAN0 arbeitet im Standard auf Level 1 und auch die SPI Ports arbeiten im Level 1. Die Interrupt Routinen der internen Geräte, dazu gehören auch die Timer arbeiten im Interrupt Level 1. Der Level 1 erlaubt nur eine beschränkte Anzahl von Interrupt Service Routinen.
Anscheinend tritt der Fehler erst mit dem S3 Chip in Verbindung mit dem USB Port auf.
Deshalb habe ich den CAN0 auf Interrupt Level 2 geändert, also eine Prio-Stufe geringer.
Ich glaub nicht, dass es mit dem SPIPortManager in Verbindung steht.

Auf einem ESP32 tritt der Fehler nicht auf, da genügend freie Interrupts im Level 1 zur Verfügung stehen.

[Manos1966]

@skippermeister kannst du auch bestätigen, dass mit Firmware opendtu-onbattery-generic_esp32s3.bin (ohne USB), deine ESP32-S3 mit USB Port funktioniert ohne Probleme? (so wie es bei mir der Fall ist)

(oder willst du, dass ich es teste - die Firmware opendtu-onbattery-generic_esp32s3_usb.bin (mit USB), auf meine ESP32-S3 mit USB Port zu installieren und gucken ob sie das gleiche Problem hat?)

[skippermeister]

@Manos1966
Ich habe heute noch einen Fehler in meinem Meanwell Laderegler gefunden. Unter bestimmten Situationen (ich vermute Waschmaschine ein/aus, also starker Lastwechsel) hat sich der Regler aufgeschwungen. Die Änderung habe ich im Source Code hochgeladen, allerdings noch kein Release erstellt.

Ich teste die Tage mal meine Software auf dem ESP32-S3 USB mit der opendtu-onbattery-generic_esp32s3.bin (ohne USB.

[AndreasBoehm]

@skippermeister das klingt so als ob dein Problem nichts mit dem SPIPortManager zu tun hat.

Mit einem Fusion Board (ESP32-S3) funktioniert die Kombination aus NRF, CMT, CAN0 und 2x Victron mit den USB builds ohne Probleme, sowohl mit aktuellem Release build als auch mit dem build aus diesem PR.

Falls ihr mit der gleichen Hardware schwierigkeiten habt wäre es super wenn Ihr ausschließen könnt das es am SPIPortManager liegt und hier kurz Bescheid gebt.

Dieser PR ist jetzt schon relativ lange offen und ich habe das Gefühl das wir hier vom Thema abkommen, jedenfalls hab ich den Überblick verloren und weiß aktuell nicht ob der SPIPortManager nun bei allen funktioniert oder nicht.

[skippermeister]

@AndreasBoehm
mein ESP32-S3 Modul unterscheidet sich vom Fusion Board darin, dass ich PSRAM habe. Am SPIPortManager liegt mein entdecktes Problem anscheinend nicht. Wie ich das sehe, hast Du bislang den S3 Chip ohne PSRAM getestet. Ich habe PSRAM. Es wird also der interne SPI0 für den PSRAM intensiv genutzt und dadurch auch Interrupts im Level 1. Da Du das Fusion Board mit USB nutzt, kann mein entdecktes Problem also auch nicht am USB liegen.

Also liegt es wohl am PSRAM.
Dann müssen wir für die PSRAM Versionen eine bedingte Kompilierung für den CAN0 einbauen, der bei aktiviertem PSRAM (-DBOARD_HAS_PSRAM) den Interrupt Level auf 2 setzt.
Ich teste das.

Du kannst diesen PR aber schließen.

[schlimmchen]

Du kannst diesen PR aber schließen.

Ich nehme an, das ist ein Tippfehler?! Der wird nicht geschlossen, der wird ge-merge't...

@AndreasBoehm Die Eingriffe in die Libs sind schon lästig. Beim Einpflegen von Änderungen aus dem Upstream kann das lästig werden. Ich sehe aber den Vorteil, den der SPI Port Manger bringt definitiv als wichtiger an. Außerdem gibt es in den Libs wenig Anpassungen und vermutlich auch zukünftig wenig Bedarf für Anpassungen.

Danke @skippermeister und @AndreasBoehm.

[swingstate]

Habe mir die Diskussion bis hier in durchgelesen und doch noch ein paar offene Fragen.
Braucht es für die Anbindung des MCP2515 nun ein I2C to MCP2515 Modul, oder habt ihr das anders, über direkte Verbindungen zu den GPIOs und Softwareanpassungen, gelöst? Ich verstehe es bisher so, dass mit diesem PR sowohl NRF als auch CMT sowie Pylontech (über einen separaten CAN Bus) zusammen mit einem Huawei Netzteil laufen werden. Richtig verstanden?

[AndreasBoehm]

Das MCP2515 Modul wird über direkte Verbindungen genutzt.

CMT, NRF und Huawei können nicht gleichzeitig genutzt werden. Eins davon musst du weg lassen.

[Manos1966]

@AndreasBoehm angenommen:
alle drei CMT, NRF und Huawei angeschlossen sind und mit Strom versorgt werden,
aber in Pin-Mapping einer davon mit -1 definiert ist,
wird das System booten?
(bin zu Faul zum testen... 🙊 bzw neu Factory flaschen falls es nicht klappt)

[AndreasBoehm]

Booten wird es auch wenn im pin mapping alle Ger äte hinterlegt sind. Wirst nur im Log sehen welches Gerät nicht aktiviert werden konnte und sonst funktioniert alles ganz normal.

[Manos1966]

Booten wird es auch wenn im pin mapping alle Ger äte hinterlegt sind. Wirst nur im Log sehen welches Gerät nicht aktiviert werden konnte und sonst funktioniert alles ganz normal.

Ich habe anderes erlebt 😨 deine Beschreibung gefehlt mir aber besser ... 👍
Dann werde ich wohl nochmals testen 🤞

UPDATE: Ich habe es getestet, due hast recht er ist NICHT aufgehangen! ❤️
NRF24, CMT2300, HUAWEI alle eingeschaltet, die OpenDTU-OnBattery hat alles meisterhaft gesteuert 🥇

Starting OpenDTU
Initialize FS... done
Reading configuration... done
Reading PinMapping... found valid mapping done
Initialize Network... done
Setting Hostname... Configuring WiFi STA using new credentials... done
Initialize NTP... done
Initialize SunPosition... done
Initialize MqTT... done
Initialize WebApi... done
Initialize Display... done
Initialize LEDs... done
Check for default DTU serial... done
done
Initialize Hoymiles interface...
[SPIPortManager] SPI0 now in use by 'NRF24'
NRF: Connection successful
[SPIPortManager] SPI0 already in use by 'NRF24'
[SPIPortManager] SPI1 now in use by 'CMT2300A'
CMT: Connection successful
Setting country mode...
Setting CMT target frequency...
Setting radio PA level...
CMT TX power set to 0 dBm
Setting DTU serial...
Setting poll interval...
Setting verbosity...
done
Initialize Huawei AC charger interface...
Huawei AC-charger miso = 39, mosi = 40, clk = 42, irq = 9, cs = 41, power_pin = 8
[SPIPortManager] SPI0 already in use by 'NRF24'
[SPIPortManager] SPI1 already in use by 'CMT2300A'
[SPIPortManager] Cannot assign another SPI port to 'Huawei CAN'
[HuaweiCanClass::init] Error Initializing Huawei CAN communication...
done
Switch to WiFi mode
Setting Hostname... done
Configuring WiFi STA using new credentials... done
Configuring WiFi STA DHCP IP... done
[DPL::announceStatus] disabled by configuration
WiFi connected

[swingstate]

Das MCP2515 Modul wird über direkte Verbindungen genutzt.

CMT, NRF und Huawei können nicht gleichzeitig genutzt werden. Eins davon musst du weg lassen.

D.h. man könnte NRF (NRF weil es mit der Zeit weniger HM WR's geben wird) und MCP2515 optional machen und jeweils per Jumper/DIP aktivieren so dass den Nutzern die Wahl bleibt. Wie wird der Wechsel dann in der Software dargestellt? Einfach ein anderes Mapping wählen?

[Manos1966]

@swingstate ich nehme alles zurueck! Du brauchst keine extra Jumper.
Auch wenn alle Geraete eingeschaltet sind, die Version von Andreas behaelt die Kontrolle!

(ich haette schwoeren koennen @AndreasBoehm ich hatte eine Version, wo ich mindenstens ein Geraet entfernen musste damit sie bootet, vielleicht bei der normalen ESP324MB? EGAL, Schnee von gestern).

[swingstate]

Ist das belegt bzw. getestet worden? D.h. das Umschalten erfolgt nur per Software bzw. Mapping Änderung? Welches physisches Interface nutzt ihr eigentlich für die Verbindung zum Huawei bzw. welches wäre sinnvoll?

[Manos1966]

Ist das belegt bzw. getestet worden? D.h. das Umschalten erfolgt nur per Software bzw. Mapping Änderung? Welches physisches Interface nutzt ihr eigentlich für die Verbindung zum Huawei bzw. welches wäre sinnvoll?

siehe #1144 (comment)

[swingstate]

Bleibt noch die Frage nach der physischen Verbindung.

[swingstate]

2 Draht Schraubklemme oder RJ45?

[gitisgreat2023]

@Manos1966

Du hast den Huawei, Pylontech, NRF und CMT Kombi zu laufen bekommen auf einem Board? Chapeau!!
Ist es ein ESP32S3 nehme ich an, oder?

Wie ist der hardware setup aus? Ist ein MCP2515 benötigt? Kannst du das Vorgehen zum nachbauen mal hier dokumentieren?
Wie nutzt du den setup jetzt? Nutzt du den Shelly script um mittels Kaskade die zwei WRs zu regeln?
Falls ja, wäre super, dann fehlt eigentlich nur noch das was schlimmchen in Vorbereitung hat (mehrere inverter zu regeln) und dann wäre alles wieder in einem Board und software und damit weniger anfällig (aber ein single point of failure natürlich auch ;-))

Booten wird es auch wenn im pin mapping alle Ger äte hinterlegt sind. Wirst nur im Log sehen welches Gerät nicht aktiviert werden konnte und sonst funktioniert alles ganz normal.

Ich habe anderes erlebt 😨 deine Beschreibung gefehlt mir aber besser ... 👍 Dann werde ich wohl nochmals testen 🤞

UPDATE: Ich habe es getestet, due hast recht er ist NICHT aufgehangen! ❤️ NRF24, CMT2300, HUAWEI alle eingeschaltet, die OpenDTU-OnBattery hat alles meisterhaft gesteuert 🥇

Starting OpenDTU
Initialize FS... done
Reading configuration... done
Reading PinMapping... found valid mapping done
Initialize Network... done
Setting Hostname... Configuring WiFi STA using new credentials... done
Initialize NTP... done
Initialize SunPosition... done
Initialize MqTT... done
Initialize WebApi... done
Initialize Display... done
Initialize LEDs... done
Check for default DTU serial... done
done
Initialize Hoymiles interface...
[SPIPortManager] SPI0 now in use by 'NRF24'
NRF: Connection successful
[SPIPortManager] SPI0 already in use by 'NRF24'
[SPIPortManager] SPI1 now in use by 'CMT2300A'
CMT: Connection successful
Setting country mode...
Setting CMT target frequency...
Setting radio PA level...
CMT TX power set to 0 dBm
Setting DTU serial...
Setting poll interval...
Setting verbosity...
done
Initialize Huawei AC charger interface...
Huawei AC-charger miso = 39, mosi = 40, clk = 42, irq = 9, cs = 41, power_pin = 8
[SPIPortManager] SPI0 already in use by 'NRF24'
[SPIPortManager] SPI1 already in use by 'CMT2300A'
[SPIPortManager] Cannot assign another SPI port to 'Huawei CAN'
[HuaweiCanClass::init] Error Initializing Huawei CAN communication...
done
Switch to WiFi mode
Setting Hostname... done
Configuring WiFi STA using new credentials... done
Configuring WiFi STA DHCP IP... done
[DPL::announceStatus] disabled by configuration
WiFi connected

[Manos1966]

Sorry @gitisgreat2023 es war nur ein Test um die neue SPIPortManager Firmware Version die Skippermeister und AndreasBoehm
zusammengebaut haben, zu testen (ESP32 4MB, ESP32-S3, OnBattery Pro PCB).

Danach habe ich alles abgebaut.

MC2515 (Joy-IT Version, sowie Standard).

NUR ZWEI VON DREI (NRF24, CMT23000, MC2515) koennen laufen.
EDIT: ich beschreibe es hier etwas verstaendlicher, fuer die jeniger die eines Tages durch die Kommentare gehen werden ohne alles lesen zu wollen:
Die OpenDTU-OnBattery prueft zur Zeit in Reinfolge:

1. NRF24
2. CMT2300
3. HuaweiCAN (MC2515)

wenn sie eine PIN-Definition in der Konfig findet, ordnet sie eins von den (nur) zwei verfuegbaren SPI zu.
Also, du ZWEI Geraete koennen funktionieren. Sie werden waehrend des Boot Vorgangs definiert (siehe mein Boot Log).

Die aktuelle Test Firmware wird sogar erkennen, falls alle drei aktiviert sind und das korrekt behandeln ohne aufzuhaengen (siehe mein Boot Log).

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.

[schlimmchen]

There are bittersweet news regarding this PR/feature: I am going to revert these changes in favor of the upstream implementation of the SpiManager, which is superior to this SPIPortManager, as it allows to share one SPI host to serve multiple SPI devices.

@AndreasBoehm is already aware and plans to help adapt the Huawei CAN implementation to use the new upstream SpiManager library.

Thanks again to @AndreasBoehm for this effort, which was highly appreciated!