Neues YouTube-Video: Visualisierung im Devices-Adapter

[leonundjulie]

@juggi1962 danke für Deine Unterstützung. Ich habe gesehen, dass Du ein paar Widgets exportiert hast. Kannst Du bitte versuchen, die gesamte View zu exportieren?

Auf Grund Deines Exports frage ich mich, ob Du für die 5 Statistiken fünf einzelne Views erzeugt hast? Und zwischen diesen über 5 Menütasten wechselst?

[juggi1962]

@leonundjulie hallo und ja ich habe 5 Seiten angelegt die musst du dann ja nur kopieren und den richtigen Datenpunkt dir holen für Tagesansicht usw.
Leider lässt sich die View hier nicht senden bekomme Meldung, dass es zu lang ist.

Gruß Jürgen

[leonundjulie]

@juggi1962 ok, dann habe ich Deine Idee aber verstanden … werde mich in Kürze an das Umsetzen herantasten. DANKE, Gruß, Andreas

[bolliy]

Neue Testversion sun2000 Adapter Version v2.4.5 released.

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Diese Update ist besonders interessant, falls du das build-in Charts anpassen möchtest.
Über den Befehl {"command": "createTemplateFromBuiltin"} im Template kann man sich das eingebaute Standarddiagramm (build-in) als Vorlage in den Template-State schreiben lassen und es dann nach Belieben anpassen.
Im Tooltip wird die Einheiten (kWh / %) explizit über tooltip.valueFormatter übergeben – das macht Templates robuster und unabhängig von Änderungen an den Serienbezeichnern.

Doku (Wiki): https://github.com/bolliy/ioBroker.sun2000/wiki/Statistk-(statistics)

Changelog
2.4.5 (2026-05-14)

• statistics fix: return weekly range up to current Monday
• statistics: added support for generating statistics templates directly from built-in charts
• statistics: improved tooltip formatter - tooltip units are now provided explicitly via tooltip.valueFormatter

[bolliy]

Mir ist aufgefallen, dass es bisher kaum Nachfragen zur Überschuss-Steuerung des sun2000 Adapters gibt. Deshalb habe ich die AI mal gebeten das Funktionalität (Surplus Power Control) genauer zu beleuchen.
Wichtig! Das Beispiel script habe ich nicht selbts geschrieben und (noch) nicht getestet. Deshalb kann ich für die Funktion kann keine Garantie oder Support übernehmen bzw. anbieten. Es soll vielmehr das Funktionsprinzip einer Überschuss-Steuerung greifbarer machen.

Überschuss-Steuerung: usablePower und Batterie-Integration

Der Adapter berechnet kontinuierlich, wie viel Solarleistung aktuell nicht selbst verbraucht wird. Dieser Wert bildet die Grundlage für Automationen, die Großverbraucher (Waschmaschine, Spülmaschine, Wallbox, Heizstab) bedarfsgerecht zuschalten – mit dem Ziel, Eigenverbrauch zu maximieren und Netzbezug zu minimieren.

---

Zwei Kerndatenpunkte

Datenpunkt	Bedeutung
collected.surplus.power	Die aktuell ins Netz eingespeiste Wirkleistung (reine Einspeisung)
collected.surplus.usablePower	Die tatsächlich nutzbare Überschussleistung: Netzeinspeisung + optionaler Batterie-Beitrag

Für Automationen sollte grundsätzlich usablePower verwendet werden, da dieser Wert die Batterie als zusätzliche Quelle einbezieht und damit ein realistischeres Bild der verfügbaren Leistung liefert.

---

Batterie-Integration: Funktionsprinzip

Ohne Konfiguration entspricht usablePower dem reinen Netzüberschuss. Sobald die Batterie ausreichend geladen ist, kann sie zusätzliche Leistung beisteuern – zum Beispiel an sonnigen Nachmittagen, wenn der SOC hoch ist und abends sowieso PV-Nachladung erwartet wird. Die Steuerlogik stellt dabei sicher, dass die Batterie nicht so weit entladen wird, dass die Nacht-Reserve gefährdet ist.

---

Parameter unter control.usableSurplus

Parameter	Funktion
minSoc	SOC-Untergrenze in %. Unterhalb dieses Werts hat Batterieladung absolute Priorität – usablePower basiert dann ausschließlich auf dem Netzüberschuss. Oberhalb von minSoc wird auch die aktuelle Ladeleistung der Batterie als Überschuss gewertet.
bufferSoc	SOC-Schwelle, ab der die Batterie aktiv Leistung zum Überschuss beisteuern darf (zusätzlich zur Einspeisung).
bufferPower	Maximale Batterie-Entladeleistung in Watt, die zum usablePower-Wert addiert wird, sobald bufferSoc erreicht ist.
bufferHysteresis	Hysterese-Band um die bufferSoc-Schwelle, um Flattern (schnelles Ein-/Ausschalten) zu vermeiden. Größere Werte = stabileres Verhalten, kleinere Werte = präzisere Regelung.
residualPower	Offset zur Feinabstimmung des Arbeitspunkts zwischen minSoc und bufferSoc. Positive Werte verschieben den Arbeitspunkt Richtung Batterieladen bzw. Netzbezug, negative Werte Richtung Einspeisung.
allowNegativeValue	Standardmäßig wird usablePower bei Werten unter 0,1 kW auf 0 geklemmt. Mit true werden auch negative Werte durchgereicht – sinnvoll für Steuerlogiken, die z.B. aktiv drosseln müssen.

---

residualPower – Feinabstimmung des Arbeitspunkts

Dieser Parameter wirkt im SOC-Bereich zwischen minSoc und bufferSoc und verschiebt den Punkt, ab dem Leistung als „nutzbar" gilt. Ein Beispiel:

• Die Anlage speist gerade 500 W ins Netz ein
• residualPower = +200 → Der Adapter zieht 200 W ab → usablePower = 300 W
• residualPower = -200 → Der Adapter addiert 200 W → usablePower = 700 W

Mit einem positiven Wert wird die Batterie bevorzugt weiter geladen bzw. ein kleiner Netz-Puffer gehalten, bevor Überschuss gemeldet wird. Ein negativer Wert meldet früher Überschuss, nimmt also in Kauf, dass minimal Strom aus dem Netz gezogen wird. Sinnvoll z.B. wenn ein Verbraucher eine Mindestleistung benötigt, die knapp über dem aktuellen Solarüberschuss liegt.

---

Empfohlene Konfigurationsstrategie

• minSoc definiert die harte Untergrenze für die Nacht-Reserve und sollte konservativ gewählt werden.
• bufferSoc und bufferPower aktivieren die Batterie als Surplus-Quelle und sind vor allem für den Nachmittag relevant, wenn hoher SOC und noch ausreichend PV-Ertrag zusammenkommen.
• Automationen reagieren dann auf usablePower und können Verbraucher mit der verfügbaren Leistung abgleichen.

---

Praxisbeispiel: Warmwasser-Heizstab per Shelly steuern

Der folgende ioBroker-JavaScript liest usablePower, prüft die Wassertemperatur über den DS18B20-Sensor des Shelly und schaltet den Heizstab entsprechend.

Voraussetzungen

• Shelly mit DS18B20-Temperatursensor am Warmwasserspeicher
• ioBroker mit Shelly-Adapter und JavaScript-Adapter
• sun2000-Adapter mit konfiguriertem usablePower-Datenpunkt

Skript

// ===== Konfiguration =====
const SURPLUS_STATE     = 'sun2000.0.collected.surplus.usablePower'; // Verfügbare Überschussleistung in W
const SHELLY_TEMP_STATE = 'shelly.0.SHSW-1#<ID>#1.ext_temperature.TC'; // DS18B20 Temperatur in °C
const SHELLY_RELAY      = 'shelly.0.SHSW-1#<ID>#1.relay.0';            // Shelly Relais

const MIN_SURPLUS_W     = 1500;   // Mindest-Überschuss in W, um Heizstab zu aktivieren
const TARGET_TEMP_C     = 60;     // Zieltemperatur Warmwasserspeicher in °C
const HYSTERESIS_C      = 3;      // Hysterese: Heizstab geht erst bei (TARGET - HYSTERESIS) wieder an
const CHECK_INTERVAL_MS = 60000;  // Prüfintervall in ms (hier: 1 Minute)

// ===== Zustandsvariable =====
let heaterOn = false;

// ===== Steuerlogik =====
function controlHeater() {
    const surplus = getState(SURPLUS_STATE).val;    // Aktueller Überschuss in W
    const temp    = getState(SHELLY_TEMP_STATE).val; // Aktuelle Wassertemperatur in °C

    system.log(`Überschuss: ${surplus} W | Wassertemperatur: ${temp} °C | Heizstab: ${heaterOn ? 'EIN' : 'AUS'}`);

    if (heaterOn) {
        // Heizstab läuft → ausschalten wenn Zieltemperatur erreicht oder Surplus weggefallen
        if (temp >= TARGET_TEMP_C || surplus < MIN_SURPLUS_W) {
            sytem.log(`Heizstab AUS → Temp: ${temp}°C / Überschuss: ${surplus}W`);
            setState(SHELLY_RELAY, false);
            heaterOn = false;
        }
    } else {
        // Heizstab aus → einschalten wenn genug Surplus UND Temp noch unter Ziel (minus Hysterese)
        if (surplus >= MIN_SURPLUS_W && temp < TARGET_TEMP_C - HYSTERESIS_C) {
            sytem.log(`Heizstab EIN → Temp: ${temp}°C / Überschuss: ${surplus}W`);
            setState(SHELLY_RELAY, true);
            heaterOn = true;
        }
    }
}

// ===== Start =====
controlHeater(); // Einmal sofort ausführen
setInterval(controlHeater, CHECK_INTERVAL_MS); // Dann zyklisch alle 60s

Schaltlogik im Überblick

Bedingung	Aktion
Surplus ≥ 1500 W und Temp < 57 °C (60 − 3 Hysterese)	Heizstab EIN
Temp ≥ 60 °C oder Surplus < 1500 W	Heizstab AUS

Wichtige Hinweise zur Konfiguration

• MIN_SURPLUS_W sollte der Leistungsaufnahme des Heizstabs entsprechen (typisch 1–3 kW). Etwas darunter ansetzen ist okay, da usablePower bereits einen Batterie-Puffer einrechnet.
• Die Hysterese verhindert, dass der Heizstab bei schwankender PV-Leistung ständig ein- und ausschaltet.
• Die Shelly-State-Pfade (<ID> ersetzen) findet man in der ioBroker-Objektliste unter dem Shelly-Adapter.
• Alternativ zu setInterval kann das Skript auch auf Änderungen von usablePower per on() reagieren – dann ist die Reaktion schneller, aber häufiger.

[juggi1962]

@bolliy Hallo und danke erst mal für diese tolle Verbesserung.
Es hat alles super funktioniert und durch das kann ich jetzt die Farben anpassen die ich schon in der Vis für andere Anzeigen verwendet habe. Jetzt ist alles einheitlich, SUPER Arbeit

Ach ja, gibt es vielleicht eine Möglichkeit den Abfrage Intervall zu ändern?
Bei der Stundenanzeige dann vielleicht 10 Minuten Anzeige würden die Kurven viel genauer sein.
Vielleicht kann man das einbauen, dass jeder wie er möchte das machen kann, oder kann man das schon im Template ändern?
Bin leider nur Anwender darum auch diese Fragen.
Danke noch mal, Gruß Jürgen

[Samson71]

@bolliy sagte:
Habe ich auf der ToDo Liste gesetzt.

In der 2.4.5 ist das aber noch nicht behoben oder? Die Meldung kommt jedenfalls immer noch regelmäßig.

Habe heute den Dongle von WLAN auf LAN ungestellt und die Firmware des WR zumindest mal aktualisiert.

[bolliy]

@Samson71 nein, bin noch am basteln ;)

[Peguschwein]

@bolliy Ich bin schoin seit einiger Zeit ein EMS zu basteln. Aber ist ein sehr komplexes Thema.
Peak-Shaving damit Speicher etc erst kurz vor erreichen der 70% Regelung geladen wird, Danach ist der Boiler an der Reihe
Netzdienlich damit ich den Peak der Anlage ausnutze statt abzuriegeln.

• EVU Überwachung
• Einspeisebegrenzung
• Batterie
• Boiler/Puffer Speicher Regelung
• Secomat
• Warnungen per whatsapp

und das kann jeden Tag anders aussehen. Wenn ich einen Wagen laden möchte soll der Speicher unf Boiler möglichst schnell geladen sein damit ich danach
die volle Energie für die beiden E-Autos habe. Also viel Regelung aber immer mit der Möglichkeit einzugreifen oder zu übersteuern.

Gruss Pegu

[Homoran]

@Peguschwein sagte:

Aber ist ein sehr komplexes Thema.

Ist es

[bolliy]

Ich bin auch dabei und bei mir im Einsatz. Kann ich aber noch nicht auf die Allgemeinheit loslassen ;)
https://github.com/bolliy/ioBroker.sun2000-ems

[lub104]

Hallo zusammen,

Ich habe das Problem das die sun2000.0.inverter.0.internalTemperature nicht mehr aktualisiert wird
Das bei Version 2.3.6 - 2.4.5., ist das ein bekanntes Problem?

[lub104]

Entschuldigung ich füge noch hinzu in sun2000.0.inverter.0.string werden auch keine Werte mehr angezeigt

[lub104]

Danke im Voraus

[bolliy]

@lub104 Bei mir werden die o.g. Daten aktualisiert und korrekt angezeigt.
Aber vielleicht hilft dir das Wiki weiter:
https://github.com/bolliy/ioBroker.sun2000/wiki/Fehlerprotokollierung-und-Fehlerbehebung-(troubleshooting)

Stephan

[bolliy]

Neue Testversion sun2000 Adapter Version v2.5.0 released.

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Es gibt einige Neuerungen im Statistik-Modul, die ich kurz vorstellen möchte.

Live-Chart

Neu ist ein Live-Chart (statistics.jsonLive), der alle 1-15 Minuten aktualisiert wird. (in der Adapter-Konfiguration unter dem Reiter Statistik eingestellbar)
Im Gegensatz zu den anderen Charts zeigt er keine kWh-Werte, sondern die durchschnittliche Leistung in kW pro Intervall — also ähnlich wie ein Echtzeit-Zähler. Die Daten werden für 48 Stunden aufbewahrt und
danach automatisch gelöscht.

Der Live-Chart ist direkt über FlexCharts nutzbar:

http://[ioBroker-ip]:8082/flexcharts/echarts.html?source=state&id=sun2000.0.statistics.flexCharts.jsonOutput.live

---

Consumption Breakdown — Hausverbrauch runterbrechen

Mit dem Consumption Breakdown lässt sich der gemessene Hausverbrauch in beliebig viele Unterkategorien aufteilen — zum Beispiel Wärmepumpe, Wallbox, Waschmaschine oder sonstige Verbraucher.
Die Breakdown-Werte werden als zusätzliche gestapelte Balken/Linien im unteren Panel jedes Charts angezeigt.

Wie funktioniert es?

Der Adapter liest die konfigurierten Quell-States (Verbrauchszähler) aus ioBroker (auch aus anderen Adaptern, mqtt, Tibberlink usw.) und zieht deren Werte vom Gesamtverbrauch ab. Im Chart erscheinen dann:

• die einzelnen Breakdown-Kategorien (z.B. Wärmepumpe, Wallbox)
• ein Restverbrauch (Consumption) — das ist der Hausverbrauch minus alle Breakdown-Werte

Die Summe aller Verbräuche im unteren Panel entspricht dem gemessenen Gesamtverbrauch.

Konfiguration

Die Konfiguration erfolgt über den State statistics.dataDef.consumptionBreakdown (beschreibbar,
Typ string, Rolle json). Dort wird ein JSON-Array eingetragen, das die Unterkategorien beschreibt.

Ein Beispiel mit zwei Einträgen:

[
  {
    "sourceId": "hm-rpc.0.OEQ1234567.1.ENERGY_COUNTER",
    "targetPath": "washingMachine",
    "name": "Waschmaschine",
    "gain": 1000,
    "color": "#e91e63",
    "type": "delta"
  },
  {
    "sourceId": "0_userdata.0.heatpump.energyToday",
    "targetPath": "heatPump",
    "name": "Wärmepumpe",
    "color": "#3f51b5",
    "type": "deltaReset"
  }
]

Was bedeuten die Felder?

Feld	Pflicht	Standard	Beschreibung
sourceId	X	—	State-ID des Quell-States in ioBroker (auch aus anderen Adaptern)
targetPath	X	—	Interner Name (darf nicht mit eingebauten Namen wie consumption, solarYield usw. kollidieren!)
name	X	—	Anzeigename in der Chart-Legende
gain	—	1	Teiler für den Rohwert — z.B. 1000 wenn der State in Wh geliefert wird, der Chart aber kWh erwartet
color	—	automatisch	Farbe der Serie als Hex-Code
type	—	delta	deltaReset (laufende Differenz mit automatischer Erkennung einer Zählerrückstellung/Reset), delta (laufende Differenz) oder level (Momentanwert)

---

Kleinere Verbesserungen

• Die Tooltip-Anzeige wurde vereinheitlicht — alle Serien zeigen Werte mit korrekter
  Einheit (kWh oder kW je nach Chart-Typ).
• Falls keine Batterie vorhanden ist, werden die Charts ohne Batterie-Information (SOC, charge, discharge) aufgebaut.

---

Alle Details, Placeholder-Übersichten und Template-Beispiele gibt es im Wiki:
https://github.com/bolliy/ioBroker.sun2000/wiki/Statistk-(statistics)

Feedback und Fragen gerne hier im Thread! 🙂

[bolliy]

ab der Adapter sun2000 Version 2.5.0 wird node.js nur noch in der Version >= 22.x unterstützt. Hier findet ihr die node.js Update-Anleitung für euren ioBroker.

[bolliy]

@Samson71 sollte nun auch ohne Speicher funktionieren. Bitte testen!
LG Stephan

[bolliy]

Wenn ihr an die flexChart-Url ein &sse anhängt wird die automatische Diagrammaktualisierungen aktiviert.
Der Browser hält eine dauerhafte Verbindung zum Server aufrecht und aktualisiert das Diagramm sobald sich die Quelldaten ändern – ohne Neuladen der Seite.

Z.B. für das Live-Chart würde die url folgendermaßen aussehen:

http://[ioBroker-ip]:8082/flexcharts/echarts.html?source=state&id=sun2000.0.statistics.flexCharts.jsonOutput.live&sse

Siehe:
https://github.com/MyHomeMyData/ioBroker.flexcharts#event-triggered-chart-refresh-sse

[Samson71]

@bolliy sagte:

@Samson71 sollte nun auch ohne Speicher funktionieren. Bitte testen!

2.5.0 problemlos installiert. Instanz grün. Ich werde berichten.

Danke für Deine unermüdlichen Verbesserungen! Das ist echt bemerkenswert. Vom Engagement her fast schade, dass ich mich schlussendlich doch gegen ein allumfassendes Huawei-System entschieden habe.