Bei dem Versuch openEMS von der Entwicklungsumgebung auf ein Debian-System (bei mir: Raspberry Pi) auszurollen, musste ich sehr viel Zeit in Recherche investieren. Die offizielle Dokumentation dazu ist ja leider nicht vollständig. Aufgrund der Aktivitäten des gesamten Projekts und den damit verbundenen zeitlichen Aufwand alles auch noch zu dokumentieren und in step-by-step Anleitungen zu packen - mehr als verständlich!
Meine Schritte habe ich mir im firmen-eigenen Wiki (sehr grob und häßlich formatiert) notiert. Vielleicht nutzen meine Notizen jemanden… OpenEMS_Deployment.pdf (138.4 KB)
vorerst mal vielen herzlichen Dank für deine Mühe und das zur Verfügung stellen deiner Doku OpenEMS_Deployment für Raspberry Pi.
Da ich selbst bis Mai letzten Jahres einen RSPPi3+ im Einsatz hatte und anschließend auf einen INTELNUC mit Proxmox umgestiegen bin, interessiert mich dein Thema sehr.
Habe auf Proxmox schon einiges in einer VM oder LXC am Laufen, z. B. iobroker, influxdb, Grafana etc.
Dies müsste doch mit deiner sehr strukturierten Checkliste auch auf einem LXC umsetzbar sein ?
Möchte gleich vorausschicken, ich bin kein IT-Spezialist (z. B. Linux etc.) , sondern Betriebswirt mit starkem Interesse zur Digitalisierung u. Visualisierung im Bereich Energie u. Energiemanagementsystemen.
Herzlichen Dank im Voraus für deine Info u. Hilfe.
Ich wiederrum habe noch nicht mit LXC gearbeitet. Der Container müsste eine Java Runtime beinhalten. SSH-Zugriff und die Möglichkeit auf´s Dateisystem zuzugreifen sind ja gegeben…
Dies nur als Gedanke - wie gesagt: noch keine Erfahrungen mit LXC und ich möchte nichts Falsches sagen.
Versuche mal als Laie Proxmox mit VM u. LXC kurz zu erklären.
Proxmox ist eine Software mit welcher man auf einer Hardware (z. B. INTELNUC läuft bei mir auf Linux), viele virtuelle Maschinen laufen lassen kann.
Der Unterschied von VM u. LXC ist folgender:
Ein LXC-Linux-Container hat laut meiner Info weniger Overhead und soll von den Ressourcen sparsamer sein.
iobroker läuft auf einer VM=Virtuell Maschine.
Influxdb u. Grafana auf einem LXC.
D. h. ich würde dann mal versuchen einen LXC-Container anzulegen, dauert ca. 2 Min. um anschließend deine Checkliste abzuarbeiten.
Der Vorteil von Proxmox ist hier, wenn der LXC nicht passt, wird er einfach wieder gelöscht und dies wars.
Der Container müsste eine Java Runtime beinhalten. SSH-Zugriff und die Möglichkeit auf´s Dateisystem zuzugreifen sind ja gegeben…
SSH-Zugriff ist auf jeden Fall gegeben, damit müsste, wie du anmerkst der Zugriff auf das Dateisystem geben sein.
Wie man Java-Runtime auf den LXC bekommt, weiß ich nicht, müsste aber auch möglich sein.
Meine Frage wäre jetzt noch, wie groß muss den die Diskgröße und der Arbeitsspeicher sein ?
Disk: 4 GB, Speicher: 1 GB ?
Ich habe keine Ahnung was dies für Ressourcen benötigt ?
Bei mir läuft es auf einem Raspi 3. Auf der grafischen Oberfläche zur Darstellung ein Chromium-Browser. Dieser benötigt aktuell die meisten Ressourcen…
Das System nutzt ca. 8GB auf der Speicherkarte. Ich habe aber ein “volles” grafisches System aufgesetzt. Das geht natürlich auch deutlich schlanker. 1 GB RAM reicht, Disk müsste auch passen.
Es laufen Edge und UI.
Ich hab das jetzt auf meinem Raspi 4 so wie in obigem PDF installiert und auch keine Fehlermeldungen erhalten.
Wenn ich allerdings versuche auf die Seite zuzugreifen, dann bleibt er bei mir im Browser mit der Meldung “Verbindung wird aufgebaut” hängen.
Vermutlich stimmen die Ports von UI und Edge nicht überein. Kannst Du in der Felix Oberfläche konfigurieren. Dies ist im Getting Started Guide beschrieben → Port für Websocket.
Ein Blick in die Entwickler-Tools des Firfox (Debugger) kann hier helfen.
Ja und den nginx habe ich so wie in den Tutorials zum Deployment auf Port 8085. wenn ich aber in Visual Studio das Edge UI erzeuge und auf den Raspi spiele, dann will sich das auf Port 8075 verbinden. So langsam verliere ich den Überblick bei den ganzen unterschiedlichen Anleitungen, die hier im Forum rumgeistern. kann sich da nicht mal jemand, der Ahnung hat erbarmen und da mal Nägel mit Köpfen machen und eine gescheite Doku erstellen?
Ich kann Deinen Frust gut verstehen. Mein Einstieg war ebenfalls holprig. Aus diesem Grund habe ich den “groben Leitfaden” auch geschrieben. Dem Dokument fehlt komplett der fachliche Hintergrund bzgl. des EMS. Ich kann Dir nur zustimmen und hoffe ebenfalls, dass es mal eine komplette Anleitung geben wird. Nur sind die Grenzen zwischen “muss programmiert werden” und “kann konfiguriert werden” fließend. Ohne in die Programmierung einzusteigen und Module anzupassen hätte ich viele Aufgaben nicht lösen können. Die Lernkurve ist leider sehr steil.
Aber zur Sache: Entweder änderst Du den Port in nginx oder im UI: src/themes\openems/environments und dann entweder edge-dev.ts oder edge-prod.ts. Je nachdem welche Umgebung Du nutzen willst.
Viel Erfolg & bleib dran - es lohnt sich
Nachtrag: Im fhem-Forum gab es auch mal einen Post: “kann das vielleicht mal jemand im Wiki dokumentieren?!”, Antwort: “Klar, Du”.
Manche Projekte leben nur wenn jeder mit anpackt. Vom Profi bis zum Anfänger (wie ich einer bin). Für das bisschen Leitfaden gab es viel positives Feedback
So, ich hab es hinbekommen. Es lag doch nicht an den Ports. Auf dem Raspberry lief schlicht und ergreifend der Controller API Websocket nicht.
Ja, vielleicht bin ich bei der ganzen Sache doch etwas zu ungeduldig. Die Installation ist aber in der Tat derart kompliziert, dass man da nicht wirklich sofort durchsteigt. Sowas ist wirklich frustrierend, wenn man sich dann mehrere Tage herum schlägt, ohne zu einem Ergebnis zu kommen.
Ich glaube ich brauch eine Auszeit von OpenEMS ode rich gebe es ganz auf. Nachdem mein Modbus zum Smartmeter aus openEMS nie so richtig funktioniert hat, ich zwar Daten in die InfluxDB schreiben, aber keine Daten aus der InfluxDB lesen konnte und das System immer instabiler wurde, habe ich den Raspi nochmal komplett neu aufgesetzt. Das Ergebnis mit der 2.7.0 war, dass jetzt gar nichts mehr geht! Alle Scripte sind fehlerfei gelaufen nginx läuft. Irgendwas von OpenEMS läuft auch, aber ich weiß nicht was, jedenfalls zeigt er mit im Apache nur sehr wenig an.
Da, wie ich merken musste auch keine Deye Hybridwechselrichter vorhanden sind werde ich wohl auf SolarAssistant wechseln. Das gibt es wenigstens als fetiges Image ohne, dass man da umständlich selbst etliche Entwicklungstools herunter laden und Quellen compilieren muss. Vielleicht schaue ich nächstes Jahr mal wieder hier vorbei in der Hoffnung, dass openEMS einen benutzerfreundlichen Entwicklungsstand erreicht hat.
