Hier die Antwort von AVM:

vielen Dank für Ihre Anfrage an den AVM Support.

Es ist sehr schade zu lesen, dass es aktuell dazu kommt, dass Geräte, die über einen AP eines anderen Herstellers mit der FRITZ!Box verbunden sind, von der FRITZ!Box nicht erkannt werden.

Die FRITZ!Box kann die Verbindungsinformationen von Geräten nicht immer korrekt ermitteln, wenn diese über einen weiteren Router, WLAN-Repeater oder Powerline-Adapter eines anderen Herstellers mit der FRITZ!Box verbunden sind. Dies betrifft auch Geräte, die über ein älteres FRITZ!Box-Modell ohne Mesh-Unterstützung mit der FRITZ!Box verbunden sind.

Die Verbindungsinformationen von Geräten, welche nicht direkt über die FRITZ!Box verbunden sind, müssen mittels des Mesh übermittelt werden. Dieses wird von Fremdgeräten nicht unterstütz. Um einen Fehler in dem Sinne handelt es nicht.

Wir prüfen allerdings, ob sich der Abruf der Verbindungsinformationen auch über Geräte anderer Hersteller im Rahmen kommender FRITZ!OS-Updates optimieren lässt.

...also typisch schwammige Antwort. Habe nochmal geantwortet, dass es zuvor ja ging. Hoffen wirs, dass sie es an die Entwicklung weiterleiten und sich was tut.

@rene_hm DANKE fürs Prüfen!
Ich habe die letzten Tage keinerlei Updates eingespielt, was auf einen Zusammenhang mit dem eBus Adapter deuten könnte. Erst nachdem er keine Daten mehr lieferte, habe ich admin auf die aktuelle Version v6.17.14 gehoben.

JS-Controller ist bei mir seit einigen Wochen auf 5.0.19, Node.JS auf v18.20.3.

Ich denke das Node.JS Update (im Rahmen des buanet Docker Container Upgrades auf 9.1.2) war das letzte, was ich gemacht hatte. Das ist erst einige Tage her... evtl. hab ich das diesen Montag gemacht, weiß gar nicht mehr sicher. Auf jeden Fall wars nicht gestern. Aber auch das war nur ein Minor-Upgrade, ich war davor schon auf Node.JS 18

Hier ebenfalls das Gleiche. Der Adapter funktioniert seit gestern schlagartig nicht mehr.
Bei mir sind die Daten vom ebusd (via 192.168.xxx.xxx:8889/data) allerdings aktuell und sie funktionieren.

Ich habe sowohl meinen ebusd-Raspi neu gestartet, als auch meinen ioBroker Container. Wenn ich den ebus-Adapter im iobroker auf DEBUG stelle, sehe ich auch dort die aktuellen Daten - aber die Objekte im iobroker werden eben nicht mehr aktualisiert.

Es scheint als wären wir nicht allein: https://github.com/rg-engineering/ioBroker.ebus/issues/86
Den letzten Beiträgen zufolge besteht bei ihnen das gleiche Problem seit 10.07.24.

Standarduser created this issue in rg-engineering/ioBroker.ebus

closed Adapter speichert keine Daten mehr #86

Hat hier auch jemand das Problem, dass der WR nicht mehr aus der "Ext. Batteriesteuerung" rauskommt, sobald er mal eine externe Vorgabe empfangen hat?

Laut Anleitung und zahlreichen Foren sollte der WR automatisch aus der ext. Steuerung rausgehen, sobald der einstellbare Timeout abgelaufen ist und keine Werte empfangen werden. Bei mir ist das leider nicht so.

Ich sende definitiv nichts, habe den Plenticore sowie den Modbus Adapter gestoppt - trotzdem hängt er im Ext. Steuerungs Modus fest.

Aktuell hilft nur ein Reboot des WR, dann steuert er die Batterie wieder intern.

Mein Usecase wäre, den Speicher nachts bei günstigem Tibberstrom zu laden und ihn tagsüber zu verbrauchen, wenn der Tibberstrom über 15ct teurer ist als nachts.

Das funktioniert auch alles - aber ich bekomme ihn eben danach nicht mehr in die interne Steuerung zurück...

Hab die aktuellste Firmware drauf (01.29.12038)

Hat jemand vielleicht ne Idee?

hmm, die 110° könnte ich mir gar nicht erklären. Das passt weder für S=180° noch für S=0°.
Habs jetzt mal eingetragen und der day1.power.remaining Wert hat sich dadurch nochmals halbiert. Daher denke ich schon, dass die 250° für SW passen müssten.

Übergangsweise stelle ich jetzt einfach die Effizienz der Module auf astronomische Werte, sodass das zumindest halbwegs passt.

Aber danke für den Tipp!

Ich frage mich, ob ich einen Fehler in der Leistungsprognosen-Konfiguration habe, denn meine Prognose ist max. 50% dessen, was tatsächlich vom Dach kommt.

Ich habe:

12 Module nach N/O (4,32 kWp)
20 Module nach S/W (7,68 kWp)

und konfiguriert habe ich folgendes:

Eigentlich müsste das doch passen, oder?

Beispiel für die S/W Seite:

Panelausrichtung 250° müsste doch S/W sein, wenn 180° S ist. (Hier bin ich verwirrt, da der Azimut doch normalerweise Süden bei 0° hat?!)
Plattenoberfläche: 35m2 / 1,7 = 20 Module, sollte auch passen?!
Dachneigung ist klar.

Laut Datenblatt haben meine Module 21,x % Effizienz. Ich habe dort inzwischen schon deutlich höhere Werte eingetragen und trotzdem ist meine Prognose weit weg vom tatsächlichen Ertrag.
Hier ein Beispiel von gestern:

Prognostiziert wurden ca. 28 kWh. Tatsächlich produziert wurden fast 50 kWh.

Standort im ioBroker ist ebenfalls korrekt gesetzt.

Habt ihr auch so eine krasse Abweichung? Habe ich irgendwo nen Fehler gemacht?

Ich antworte mir mal selbst: inzwischen läuft alles wie es soll. Ich habe dann aus Verzweiflung mal via Modbus Register 1038 (Battery Max Charge Power) gesetzt, welches im Plenticore Adapter dann sofort unter ExternControl_MaxChargePowerAbs erschien. Darüber wurde der Wert vom WR berücksichtigt. Seitdem kann ich die Werte auch über den Plenticore-Adapter setzen.

Offensichtlich hatte sich die WR-Software ein wenig aufgehangen. Also: Funktioniert alles auch mit Pylontech Akkus. (Obwohl dort die "intelligente Batteriesteuerung" gesperrt ist)

hatte denn jemand mal Erfolg, andere Batterien als BYD extern zu steuern?

Ich habe an meinem Plenticore eine Pylontech Force H2 dran, externe Batteriesteuerung ist aktiv, der WR akzeptiert auch den gesetzten Wert für ExternControl_MaxChargePowerAbs - jedoch wird er nicht beachtet. Die Steuerung scheint trotzdem weiter intern zu laufen, obwohl der WR in den Momentanwerten "externe Steuerung aktiv" anzeigt.

Mir gehts in erster Linie darum, zu vermeiden dass die Batterie im Sommer ständig 100% SoC hat. Ich würde daher gerne den Max SoC bis Nachmittags begrenzen. Gibts denn sonst Workarounds dafür?

@homoran said in Test eCharts Adapter:

nur mit Trick.

Danke für die Bestätigung und den Trick! So überlege ich es jetzt zu bauen, aber dann stimmen halt die Werte im Tooltip nicht mehr.

Top wäre es, wenn es visuell gestapelt dargestellt würde, aber die Werte im Tooltip halt die richtigen wären.
Naja, vielleicht kommt die Funktion ja noch eines Tages.

Ich nutze eCharts nun seit ca. einem Jahr und bin schwer begeistert. Funktioniert bestens.
Nur eine Sache habe ich noch nicht herausgefunden:

Kann man irgendwie gestapelte Graphen bauen? Ich würde gerne in meiner PV-Visualisierung die Bezugsquellen stapeln, also z.B. PV-Direktbezug unten und Akkubezug darüber, so wie das im Portal meines Wechselrichters sehen kann:

hier liegen die blauen und der gelbe Graph auf dem grünen "oben drauf".

So sieht es hingegen bei mir im eCharts aus:

hier starten alle Graphen auf der 0-Linie der Y-Achse. Kann man irgendwie einstellen, dass der Start der Y-Achse eine andere Datenquelle sein soll?
Ich hoffe es ist halbwegs verständlich was ich meine.

Hier die Antwort von AVM:

vielen Dank für Ihre Anfrage an den AVM Support.

Es ist sehr schade zu lesen, dass es aktuell dazu kommt, dass Geräte, die über einen AP eines anderen Herstellers mit der FRITZ!Box verbunden sind, von der FRITZ!Box nicht erkannt werden.

Die FRITZ!Box kann die Verbindungsinformationen von Geräten nicht immer korrekt ermitteln, wenn diese über einen weiteren Router, WLAN-Repeater oder Powerline-Adapter eines anderen Herstellers mit der FRITZ!Box verbunden sind. Dies betrifft auch Geräte, die über ein älteres FRITZ!Box-Modell ohne Mesh-Unterstützung mit der FRITZ!Box verbunden sind.

Die Verbindungsinformationen von Geräten, welche nicht direkt über die FRITZ!Box verbunden sind, müssen mittels des Mesh übermittelt werden. Dieses wird von Fremdgeräten nicht unterstütz. Um einen Fehler in dem Sinne handelt es nicht.

Wir prüfen allerdings, ob sich der Abruf der Verbindungsinformationen auch über Geräte anderer Hersteller im Rahmen kommender FRITZ!OS-Updates optimieren lässt.

...also typisch schwammige Antwort. Habe nochmal geantwortet, dass es zuvor ja ging. Hoffen wirs, dass sie es an die Entwicklung weiterleiten und sich was tut.