Balkonkraftwerk Teil 9: MQTT und REST-API

Balkonkraftwerk

Wieder geht es um das Thema Monitoring eines Balkonkraftwerks, zu dem ich bereits zwei Artikel verfasst hatte. Hier sprechen wir aber nicht über Geräte, die das Monitoring eines BKWs ermöglichen, sondern über die Monitoringdaten selbst, also vor allem Leistung und Energie. Und wie wir diese Daten von DTUs (Data Transfer Units) und Shellies in andere Systeme hinein bekommen. MQTT (Message Queuing Telemetry Transport) ist dabei das Mittel der Wahl, wenn Monitoringgeräte von sich aus Daten exportieren sollen. Und per REST-API (Representational State Transfer) können wir in umgekehrter Richtung Daten von einem Monitoring Device abfragen. Beide Protokolle MQTT und REST-API kann man als Bestandteile der Internets der Dinge (IoT) betrachten und für ein Balkonkraftwerk bilden sie die Brücke zur Hausautomation.

MQTT- Message Queuing Telemetry Transport

Was ist MQTT?

MQTT ist ein Client-Server-Protokoll aus dem Bereich der Maschine-zu-Maschine-Kommunikation oder Internet der Dinge. Clients sind dabei im BKW-Umfeld die Monitoring Geräte, wie etwa Shelly-Devises oder DTUs. Sie sprechen mit einem so genannten MQTT-Broker (Server). Die Kommunikation beruht dabei auf einem Publish und Subscribe von Topics. Diese Begriffe muss ich aber erst einmal erklären:

Ein Topic ist eine Art Titel, Ordnungsbegriff oder Namen und hierarchisch aufgebaut, zum Beispiel:

shellies/shellyplug-s/relay/0/power

Das wäre die Leistung eines Shelly Plug S, die dieses Gerät periodisch oder bei Änderungen per Publish an den MQTT-Broker sendet. Der Broker braucht dafür nicht extra konfiguriert werden, wenn er die erste Nachricht dieser Art bekommt, legt er den Topic automatisch an und aktualisiert mit jeder neuen Meldung den Dateninhalt, also hier den Leistungswert.

Ein anderer Client kann nun einen Topic (oder mehrere) abonnieren (Subscribe). Damit sagt er dem MQTT-Broker, dass er an diesen Daten interessiert ist und künftig Updates dafür erhalten möchte. Der MQTT-Broker versorgt dann alle Subscriber mir den abonnierten Topics.

Der MQTT-Broker ist also eine Art Datenverteiler, der den gesamten Datenwust, denn ein Publisher wie der Shelly Plug S anliefert, zwischenspeichert und einzelne Topics dann an interessierte Subscriber ausliefert. Der Shelly Plug S muss sich nicht darum kümmern, wer alles seine Daten und welche davon bekommen möchte und einem Abonnenten kann es egal sein, woher die Daten ursprünglich stammen. Diese Vereinfachung und Abstraktion der Datenentstehung und ihrer Verwendung ermöglicht der MQTT Broker. Aber Obacht, der MQTT-Broker speichert keine historischen Daten sondern nur immer den letzten Momentanwert zu jedem Topic, er ist also keine Datenbank, aus der man schöne Grafiken generieren könnte.

Mehr müssen wir über MQTT erst mal gar nicht wissen. Sehen wir uns als nächstes an, wie man einen Client für MQTT konfiguriert.

MQTT Client Konfiguration

MQTT Client bei OpenDTU
OpenDTU MQTT Daten

Nehmen wir als Beispiel im Bild oben OpenDTU und konfigurieren dort unter Einstellungen – MQTT-Einstellungen einen MQTT-Broker samt Topic. Das ist denkbar einfach, es muss nur die URL oder IP-Adresse des MQTT-Servers eingegeben werden und der Basis Topic (hier: dtu/open/). Die Möglichkeit einer Anmeldung mit Benutzername und Passwort ist optional. Der Standard-Netzwerk-Port für MQTT ist 1883.

Sobald die Einstellung gespeichert ist, wird OpenDTU versuchen, Daten an den MQTT-Broker zu liefern und zwar alle 5 Sekunden. Wie das aussieht und was alles an Daten ankommt zeigt das Bild rechts. dtu/open/ war der konfigurierte Basis Topic, die gesamte Datenstruktur darunter stammt von OpenDTU und sie wird ständig aktualisiert.

Der interessierte Subscriber kann sich nun aussuchen, welche einzelnen Sub-Topics er für seine Zwecke abonnieren möchte, ohne sich mit dem ganzen Rest zu belasten. Ein Subscribe auf die DC-Leistung des ersten Solarmoduls (hier 30,40W) würde also hier im Beispiel auf den Topic dtu/open/11218/1/power gehen. (Die Seriennummer des Wechselrichters, IP und Hostname habe ich hier aus Datenschutzgründen gekürzt oder gelöscht.)

Weiter erkennt man, dass es unter dtu noch einen Topic ahoy gibt mit zusätzlichen 32 Unter-Topics. Es lässt sich also mit den Topics eine schön geordnete Datenstruktur aufbauen.

Beispiele

Ich hatte es in meinem Artikel über Ahoy und OpenDTU erwähnt, dass diesen DTUs im Gegensatz zum Original der Zugang zur Hoymiles Cloud fehlt und damit auch eine grafische Darstellung des Leistungsverlaufs zum Beispiel. Wie wäre es nun, wenn wir mit Hilfe von MQTT und einigen anderen Tools eine eigene Lösung für die grafische Darstellung der Balkonkraftwerksdaten erstellen?

Grafana Server für das Balkonkraftwerk

Der Grafana Desktop ist eine mächtige Plattform zur Visualisierung von allen möglichen Daten aus dem Bereich des Internet-of-Things, warum also nicht auch für ein Balkonkraftwerk. Hier ein Bild, wie das aussehen könnte.

Was braucht man dazu?

Neben einer Datenquelle (einer DTU oder einem Shelly) ist vor allem ein Server erforderlich. Das kann beispielsweise ein Raspberry Pi sein, oder auch eine virtuelle Linux-Maschine auf einem PC. Weiter werden folgende Softwareprodukte benötigt (alle kostenlos unter Linux im Internet herunterladbar und als Docker-Images installierbar):

  • Mosquitto als MQTT-Broker,
  • Node Red als grafische Programmierumgebung,
  • InfluxDB als Zeitreihen-Datenbank und
  • Grafana für die Grafik.
  • Zusätzlich als Empfehlung den MQTT Explorer um einen Einblick in die MQTT-Strukturen zu erhalten
Installation

Eine Installationsanleitung für die fünf eben genannten Softwareprodukte würde den Umfang dieses Artikels bei weitem sprengen, deshalb verweise ich zu diesem Zweck auf ein sehr gutes Youtube-Video von Dennis Schröder bei „Raspberry Pi Cloud“:

TUTORIAL: Shelly und Tasmota mit MQTT, Node-Red, InfluxDB ins Grafana Dashboard – Balkonkraftwerk

Zu diesem Video muss ich allerdings ergänzen, dass in der aktuellen Version von Mosquitto (im März 2023) anonyme MQTT-Clients (also ohne Usernamen und Passwort) nur zulässig sind, wenn dies in der Mosquitto Konfiguration explizit erlaubt wurde. Und das machen wir durch Editieren der mosquitto.conf Datei wie folgt:

sudo nano /var/lib/docker/volumes/mosquitto_conf/_data/mosquitto.conf

In der Datei folgende Zeilen suchen und das voranstehende # Zeichen entfernen, so dass die Statements wirksam werden:

  • listener 1883
  • allow_anonymous true

Strg-x zum Beenden, j zum Speichern und Enter zum bestätigen des Dateinamens. Alles Weitere wird im Video wunderbar erklärt.

Iobroker als Einstieg in die Hausautomation

Ein weiteres Beispiel, wie sich MQTT-Daten aus DTUs, Shellies und anderen Geräten weiterverarbeiten lassen, ist iobroker. Iobroker ist eine Plattform für die Hausautomation, in die sich über viele verschiedene Adapter unterschiedliche Geräte, Systeme und auch Visualisierungen einbinden lassen. Auch Automatisierungen sind mit iobroker sehr einfach möglich, wie wir noch sehen werden.

Jarvis Visualisierung in iobroker
Was braucht man dafür

Auch für iobroker ist ein eigener Server in Form eines Raspberry Pi oder einer virtuellen Maschine erforderlich. Dazu folgende Softwareprodukte, wobei einige nur Beispiele sind und es dazu auch Alternativen gibt:

  • iobroker selbst
  • in iobroker der Adapter Javascript, mit dem auch visuell über Blockly programmiert werden kann
  • in iobroker der Adapter MQTT als MQTT Broker
  • in iobroker der Adapter für Influxdb
  • in iobroker der Adapter Jarvis als Visualisierung (alternativ auch Vis)
  • Influxdb als Datenbank
Zentrale Objektdatenbank, Programmierung und Visualisierung in iobroker

Für die Installation von iobroker und den benötigten Adaptern gibt es zahlreiche Videos im Internet. Der Vorteil von iobroker im Vergleich zur oben dargestellten Lösung mit Mosquitto ist, dass mit iobroker der MQTT-Broker, die Programmierung, die Datenspeicherung und die Visualisierung an einer Stelle zusammengeführt werden. Alle Daten liegen zentral und gemeinsam in einer Objektstruktur, egal ob sie von MQTT stammen, aus anderen Datenquellen oder ob sie von Hand erstellt wurden. Wir haben immer eine gemeinsame Hierarchie aller Objekte und können direkt dort mit einem Klick für jedes Objekt entscheiden, ob eine Langzeitdatenhaltung in Influxdb erfolgen soll. Bei Mosquitto mussten wir bereits dafür in Node Red programmieren.

Oben sieht man das Beispiel einer Visualisierung mit Jarvis. Dort fließen die Daten aus OpenDTU und eines Shelly Plus 1PM ein. Jarvis ist ein Visualisierungs-Adapter in iobroker, er ist relativ einfach gehalten und durch sein reponsible design automatisch auch fürs Smartphone geeignet. Standardmäßig wird in iobroker der Adapter Vis zur Visualisierung verwendet. Mit dem ist wirklich alles möglich inclusive der Einbindung eigener Grafiken und freier Positionierung aller Elemente. Vis ist allerdings auch sehr komplex. Beiden ist gemeinsam, dass (im Unterschied zu Grafana) auch Steuerelemente möglich sind, die Lampen oder Shellies aus der Visualisierung heraus steuern lassen.

Blocly Programmierung

Rechts ist ein Beispiel einer Blockly-Programmierung innerhalb von iobroker dargestellt. Hier habe ich die Waschmaschinen-Steuerung aus Teil 7 dieser Artikelreihe mit Blockly umgesetzt anstelle von Shelly Szenen. Blockly ist quasi eine grafische Oberfläche zu Javascript. Die einzelnen Programmelemente können aus einem Vorrat ausgewählt und dann nach Wunsch in einander verschachtelt werden. Blocky generiert daraus dann Javascript Code, der sofort und ständig in iobroker ausgeführt werden kann.

MQTT versus proprietärer Benutzeroberflächen

Shellies und DTU bringen alle ihre eigenen Bedien- und Visualisierungsoberflächen mit, die keinesfalls schlecht sind. Warum sollte man also die Daten der Geräte per MQTT verschicken, um sie dann woanders anzuzeigen? Hier einige gute Gründe für MQTT:

  • Der MQTT Broker kann Daten von ganz unterschiedlichen Systemen zusammenführen.
  • Auf einen MQTT Broker können unterschiedliche Systeme zur Speicherung, Verarbeitung oder zur Visualisierung der Daten zugreifen.
  • Ein eigener MQTT Broker hält die Daten im eigenen Netzwerk, es gehen keine Informationen in fremde Clouds (Stichwort Datenschutz).
  • Sensoren ohne eigene Datenhaltung (das sind Ahoy und OpenDTU und die meisten Shellies, wenn man die Shelly Cloud nicht betrachtet) können durch MQTT und eine dahinter liegende Datenbank eine History für ihre Daten bekommen.

REST-API – Representational State Transfer Application Programming Interface

Was ist die REST-API

Representational State Transfer (REST) ist eine Möglichkeit der Maschine-zu-Maschine-Kommunikation. Dabei setzt REST auf das HTTP-Protokoll, also das selbe Protokoll, das wir im Webbrowser verwenden um einen Web-Server abzufragen. Das ist wohl auch ein Grund, warum OpenDTU diese Schnittstelle Web API nennt und nicht REST-API. Betrachten wir hier Web API einfach als Subset einer vollständigen REST-Implementierung – gemeint ist im Balkonkraftwerk-Umfeld immer das selbe, die Abfrage eines Geräts über das HTTP Protokoll.

REST API

Das schöne an REST ist, dass wir die Abfragen (zumindest was die GET-Methode angeht) auch im Browser machen können. Dazu gleich ein Test mit folgender Eingabe in der URL-Zeile im Browser:

http://192.168.0.33/api/livedata/status

Wobei 192.168.0.33 die IP-Adresse einer OpenDTU ist. Das Ergebnis sieht dann aus wie im Bild rechts. Dazu zwei Anmerkungen:

  • Den blau hinterlegten Topic 0 habe ich eingeklappt, dahinter verbirgt sich eine Unmenge an weiteren Informationen, die ich aus Platzgründen hier verborgen habe.
  • Nicht jeder Browser stellt JSON-Daten so schön strukturiert dar, wie Firefox, möglicherweise werden die Daten auch in Rohform angezeigt.

Alle Shelly Geräte, Ahoy- und OpenDTU und viele weitere Geräte bieten eine REST API an, über die sie ausgelesen und auch gesteuert werden können. Die Befehls- ebenso wie die Datenstruktur unterscheiden sich allerdings von Gerät zu Gerät.

REST (Web) API Befehlsumfang

Hier eine kurze Linksammlung zu den entsprechenden Dokumentationen:

  • Shelly API Doku, unterschieden nach Shelly Geräten der ersten und der zweiten Generation
  • Doku der Web API von OpenDTU
  • Bei AhoyDTU findet man die REST API Aufrufe im Ahoy-Menü unter REST API

Was unterscheidet REST von MQTT?

Beides sind Kommunikationsprotokolle mit denen wir an die Daten von Shellies und DTUs kommen können und über die diese Geräte auch gesteuert werden können. Dabei werden allerdings unterschiedliche Wege gegangen. Bei MQTT gibt es einen zentralen Server, den MQTT Broker, an den die Daten geschickt werden und von dem sie dann bezogen werden können. Bei REST gibt es keine zentrale Instanz, hier wird immer direkt mit dem entsprechenden Gerät kommuniziert. Das ist unkompliziert und schnell, der Client muss aber die Adressen der Geräte kennen, die er ansprechen will, er kann sich nicht einfach aus dem Datenreservoir eines Brokers bedienen. Und der Client muss das Gerät aktiv pollen, also von sich aus immer wieder ansprechen, wenn er aktualisierte Daten möchte.

Ein Praxisbeispiel

Das folgende Python-Script ist wieder die Waschmaschinenautomatisierung, die ich oben bereits in iobroker-Blockly realisiert hatte. Diesmal erfolgt die Abfrage der Solarleistung allerdings nicht von einem Shelly Plus 1PM sondern von einer AhoyDTU.

import time
import requests
EINSCHALTSCHWELLE = 100

while True:
 try:
  dtu = requests.get("http://192.168.0.36/api/live")
  shelly = requests.get("http://192.168.0.25/relay/0")
 except:
  print("Kommunikationsfehler bei der Abfrage von DTU oder Shelly")
  continue

 if dtu.json() is None: continue
 if shelly.json() is None: continue
 leistung = dtu.json()["inverter"][0]["ch"][0][2]
 schalter = shelly.json()["ison"]
 print(f"Solarleistung: {leistung:5.1f} W, Schalterstatus: {schalter}")

 if not schalter and leistung > EINSCHALTSCHWELLE:
  try:
   requests.get("http://192.168.0.25/relay/0?turn=on")
  except:
   print("Kommunikationsfehler beim Einschalten der Waschmaschine")
   continue
  print("Waschmaschine eingeschaltet")
 time.sleep(0.5)
AhoyDTU

Um HTTP-Abfragen absetzen zu können verwende ich das Modul requests und die EINSCHALTSCHWELLE definiert die Leistung in Watt, bei der die Waschmaschine eingeschaltet werden soll. In einer großen Endlos-While-Schleife habe ich drei Blöcke:

Im ersten Block wird von der AhoyDTU die Live-Datenstruktur abgerufen und gleich danach vom Shelly Plug S der Zustand des Relay 0.

Im zweiten Block werden die abgerufenen Daten geprüft, ob überhaupt Inhalte geliefert wurden und dann werden aus den JSON-Datenstrukturen die Daten extrahiert, die hier von Interesse sind. Das ist bei der DTU die aktuelle Leistung in Watt und beim Shelly der Zustand des Schalters (also des Relais), der ist entweder False oder True. Per print werden diese Daten ausgegeben.

Shelly Plug S

Im dritten Block erfolgt die Ausscheidung, ob der Schalter aus ist und gleichzeitig die aktuelle Leistung den Schwellwert überschreitet. Nur in diesem Fall wird am Shelly das Relais geschlossen und die Waschmaschine läuft an. Andernfalls, also wenn die nötige Leistung nicht erreicht ist, oder wenn die Waschmaschine bereits läuft, passiert nichts. Nach einer halben Sekunde Zeitverzögerung wiederholt sich der ganze Vorgang.

Die try-except Klammerungen dienen nur dazu, dass das Script nicht mit Fehler abbricht, wenn bei der Kommunikation über das Netzwerk etwas schief geht.

Weitere Artikel in dieser Kategorie:

19 Kommentare

  1. Holger

    Also irgendwie klingt das alles EXTREM kompliziert. Gibt es keine einfache Software, die einfach die Tageswerte aufaddiert und ein bißchen visualisiert. Nett wäre natürlich, wenn man einen (legalen) Sensor einschleifen könnte, der den Stromverbrauch erfaßt und so ausgerechnet werden kann, wieviel Strom des „Balkonkraftwerks“ (ich kenne niemanden, der die Panele nicht auf der Garage hat) selbst verbraucht wird.

    Antworten
    1. Helmut (Beitrag Autor)

      Wenn Du es einfach haben willst, dann nimm ein Shelly-Gerät und die Shelly App zeigt Dir nette Grafiken. Wenn Du aber Deinen Stromverbrauch erfassen willst und den Deiner eigenen Erzeugung und Einspeisung ins Netz gegenüberstellen, dann ist das halt naturgemäß etwas komplexer. Iobroker kann dann die Zentrale sein, die alle Daten zusammenführt und auf der Du dann Deine individuelle Visualisierung aufsetzen kannst.

      Antworten
  2. Lasse

    Hallo,

    tausend Dank erstmal für alle 9 Beiträge. Die sind wirklich phantastisch und sehr informativ. Zum Beispiel habe ich über Deinen Blog (Teil 5) zum ersten mal grob kappiert, wie die verschiedenen Datenangebaen von Modul und Wechselrichter zusammenspielen und zusammenpassen müssen.

    Eine Frage zum Monitoring: Welchen Raspberry Pi hast du genommen bzw. würdest du empfehlen? Ich habe etwas Erfahrung mit Arduino, aber noch nie mit Raspberries zu tun gehabt.

    Vielen Dank,
    Lasse

    Antworten
    1. Helmut (Beitrag Autor)

      Hallo Lasse, die Server in diesem Artikel habe ich jeweils auf einem großen Rechner als virtuelle Maschine unter VMware aufgesetzt und nicht mittels Raspberry Pi. Die sind zur Zeit auch nur schwer zu bekommen. Ich hab zum Glück noch ein paar und bin gerade dabei „Home Assistant“ auf einem Raspberry Pi 4 aufzusetzen.
      Viel Erfolg
      Helmut

      Antworten
  3. Tito

    Hallo Helmut,

    ich habe als erstes mal versucht dem von Dir verlinkten Tutorial mit den Docker Containern zu folgen, das wurde leider nix… Ich meine dieses hier:
    https://www.youtube.com/watch?v=D1rHGaviECY

    Das hat leider nicht so geklappt, da hakte es an mehreren Stellen, da mir das Terminal diverse Meldungen gab mit denen ich nicht weiter kam.

    Nun möchte ich es mit iobroker versuchen. Installation iobroker war kein Ding. Die Adapter habe ich auch installiert und influxdb über diese Anleitung installiert:
    https://pimylifeup.com/raspberry-pi-influxdb/

    Magst du vielleicht „kurz“ schildern wie ich jetzt weiter machen muss? Das geht aus deinem Artikel nicht so genau hervor…

    Antworten
    1. Helmut (Beitrag Autor)

      Richtig, im Artikel ist iobroker als Beispiel für einen MQTT-Broker aufgeführt, was natürlich noch keine Installationsanleitung darstellt. Wenn Du Jarvis oder eine andere Visualisierung als iobroker-Adapter installiert hast, dann kannst Du in der Oberfläche des entsprechenden Adapters Deine Visualisierung nach Deinen Wünschen zusammenbauen.

      Antworten
  4. Kurt Pfeifle

    Hallo Helmut, habe vor ein paar Minuten dein Blog entdeckt und bin bereits jetzt begeistert über die Themen die du seit ein paar Jahren da behandelst und über die Sorgfalt und Ausführlichkeit, mit denen du dich ihnen widmest. Vielen Dank — ich selbst werde mich demnächst mit MQTT, Grafana und InfluxDB im Kontext unseres Balkonkraftwerks erstmals näher befassen, und da ist Deine Artikelserie ein willkommener Einstieg. Liebe Grüße, Kurt.

    Antworten
  5. Kurt Pfeifle

    Ich bin dabei, dein Tutorial nachzuvollziehen. Allerdings mit Docker auf Windows 11 (habe gerade keine Linux). Dort schaffe ich es nicht eine mosquitto.conf zu editieren so dass Mosquitto ‚allow_anonymous true‘ tatsächlich honoriert. Im Docker desktop stehen im log file die Zeilen:

    2023-05-19 04:02:21 1684461741: Config loaded from /mosquitto/config/mosquitto.conf.
    2023-05-19 04:02:21 1684461741: Starting in local only mode. Connections will only be possible from clients running on this machine.
    2023-05-19 04:02:21 1684461741: Create a configuration file which defines a listener to allow remote access.

    Den Pfad ‚/mosquitto/config/mosquitto.conf‘ gibt’s weder in Windows noch im WSL2 (Windows Subsystem for Linux). Mir bleibt ein Rätsel, wo Mosquitto das herholt.

    Antworten
    1. Helmut (Beitrag Autor)

      Sorry, zu Windows kann ich nichts sagen, da musst Du mal etwas Recherche betreiben, wo Docker unter Windows solche Konfigurationen ablegt.

      Antworten
  6. CN

    Hi,

    “ Das ist denkbar einfach ……“, dann weiß ich schon, daß nach spätestens zwei weiteren Zeilen das große ääääähhh?? kommt.
    Beispiel: … es muss nur die URL oder IP-Adresse des MQTT-Servers eingegeben werden und der Basis Topic (hier: dtu/open/).
    Wo bekomm ich die IP-Addresse des Servers her? Weder die der openDTU, noch die meines Rechners, noch die IpV4 aus meiner FritzBox funzen. Der MQTT-Explorer bricht jeden Verbindungsversuch ab.
    … aber ist ja alles ganz einfach …. hrrnghh

    Antworten
    1. Helmut (Beitrag Autor)

      Wenn Du einen eigenen MQTT Broker aufgesetzt hast, oder einen iobroker oder Home Assistent, dann hast Du ja einen eigenen Server oder Raspberry Pi dafür verwendet. Und dann weißt Du auch Namen und IP-Adresse. Wenn Du keinen eigenen MQTT Server hast, welchen möchtest Du dann ansprechen?

      Antworten
  7. Jörg Hedtmann

    Nur eine kleine Anmerkung: das „MQ“ hat nichts mit Message Queue zu tun, das ist erst eine spätere Interpretation. Das MQTT-Protokoll wurde ursprünglich für die IBM-Geräteserie MQ-xxx entwickelt, daher der Name.

    Nur falls es jemanden interessiert…

    Beste Grüße, Jörg

    Antworten
  8. Holger Lang

    Ich habe genau die gleichen Fragen gehabt, versch. Wechselrichter, laderegler, Verbraucher, zu überwachen und zu steuern.. beste Lösung ist meiner Meinung hier Home Assistent das ist eine Integrationsplattform läuft auf Linux im Rasberry oder auf Intel nux Server.
    Dort sind bereits viele Hersteller und Geräte integriert. Ich kann sehr viel überwachen Steuern ..regeln, programmieren und das dann auch weltweit überwachen und eingreifen. Kann aber auch alles regeln gibt es ein fertiges Energie Dashboard, auf dem viele Daten kumuliert werden das ist einfach eine bessere Lösung, die sehr viel leichter ist als hier alles von null an aufzubauen.

    Antworten
    1. Helmut (Beitrag Autor)

      Wer sich für Home Assistant interessiert, der findet hier einen eigenen Artikel dazu.

      Antworten
  9. Peter Müller

    Hallo Helmut, ich komme aus der iobroker Welt.
    MQTT ist da ja kein Problem.
    Mich würden mal interessieren welche Datenpunkte es da alle gibt.
    Kann auch die Leistung über MQTT begrenzt werden?

    Antworten
    1. Helmut (Beitrag Autor)

      Hallo Peter,
      das ist das schöne am ioBroker, dass er die Datenstruktur, so wie sie von Ahoy oder OpenDTU geliefert wird, 1:1 unter dem Menüpunkt Objekte wiedergibt. Dort findest Du also alle Datenpunkte. Alternativ kannst Du – bei ioBroker und auch bei anderen MQTT-Brokern – den MQTT-Explorer installieren und damit in die Datenstruktur schauen.
      Leistungsbegrenzung ist jetzt nicht so mein Thema, hab ich also auch nicht probiert, aber das kannst Du ja unter Objekte oder mit dem MQTT-Explorer ebenfalls leicht testen.

      Antworten
  10. Robin Bastian

    Hallo Herr Karger,
    durch Zufall bin ich auf Ihre sehr interessante Website gestoßen. Ich bin Softwareentwickler und möchte mein Balkonkraftwerk zusammen mit einem Batteriespeicher durch eine eigene Software optimieren. Den Stromtarif- und Verbrauch bekomme ich in Echtzeit über eine websocket-Schnittstelle von Tibber (Pulse IR). Was ich noch suche, ist ein Batteriespeicher in der Gewichtsklasse 3-5 kwh, der sich per API ansteuern lässt. Insbesondere die Funktionen „Ladezustand“, „Ladenvorgang ein“ und „Ladevorgang aus“ wären wichtig. Haben Sie Erfahrungen oder einen Tipp für so einen Speicher? Protokoll und Schnittstelle wäre mir ziemlich schnuppe (MQTT, GraphQL, SOAP, REST etc.). Schön wäre, wenn das ohne zusätzliche propritäre Hardware/Dongle usw. ginge.

    Ziel ist, dass man anhand des aktuellen Preises an der Strombörse Ladung und Entladung des Speichers steuere und im Idealfall im Sommer „kostenlos“ Strom bekomme.

    Herzlichen Dank,
    RB

    Antworten
    1. Helmut (Beitrag Autor)

      Nein, sorry Herr Bastian,
      Batteriespeicher sind nicht Thema meines Blogs und ich betreibe auch keinen. Dazu kann ich Ihnen also keine Auskunft geben.

      Antworten
    2. Klaus Eyssel

      Hallo,
      schau mal bei http://www.maxxisun.de rein. Dort gibt es verschiedene Batteriespeicher auch mit interessanter Steuerung
      Gruß Klaus

      Antworten

Schreiben Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert