Monatsrückblick Januar/Februar 2026 ist online!

[pdbjjens]

Ich arbeite zur Zeit an einem neuen Release des sma-em mit einigen Fehlerbehebungen und einer funktionalen Erweiterung bzgl. der Auswahlmöglichkeit eines bestimmten Netzwerks auf das auf Multicasts des SHM oder SMA-EM gelauscht werden soll (anstelle auf alle vorhandenen). Diese Auswahlmöglichkeit wurde immer mal wieder nachgefragt, da sich beim Verbinden mit allen Netzwerken oft unerwartete Fehler ergaben - insbesondere in Docker-Umgebungen.

Die ganz Wagemutigen unter euch können sich den Adapter von
https://github.com/iobroker-community-adapters/ioBroker.sma-em.git
installieren.
Aber VORSICHT: es ist ein Pre-Alpha Stand und Ihr solltet wissen, was Ihr tut - insbesondere nicht auf einem produktiven ioBroker installieren!
Aber ich wäre wirklich über jedes Feedback erfreut - insbesondere, ob die neue IP-Auswahlfunktion auf der Config-Seite des Adapters euren Erwartungen und Anforderungen entspricht.

[Winni]

@pdbjjens Hallo, habe mal erst von github und dann über den link (https://github.com/pdbjjens/ioBroker.sma-em.git) installiert. Es bleibt aber immer bei der Version 0.7.

[pdbjjens]

@winni
Ja, das ist korrekt so, ich habe noch kein neues Release gemacht; es bleibt daher bei v0.7.0. Wenn Du aber von GitHub direkt (Benutzerdefiniert) installierst, müsstest Du auf der Konfigurationsseite "Multicast Einstellungen" eine neue Auswahlbox "Eigene Netzwerk-Schnittstellen IPs" eine Liste der verfügbaren IPs Deines Hosts finden, wovon Du alle oder eine auswählen kannst.

[Winni]

@pdbjjens danke für deine Antwort, so habe ich es gemacht, schau:

Ich sehe aber keinen Unterschied zu vorher.

Oder habe ich Tomaten auf den Augen 😉

[ticaki]

@winni
ich installiere ihn mit dieser Angabe:

https://github.com/iobroker-community-adapters/ioBroker.sma-em

und das hat jetzt 4 mal funktioniert(hab vorher getestet und meine eigene Version gehabt)

[Winni]

@ticaki Ok, so hats funktioniert, danke 😀

Edit: Schaut gut aus, läuft :+1:

[pdbjjens]

@winni
Ooops, hab den falschen Github link oben gepostet, der von @ticaki ist richtig. Ich bitte um Entschuldigung. Ich werde meinen Post oben korrigieren.

[Winni]

@pdbjjens Kein Problem, der Adapter läuft gut. Danke für deine Arbeit :+1:

[tuning]

@pdbjjens
Danke für deine Arbeit.
Mit dem letzten update wurde die Zeitbegrenzung eingeführt um die Systemlast kleiner zu machen.
Die Zeiten haben einen min. Wert von 1sek. bzw 30sek.
Da meine Bezug/Einspeisung pfeile in der vis die Daten von diesem Adapter bekommen.
Kommen die Daten zu langsam an, überschneiden sich Pfeile in der Vis manchmal.
Gibt es eine möglichkeit diese Zeitbegrenzun raus zu nehmen?

[pdbjjens]

@tuning said in Test Adapter sma-em v0.7.x Latest:

Gibt es eine möglichkeit diese Zeitbegrenzun raus zu nehmen?

Nein, die Möglichkeit gibt es nicht. Das sollte auch nicht nötig sein, denn genau wie früher werden die realtime Datenpunkte synchron zum selben Zeitpunkt upgedatet, nur eben im Abstand von minimal 1s (früher 200ms, 600ms oder 1s je nach Einstellung des EM oder SHM).

Allerdings möchte ich Dein Problem genauer verstehen.
Wie lange dauert denn die Überschneidung der Pfeile (bei einem Realtime-Intervall von 1s)?
Ich nehme an, Du nutzt die Datenpunkte pregard bzw. psurplus?
Weiterhin nehme ich an, dass Du ein Javascript oder Blockly verwendest um die Vis (welche?) anzusteuern.
Wenn Du Dein Skript hier posten magst, gibt es vielleicht Hinweise wie man die Asynchronitäten der Auslesung und Anzeige der Datenpunkte in den Griff kriegen kann.

Ergänzung: Durch die Mittelwertbildung während des Aktualisierungsintervalls kann es passieren, das die Werte von pregard bzw. psurplus beide > 0 sind. Da Dein Skript vermutlich auf > 0 abfragt, führt das dann zu dem von Dir bemerkten Zustand für die Dauer eines Aktualisierungsintervalls (1s).
Ich sehe da mehrere Lösungsmöglichkeiten:

• Änderung Deines Skripts, so dass eine Umschaltung der Pfeilrichtung erst erfolgt, wenn einer von beiden Werten = 0 und der andere > 0 ist.
• Generelle Abschaltung der Mittelwertbildung im Adapter für alle realtime Datenpunkte d.h. es wird jeweils der letzte Wert des Aktualisierungsintervalls genommen. Dadurch ist sichergestellt, dass ein eindeutiger Wert =0 oder >0 in pregard bzw. psurplus steht. Nachteil ist, dass eventuelle Änderungen des Leistungswertes während des Aktualisierungsintervalls nicht berücksichtigt werden und es daher zu Ungenauigkeiten kommt, wenn man die Leistungsmesswerte z.B. zur Berechnung der Arbeit benutzen möchte.
• Modifikation der Mittelwertbildung im Adapter für alle realtime Datenpunkte in der Weise, dass wenn pregard bzw. psurplus während eines Aktualisierungsintervalls mindestens 1-mal auf 0 geht, wird der letzte Messwert des Aktualisierungsintervalls statt des Mittelwerts genommen. So ist sichergestellt, dass am Ende des Aktualisierungsintervalls ein eindeutiger Wert =0 oder >0 in pregard bzw. psurplus steht. Nachteil ist dabei, dass sich dadurch Ungenauigkeiten bei der Arbeitsberechnung (s.o.) ergeben- wenn auch geringere.

Im Interesse einer möglichst hohen Messgenauigkeit würde ich die beiden letzten Alternativen nicht bevorzugen. Wie sehen Du und andere User hier im Forum das?

[ticaki]

@pdbjjens
Mir ist noch nicht aufgefallen, das einer der Werte nicht null war. Hab aber auch keine Wellenpaketsteuerung an einem großen Verbraucher.

[pdbjjens]

@ticaki
Mir schon, z.B. an einem Tag wie heute mit geringen Solarerträgen die auch noch häufig schwanken, kommt es vor, dass die Richtung oft (im 200 Millisekundentakt!) wechselt und durch die Mittelwertbildung pregard bzw. psurplus beide gleichzeitig >0 sind. Aber ich meine, das kann man gut in einem Skript abfangen (statt im Adapter). Das hätte den zusätzlichen Vorteil, dass in der VIS die Pfeilrichtung nicht so häufig wechselt.

[ticaki]

@pdbjjens
Dann ist wohl mein HomeManager auf sekunde eingestellt. hab heute einen kleinen Spike drin von 1 Sekunde, aber auch da ist einer der Werte 0, mal sehen ob ich das ändern kann.

[Sneak-L8]

Ich hatte es mal in einer älteren Version, dass die Werte nicht ausgenullt wurden, wenn von regard beg furious oder umgekehrt gewechselt wurde.
gebaute weiß ich schwer nicht mehr (als Adapter-Version, automatisches (?) des SHM,...

[tuning]

@pdbjjens
Danke für deine Rückmeldung.
Du hast genau recht mit deinen Annahmen.
Ich kann den Skript ändern, dann funktioniert die Anzeige.

Das Problem bleibt halt, da SMA kein Lademanagment hat, welches den Spreicher nicht gleich auf 100% ladet, muss man es selber machen. (das Prognosebasierte Lademanagment funktioniert zur Zeit nicht vernünftig)
Und dafür würde ich halt auch die selben schnellen werte wie SMA benötigen.

[pingpong]

Hallo, ich habe das Problem, dass seit ein paar Tagen für psurplus und pregard genau die Hälfte anzeigt wird, als im Sunny Portal. z.B. Sunny Portal 500W im ioBroker 250W. Vorher hat es Monate funktioniert. Ich bin mir nicht bewusst eine Änderung gemacht zu haben. Hat jemand eine Idee, was falsch läuft?

[pdbjjens]

@pingpong
Welche Adapter Version ist im Einsatz? Hast Du evtl. ein Update auf v0.7.0 gemacht?

[pingpong]

@pingpong Heute sind die Werte wieder richtig. Sehr seltsam.

[pingpong]

@pdbjjens Ja, ich habe die v0.7.0. Das Update ist aber schon länger her.

[pdbjjens]

@tuning said in Test Adapter sma-em v0.7.x Latest:

Und dafür würde ich halt auch die selben schnellen werte wie SMA benötigen.

Ich würde gerne verstehen, warum Dir das Update Intervall von 1s nicht ausreicht.
Würdest Du mir bitte in ein paar Sätzen erklären, wie Dein Lademanagement funktioniert bzw. funktionieren soll?

Bisher habe ich von anderen Usern der v0.7.0 kein Feedback, dass sie mit der Mittelwertbildung und einem Update Intervall von 1s in Ihren Applikationen Schwierigkeiten hätten.
Daher meine Frage in die Runde in diesem Thread: sieht jemand die Notwendigkeit, das alte Verhalten zurückzubringen? Wenn ja, warum?