osEMS - open source Energy Managment System

  • Hallo in die Runde,
    ich hoffe, dass ich an diesem Platz hier nicht ganz daneben liege. Wie o.g. Name schon vermuten lässt, möchte ich hier kurz meine Vorstellung eines zukunftsfähigen EMS aufzeigen und Interessierte zur Planungsunterstützung und Realisierung anregen.


    Ursächlich für den Threadstart sind die noch immer fehlenden bzw. inkompatiblen Standards, der unterschiedlichen Erzeuger (PV, Wind...), der Speicher und Verbraucher. Hier pusht jeder Hersteller sein System und der interessierte Endkunde zahlt hierfür meistens viel Geld bis hin zum "Lehrgeld" (System ggf. gar nicht kompatibel).
    Ich habe bereits viel recherchiert und sehe z.B. bei OpenHab oder OGEMA Anzeichen, wie zumindest die Software (SW) funktionieren könnte.


    Ich möchte hier ausdrücklich elektronisch und programmiertechnisch versierte user ansprechen, die bereits Erfahrungen mit openhab, arduino, bascom, C und natürlich Hardwareentwicklung haben. Ich selbst bin mehr auf der letztgenannten Schiene unterwegs (ca. 20 Jahre Elektronikentwicklung - allerdings non profit als Hobby).


    zum Projekt osEMS:
    1. Die Hauptidee besteht darin, die verschiedensten Einheiten (Erzeuger, Speicher, Verbraucher) so zu koppeln, dass die Anbindung über eine normale LAN-Schnittstelle oder (notfalls) per WLAN erfolgen kann. Dies soll über die s.g. "osEMS-controli_x"-Module erfolgen, die als Bindeglied zu den Einheiten dienen. Die "osEMS-controli_x" sollen mit µC's aufgebaut, fast immer identische HW und dann mit gerätespezifischer SW ausgestattet werden (=> kein Betriebssystem, sehr stabil, stromsparend, Bascom oder Arduino o.ä.).


    2. Das eigentliche osEMS-Gehirn soll nur Software sein, welche auf einem Server läuft, der vorzugsweise ein embedded Linuxsystem im 24/7-Betrieb darstellt. Da ich mich bei SW nicht so gut auskenne, wären hier Vorschläge willkommen, wie man das mit bereits vorhandener SW auf open source-basis bewerkstelligen kann (openHab - mit bindings? o.ä.)


    zu 1. Durch die modulare Entkopplung der Einheiten/Geräte können verschiedene Personen gerätespezifisch entwickeln. Meist sind simple 0-5V (0-10V) an den Geräten Schnittstellen vorhanden, manchmal aber auch digitale RS485-Connections.
    Die Hardware könnte also wegen geringer Varianz in Massen gefertigt werden - die Anpass. erfolgt in SW.
    Bsp.: Wir bauen einen starken LiFeYPo4-Lader, der jeweils per 0-5V-Signal in der Ladeschlussspannung als auch im Stromfluss (Leistung) geregelt werden kann. 2 Schnittstellen mit je 0-5V (0-10V jumperbar) sind mit einem AVR oder Arduino und einer LAN-Anbindung auf einer Standardplatine verfügbar. Sie müssen nun noch eigensicher programmiert werden (shutdown bei Strom oder LAN-Ausfall usw.) und das Protokoll des osEMS-Servers per LAN/WLAN sprechen.


    Das in Kürze. Der Rest erschliesst sich hoffentlich aus meiner CAD-Skizze.


    VG iot

  • Hi iot.


    Das klingt nach einem interessanten Projekt, was mich ebenfalls sehr interessiert. Lieder kann ich dir nicht viel dazu beitragen, was aber zum größten Teil an der verfügbaren Zeit liegen wird. Trotzdem wünsche ich dir viel Erfolg und ich werde eifrig in dem Thread mitlesen.


    Gruß
    Tobl

  • Danke für den Link Steffi.
    Das muss ich mir noch komplett durchlesen. Teile der benötigten SW für osEMS stecken in den Thread drin. Das habe ich beim Überfliegen schon gesehen.
    Ist das SEMP-Protokoll offen? Falls ja, wäre es in der Tat sinnvoll, so etwas weiterzunutzen.


    Der Unterschied beim osEMS dürfte sein, dass bei der Hardwareschnittstelle LAN <-> "osEMS-controli_x"-Modul <-> Gerät mit dem "controli" ein Quasistandard bei de HW geschaffen würde, weil es er fast immer gleich aussieht. Bei der SMA-Lösung wird das dort als "Gateway" bezeichnete Modul vom Gerätehersteller geliefert, was sicher immer anders geartet ausfällt und vermutlich auch nicht gerade günstig sein wird. Sobald Ethernet oder LAN auf dem Label steht, ist es teure "Raketentechnik" (leider).
    Ich vergleiche das gern mit meiner Gastherme, die mit einem herstellerspezifischen Simple-0...10V-Leistungssteuerungsschnittstelle ausgestattet ist (und die war schon teuer :-(). Diese ist völlig ausreichend, um die Therme in allen Regelungsschemata zu nutzen. Das "Herunterbrechen" auf solche Schnittstellen hilft unheimlich, wenn mal SW-bugs o.ä. aufzuspüren sind.
    Die ganze manuelle Programmierorgie an einem Thermendisplay mit Knöpfechen tue ich mir seit 2006 schon nicht mehr an :D .


    Bis dato sehe ich beim osEMS die 0-5V bzw. 0-10V sowie die RS485 (Modbus)-Kommunikation, die aktuelle Geräte so implementiert haben, dass sie von einem gescheiten EMS ferngesteuert werden können. Gibt es dazu weitere Vorschläge?


    Der SHM hat sicher Potential. So richtig sehe ich aber keinen Vorteil, eine spezielle HW dafür zu verwenden, wenn man weitgehend auf eine TCP/IP-Infrastruktur setzt. Dort ist doch der entscheidende Vorteil, dass die controli/gateway und der Server (eigentlich nur die SW) völlig getrennt stehen können.
    Braucht man WLAN/BT-Funkdosenansteuerung, macht das eben ein controli/gateway, der statt RS485/0-5V eben die Funkmodule drauf hat. Die "echten" Geräte (PV-WR, Akku-WR, WP usw.) sollten aber besser über die o.g. drahtgebundenen SSt. angebunden werden - getreu dem Motto: Wer Funk kennt, nimmt Kabel :-).


    VG iot

  • Hallo swiss,
    Raspis sind für die "osEMS-controli_x" oversized. Gerade diese kleinen Module müssen ohne ein Betriebssystem auskommen (im Gegensatz zum Server), weil ein OS eben gepflegt werden muss. Deshalb hast Du auch ein EMDO entworfen :-).


    Mir schwebt eher eine Miniplatine mit den genannten SSt. + LAN-Modul vor, auf welche ein etwas potenterer AVR (1284-er oder 256-er) gesteckt wird. Letzteren am besten gesockelt, um auch mal den IC solo versenden zu können. Nicht jeder möchte sich einen Programmer zulegen und das Teil flashen.
    Freilich ist der AVR nicht so potent, aber das brauchen wir als simplen SSt.-Konverter + Realisierung Eigensicherheit auch nicht. Hier brauchen wir den "Range Rover", der langzeitstabil läuft und bei einem Reset innerhalb kürzester Zeit wieder online ist. Der darf auch in Basic geproggt werden.


    Für das LAN-Modul gibt es etwas mit integriertem Webserver (UART to LAN), was äußerst kompakt mit auf die Platine gelötet werden kann:
    http://www.usriot.com/Product/129.html
    Die chain wäre dann: LAN <-> Superport USR-K3 <-> UART <- >AVR
    Vom AVR wären über seine Ports die diversen Geräteansteuerungen realisierbar. AVR -> 2..3x 0-5V (0-10V) -> Device
    und AVR <-> 2x RS485 <-> Device
    Die Firmware könnte bei RS485 dann auf ggf. vorh. Unterschiede der diversen Geräte angepasst werden. Bei 0-5/0-10V ist es immer dasselbe.


    Ach ja - durch die AVR-Zwischenschaltung müssten auch 2x RS485-connections möglich sein, was die hier diskutierte Problematik etwas entschäften würde:
    http://www.photovoltaikforum.c…hiedene-wr-h-t101702.html
    RS485 von Hersteller A ist eben nicht dasselbe wie von Hersteller B, C....und meist nicht kombinierbar.


    VG iot

  • Hallo iot,


    Ich verstehe nicht welches Problem Du eigentlich lösen möchtest. Die Tatsache dass Hersteller proprietäre Schnittstellen einsetzen? Das wird sich durch einen "offenen" Standard ohne Marktmacht nicht ändern.


    Warum ist es so wichtig standardisierte Geräteadapter zu verwenden? Spielt es nicht letztlich gar keine Rolle mit welchem Typ von Adapter gearbeitet wird solange er an eine zentrale Steuerungskomponente angebunden werden kann? Volkszaehler ist ein Projektbeispiel für diese Philosopie.


    Also was ist der Kern Deiner Lösung bzw. warum kann sie proprietäre Lösung oder bestehende Open Source Steuerungen (fhem etc) ersetzen?


    Viele Grüße, Andreas

  • Sorry habe die Logik nicht verstanden. Wenn Du nach dem Schema eh ein Rasp nimmst, dann kannst ja alle so machen. Wenn Du Dir die Mühe machst ein Linux zu patchen, dann kannst ja auch gleich alle so patchen.
    Das mit der Eigensicherung ist Augenwischerei. Ein Linux mit MMU und ein AVR ohne MMU würde ich beides nicht für kritische Applikationen nehmen. Da würde ich was mit Analogelektronik bauen, oder noch besser zukaufen.

  • Ich springe hier auch mal auf den Thread auf, nachdem ich mit iot einige PM getauscht habe.


    Zitat von andig2


    Ich verstehe nicht welches Problem Du eigentlich lösen möchtest.


    Ich muss gestehen, dass ich das bisher auch noch nicht verstanden habe (was auch an mir liegen kann). Angenommen HW und SW dieses osEMS wären fertig und Interessenten könnten dieses beziehen. Wie soll es dazu kommen, wenn Sie nur mit vielen technischen Begriffen konfrontiert werden, aber sie gar nicht erkennen können, was eigentlich das Ziel sein soll.


    Für mich scheint osEMS eine ähnliche Zielgruppe ansprechen zu wollen, wie OpenHab etc.. Als ich mit "Smart Appliance Enabler (SAE)" begonnen habe, habe ich mir auch OpenHab angesehen, nachdem im SEMP-Thread nach einer Integration von SHM und OpenHab gefragt worden war. Der SHM ist bereits ein Energy Management System, warum sollte man da noch zweites dranflanschen wollen? Der SAE hat (aus meiner Sicht) einen klaren Fokus: Für den SHM nicht-smarte Geräte smart machen, indem der Stromverbrauch gemessen wird und die Geräte für den SHM schaltbar gemacht werden.


    Zitat von andig2


    Warum ist es so wichtig standardisierte Geräteadapter zu verwenden? Spielt es nicht letztlich gar keine Rolle mit welchem Typ von Adapter gearbeitet wird solange er an eine zentrale Steuerungskomponente angebunden werden kann?


    Ich kann auch nicht erkennen, warum Geräteadapter notwendig sind. Bei der zentralen Steuerkomponente stellt sich allerdings die Frage nach der Eignung für das zu steuernde Aggregat. Der SHM ist wohl eher nicht geeignet, die Steuerung meiner Wärmepumpe zu ersetzen, indem er alle Ventile etc. selbst steuern. Aber Software für universelle Heizungssteuerungen gibt es ja auch schon (ist mir aber zu riskant).


    Zitat von andig2


    Volkszaehler ist ein Projektbeispiel für diese Philosopie.


    Auf Volkszaehler-Homepage sieht man sofort, wofür das Projekt steht: Messen, (Übertragen), Speichern, Auswerten.
    Wenn man jetzt überlegt, ob sich das in den SHM sinnvoll integrieren läßt: Speichern und Auswerten mach der SHM, bleibt also nur Messen übrig. Dafür fehlt "Schalten". Eine Integration der Beiden macht aus meiner Sicht also wenig Sinn.


    Zitat von iot


    Vielleicht probieren wir es mit RPi2 + UniPi.


    Das für Volkszaehler Geschriebene gilt analog für UniPi, zumindest wenn man das im Kontext des SHM sieht. Nur wenn man noch nichts dergleichen hat, könnte man UniPi in Erwägung ziehen.


    Axel

  • Hallo und erstmal ALLES GUTE für dieses Jahr!

    Zitat von andig2


    Ich verstehe nicht welches Problem Du eigentlich lösen möchtest. Die Tatsache dass Hersteller proprietäre Schnittstellen einsetzen? Das wird sich durch einen "offenen" Standard ohne Marktmacht nicht ändern.


    Nein - ich möchte die offenen Schnittstellen (SSt.), falls vorhanden, nutzen. Dazu zählen die simplen Spannung-/Strom-SSt. 0-5/0-10V/4-20mA sowie RS485 Modbus-SSt. mit offenem Protokoll - weiters remote controlled (RC) Schalter.


    Zitat von andig2


    Warum ist es so wichtig standardisierte Geräteadapter zu verwenden? Spielt es nicht letztlich gar keine Rolle mit welchem Typ von Adapter gearbeitet wird solange er an eine zentrale Steuerungskomponente angebunden werden kann? Volkszaehler ist ein Projektbeispiel für diese Philosopie.
    Also was ist der Kern Deiner Lösung bzw. warum kann sie proprietäre Lösung oder bestehende Open Source Steuerungen (fhem etc) ersetzen?
    Viele Grüße, Andreas


    Standards sind schon eine tolle Sache, wenn Sie von den Herstellern 1:1 und kompatibel umgesetzt werden. Im heutigen Markt ist das aber eher Wunschdenken.
    Den VZ nutze ich selbst und es ist ein tolles Projekt, was ich selbst im Wiki schon unterstützt habe (VIR - variable Impulsrate am S0-Zähler). Was fehlt ist ein komplettes open source Enegie Managment System (osEMS) oder habe ich etwas bei meiner Recherche übersehen? Der VZ ist nur ein wichtiger Teil davon.
    OpenHab ist mein persönlicher Favorit für das osEMS, da es im Gegensatz zu FHEM eventbasiert funktioniert. Ein EMS muss so ziemlich alle Energieflüsse (ich rede jetzt erstmal nur von Strom) händeln können. Die Config sollte für den Enduser webbased (mit Parametereinstellungen der einzelenen Geräte) erfolgen können.
    Da ich ein freies EMS nicht gefunden habe, kam die Info bezüglich des SHM und SEMP-Protokoll. Das wäre ggf. ein Zwischenschritt.


    Da ich mich mehr auf HW konzentriere, bin ich auf ein möglichst umfängliches Shield aus, was die o.g. SSt. hw-seitig abdeckt. Dabei soll natürlich ein Massencontroller zum Einsatz kommen, der dort nur eingesteckt wird.
    Für den RPi (den ich (noch) als oversized ansehe) gibt es da schon käufliche Einheiten wie diese beiden.
    http://unipi.technology/shop/
    https://www.cube-controls.com/pi-cubes/
    Diese sind zwar a) recht teuer und b) recht groß in den Abmess. (zumindest das UniPi), aber dort müsste zumindest von der HW kein neues Rad erfunden werden.


    Bei der AVR-Var. gibt's das noch nicht. Deshalb die Idee des Shields mit LAN, 2x Spann., 2x RS485 und GPIO => Summe = controli
    Dieses Ding dann möglichst günstig und das geht nur, wenn es wenig HW-Varianten davon gibt. Alternativ könnte man auch die Platine für Vollbelegung auslegen und nur das nötige bestücken.


    *****************************************************************************************
    Um die Sache mal übersichtlicher zu mache ein Bsp.:
    1 Erzeuger: PV-Anlage mit WR, der RS485-Modbus (offenes) Protokoll hat
    1 LiPoFeY4-Akku (Stomspeicher)
    1 Ladegerät mit 0-5V Input zur Leistungsregelung (Strom_in f. LiPo)
    1 Batterie-WR mit 0-5V Input zur Leistungsregelung (Strom_out f. LiPo)
    1 Wärmepumpe (WP) mit 0-5V Input zur Leistungsregelung (steht 20m vom Keller weg
    1 Smartmeter (SM) mit LAN-SSt. (SDM630, EM300 oder recht neu UEM80)


    Jetzt wäre es perfekt, wenn ein osEMS auf dem ggf. schon vorh. Server liefe und lanbasiert die controlis (gateways) mit Infos versorgt, so dass am SM kein Bezug/Einspeis. vorliegt.
    Ein controli kann dann z.B. das Ladegerät und den Batterie-WR bedienen, ein anderes die PV und das 3. die WP. Also je räumlich getrennter Einheit ein controli.


    Das in Kürze
    VG iot