Nur zur Info: Ich habe das Repository für die Adapter-Entwicklung nun an @Excodibur übergeben. Schön, dass sich jemand gefunden hat, der den Adapter weiterentwickeln möchte

Also, zum Aktivieren der externen Steuerung:

• Login via Browser (z. B. Firefox)
• Navigation zu Servicemenü -> Batterieeinstellungen
• Rechtsklick auf die inaktive Auswahlbox, in der "Intern" steht
• Developer Konsole öffnen durch Klick auf "Element untersuchen" (oder vergleichbar in anderem Browser)
• Attribut "Disabled" bei der Selectbox entfernen (Doppelklick auf "Disabled" und löschen, dann Enter)
• Das Auswahlfeld ist nun benutzbar und man kann die Einstellung auch effektiv speichern
• Anschließend sind die Felder wie MinSoC, max. Ladestrom usw. im ModBus auch beschreibbar

Soweit ich das mit den Warnungen richtig sehe, ist das ein Problem mit den deviceURLs. Er scheint da etwas nicht zu finden.

Ich habe auf Basis des Skripts jetzt einen Adapter entwickelt und dabei auch einige Bugs gefixt (vermutlich auch neue eingebaut ).

https://github.com/StrathCole/ioBroker.tahoma

Ich habe einen Adapter auf Basis des Skripts aus https://forum.iobroker.net/post/355807 entwickelt und eine erste lauffähige Version online gestellt.
Über Rückmeldungen würde ich mich freuen. Danke an @thoemmes86 und @CodeMasteR für die initiale Entwicklung und Erweiterung des Skripts.

Viele Grüße
Marius

Auch wenn das Thema nun schon alt ist, muss ich mich doch einmal dazu äußern.

Zuerst einmal vorweg:
Ich arbeite als selbstständiger Entwickler (nicht mit nodejs, dazu bin ich nur durch ioBroker gekommen) und habe eine Familie. Das bedeutet, dass neben der Arbeit ohnehin nur noch wenig Freizeit bleibt und ich diese eher mit der Familie verbringe als noch mehr Stunden den PC zu hüten.
Dazu bin ich in einem größeren Open Source Projekt involviert, das für mich einen um Welten höheren Stellenwert hat als der ioBroker (sorry @apollon77 ), also muss auch da noch ein Teil der Freizeit einfließen.

Dann noch ein paar generelle Fakten:
Alle Adapter, die ich erstellt habe, habe ich vornehmlich erst einmal aus egoistischen Gründen erstellt, eben weil ich die entsprechenden Geräte besitze und ioBroker nutzen wollte, sie zu steuern.

Es gibt nur einen Adapter, den ich wirklich von "null" auf selbst entwickelt habe, und das ist der Kostal Adapter, da ich diesen selbst auch am dringendsten benötige. Entsprechend ist dies auch der Adapter, in den vorrangig Zeit fließt, wenn doch einmal etwas übrig ist.

Der Tahoma Adapter ist aus reiner Bequemlichkeit und dem Gedanken entstanden, dass evtl. andere User dazu beitragen.
Direkt auf der Startseite im Git habe ich extra geschrieben:

An ioBroker adapter for Somfy Tahoma. This project has no affiliation with Somfy. Initially based on the script taken from https://forum.iobroker.net/post/336001

Ich habe also ein fertiges Javascript genommen, versucht es einigermaßen zu verstehen, Probleme zu beheben, die bei mir aufgetreten sind, und dann in einen Adapter zu packen und auf github zu laden, um es a) anderen Usern einfacher zu machen, es zu installieren und b) es anderen Usern einfacher zu machen, via PR Code beizutragen (ist übrigens so gut wie nicht passiert).
Dazu kommt, dass ich ausschließlich eine Tahoma Box und die io Rollläden besitze, ich kann also alles andere wie Rollos etc. nicht selbst testen, habe keine Möglichkeit, Zustände und Infos aus dem Code der Cloud zu holen. Entsprechend ist das Einbauen dieser Dinge und Beheben von Problemen damit ein extrem unschönes und aufwändiges Unterfangen.

Und weswegen ich auf den Beitrag von @uwe72 so reagiert habe, kann ich auch genau sagen. Es ist auf gut Deusch gesagt zum Kotzen, wie oft man in der Open-Source-Welt auf User stößt, die wie selbstverständlich kostenlose Dinge abgreifen (ja, dieses Wort ist bewusst gewählt) und bei Problemen so tun, als wären ihre Probleme mit der Software das Wichtigste auf der Welt. Mittlerweile habe ich mir angewöhnt, diese Benutzer entweder zu ignorieren oder entsprechende Beiträge zur Community meinerseits einzustellen. Normalerweise nehme ich mir inzwischen auch nicht mehr die Zeit, auf so etwas groß zu reagieren, aber da sich hier auch apollon und andere entsprechend "genötigt" gefühlt haben, etwas schreiben zu müssen, wollte ich sie nicht ganz allein und ohne Infos dastehen lassen.

Zum Schluss noch gesagt: Bei mir läuft der Adapter. Ja, ich muss ihn alle 1-2 Wochen mal für ein paar Stunden abschalten und dann neu starten, aber er funktioniert für mich in allen Teilen, die ich benötige. Und entsprechend muss ich nun einmal so "egoistisch" sein und nur Dinge tun, die ich entweder selbst benötige oder für die ich tatsächlich mal etwas von seltener überschüssiger Zeit habe. Klar mag das für einige User scheiße sein, aber dann müssen sich eben ein paar mehr Menschen finden, die zu so einem Adapter beitragen.

In diesem Sinne schon mal ein schönes verlängertes Wochenende.

Hallo zusammen,

ich bin noch neu hier, habe aber einige Threads durchgelesen.
Da ich selbst gerade dabei bin, meine Haussteuerung mit ioBroker aufzumöbeln und wir kürzlich eine PV-Anlage mit BYD-Speicher und Plenticore WR bekommen haben, habe ich nach einer vernünftigen Lösung gesucht.

Wir in anderen Foren auch zu lesen ist, funktioniert z. B. die "Dynamische SoC-Regelung" nur mäßig und es fehlt die Möglichkeit, via ModBus Werte zu setzen.
Also habe ich mich dran gesetzt, meinen ersten Adapter zu entwickeln, der die interne Web-API (kein Screenscraping) des Plenticore nutzt.

Ich selbst habe einen Plenticore Plus 10, weiß also nicht, ob die API bei allen Modellen der Reihe identisch ist und somit der Adapter überhaupt funktioniert. Für Rückmeldungen wär ich daher dankbar

Falls jemand Interesse hat, hier das Ergebnis:
https://github.com/StrathCole/iobroker.plenticore

Liebe Grüße
Marius aka StrathCole

Für die neue Version meines Plenticore-Adapters benötigte ich die Wetterdaten von Darksky.
Der Adapter ist bisher nur eine simple Basis, der nach Eingabe eines API-Keys (kostenfrei über die DarkSky-Seite) die aktuellen Wetterdaten und Vohersagen von darksky.net abruft. Mit dem kostenlosen API-Key sind derzeit meines Wissens nach 1000 Anfragen täglich möglich. Dies reicht für eine 5-minütliche Abfrage der Daten.

Viele Grüße
Marius

In meinen Augen: Licht = 100% Beleuchtung, Rollladen / Markise = 100% Verdunkelung / Verschattung.

@Marco-Laser Die Statistik-Objekte habe ich nun auch eingebunden.

Wichtig: Vor dem Aktualisieren auf den neuen Stand bitte die Instanz deaktivieren und nach dem Aktualisieren in der Instanz das Passwort neu eintragen. Es wird jetzt verschlüsselt gespeichert, dadurch könnte er das alte nicht mehr lesen.

Die Datenpunkte sind übrigens unter scb.statistic zu finden.

@AlCalzone sagte in [Umfrage] Rolladenposition in % was ist logischer?:

Beispiel: Z-Wave (Multilevel Switch). Dahinter kann sich eine Lampe oder ein Rolladen oder ganz was anderes verstecken.

Dann darf der Datenpunkt ja auch kein level.blind haben. Sonst ist ja festgelegt, dass es ein Beschattungsgerät / Rollladen ist und keine Lampe.

Ich bin auch der Meinung, dass separate Roles, also level.opened.blind oder level.closed.blind sinnvoll wären wie oben vorgeschlagen, damit wäre die ganze Diskussion müßig und allen geholfen

@honnkoponko Kann ich nicht beantworten. Habe Szenen nie genutzt.

@honnkoponko Wie gesagt. Lokale Steuerung nutzt keinerlei Cloud-Verbindung und ist daher auch unabhängigvon einer Internetverbindung. Aber es sind keine Szenen verfügbar. Der Adapter kann beides. In den Einstellungen gibt es da eine Option für die lokale Verbindung.

Also seit ich die lokale Verbindung nutze, hatte ich noch keine Unterbrechung. Cloud nutze ich gar nicht mehr. Lokal gibt es natürlich keine Szenen.

@alexburna sagte in IOBroker Anbindung an einen Kostal Plenticore:

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?!)

Ich glaube, SW ist 110° in der Konfiguration. Ich habe SSW Ausrichtung mit 11° Abweichung und bei mir ist 169° eingetragen.

@gammler2003 Mir ist das Verhalten nicht bekannt.

Schau mal bei den Objekten unter system.adapter.tahoma und geh dort auf den Edit-Stift rechts. Dann löscht du unter "native" den Wert beim bearer token raus. Vielleicht hilft das.

@dakusk Zu welchen Zeitpunkten treten diese auf? Nach einem Befehl oder einfach so?

@wusa In der Konfig mal versuchen, mDNS zu aktivieren.

@diginix sagte in IOBroker Anbindung an einen Kostal Plenticore:

@strathcole Bei mir stimmt pvforecast auch nicht immer, aber selten liegt die Prognose zu hoch:

Dafür ist eben die von deinem Adapter manchmal unter 50%. Ist mir prinzipiell aber egal, …

Mir ist es nicht so ganz egal Mich nervt es. Ich bin auch nicht sicher, woran es liegt. Ich vermute daran, dass ich die Vorhersage inzwischen bei Sonnenaufgang einfriere, damit diese wilden Sprünge nicht mehr auftreten. Könnte zumindest sein, dass dadurch dann ggf. aktualisierte Daten nicht mehr einfließen. Im Moment habe ich nur leider nicht die Zeit, mir mal die Vorhersage-Rohdaten an solchen Tagen mitloggen zu lassen und auszuwerten.

@diginix Ich habe mir das mit den Prognosen noch einmal angeschaut.

Leider kann ich bei mir da wahnsinnig große Schwankungen feststellen zwischen der Qualität von pvforecast und Plenticore. Bei pvforecast habe ich das Problem, dass die Schätzung an einigen Tagen deutlich zu hoch ist. Das bringt dann Probleme im vorgezogenen Verbrauch.

Beispiel der letzten 7 Tage:

10.5.:
Plenti: 18.400
pvf: 42.100
Real: 52.800

11.5.:
Plenti: 60.500
pvf: 80.000
Real: 60.900

12.5.:
Plenti: 28.400
pvf: 57.500
Real: 61.700

13.5.:
Plenti: 57.400
pvf: 69.100
Real: 61.600

14.5.:
Plenti: 71.500
pvf: 83.600
Real: 64.000

15.5.:
Plenti: 55.500
pvf: 76.400
Real: 61.400

16.5.:
Plenti: 18.900
pvf: 45.800
Real: 47.200

@diginix sagte in IOBroker Anbindung an einen Kostal Plenticore:

@strathcole Obwohl ich die dynamische MinSOC Steuerung in der Instanz aus habe, wurde vorhin mein MinSOC von 5% auf 10% gesetzt. Danach habe ich mal tesweise das "Dynamisches Batteriemanagement" deaktiviert und dadurch wurde der MinSOC erneut von 10% auf 12% und wieder auf 10% gesetzt.

Das sollte er eigentlich nicht machen. Ich habe da auch nichts am Code geändert, müsste also schauen, ob etwas durch die Contributions verändert wurde, das das verursachen könnte.

Die Batteriestrategie steht auf Variante 1. Aber bis Adapter v2.2.1 wurde der MinSOC nicht durch die Dynamisches Batteriemanagement (Intelligente Batteriesteuerung) verändert.
Ich habe nun alle Steuerungen in der Instanz aus, aber dennoch steht im Log:
"Using forecast of day 2 for MinSoC calculation." und der MinSOC wird geändert.

Das steht da eigentlich immer.

Ich habe die readme in EN und DE zu beiden Strategien durchgelesen aber es noch nicht verstanden
Kannst du zum einen sagen was die Intentionen der 2 verschiedenen Srategien sind und warum der MinSOC vom Adapter geändert wird obwohl die Steuerung gar nicht aktiv ist.

Nein, die zweite Strategie hat "PastCoder" integriert. Die Begründung steht hier:
https://github.com/StrathCole/ioBroker.plenticore/pull/62

Problem ist auch, dass die Prognose vom Plenticode mittlerweile schlechter ist als die vom pvforecast. Bis vor Wochen habe ich immer die vom Plenticore gelobt. Für morgen sagt dein Adapter nur 11 kWh voraus und pvforecast 30 kWh.

Ja, ich kann nicht sagen, woran es liegt, aber es ist mir selbst auch schon aufgefallen. In der Vorhersageberechnung wurde meines Wissens nach nichts verändert, das Ursache sein könnte. Muss ich aber noch mal vergleichen. Entweder ist da ein Bug in einer der letzten Versionen eingeflossen oder die Wetterdaten der Anbieter, die ich nutze, sind so deutlich schlechter geworden. Ich habe derzeit auch große Abweichungen.

PastCoder created this issue in StrathCole/ioBroker.plenticore

closed Battery strategy 2 #62