Feedback 2.0 Alpha 1

Fragen zur Nutzung, Features, usw..
HSC
Beiträge: 3941
Registriert: So Jan 10, 2021 8:49 am

Re: Feedback 2.0 Alpha 1

Beitrag von HSC »

LutzB hat geschrieben: Fr Dez 24, 2021 1:24 pm Wir freuen uns auf eure Rückmeldungen.
Hallo Lutz,
könntest Du bitte noch beide "Alpha 1"- Threads miteinender verlinken?
viewtopic.php?f=3&t=4513 & viewtopic.php?p=53275#p53275
VG
derNeueDet
Beiträge: 4229
Registriert: Mi Nov 11, 2020 7:16 pm

Re: Feedback 2.0 Alpha 1

Beitrag von derNeueDet »

Wie gehen wir mit Meldungen zur Alpha um? Hier im Thread oder eigene Threads bei Issues? Oder in Git ein Issue aufmachen dazu?

VG
Det
10kWp PV mit SMA Tripower 10000TL-10 (PE11 mit SDM72V2); 2,4kWp mit Solis 2.5 G6 (EE11 mit SDM120). OpenWB Standard+. EVU EM540 an einem Raspi mit Venus OS. BEV Mercedes EQA 250 (07/2023)
LutzB
Beiträge: 3513
Registriert: Di Feb 25, 2020 9:23 am

Re: Feedback 2.0 Alpha 1

Beitrag von LutzB »

Allgemeines gerne hier posten. Konkrete Dinge im Code wohl besser auf GitHub. Zwei Issues gibt es aktuell schon, die dort gut aufgehoben sind, damit es nicht untergeht.

Bitte habt Verständnis, dass die Rückmeldungen etwas länger dauern können.
derNeueDet
Beiträge: 4229
Registriert: Mi Nov 11, 2020 7:16 pm

Re: Feedback 2.0 Alpha 1

Beitrag von derNeueDet »

Hallo Lutz,

Ja ich hab da schon mal angefangen mit Issues im GitHub. Kein Thema, wenn es länger dauert. Evtl. Schaffe ich es ja auch selbst, wenn ich die nächsten Tage etwas Zeit finde. Aber die Struktur ist doch etwas komplexer als bisher. Ich glaube ohne IDE ist das nicht so einfach zu debuggen für einen Außenstehenden. Aber die ersten Dinge habe ich schon gefunden und die Installation auf einem Raspi 3b+ unter Bullseye war problemlos.

VG
Det
10kWp PV mit SMA Tripower 10000TL-10 (PE11 mit SDM72V2); 2,4kWp mit Solis 2.5 G6 (EE11 mit SDM120). OpenWB Standard+. EVU EM540 an einem Raspi mit Venus OS. BEV Mercedes EQA 250 (07/2023)
LutzB
Beiträge: 3513
Registriert: Di Feb 25, 2020 9:23 am

Re: Feedback 2.0 Alpha 1

Beitrag von LutzB »

Als IDE nutzen wir VS Code. Mit der Remote Erweiterung kann man dann direkt auf dem Pi arbeiten. Wenn Bedarf besteht, können wir dazu auch ein HowTo erstellen.
Bucky2k
Beiträge: 398
Registriert: Sa Nov 09, 2019 1:17 pm

Re: Feedback 2.0 Alpha 1

Beitrag von Bucky2k »

Ich bin ja mit zwei LP unterwegs, einer davon der heute nicht mehr angebotene "Satellit" ohne eigenen RasPI. Ich vermute hierzu ist noch nichts verfügbar/lauffähig, richtig?
Bastelfrosch
Beiträge: 213
Registriert: Mi Mär 25, 2020 9:19 am

Re: Feedback 2.0 Alpha 1

Beitrag von Bastelfrosch »

Geht mir genauso, ich gehe mal davon aus,dass es hier das noch nicht festgestellte Modul IP-EVSE geben wird, mit dem der Satellit läuft...
openWB
Site Admin
Beiträge: 7999
Registriert: So Okt 07, 2018 1:50 pm

Re: Feedback 2.0 Alpha 1

Beitrag von openWB »

Satellit Unterstützung ist noch auf der Roadmap, dauert allerdings noch.
Hier muss zunächst die Heartbeat Funktionalität implementiert werden an den Satelliten.
Supportanfragen bitte NICHT per PN stellen.
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
derNeueDet
Beiträge: 4229
Registriert: Mi Nov 11, 2020 7:16 pm

Re: Feedback 2.0 Alpha 1

Beitrag von derNeueDet »

LutzB hat geschrieben: Di Dez 28, 2021 7:59 pm Als IDE nutzen wir VS Code. Mit der Remote Erweiterung kann man dann direkt auf dem Pi arbeiten. Wenn Bedarf besteht, können wir dazu auch ein HowTo erstellen.
VS Code und die SSH Remote Erweiterung hab ich schon mal installiert, aber heute hab ich mich erst mal so im System umgeschaut. Wenn ihr schon ne kurze Anleitung habt, dann gerne her damit.

VG
Det
10kWp PV mit SMA Tripower 10000TL-10 (PE11 mit SDM72V2); 2,4kWp mit Solis 2.5 G6 (EE11 mit SDM120). OpenWB Standard+. EVU EM540 an einem Raspi mit Venus OS. BEV Mercedes EQA 250 (07/2023)
yankee
Beiträge: 481
Registriert: Sa Mai 16, 2020 11:34 am

Re: Feedback 2.0 Alpha 1

Beitrag von yankee »

Es soll ja um Feedback gehen, also was ich mir so aufgefallen ist...

Das erste ist: Wie lasse ich das denn laufen? Noch einen Raspi gerade rumfliegen habe ich nicht. Und es erscheint mir auch unnötig aufwendig extra gesonderte Hardware aufzubauen nur um da mal reinzuschauen und ein bißchen mit rumzuspielen. Die Software kann einfach lokal auf meinem Computer laufen. In einem Docker-Container zum Beispiel.

Habe ich mir so gedacht. War kompliziert. Die install-Script konnte ich nicht nehmen, weil die zu Raspberry-spezifisch waren. Ich musste meinen eigenen Kram zurecht basteln.

Ich habe mir dann eine Datei `run-within-docker.sh` gebastelt:

Code: Alles auswählen

service apache2 start
mosquitto -c /var/www/html/openWB/data/config/mosquitto_local.conf -v &
sleep 1
mosquitto -c /var/www/html/openWB/data/config/openwb_local.conf -v &
sleep 1
mosquitto_pub -p 1886 -t openWB/system/update_in_progress -r -m 'false'
mosquitto_pub -p 1883 -t openWB/system/update_in_progress -r -m 'false'
mosquitto_pub -p 1886 -t openWB/system/boot_done -r -m 'true'
mosquitto_pub -p 1883 -t openWB/system/boot_done -r -m 'true'
mosquitto_pub -t openWB/system/reloadDisplay -m "1"
touch /var/www/html/openWB/ramdisk/bootdone
sudo -u pi /var/www/html/openWB/packages/main.py
Und dazu ein Dockerfile:

Code: Alles auswählen

FROM debian:bullseye

RUN apt update && \
    apt install -y sudo curl iproute2 vim bc apache2 php php-gd php-curl php-xml php-json libapache2-mod-php jq git mosquitto mosquitto-clients socat python3-pip sshpass

RUN useradd -m pi && \
    mkdir /var/www/html/openWB /run/mosquitto && \
    chown pi:pi /var/www/html/openWB && \
    chown mosquitto:mosquitto /run/mosquitto && \
    sudo -u pi git clone https://github.com/openWB/core.git --branch master /var/www/html/openWB && \
    sudo -u pi pip install -r /var/www/html/openWB/requirements.txt && \
    chmod +x /var/www/html/openWB/runs/* /var/www/html/openWB/*.sh && \
    touch /var/log/openWB.log && \
    chmod 777 /var/log/openWB.log && \
    cp /var/www/html/openWB/data/config/000-default.conf /etc/apache2/sites-available/ && \
    sed -i '/^include_dir/d' /var/www/html/openWB/data/config/mosquitto_local.conf && \
    sed -i 's/^listener .*/listener 1886 127.0.0.1/' /var/www/html/openWB/data/config/openwb_local.conf && \
    cat /var/www/html/openWB/data/config/openwb.conf >> /var/www/html/openWB/data/config/mosquitto_local.conf && \
    sudo -u pi mkdir /var/www/html/openWB/ramdisk && \
    sed -i '12d;96,106d;107i\    return []' /var/www/html/openWB/packages/modules/loadvars.py && \
    cp /var/www/html/openWB/index.html /var/www/html/index.html

COPY run-within-docker.sh /var/www/html/openWB/

CMD ["/bin/bash", "/var/www/html/openWB/run-within-docker.sh"]

# Http
EXPOSE 80
# MQTT
EXPOSE 1883
# MQTT Websocket
EXPOSE 9001
Das dann gebaut mit:

Code: Alles auswählen

sudo docker build -t openwb2 .
Und ausgeführt mit:

Code: Alles auswählen

sudo docker run -p 7080:80 -p 1883:1883 -p 9001:9001 -it openwb2
Siehe da, ich kann mit dem Browser auf http://localhost:7080 gehen und ich sehe ein bißchen was :-).

Allerdings ist das ein fragiles Konstrukt mit meinen Änderungen die ich im Dockerfile einfach mal so mit sed hier und da durchführe. Es wäre schon toll / sinnvoll, das ganze etwas kompatibler zu gestalten.

Ich frage mich etwas wie ihr das eigentlich testet, was ihr bastelt. Kopiert ihr bei jeder Änderung alles auf einen Raspberry und führt es da aus? Also klar ist eine Möglichkeit, aber man muss dann immer einen Raspberry zur Hand haben. Und man muss den Code ständig syncen. Wenn man was verkonfiguriert hat muss man (je nachdem wie schlimm es ist, was man verzapft hat) die komplette SD-Karte vom Raspberry zurücksetzen. Ja, geht alles, kann man auch automatisieren, aber so eine schöne lokale Umgebung die man kurz auf seinem Computer direkt laufen lässt ist doch viel einfacher?!

Docker läuft auch auf dem Raspberry. Ich würde sogar in Erwägung ziehen die Software selbst dort in einem Docker-Container laufen zu lassen. Dann hat man eine immer gleiche Umgebung die überall funktioniert. (naja gut, "immer und überall" ist vielleicht etwas sehr optimistisch, Docker hat schließlich auch seine Limitierungen, aber man kommt dem Ziel schon ganz schön nah).

Was mir noch auffällt ist, dass das Repo sehr groß ist. In etwa 100 MB. Gut, das alte Repo war noch größer, aber das ist keine Ausrede ;-). Größte Datei war offenbar ein versehentlich hinzugefügtes Backup in commit 017748b251b90241d228971a7b1e4a4ed09ff967 mit 26 MB. Das Repository könnte man also um 25% verkleinern, wenn man diese Datei rückwirkend rauswerfen würde :-).

Dass die kompilierte Webseite da drin ist, wird der Größe des Repositories jedenfalls nicht unbedingt gut tun, weil hier große Diffs entstehen die sich nicht gut kompilieren lassen und ist meines Erachtens auch keine gute Idee. So gesehen finde ich bei kritischer Betrachtung die Idee einfach "git clone" zu verwenden generell nicht optimal. Aber gut, es funktioniert.

Es sind offenbar noch diverse alte (Frontend-)Skripte vorhanden bei denen ich davon ausgehe, dass die nicht mehr gebraucht werden?! Ich habe da noch nicht ganz geblickt.

Es sind auch noch jede Menge PHP-Dateien da. Und Apache wird verwendet. Ich nehme an das fliegt noch alles raus? Ich blicke nicht ganz ob das tatsächlich noch verwendet wird. Für die Übersicht wäre es jedenfalls schön, wenn nurnoch Code im Repo ist, der auch gebraucht wird....
Gesperrt