UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[ArnoD]

@psrelax
Falls du die neue Version schon heruntergeladen hast, bitte noch mal erneuern. Habe noch einen kleinen Fehler gefunden und das Script neu hochgeladen.

[psrelax]

@arnod
Danke für den Hinweis. Habs nochmal geholt.

[TscharlieAlt]

@arnod
Ich habe die bisherige e3dc-rscp Instanz gelöscht und dann neu aufgesetzt nur mit den Daten der S10. Zusätzlich habe ich eine zweite Instanz von e3dc.rscp angelegt mit den Daten der Quattroporte, die eine eigene IP-Adresse hat. Funktioniert wunderbar. Alle Daten sind jetzt verfügbar.

Bei dieser Übersicht kann man ja Daten miteinander verknüpfen, so dass der "Hausverbrauch" auch richtig angezeigt wird. Bei der S10 und damit auch in den Objekten wird nämlich der "Hausverbrauch" incl. der weiter geleiteten Ladeleistung an die Quattroporte ausgewiesen. Nur bei der Darstellung im Flot-Editor habe ich keine Möglichkeit gefunden, Daten miteinander zu verknüpfen, d.h. zu addieren oder subtrahieren. Gibt es hierzu eine Lösung?

Problem ist allerdings die mit Charge-Control primär beabsichtigte Ladesteuerung, die ich heute gestartet hatte. Sie funktioniert nicht. Ich habe das Script gestoppt und neu gestartet. Leider ohne Erfolg. Das letzte Protokoll ist beigefügt.
iobroker.2025-04-28.log
Mit den Warnhinweisen kann ich nichts anfangen. Wo liegt das Problem?

[ArnoD]

@tscharliealt
Hier wird es für mich fast unmöglich dir zu helfen, da ich nicht weiß wie das mit zwei E3DC von der Kommunikation abläuft.
Der Fehler Received data type ERROR: RSCP_ERR_ALREADY_IN_USE (8) - tag TAG_EMS_SET_POWER (0x1800030) deutet darauf hin, dass die Schnittstelle bereits verwendet wird und deswegen kein Zugriff auf SET_POWER möglich ist, aber mit Sicherheit sagen kann ich das nicht.

Was ich gelesen habe ist, dass ein E3DC der Master ist und das andere E3DC steuert, dann kannst du auch nur auf den Master wahrscheinlich zugreifen.
Lauter Vermutungen, die ich dir leider nicht sicher beantworten kann.

Wird beim E3DC welches als Master eingestellt ist, z.B. der Batterie SOC von beiden angezeigt, also ein mix Wert oder haben beide jeweils einen eigene SOC Wert ?
Wie wird das ganze z.B im E3DC Portal angezeigt, jedes für sich oder nur der Master?

Der Meldung nach zu urteilen ist das Q10 der Master und das S10 der Slave, welches versuchst du über das Script zu steuern?

[TscharlieAlt]

@arnod
Der Aufbau der Farm ist wie folgt:
S10 und Q10 sind die beiden Farmteilnehmer. In der Message auf dem Display der S10 heißt es: "EMS remote control aktive! by Q10". Das ist keine Fehlermeldung, sondern nur eine Statusmeldung. Wie du schon angedeutet hast, scheint hierdurch der Zugriff auf die EMS bei S10 gesperrt zu sein, da Q10 darauf zugreift. Die Software für die Farmsteuerung ist auf der Q10 installiert. Ob es einen Master im engeren Sinn gibt, entzieht sich meiner Kenntnis. Im Portal von E3DC werden aber nicht nur die Farmwerte, also die zusammengerechneten Werte beider Farmteilnehmer, sondern auch die Werte der einzelnen Farmteilnehmer angezeigt (bei S10: PV, Batterieleistung, SOC, Netz, Hausverbrauch und Wallbox; bei Q10: Batterieleistung, SOC, Hausverbrauch, Netz im Sinne von Strombezug und Stromabgabe an die S10). Für jedes einzelne Batteriemodul gibt es getrennte Werte, die ich bei den Views auch erfasst habe:

Das Script Charge-Control greift für die Steuerung von Anfang an automatisch, d.h. ohne mein Zutun auf die S10 zu. In der S10 sind die Wechselrichter eingebaut, in der Q10 nicht. Die ganze Abwicklung läuft über die S10 (PV-Eingänge, Netzanschluss, Wallbox, Notstromfunktion), die auch alleine lauffähig ist (z.B. bei Notstrombetrieb). Ich könnte mal versuchen auf die Q10 umzustellen. Wie geht das?

[ArnoD]

@tscharliealt sagte in E3DC Hauskraftwerk steuern:

Das Script Charge-Control greift für die Steuerung von Anfang an automatisch, d.h. ohne mein Zutun auf die S10 zu.

Nicht ganz richtig, das Script Charge-Control greift für die Steuerung von Anfang an auf den Adapter e3dc-rscp zu.
Ganz oben im Script kannst du die Instanz vom e3dc-rscp Adapter festlegen:

Wenn der e3dc-rscp Adapter mit der Instanz 0 auf das S10 zugreift, dann natürlich auch das Script.

[TscharlieAlt]

@arnod
Funktioniert leider nicht, es gibt eine ganze Reihe von Fehlermeldungen, aber keine Steuerung. Dann muss ich bedauerlicherweise wohl auf die automatische Steuerung einer Ladesperre verzichten?

[ArnoD]

@tscharliealt
Was sind das für Fehlermeldungen ?

[as]

@arnod ich bekomme auch seit V.19 Warnung -> warn script.js.Charge_Control15-20: Ungültige State-ID:

welche Auswirkung konnte ich noch nicht feststeller->Erfahrungen Tipps??

[ArnoD]

@as
Wie lautet der genaue Meldungstext?
Ungültige State-ID weist auf einen falschen Pfad zu einer Objekt-ID hin.
Vermute du hast bei den Parameter was vergessen einzutragen oder hast eventuell einen Schreibfehler.

[as]

@arnod das ist der genaue text
gerade nachmals getestet
da ich sonst abends dran arbeite kahm es Immer nach abfrage Solarerträge Solcast etc-> jz am tage komischerweise nicht offenbar Zusammenhang damit

[ArnoD]

@as
Normalerweise müsste nach dem Ungültige State-ID: noch die ID angegeben sein die es betrifft.

Es werden die Pfadangaben von folgenden Objekt ID geprüft:
0_userdata.0.Charge_Control.USER_ANPASSUNGEN.10_Path_LeistungHeizstab
0_userdata.0.Charge_Control.USER_ANPASSUNGEN.10_Path_WallboxLadeLeistung_1
0_userdata.0.Charge_Control.USER_ANPASSUNGEN.10_Path_WallboxLadeLeistung_2
0_userdata.0.Charge_Control.USER_ANPASSUNGEN.10_Path_LeistungLW_Pumpe

In einem von den vier stimmt die Pfadangabe nicht.

[TscharlieAlt]

@arnod
Permanente Wiederholung der gleichen Fehlermeldungen (die Logdatei selbst kann ich nicht hochladen):

Log.2025-04-30.pdf

[ArnoD]

@tscharliealt
Welche Version vom Skript Charge-Control und Adapter e3dc-rscp hast du gerade?

Die Fehlermeldung kommt wahrscheinlich von einem falschen Pfad zur Objekt-ID "PARAM_EP_RESERVE_ENERGY".
Diese wurde im Adapter e3dc-rscp bei einer Version mal geändert.

[TscharlieAlt]

@arnod

Lt. Script: Charge-Control Version 1.5.20
E3DC-rscp: Installierte Version: 1.4.2

Aktuell gibt es noch ein anderes Problem: Mehrere (ich vermute eher alle) Daten in Objekt "0_userdata_0_Charge_Control_Allgemein" werden nicht mehr aktualisiert, der letzte Zeitstempel ist vom 01.05.2025. Ein Stop und Neustart des Scripts bringt folgende Fehlermeldungen, aber keine Aktualisierung der Daten:

Was könnte die Ursache sein und wie kann ich das Problem lösen?

[ArnoD]

@tscharliealt
Kannst du mal bitte eine Screenshot von deinen Einstellungen 0_userdata.0.Charge_Control.USER_ANPASSUNGEN hier einstellen und dabei bitte die Solcast und Proplanta Einstellungen auslassen oder schwärzen.

[ArnoD]

@tscharliealt
Kannst du bitte mal die Version 1.5.21 von Github testen.
Habe da mal versucht den Fehler abzufangen, um eine LOG Ausgabe zu bekommen, welche Objekt-ID nicht stimmt.

[TscharlieAlt]

@arnod

beiliegend der Screenshot mit den Anpassungen:
User_Anpassungen.pdf

Außerdem das Protokoll nach Installation der neuen Version:
iobroker.2025-05-04.log
Den in Zeile 6 ff. genannten Pfad für die Fehlermeldungen "Die Objekt ID = 0_userdata.0.TibberSkript.." gibt es nicht. Siehe Screenshot:
0_userdata.pdf

Hilft das?

[TscharlieAlt]

@arnod

Übrigens: Nach Start der neuen Version 1.5.21 werden die Daten im Objekt "0_userdata.0.Charge_Control_Allgemein" wieder aktualisiert bisher ausgenommen "save_powerLM2_kWh" und "save_power_W" sowie "Prognoseberechnung_kWh_heute".

[ArnoD]

@tscharliealt
Bitte mal 10_LogHistoryLokal auf = false einstellen oder auch bei 10_LogHistoryPath einen Pfad angeben, wo der User iobroker auch Zugriff hat um die History Daten speichern zu können z.B. /opt/iobroker/

10_ScriptTibber = false einstellen da bei dir das Tibber Script nicht läuft, dann sollten die ganzen TibberSkript Fehler schon mal weg sein.