Keine NRF Verbindung nach Aktivierung des AC Ladegeräts

[woollfi]

What happened?

NRF Chip verbunden und konfiguriert, nach Aktivierung des AC Ladegeräts ist der NRF Chip nicht mehr verbunden

To Reproduce Bug

NRF einrichten, AC Ladegerät aktivieren

Expected Behavior

NRF und AC Ladegerät sollte funktionieren

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

2024.08.18

Relevant log/trace output

No response

Anything else?

No response

Please confirm the following

• I believe this issue is a bug that affects all users of OpenDTU, not something specific to my installation.
• I have already searched for relevant existing issues and discussions before opening this report.
• I have updated the title field above with a concise description.
• I have double checked that my inverter does not contain a W in the model name (like HMS-xxxW) as they are not supported

[spcqike]

wie sieht dein pinmapping aus? sicher, dass alles korrekt verbunden und gemapped ist?

[woollfi]

ich habe auch schon mehrere mappings probiert, bei einem verursacht das AC Ladegerät ein Bootloop, aber der NRF funktioniert nur bei deaktivierten AC Ladegerät

[Solarteur]

GPIO 17 ist doppelt belegt: Huawei mosi und LED0 - das kann nicht gehen.

2024.08.18 und Vorgänger laufen bei mir (NRF24, Huawei-Ladegerät, Pylontech-Akku) völlig problemlos.

[woollfi]

angepasst, Problem besteht trotzdem

[schlimmchen]

Was hast du für einen Chip (ESP32 oder ESP32-S3 oder sonstwas) und was für ein Board? @Tiese sagt auch, dass sein NRF24 nach dem Update nicht mehr funktioniert.

[woollfi]

einen ESP32-S3, aber sobald ich das AC Ladegerät deaktiviere, geht der NRF

https://de.aliexpress.com/item/1005006418608267.html?spm=a2g0o.order_list.order_list_main.76.7baa5c5flOeANP&gatewayAdapt=glo2deu

[Tiese]

Bei mir sieht der NRF24-Status aber so aus...

Und geht dennoch nicht. 😢

[woollfi]

wie merkst du das er nicht geht? Sendeleistung zu schwach?

[Tiese]

1. steht in der Konsole nur (natürlich unendlich untereinander)...

Fetch inverter: 11219xxx
All missing
Nothing received, resend whole request

2. Der WR ist rot hinterlegt
3. Wenn ich ihm Daten sende, erscheint nur...
   

[Tiese]

PS: Ach so: und alle Werte stehen auf "0"!

[woollfi]

hast du das AC Ladegerät aktiviert?

[Tiese]

Nein.
Und ich habe nicht den ESP32S3, sondern den hier.

[schlimmchen]

Pins GPIO35, GPIO36 und GPIO37 solltest du meiden, siehe Doku. Das müsste sogar wichtig sein, weil du ein Modell mit 16MB Flashspeicher hast. Daher würde ich eigentlich erwarten, dass dein NRF24 auch unabhängig vom AC charger nicht funktioniert... Das ist aber nicht der Fall?!

Dann verwendest du GPIO33 für Huawei Power. Auch dieser Pin ist auf deinem Board fürs Octal SPI in Gebrauch. Außerdem scheint es ein Fehler zu sein, das du "33" gewählt hast, denn GPIO33 ist auf deinem Board gar nicht verfügbar auf einer Pinleiste. Wenn ich sehe, wo die Pins angeordnet sind, hast du vermutlich an GPIO3 angeschlossen.

Bitte mach GPIO 35 - 37 frei und korrigiere Huawei Power auf 3 (vermutlich).

[woollfi]

Power ist doch die Stromversorgung des Can Moduls, die hängt auf 3,3V und eine auf 5V, was soll ich dann ins Pinout reinschreiben?
Bei diesem Pinout kommt eine Bootloop, darf man hier auch was nicht nehmen?

[schlimmchen]

Power ist doch die Stromversorgung des Can Moduls, die hängt auf 3,3V und eine auf 5V, was soll ich dann ins Pinout reinschreiben?

... Aber das steht doch alles in der Doku?!

Ich versteh jetzt nicht so recht, wie du auf die Idee kommst, da 33 einzutragen für "3.3V". So hast du es gemeint, oder? Bei diesem Pin handelt es sich um einen Output, der das Netzteil einschaltet -- soweit ich das verstehe, kann hier keine Gewähr geben.

Bei diesem Pinout kommt eine Bootloop, darf man hier auch was nicht nehmen?

Da würde ich keine Probleme erwarten. Wie sieht denn deine vollständige pin_mapping.json aus? Hast du einen der Pins woanders schon in Verwendung?

[woollfi]

die 33 habe ich übernommen, jetzt verstehe ich das, wenn ich das nicht verwende, dann -1 ?

ich teste dann ein neues pinout und gebe Bescheid ob sich was ändert

[schlimmchen]

wenn ich das nicht verwende, dann -1 ?

-1 ist "nicht benutzen", aber ob der Pin optional ist, weiß ich nicht.

Das Diagramm ist für ein ESP32 DevKit. Das hat mit dem ESP32-S3 DevKit nichts zu tun bzw. ist inkompatibel.

[woollfi]

das weiß ich das es für ESP32 ist, aber jetzt weiß ich was der Power Pin ist, das könnte der Grund sein für das aufhängen wenn AC aktiviert, ich werde gleich testen
mein neues Pinout:

[
    {
        "name": "Huawei+Battery+Display",
        "battery": {
            "rx": 39,
            "tx": 40
        },
	"display": {
            "type": 5,
            "data": 41,
            "clk": 42
	},
	 "eth": {
            "enabled": false,
	    "phy_addr": 0,
	    "power": -1,
	    "mdc": -1,
	    "mdio": -1,
	    "type": 0,
	    "clk_mode": 0
        },	
        "huawei": {
            "miso": 16,
            "mosi": 17,
            "clk": 18,
            "irq": 8,
            "power": 3,
            "cs": 15
        },
       "nrf24": {
            "miso": 14,
            "mosi": 9,
            "clk": 10,
            "irq": 13,
            "en": 12,
            "cs": 11
        }     
    }
]

[woollfi]

Getestet, wenn ich jetzt AC aktiviere hängt sich der ESP auf und kommt in einen bootloop, wo am Display openDTU! steht.
Ohne AC geht der NRF.

[woollfi]

Das mit dem Update verstehe ich auch nicht

[schlimmchen]

Ignoriere die Info zum Update, siehe #1190.

Getestet, wenn ich jetzt AC aktiviere hängt sich der ESP auf und kommt in einen bootloop, wo am Display openDTU!

Jo... Dann wäre es jetzt wichtig, die Ausgaben an der seriellen Konsole zu sehen, um der Exception, die den Bootloop auslöst auf die Spur zu kommen.

[woollfi]

https://pastebin.com/GaGqbRmm

[schlimmchen]

Nebenbemerkung: Im Log ist irgendetwas komisch. Da fehlt doch Zeug? Hast du generic_esp32s3_usb oder generic_esp32 installiert und hast du den Log vom nativen USB Port oder vom Port an der UART Bridge? Wenn du die _usb Variante benutzt, solltest du auch den nativen USB-Port benutzen. Auf dem Bild, das du oben gezeigt hast, ist es der linke Port.

Aha, jetzt haben wir immerhin ein anderes Problem, eins das greifbar ist, nämlich ist nun der Stack für den Huawei AC charger Task zu klein. Aber warum?! Und warum scheinbar nur bei dir? Sehr merkwürdig. Bist du etwa der erste, der das auf einem ESP32-S3 nutzt?

0x4037d615: _frxt_setup_switch at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port/xtensa/portasm.S:79
0x403794ae: _xt_lowint1 at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1103
0x4037e710: xQueueSemaphoreTake at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c:1612
0x42072b55: spiTransaction at /home/beki/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c:1094 (discriminator 1)
0x4205dfe5: SPIClass::beginTransaction(SPISettings) at /home/beki/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp:186
0x4206057a: MCP_CAN::mcp2515_readRegister(unsigned char) at /home/beki/Documents/OpenDTU-OnBattery/.pio/libdeps/generic_esp32s3_usb/mcp_can/mcp_can.cpp:51
0x42060db9: MCP_CAN::mcp2515_getNextFreeTXBuf(unsigned char*) at /home/beki/Documents/OpenDTU-OnBattery/.pio/libdeps/generic_esp32s3_usb/mcp_can/mcp_can.cpp:798
0x42060f22: MCP_CAN::sendMsg() at /home/beki/Documents/OpenDTU-OnBattery/.pio/libdeps/generic_esp32s3_usb/mcp_can/mcp_can.cpp:1116
0x42060f9d: MCP_CAN::sendMsgBuf(unsigned long, unsigned char, unsigned char, unsigned char*) at /home/beki/Documents/OpenDTU-OnBattery/.pio/libdeps/generic_esp32s3_usb/mcp_can/mcp_can.cpp:1151
0x42012c1a: HuaweiCanCommClass::sendRequest() at /home/beki/Documents/OpenDTU-OnBattery/src/Huawei_can.cpp:189
0x42012ec2: HuaweiCanCommClass::loop() at /home/beki/Documents/OpenDTU-OnBattery/src/Huawei_can.cpp:136
0x42012f06: HuaweiCanCommunicationTask(void*) at /home/beki/Documents/OpenDTU-OnBattery/src/Huawei_can.cpp:31 (discriminator 1)

Dann installiere bitte als nächtes eine development firmware, denn das Problem hat @AndreasBoehm in df53f34 bereits behoben, er hatte das im Rahmen von #1144 beobachtet.

[woollfi]

Problem ist mit der Development Firmware gelöst, huawei und NRF funktionieren gleichzeitig.
Log konnte ich erst starten als die dTU schon lief, vielleicht schaut deswegen der log seltsam aus.


Meine letzte Frage, wenn ich jetzt das JKBMS anhänge, gab es früher auch Probleme, da wurde gesagt, das die Masse eine galvanische Trennung braucht, stimmt das, lässt sich sowas irgendwie leicht bauen?
Besten Dank für die Hilfe

[schlimmchen]

wenn ich jetzt das JKBMS anhänge

Schau mal in die Doku, ich hoffe da ist es hinreichend erklärt.

Deine konkrete Frage nach der galvanischen Trennung ist meiner Meinung nach so zu beantworten: Wenn du den RS485 Adapter verwendest, gibt es nichts zu beachten, der RS485 Bus ist galvanisch getrennt. Aber ja, man sollte den Anschluss über den Adapter bevorzugen, statt des ESP32 direkt an die Pins des BMS anzuklemmen.

[schlimmchen]

Danke für die Rückmeldung. Ich schließe das Issue, weil dein ursprüngliches Problem mit #1204 behoben ist.

[github-actions]

This issue 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.