Support für Fusion Board möglich?

[Saarblick]

Hallo,

Ich setzte zwei Hoys ein, einmal HM600 einmal HMT2250, konnte ein Fusion Board bekommen was auf einer Platine mit OpenDTU beide WR-Typen ansprechen kann.
Wollte als nächsten Schritt Zero-Export und danach die Einbindung eines Pylontecs angehen.
Leider scheint OnBattery derzeit nicht mit dem Fusion Board kompatibel zu sein.
Könnte das mal überprüft und evtl. kompatibel gemacht werden? :-)

https://github.com/markusdd/OpenDTUFusionDocs

Gruss und vielen Dank

[spcqike]

Was genau ist denn nicht kompatibel?

Ich habe leider keins dieser Boards, aber der Code beinhaltet es

[helgeerbe]

Die GPIOs sind nicht rausgeführt, um Victron MPPT (serial) und/oder Pylontech Battery (CAN-BUS) anzuschliessen. Wenn du das alles nicht brauchst, sollte openDTU-onBattery auch auf den Fusion Board laufen, wenn das original auch drauf läuft.

[teletapi]

Das Repo lässt sich unter s3 und Fusionsboard nicht compilieren, weder per Master noch per Dev03

[helgeerbe]

Ach so. Da kannst du dummy Werte angeben, da die Anschlüsse eh nicht benutzt werden können. Dann noch drauf achten, dass due die Hardware in OpenDTU-onBattery nicht in der Oberfläche aktivierst. Bzw. freie GPIOs verwenden, damit du keine Konflikte bekommst.

    -DVICTRON_PIN_TX=21
    -DVICTRON_PIN_RX=22
    -DPYLONTECH_PIN_RX=27
    -DPYLONTECH_PIN_TX=14
    -DHUAWEI_PIN_MISO=12
    -DHUAWEI_PIN_MOSI=13
    -DHUAWEI_PIN_SCLK=26
    -DHUAWEI_PIN_IRQ=25
    -DHUAWEI_PIN_CS=15
    -DHUAWEI_PIN_POWER=33

[markusdd]

Darf ich fragen welche GPIOs ihr braucht? Es stehen auf dem Fusion alle Pins die der ESP hat irgendwie zur verfügung.
(der ESP32-S3 kann alle pins eh überall hinmappen, also man kann auf den Display-SPI-Header, den UART/I2C/JTAG-Header alles drauflegen was man mag.

Die Pinsbelegungstabelle des Fusion und welche man frei belegen kann findet man hier:
https://github.com/markusdd/OpenDTUFusionDocs#pin-mapping-of-the-esp32-s3-on-opendtu-fusion-v2x

EDIT: Also gemäß eurer Grafik hier https://github.com/helgeerbe/OpenDTU-OnBattery#symbolic-view ist das mit dem Fusion 0.0 Problem das umzusetzen. Einfach entscheiden wo man den kram anschließen will und entsprechend die pin.-summern eintragen.
NRF24 und CMT2300A sind onboard und brauchen demsntsprechend extern nicht bespielt und verdrahtet zu werden.

[markusdd]

also für 4x pins würde sich der JTAG header eignen oben rechts. Da debugging über USB geht beim S3 und die meisten eh primär mit printf über USB oder UART arbeiten ist der idR unbenutzt.

Da könnt ihr also einfach die TCK/TMS/TDO/TDI pins missbrauchen. Dann sind sowohl SPI als auch i2c display header noch frei.

[swingstate]

@markusdd planst Du das Board ggfs. noch zu erweitern, beispielsweise mit einen GPIO extender?

[markusdd]

was meinst du damit? Alle pins die frei sind, sind bereits auf pin header geführt. es gibt am ESP keinen freien Pin mehr. Wir haben überlegt evtl mal noch ein PoE-Shield zu machen weil das noch einige weitere SMD-komponenten braucht.
Einen modbus transceiver gibts ja schon.

[swingstate]

Mittels z.b. MCP23016 weitere PINs ermöglichen. Um z.b. ein AC relay (8-10A) bei entsprechender DC/Batteriespannung zu steuern. Beispielsweise als last resort Abschaltung des Wechselrichters auf der AC Seite, um die Batterie nicht zu tief zu entladen.
Das Relay könnte dann ja auch ggfs. in Smarthomesteuerungen integriert werden, um in Automatisierungen verwendet zu werden.

Ein anderer, aber wohl komplexerer Fall, ist die sichere Trennung der Batterie nahe der Unterspannung und erneuter Verbindung bei entsprechender Spannung ohne dass der Inverter mit 100A geflutet wird (Inrush current limiter).

[markusdd]

Da würde dann aber ein Relaisboard mit entsprechender Extension mehr sinn ergeben.
Zum Thema inrush current gibt es imho ein eigenes PCB Projekt im Discord von OpenDTU/ahoy.
Da sind dann auch ganz andere Komponentenklassen drauf.

Problem ist, dass man natürlich am Ende fast alles machen kann, man muss natürlich aber am Ende dann auch wirklich die Größe des Zielpublikums und deren Fähigkeiten beachten. Für Ethernet/PoE scheint es eine relevante Zielgruppe zu geben, sodass sich ein Shield lohnen kann. Gerade bei Storage setups wird es aber schnell exotisch. Der eine hat, CAN, der andere Modbus, der nächste UART, der nächste ne latte GPIOOs um noch XYZ zu steuern xD

Lange rede kurzer Sinn: soweit ich das Überblicke sind eigentlich noch immer etliche Pins frei, weil 2x RX/TX gehen ja über wie gesagt z.B. den JTAG header. Dann gibts immer noch RX/TX und SCL/SDA auf den I2C/UART headern, sind nochmal 4 nutzbare pins. Und der SPI Header hat dann nochmal 6 Pins zur freien verfügung. Macht insgesamt 14 freie Leitungen für Zig anwendungszwecke.
Wer Modbus oder long-distance UART braucht muss davon nichtmal was abzwacken, weil dafür haben wir ja sogar nen modbus transceiver aufm basisboard.

Man kann natürlich über ein zweites Shield nachdenken, welches z.B. einen CAN TRansceiver an Board hat oder so, aber da müsste dann jemand mit dem willen antreten da mit ein Konzept zu erarbeiten udn das dann auch zuu testen, weil so ein Setup hab ich nicht.