Mit welchem Board anfangen?

[Driziman]

Hallo zusammen,

ich möchte mir ein OpenDTU-OnBattery System aufbauen.

Unterstützt werden sollen:

• 1x Hoymiles HM Inverter für die Einspeisung (NRF24)
• 1x Pylontech Protokoll kompatible Batterie über CAN-Bus
• 1x Huawei R4850G2 für das Laden über AC (Joy-IT SBC-CAN01)
• 1x Ethernetport

Am liebsten wäre mir ein Board, welches möglichst viele der o.g. Komponenten schon an Bord hat. Deshalb hatte ich mich schon auf das FusionBoard mit PoE und CAN/ISO Shield Erweiterungen festgelegt.

Jetzt habe ich aber bedenken, dass nicht genügend PINs für die Huawei Erweiterung übrig sind. Kann das jemand bestätigen/dementieren?

Ich habe auch kein Problem damit, das Board von Grund auf neu aufzubauen falls nötig, welches Board wäre hierfür der beste Start (außer, dass es mindestens 8MB haben sollte)?

Vielen Dank für eure Hilfe!

[schlimmchen]

OpenDTU Fusion mit PoE Hat vertrieben von Alliance Apps.

Für die Kommunikation mit dem Huawei brauchst du zur Zeit noch diesen MCP2515 (oder so ähnlich, siehe Wiki) CAN Transceiver, der per SPI angeklemmt wird.

[Driziman]

Danke dir. Das habe ich schon verstanden. Was ich nicht verstehe ist, ob ich am Fusion Board in o.g. Konfiguration noch genügend (und die richtigen) PINs für den MCP2515 frei habe.

[schlimmchen]

Ich sehe du hast schon einen passenden CAN Controller für das Huawei Netzteil. Dann willst du noch eine zweite CAN Schnittstelle für die Pylontech-kompatible Batterie. Dann musst du ein bisschen basteln. Denn dann willst du eigentlich auch noch das CAN/Iso Shield, aber dann wird es eng mit Pins bzw. du musst anfangen mit Löten. Du kannst dann die für ein I2C Dispaly vorgesehen Pins verwenden, musst aber noch mind. zwei weitere (ich weiß nicht ob vielleicht sogar drei) vom SPI Display Header nehmen, auf dem theoretisch das CAN/Iso Shield steckt.

Ist das verständlich ausgedrückt?

Mit aktuellem Softwarestand geht es wohl nur mit Basteln, wenn ich nicht etwas übersehen habe.

Ich rate dir dennoch zum Fusion Board, weil du dann recht wenig basteln musst und mit dem RF Teil keine Probleme haben wirst.

[Driziman]

Ja, ist verständlich und so hatte ich das auch erwartet. Ich denke, dass ich auf den Ethernetport (und damit auf die PoE Erweiterung) verzichte und damit genug Pins zum Anschluss des R4850G2 CAN Controllers zur Verfügung habe.

[stefan123t]

Ich hatte die selbe Frage oder Überlegungen schon seit geraumer Zeit im Hinterkopf. Nicht weil das OpenDTU-Fusion Board nicht gut wäre sondern weil es ja einen kleinen / feinen Unterschied zum PCB Pro aus #541 geben dürfte.

@schlimmchen warum empfiehlst Du in diesem Fall das OpenDTU-Fusion board anstelle des PCB Pro ?

Ausschließlich wegen der Ethernet Anforderung des Nutzers bzw. dem PoE HAT fürs Fusion ?

Eine andere Alternative mit PoE wäre vermutlich nur ein Olimex PoE mit dem ganzen notwendigen Hardwarezoo außen herum selber zu bauen.
Bei meinen dicken Fingern und den dünnen Dupont Kabeln würde man definitiv lieber eine ordentliche Platine für so eine wichtige Komponente vorziehen.

Kann man auf einem CAN Bus am CAN/ISO Shield/HAT immer nur zwei Geräte ansprechen (OpenDTU-OnBattery + Pylontech / Huawei) oder könnte man die theoretisch auch alle drei anschliessen weil sie ja auf andere Adressen antworten?

https://wiki.ta.co.at/CAN-Bus

Braucht man dann an jedem angeschlossenen CAN-Bus Teilnehmer eigene Abschlusswiderstönde oder nur beim ersten und letzten Teilnehmer wie früher beim BNC LAN / ISDN ? Offenbar reicht es bis 10m bei Sternverkabelung die jeweiligen „toten“ Enden zu terminieren.

[stefan123t]

Adding/Tagging @MalteSchm and @berni2288 who contributed the original CAN Bus implementation and replaced it with the Espressif TWAI (Two-Wire Automotive Interface) in PR #135

• The TWAI (Two-Wire Automotive Interface) driver/twai/include/driver/twai.h/driver/twai.c from Espressif is used for most of the BatteryProvider's.

OpenDTU-OnBattery/src/BatteryCanReceiver.cpp

Line 39 in a8f57d9

twai_timing_config_t t_config = TWAI_TIMING_CONFIG_500KBITS();

    twai_timing_config_t t_config = TWAI_TIMING_CONFIG_500KBITS();

Using the TWAI_TIMING_CONFIG_500KBITS() Macro which is defined here:
https://github.com/espressif/esp-idf/blob/7a305c0284b7af7cd8b8f12b48f72e2685d9a363/components/hal/include/hal/twai_types.h#L74-84

#define TWAI_TIMING_CONFIG_500KBITS()   {.clk_src = TWAI_CLK_SRC_DEFAULT, .quanta_resolution_hz = 8000000, .brp = 0, .tseg_1 = 11, .tseg_2 = 4, .sjw = 3, .triple_sampling = false}
...
#define TWAI_TIMING_CONFIG_500KBITS()   {.clk_src = TWAI_CLK_SRC_DEFAULT, .quanta_resolution_hz = 10000000, .brp = 0, .tseg_1 = 15, .tseg_2 = 4, .sjw = 3, .triple_sampling = false}

• The MCP2515 for the Huawei CAN is initialized here

https://github.com/hoylabs/OpenDTU-OnBattery/blob/4ee49a6ecb90a800e57db7554a88b53cb0bf55af/src/Huawei_can.cpp#L36C1-L42C1

    CAN = new MCP_CAN(spi, huawei_cs);
    if (!CAN->begin(MCP_ANY, CAN_125KBPS, MCP_8MHZ) == CAN_OK) {
        MessageOutput.println("[HuaweiCanClass::init] Error Initializing MCP2515...");
        return;
    }

I understand that we need a specific MCP2515 transceiver for some electronic reasons according to the fine manual of the Huawei Wiki.

---

Can we instantiate two TWAI driver classes mapped to the same RX/TX GPIO pins, i.e. both linked to the same transceiver ?

Only difference one class is instantiated with the TWAI_TIMING_CONFIG_500KBITS() macro for listening to the Battery and another class configured using the TWAI_TIMING_CONFIG_125KBITS() macro allowing us to send & receive data to/from the Huawei Charger.

I do not know if this may lead to issues with CAN Bus arbitration and/or if we can bind the TWAI code twice to the same RX/TX ?

Or can we simply switch the TWAI / CAN Bus driver and/or its Baud Rate every time we need to communicate with the Huawei Charger and then fallback listening to the Battery ?

[MalteSchm]

The bus speeds differ. While most things are technically possible the effort and complexity clearly speak against such an approach

[stefan123t]

@MalteSchm and would it be advisable to use the TWAI library for the Huawei Implementation too,
i.e. but on the separate CAN Bus that the MCP2515 is connected to.

Or does the TWAI library not support the MCP2515 features (which ?) we need for the Huawei communication ?

Reason would be to use the same backend code instead of two distinct libraries.
This would IMHO probably even safe us some of the code size in Flash.

[MalteSchm]

The MCP2515 is a CAN controller with a specific instruction set that you control over SPI. The lib available here https://github.com/coryjfowler/MCP_CAN_lib controls this IC
The TWAI library is a lib for interfacing with the internal CAN controller of the ESP. The ESP had/has only one CAN controller (you might want to check this once more for the ESP32-S3).

I suppose that the instruction sets differ, hence the different libs.

If you want to solve this I suggest building a separate CAN bus speed converter that reads data from the Huawei and supplies this at a higher rate using a 2nd CAN interface. One CAN interface can be connected to the Huawei, one to the ESP that runs OpenDTU. This converter would be implemented using a 2nd ESP. This would enable using one CAN bus only.

[stefan123t]

Thanks @MalteSchm and @schlimmchen I searched a bit myself and there is a project from AutoSportLabs ASL out there that followed the same approach:

• use the built in TWAI CAN Controller
• use a separate MCP2515 CAN Controller

---

ESP32-CAN-X2 Dual CAN bus automotive grade development board
https://www.autosportlabs.com/product/esp32-can-x2-dual-can-bus-automotive-grade-development-board/

The Autosport Labs ESP32-CAN-X2 is a development board designed to make CAN bus communications easy for automotive and industrial applications.

It features the ESP32-S3-WROOM-1-N8R8 using an Xtensa® 32-bit LX7 CPU operating at up to 240 MHz (8MB flash, 8MB PSRAM), dual CAN bus support, two CAN bus transceivers, and an automotive-grade power supply to safely integrate it into your car project.

• Bridge two CAN bus networks with different baud rates
• Collect data from two different CAN bus networks with different baud rates

2nd CAN bus provided by MCP2515: while CAN1 uses the built in TWAI CAN compatible controller; CAN2 uses the on-board MCP2515 CAN bus controller

ESP32-CAN-X2 Documentation
https://wiki.autosportlabs.com/ESP32-CAN-X2

Examples Code
https://github.com/autosportlabs/ESP32-CAN-X2

[ck873]

Ich bin noch eher Anfänger (gerade was Bus Systeme angeht) und möchte ein rein AC gekoppeltes System aufbauen (mit R4850G2, einem AO Lithium Speicher und einem HM-1500 WR). Wenn ich das richtig verstehe ist es nicht so ohne weiteres möglich mit dem CANbus des Speichers und den des R4850G2 zu kommunizieren. Gibt es hierfür aktuell überhaupt eine Lösung (in der openDTU onbattery Doku wird der AC gekoppelt Speicher ja sogar vorgeschlagen)? Wäre super wenn ihr mir etwas weiterhelfen könntet. :-)

[stefan123t]

@ck873 siehe oben die Antwort von schlimmchen:

OpenDTU Fusion mit PoE Hat vertrieben von Alliance Apps.

Für die Kommunikation mit dem Huawei brauchst du zur Zeit noch diesen MCP2515 (oder so ähnlich, siehe Wiki) CAN Transceiver, der per SPI angeklemmt wird.

D.h. Kommunikation ist möglich, aber nur mit je einer festen Bus Geschwindigkeit und da die Geräte (speziell das Huawei R4850G2) unterschiedliche feste Geschwindigkeiten (default 500 kBps vs. Huawei 125 kBps) vorgegeben haben, geht es nur mit einem zweiten separaten CAN Bus.

1. eingebauter TWAI CAN Controller des ESP32-S3 für eine/mehrere Pylontech Protokoll kompatible Batterien mit TWAI_TIMING_CONFIG_500KBITS
2. separater MCP2515 CAN Controller für das Huawei R4850G2 mit CAN_125KBPS

[ck873]

Danke schon mal für die Antwort ;-)
Den zweiten CAN Controller (MCP2515) kann ich dann an jedes ESP32-S3 Boards anschließen? Neben den beiden CAN Bus Controlleren brauche ich auch noch ein NRF24 Modul und wollte auf jedenfall einen Ethernetport. Passt das dann noch alles auf das Board?
Oder noch besser könnt ihr mir eine Hardware Empfehlung für diesen spezifischen Aufbau geben?