go-eCharger mit 1-/3-Phasen Umschaltung

[philipp123]

(dies konnte ich allerdings nicht wirklich testen, da ich "nur" einen Go-e mit HW Version 3 habe aber keinen "alten" - allerdings ist mittlerweile bestätigt worden, dass der HWv2 diesen Parameter nicht hat und somit sollte es auf alle Fälle funktionieren).

Den Test kannst du dir vermutlich auch sparen, da es der Code nie in die Nightly schaffen wird nach den Aussagen von openWB und der Diskussion Sommerupdate und unserer Erfahrung mit PR 1559.

Von daher wird das wenn dann getestet, wenn es einen Nutzer gibt, der V2 und V3 im Einsatz hat und es sich selbst installiert.

Du kannst aber auch einfach einen PR stellen, ist ja kein Aufwand. Wenn der gleich abgelehnt wird, hast du Gewissheit. Sollte er doch bearbeitet werden und nicht nur liegen bleiben und ein Test mit V2 nötig sein, kann ich das übernehmen.

[AlSi_8480]

Sollte es nur an einem V2 zum vergleichenden testen mangeln, kann ich gerne einen von meinen zur Verfügung stellen.

[Stevie_AN]

Den Test kannst du dir vermutlich auch sparen, da es der Code nie in die Nightly schaffen wird ...

...und es sich selbst installiert.

Da möchte ich an dieser Stelle gleich mal die hoffentlich nicht allzu dumme Frage stellen, wie denn das einfachste und sicherste Vorgehen ist, um diese und ähnliche Änderungen am besten vom Github in die openWB zu bekommen? Voraussetzung SSH-Zugang ist klar - aber tauscht man dann einfach ein paar Dateien aus (evtl. FTP-Transfer)?

[philipp123]

Da möchte ich an dieser Stelle gleich mal die hoffentlich nicht allzu dumme Frage stellen, wie denn das einfachste und sicherste Vorgehen ist, um diese und ähnliche Änderungen am besten vom Github in die openWB zu bekommen? Voraussetzung SSH-Zugang ist klar - aber tauscht man dann einfach ein paar Dateien aus (evtl. FTP-Transfer)?

Ja, man tauscht einfach Dateien aus. Sind in dem Fall glaube ich 2 Stück. Anleitungen wie man das z.B. mit FileZilla über SSH machen kann gibt es massig.

Und jetzt das ABER: Bei jedem Update überbügelt es die manuellen Dateien wieder.

[LutzB]

Eine etwas saubere Lösung:
Auf GitHub einen eigene Fork erstellen und die openWB auf diesen "verbiegen". Dann kann man dort alle Änderungen selbst pflegen und das Update kommt vom eigenen Fork.

[Stevie_AN]

Ja, man tauscht einfach Dateien aus. Sind in dem Fall glaube ich 2 Stück. Anleitungen wie man das z.B. mit FileZilla über SSH machen kann gibt es massig.

Wenn ich das richtig verstanden habe, wären es in diesem Fall 4 Dateien:

goe1p3.png (5.94 KiB) 2585 mal betrachtet

Eine etwas saubere Lösung:
Auf GitHub einen eigene Fork erstellen und die openWB auf diesen "verbiegen". Dann kann man dort alle Änderungen selbst pflegen und das Update kommt vom eigenen Fork.

Das klingt sehr elegant, ist mir aber glaub ne Nummer zu groß. Ich dachte eher so in Richtung... Updatedatei vorher lokal auf dem Rechner speichern --> modifizieren --> modifiziertes Update in die openWB laden. Ginge das auch?

Sorry, hat mit dem Ursprungsthema leider nichts mehr zu tun - hat mich halt trotzdem interessiert.

[philipp123]

Wenn ich das richtig verstanden habe, wären es in diesem Fall 4 Dateien:

Es müsste doch um die Dateien
runs/u1p3pcheck.sh und runs/u1p3pgoe.py gehen?

Das klingt sehr elegant, ist mir aber glaub ne Nummer zu groß. Ich dachte eher so in Richtung... Updatedatei vorher lokal auf dem Rechner speichern --> modifizieren --> modifiziertes Update in die openWB laden. Ginge das auch?

Ich habe das mit dem Fork bei mir so laufen. Definitiv die sauberste Lösung. Aber man muss sich dann etwas mit Git beschäftigen, da auch plötzlich Konflikte hochkommen können wenn was in der offiziellen Nightly geändert wird.

Ohne Fork ist das einfachste, nach jedem Update die 2 Dateien immer wieder rein zu kopieren. Das Uodate vor dem Laden zu modifizieren ist im Endeffekt der eigene Fork, da man ja aus Github updated und nicht aus einer Updatedatei.

[sunscreen69]

Nehmen wir mal an, ich hätte einen eigenen Fork den ich selbst über Merge mit snaptec:master aktuell halte.
Was müsste ich denn Ändern, damit ich bei einem Merge den Update über die Oberfläche der OpenWB machen kann, die sich dann meinen aktuellen For zieht und nicht das Original. Oder würde man das besser anders lösen?

[philipp123]

Nehmen wir mal an, ich hätte einen eigenen Fork den ich selbst über Merge mit snaptec:master aktuell halte.
Was müsste ich denn Ändern, damit ich bei einem Merge den Update über die Oberfläche der OpenWB machen kann, die sich dann meinen aktuellen For zieht und nicht das Original. Oder würde man das besser anders lösen?

Die sauberste Lösung ist wie du oben beschrieben hast. Wenn nämlich alle jetzt an ihrer Box spielen und dann die Updates nicht mehr mitgehen, wäre das auch für die Tests etc. meiner Meinung nach eine Katastrophe.

Mir hat damals der Tip geholfen von Tensing2 geholfen (Hier gekürzt):

Das kann man mit einem GIT-Befehl ändern:
$ git remote rm origin
$ git remote add origin git@newserver:project.git
$ git remote show origin

Wenn du Lust hast, kannst du ja mal auf der Konsole git remote show origin eingeben. Damit machst du nichts kaputt.

Wenn dich das nicht weiter bringt, würde ich aber ehrlich gesagt an deiner Stelle die Finger davon lassen.

[Stevie_AN]

Nehmen wir mal an, ich hätte einen eigenen Fork den ich selbst über Merge mit snaptec:master aktuell halte.
Was müsste ich denn Ändern, damit ich bei einem Merge den Update über die Oberfläche der OpenWB machen kann, die sich dann meinen aktuellen For zieht und nicht das Original. Oder würde man das besser anders lösen?

Also, ohne es getestet zu haben und ACHTUNG "gefährliches Halbwissen!"

Ich würde mir die config-Datei in: /var/www/html/openWB/.git/ editieren:

Code: Alles auswählen

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = https://github.com/snaptec/openWB.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "stable"]
	remote = origin
	merge = refs/heads/stable

und die URL entsprechend auf die eigene Fork umbiegen.

Bin aber weder Programmierer noch sonst irgendwas. Deshalb: OHNE GARANTIE