Hallo Zusammen!
Ich habe mir gerade die Software so modifiziert, dass meine IFEU Ladebox mit Phoenix Controller unterstützt wird.
Nachteil: ich kann so ohne weiteres keine Updates mehr einspielen.
Folgende Dateien mussten bearbeitet werden:
/openWB/web/settings/modulconfiglp.php
openWB/runs/set-current.sh
Neu erstellt:
openWB/modules/:
main.sh
phoenix.py
evsephoenixwritemodbus.py
Es wäre gundsätzlich einfacher, wenn folgende Dinge schon in der offiziellen Version vorhanden wären:
/openWB/web/settings/modulconfiglp.php: Option für Wallbox USER1 mit ID=evseconuser1,ladeleistungmodul=user1lllp1 IP Variable user1iplp1 user1idlp1 user1httplp1 (weitere Ladepunkte entsprechend).
/openWB/runs/set-current.sh: Zuordnung evsecon - evseconuser1 = setChargingCurrentIpUser1 $current $user1iplp1 $user1idlp1 $user1httplp1
mit function: function setChargingCurrentIpPhoenix () {
current=$1
evseip=$2
id =$3
http=$4
# set desired charging current
sudo /var/www/html/openWB/modules/user1lp1/write.sh $current $evseip $id $http
Dann brauch man nur noch im Ordner /var/www/html/openWB/modules/user1lp1/ seinen code platzieren und das ganze läuft.
Wenn man das für 2 bis 3 Ladepunkte einbaut, evtl. noch 2 - 3 verschiedene USER Wallboxen wird das ganze ungemein flexiebel.
Noch schöner wäre es natürlich wenn neue Module mit in die offizielle Version aufgenommen werden könnten, aber ich habe gesehen, dass es eine gewisse Abneigung gegenüber Phoenix gibt.
Gruß,
Burkhard
USER Wallbox
Re: USER Wallbox
Extra für sowas gibt es HTTP als Ladepunktoption.
Du kannst gerne einen Handler bauen für die Selbstinstallierer der hier „übersetzt“.
Leider erhalten wir von Phoenix keinen dedizierten Support.
In der Folge würden Nutzer sich openWB selbst installieren oder die Standalone kaufen und dann ein „Anrecht“ auf Support haben. Für etwas das wir nicht supporten können weil der Hersteller nicht mitspielt. Heißt uns entstehen Kosten und der Support wird gebunden. Der Nutzer ist dann verärgert und schickt die Standalone (zurecht) zurück. Nutzer verärgert und unnötig Kosten produziert.
Um das Problem zu umgehen die Möglichkeit „http“ auszuwählen. Ein kleiner Handler dazwischen und versierte Selbstinstallierer können es frei nutzen.
Du kannst gerne einen Handler bauen für die Selbstinstallierer der hier „übersetzt“.
Leider erhalten wir von Phoenix keinen dedizierten Support.
In der Folge würden Nutzer sich openWB selbst installieren oder die Standalone kaufen und dann ein „Anrecht“ auf Support haben. Für etwas das wir nicht supporten können weil der Hersteller nicht mitspielt. Heißt uns entstehen Kosten und der Support wird gebunden. Der Nutzer ist dann verärgert und schickt die Standalone (zurecht) zurück. Nutzer verärgert und unnötig Kosten produziert.
Um das Problem zu umgehen die Möglichkeit „http“ auszuwählen. Ein kleiner Handler dazwischen und versierte Selbstinstallierer können es frei nutzen.
Supportanfragen bitte NICHT per PN stellen.
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
Re: USER Wallbox
Hi!
Das klingt ja grundsätzlich interessant, gibt es dazu eine Dokumentation, ich konnte keine finden.
Gruß,
Burkhard
Das klingt ja grundsätzlich interessant, gibt es dazu eine Dokumentation, ich konnte keine finden.
Gruß,
Burkhard
Re: USER Wallbox
Das Modul in der openWB mal auswählen. Da steht bei was passiert.
Supportanfragen bitte NICHT per PN stellen.
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
Re: USER Wallbox
Danke!
Dann muss ich mal durchschieben, dann HTTP ist nur bei Ladepunkt 1 verfügbar. Also muss ich doch wieder an
/openWB/web/settings/modulconfiglp.php
rumbasteln
.
Gruß,
Burkhar
Dann muss ich mal durchschieben, dann HTTP ist nur bei Ladepunkt 1 verfügbar. Also muss ich doch wieder an
/openWB/web/settings/modulconfiglp.php
rumbasteln
.Gruß,
Burkhar
Re: USER Wallbox
Ehrlich gesagt, verstehe ich nicht, warum http nur für Ladepunkt 1 verfügbar ist. Allgemein, warum nicht alle Optionen an allen Ladepunkten verfügbar sind.
Wenn ich das jetzt anpasse, kann ich ja wieder keine Updates durchführen....
Gruß,
Burkhard
Wenn ich das jetzt anpasse, kann ich ja wieder keine Updates durchführen....
Gruß,
Burkhard
Re: USER Wallbox
Das "ist halt so gewachsen". Wenn Du das für Lp2 ergänzt, dann mach doch bitte einen Pullrequest auf GitHub.So wandert es in den offiziellen Code, alle haben was davon und Du kannst weiter Updates einspielen.
Re: USER Wallbox
Ich denke, ich werde den ganzen Satz von Ladepunkt 1 auf Ladepunkt 2 und 3 kopieren.
Müssen die Scripte zum laden und schreiben der conifg auch noch angepasst werden oder sind die universell.
Am Ende wird es bei mir so aussehen, dass ich eine Keba und zwei Phoenix am laufen haben werde.
Gruß,
Burkhard
Müssen die Scripte zum laden und schreiben der conifg auch noch angepasst werden oder sind die universell.
Am Ende wird es bei mir so aussehen, dass ich eine Keba und zwei Phoenix am laufen haben werde.
Gruß,
Burkhard
Re: USER Wallbox
Die sind jetzt so universell, dass nur das Name-Attribut mit der Bezeichnung in der openwb.conf übereinstimmen muss. Der Eintrag in der Datei muss durch die atreboot.sh einmalig angelegt werden. Wenn Du reinschaust, gibt es genau das zu Hauf. Einfach kopieren, Namen anpassen und gut.
Re: USER Wallbox
Sooooooo ....
Ich habe mich jetzt etwas intensiver mit der Software beschäftigt und muss sagen, dass es so nicht wirklich Sinn macht, aus meiner Sicht.
Eigentlich erwarte ich als Anwender, dass unterstützte Wallboxen/Ladegeräte an jedem verfügbaren Ladepunkt ausgewählt werden können.
Dass Ladepunkt 1 und 2 bevorzugt werden, wass SOC laden, Grafiken und Auswertung angeht, kann ich gut akzeptieren, denn auch noch 8 Fahrzeug SOC Linien in der Grafik macht es nicht gerade übersichtlicher.
Das ganze im jetzigen Zustand umzusetzen ist nahezu unmöglich, da folgende Strukturen in der Programmierung zu "gewachsen" sind:
Ladpunkt 1 war offensichtlich mal der einzige Ladepunkt, deswegen gibt es fast keine Kennung der Variablen als Zugehörig zu LP1.
Dann wird später mal als Kennung S1 für LP2 hinzugefügt und S2 für LP3 (evsecons1 ist die Anbindung für LP2, wer macht sowas?). Für Messungen wird MP2 an LP2 verwendet, was eine Übersetzung für andere Ladepunkte weiter erschwert.
Mein Ziel wäre es jetzt den Ladepunkt 1 jetzt so zu reformieren (evsecons wird zu evseconsLP1 usw.) dass man den ganzen Block für die weiteren Ladepunkte kopieren kann und man nur LP1 mit LP2 usw. ersetzten braucht. Variablen die für jeden Ladepunkt gleich bleiben würde ich mit LPx versehen, dass macht auch erkennbar, dass diese Variable mehrfach genuzt wird.
Mir ist klar, dass das alle .sh Dateien betreffen würde. Und auch, dass Funktionen bereitgestellt würden, die im Moment nicht an höheren Ladepunkten verarbeitet werden (SOC laden). Auch würde ich Ladepunkt1 abschaltbar machen (lasts2mman) nur um die Konsistenz zu erhalten.
Nun die Frage: ist das erstrebenswert? Ich bin als Programierer Autodidakt und habe das nie offizell gelernt, geschweige denn studiert. Ich zweifel dran, dass ich gerade der richtige für sochl einen massiven Umbau bin. Dazu kommt, dass ich noch nie mit Github gearbeitet habe und noch nicht die geringste Ahnung habe ob ich den Code normal local bearbeiten kann und ihn dann hochlade oder ob ich ihn direkt auf Github bearbeiten muss, wass natürlich dateiübergreifendes Umbenennen von Variablen nahezu unmöglich mach.
Ich werde meine Dateien erst mal wieder in originalzustand versetzten und dann den Phoenix Controller wieder direkt einbauen. Das bekomme ich auch noch für zwei Ladepunkte hin. Wie ich dann die Keba an den dritten bekommen sehe ich dann.
Macht es Sinn diese große Reformation von meiner Seite aus anzugehen oder hat das ein Profi schon auf seiner Liste?
Gruß,
Burkhard
Ich habe mich jetzt etwas intensiver mit der Software beschäftigt und muss sagen, dass es so nicht wirklich Sinn macht, aus meiner Sicht.
Eigentlich erwarte ich als Anwender, dass unterstützte Wallboxen/Ladegeräte an jedem verfügbaren Ladepunkt ausgewählt werden können.
Dass Ladepunkt 1 und 2 bevorzugt werden, wass SOC laden, Grafiken und Auswertung angeht, kann ich gut akzeptieren, denn auch noch 8 Fahrzeug SOC Linien in der Grafik macht es nicht gerade übersichtlicher.
Das ganze im jetzigen Zustand umzusetzen ist nahezu unmöglich, da folgende Strukturen in der Programmierung zu "gewachsen" sind:
Ladpunkt 1 war offensichtlich mal der einzige Ladepunkt, deswegen gibt es fast keine Kennung der Variablen als Zugehörig zu LP1.
Dann wird später mal als Kennung S1 für LP2 hinzugefügt und S2 für LP3 (evsecons1 ist die Anbindung für LP2, wer macht sowas?). Für Messungen wird MP2 an LP2 verwendet, was eine Übersetzung für andere Ladepunkte weiter erschwert.
Mein Ziel wäre es jetzt den Ladepunkt 1 jetzt so zu reformieren (evsecons wird zu evseconsLP1 usw.) dass man den ganzen Block für die weiteren Ladepunkte kopieren kann und man nur LP1 mit LP2 usw. ersetzten braucht. Variablen die für jeden Ladepunkt gleich bleiben würde ich mit LPx versehen, dass macht auch erkennbar, dass diese Variable mehrfach genuzt wird.
Mir ist klar, dass das alle .sh Dateien betreffen würde. Und auch, dass Funktionen bereitgestellt würden, die im Moment nicht an höheren Ladepunkten verarbeitet werden (SOC laden). Auch würde ich Ladepunkt1 abschaltbar machen (lasts2mman) nur um die Konsistenz zu erhalten.
Nun die Frage: ist das erstrebenswert? Ich bin als Programierer Autodidakt und habe das nie offizell gelernt, geschweige denn studiert. Ich zweifel dran, dass ich gerade der richtige für sochl einen massiven Umbau bin. Dazu kommt, dass ich noch nie mit Github gearbeitet habe und noch nicht die geringste Ahnung habe ob ich den Code normal local bearbeiten kann und ihn dann hochlade oder ob ich ihn direkt auf Github bearbeiten muss, wass natürlich dateiübergreifendes Umbenennen von Variablen nahezu unmöglich mach.
Ich werde meine Dateien erst mal wieder in originalzustand versetzten und dann den Phoenix Controller wieder direkt einbauen. Das bekomme ich auch noch für zwei Ladepunkte hin. Wie ich dann die Keba an den dritten bekommen sehe ich dann.
Macht es Sinn diese große Reformation von meiner Seite aus anzugehen oder hat das ein Profi schon auf seiner Liste?
Gruß,
Burkhard