Hoymiles-Library als extra Repository

[sivar2311]

Moin @tbnobody!
Könntest du dir vorstellen, die Hoymiles-Library in ein extra Repository zu legen?
Damit könnte die Library in andere Projekte einfacher eingebunden werden.

lib_deps = 
  https://github.com/tbnobody/hoymiles.git

[battifreund]

Moin! Das wäre wirklich super. So wäre eine ESPHome-Komponente einfacher möglich.

[sivar2311]

Ich habe die Hoymiles Library zum testen in ein eigenes Repository unter sivar2311/Hoymiles gelegt und kleine Pfadanpassungen vorgenommen.

Weiterhin habe ich einen Fork der openDTU mit folgenden Modifikationen angelegt:

• platformio.ini angepasst (lib_deps um https://github.com/sivar2311/Hoymiles.git ergänzt)
• ResetReason.h in das include Verzeichnis verschoben
• ResetReason.cppin das src Verzeichnis verschoben
• lib Verzeichnis gelöscht

Das ganze kompiliert wunderbar und die Library kann / könnte so auch in anderen Projekten wunderbar eingesetzt werden.
Ein kleines Test-Projekt habe ich unter sivar2311/Hoymiles-Test abgelegt.

Da sich die Pflege dieser externen Library schwierig gestalten wird, werde ich die Repositories demnächst wieder löschen (sie dienen nur zum Test)

[tbnobody]

Hallo @sivar2311 ich finde die Idee generell gut die Hoymiles Lib separat zu hosten und einzubinden. Das im aktuellen Stadium zu machen würde aber zum einen die lokale Entwicklung hier etwas verkomplizieren (gut, ich müsste die Lib zum Entwickeln wohl statt über die platformio.ini mit git submodules einbinden) und außerdem ist das Klassen-Interface auch noch alles andere als stabil.

[sivar2311]

Hallo @tbnobody !

Das im aktuellen Stadium zu machen würde aber zum einen die lokale Entwicklung hier etwas verkomplizieren (gut, ich müsste die Lib zum Entwickeln wohl statt über die platformio.ini mit git submodules einbinden)...

Mit git submodules kenne ich mich nicht aus.
Wenn ich Bibliotheken entwickle, erstelle ich zuerst das Repository und clone es dann in das globale PlatformIO Library Verzeichnis unter C:\Users\<username>\.platformio\lib (Windows). So kann man prima lokal arbeiten und das (Test-)Projekt greift auf die lokale Version der Library zu. Im Testprojekt dann natürlich ohne den lib_deps Eintrag.

und außerdem ist das Klassen-Interface auch noch alles andere als stabil.

Vielleicht noch nicht stabil, aber dennoch sehr schön umgesetzt!
Da sind noch so einige Tricks die ich mir abschauen kann :)

[sivar2311]

Hi @tbnobody !
Ich habe mich mit den git submodules beschäftigt und finde es "suboptimal".
Sowohl beim clonen des Repository als auch beim Download als ZIP-Datei werden die submodules nicht beachtet.
Es würde also die Hoymiles-Bibliothek fehlen und das Projekt lässt sich nicht kompilieren.

Dann doch lieber die Verknüpfung via lib_deps :)

[madmartin]

@tbnobody
Ich finde git submodule auch nicht gut. Stimme @sivar2311 in allen Punkten voll zu.

[tbnobody]

Hallo @sivar2311 ,

Das herunterladen als ZIP Datei wird sowieso nicht supported bzw. brachte bis vor ein paar commits sowieso einen Fehler beim kompilieren...

Und zum Thema Git Submodules.... https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/How-to-clone-a-git-repository-with-submodules-init-and-update

[sivar2311]

git submodule update habe ich bei meinen ersten Versuchen auch schon kennen gelernt :)
Leider gibt's m. E. dafür keinen einfachen Menüpunkt in VS-Code.