[Adapter] cloudfreie Auslesung von Deye-Invertern

[Rene55]

@berndsolar13 Dass eine Diskrepanz zwischen der internen Berechnung und einem externen Leistungsmesser vorhanden ist, ist bekannt. Aber dass die Differenz so groß ist, ist mir auch neu.

[berndsolar13]

Der Witz ist, unterhalb von 400 Watt sind die Tasmota Steckdose und die Werte vom Wechselrichter nahezu identisch. Aber je höher der Wert, um so größer die Abweichung. Fand das etwas komisch, daher die Nachfrage.

[Rene55]

@berndsolar13 Ja sehr seltsam. Ich werd in den nächsten Tagen auch mal einen Vergleich machen zwischen interner und externer Messung. Mal sehen, was ich dann zu sehen bekommen.

[dontobi]

@rene55 meine Anlage ist gerade einmal 10 Tage alt. Meinst du ich sollte da einen anderen Wert bei Rule nutzen? Wenn ja, welchen schlägst du vor?

[Rene55]

@dontobi Kannst ja erstmal laufen lassen, solange der Wert z.B für Total_PV_Power plausibel ist. Grundsätzlich müsste man für diese Werte 32-bit nehmen, die dann mit der rule = 3 abgedeckt werden. Und genau hier kann es sein, dass da noch ein Fehler drin steckt. Da bräuchte ich dann eine Rückmeldung. (Ich werde so einen hohen Wert erst in ein paar Jahren bekommen ).

[JB_Sullivan]

@rene55 Nàbend zusammen - ich habe heute von 0.0.7 auf 0.0.9 geupdatet. Im Change Log zu den Versionen waren keine breaking Changes vermerkt, aber der Adapter bleibt seit dem Rot.

.... jetzt sowieso, weil es dunkel ist, aber auch schon heute Nachmittag wo schöner Sonnenschein herrschte.

Habe ich irgend etwas verpasst, auf was ich bei dem Versionssprung hätte achten müssen?

[Thomas Braun]

@jb_sullivan sagte in [neuer Adapter] cloudfreie Auslesung von Deye-Invertern:

aber der Adapter bleibt seit dem Rot.

Und im Log steht dazu was?

[JB_Sullivan]

@thomas-braun Nichts, womit ICH etwas anfangen könnte.

Das hier ist die einzige Auffälligkeit (habe die Seriennummer, durch Wort Seriennummer ersetzt). In den Instanzeinstellungen, wo die Seriennummer eingetragen ist, ist hinter der Nummer aber KEIN "."

2023-08-24 08:42:36.721  - error: deyeidc.0 (15948) The id "deyeidc.0.Seriennummer." is invalid. Ids are not allowed to end in "."

2023-08-24 08:42:36.715  - error: deyeidc.0 (15948) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2023-08-24 08:42:36.716  - error: deyeidc.0 (15948) unhandled promise rejection: The id "deyeidc.0.Seriennummer." is invalid. Ids are not allowed to end in "."
2023-08-24 08:42:36.720  - error: deyeidc.0 (15948) Error: The id "deyeidc.0.Seriennnummer." is invalid. Ids are not allowed to end in "."
    at Validator.validateId (C:\ioBroker\GLT\node_modules\@iobroker\js-controller-adapter\build\lib\adapter\validator.js:147:23)
    at Deyeidc._getForeignState (C:\ioBroker\GLT\node_modules\@iobroker\js-controller-adapter\build\lib\adapter\adapter.js:6354:25)
    at Deyeidc.getForeignState (C:\ioBroker\GLT\node_modules\@iobroker\js-controller-adapter\build\lib\adapter\adapter.js:6340:21)
    at Deyeidc.getState (C:\ioBroker\GLT\node_modules\@iobroker\js-controller-adapter\build\lib\adapter\adapter.js:6312:21)
    at C:\ioBroker\GLT\node_modules\@iobroker\js-controller-common\build\lib\common\tools.js:2043:16
    at new Promise (<anonymous>)
    at Deyeidc.getStateAsync (C:\ioBroker\GLT\node_modules\@iobroker\js-controller-common\build\lib\common\tools.js:2042:16)
    at Deyeidc.readComputeAndWatch (C:\ioBroker\GLT\node_modules\iobroker.deyeidc\main.js:325:31)
    at Deyeidc.onData (C:\ioBroker\GLT\node_modules\iobroker.deyeidc\main.js:170:16)
2023-08-24 08:42:36.721  - error: deyeidc.0 (15948) The id "deyeidc.0.Seriennummer." is invalid. Ids are not allowed to end in "."
2023-08-24 08:42:36.728  - info: deyeidc.0 (15948) terminating
2023-08-24 08:42:36.730  - warn: deyeidc.0 (15948) Terminated (UNCAUGHT_EXCEPTION): Without reason
2023-08-24 08:42:37.233  - info: deyeidc.0 (15948) terminating
2023-08-24 08:42:37.786  - error: host.GLT instance system.adapter.deyeidc.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2023-08-24 08:42:37.787  - info: host.GLT Restart adapter system.adapter.deyeidc.0 because enabled

[Rene55]

@jb_sullivan sagte in [neuer Adapter] cloudfreie Auslesung von Deye-Invertern:

The id "deyeidc.0.Seriennummer." is invalid.

Ist das so in im ersten Tab eingetragen? Die Meldung ist doch sicherlich selbsterklärend.

[JB_Sullivan]

@rene55 Ja, die Seriennummer ist im ersten Tab korrekt und ohne Punkt eingetragen. Mittlerweile habe ich festgestellt, das im dritten Tab die Felder für die Rechenformeln leer sind (waren aber vorher OK). Ich habe da jetzt wieder die Formeln eingetragen und nun funktioniert der Adpater in der 0.0.9er Version auch wieder.

[Rene55]

@jb_sullivan Ja schön, freut mich. Irgendwie irritierend. Die Eingaben im dritten Tab haben aber nichts mit der Seriennummer im ersten Tab zu tun.
Und ja, es gab eine kleine Änderung bei den berechneten Feldern. Die bestanden vor Version 0.0.x (7?) aus zwei Feldern - jetzt ist es nur noch eins mit Rechenvorschrift. Ich hoffe, es gab nicht zu viel Handarbeit.

[dontobi]

Ich habe mir die Konfiguration meines Wechselrichters nochmals angesehen. Die Rules habe ich angepasst und dabei auch etwas festgestellt.

Wenn man bei den Temperaturen die Rule auf 1, 2, 3 oder 4 stellt, erhalte ich immer Werte mit 100°C zu viel zurück. Stellt man die Rule auf 6, kommen die Werte korrekt an. Somit entfällt die Berechnung.

Anbei meine aktuelle Konfiguration:
Deye_Sun10K-SG04LP3-EU.json

[Rene55]

@dontobi Ja da hast du recht, hätte ich beim Vorschlag -100 auch dran denken können. Diesen Temperaturoffset haben die kleinen WR auch, daher gibt es die Rule 6. Ich hab das jetzt auch mal (in der Adapter-ReadMe) Dokumentiert.

[MPF]

@t15j sagte in [neuer Adapter] cloudfreie Auslesung von Deye-Invertern:

@rene55
Moin, herzlichen Dank für diesen Adapter - ich bin absoluter ioBroker Neuling und solch ein Adapter hilft mir sehr!

Ich habe zwei Deye WR (600 und 80g), nach dem ganzen hin und her habe ich gestern die Namensgebung der Spulen für mich angepasst und dann alle erzeugten Objekte (ausgelesenen Werte) einmal gelöscht (über den Reiter Objekte) und hoffte, dass diese dann neu erstellt werden - wurden sie auch, allerdings nur bei einem der beiden WR (der mit ID 0), bei ID 1 wurden die Werte nicht neu angelegt.
Also dachte ich mit, dass sie erst angelegt werden, wenn Änderungen auftreten und habe alle Spulen einmal mit Register 109 füllen lassen - hat auch geklappt, allerdings habe ich jetzt dort nach rd. 12 Stunden immer noch den damaligen Wert stehen:

(Bei den nicht markierten Werten bin ich mir unsicher, ob diese aktuell sind)

Die Spulen sind natürlich wieder auf ihren alten Werten:

Im Log sehe ich aktuell folgenden Fehler:

Vermutlich hilft es, wenn ich den Adapter lösche und neu anlege - nur wollte ich das Verhalten hier einmal kurz schildern, evtl. ist es ja auch ein Logik-Fehler in der Anwendung.

Vielleicht gibt es ja aber auch eine andere Lösung?

Danke
Thomas

PS: gibt es eine Möglichkeit die Konfiguration eines Adapters auf den anderen einfach zu übertragen bzw. gibt es eine Datei in der ich dass machen könnte, gestern per SSH habe ich nur eine zentrale Datei mit allen Objekten gefunden, darf ich da einfach etwas passendes ergänzen?

Hi,

ich habe auch jeden Tag mehrfach diese Warn-Meldung. Benutzte die Version 0.11.
Adapter gelöscht und neu installiert, brachte auch kein Erfolg.

[Gaunt]

@mpf said in [neuer Adapter] cloudfreie Auslesung von Deye-Invertern:

ich habe auch jeden Tag mehrfach diese Warn-Meldung. Benutzte die Version 0.11.
Adapter gelöscht und neu installiert, brachte auch kein Erfolg.

Bin seit heute auch dabei um von der Cloud weg zu kommen und bekomme ebenfalls diese Fehlermeldung.

[Rene55]

@mpf Ich weiß jetzt aus dem Zusammenhang nicht genau, was deine Frage ist.

Ich vermute mal, es geht um die Warnmeldung:
@Gaunt Diese Meldung wird generiert, wenn der Inverter keine plausiblen Daten liefert. Wie die Daten validiert werden weiß ich nicht. Für uns Benutzer heist das nur, dass der Adapter die Daten nicht übernimmt, damit kein Mist in den Datenpunkten landet.
Nach welchen Kriterien das erfolgt und wie oft diese Meldung erzeugt wird habe ich noch nicht sondieren können.

[MPF]

@rene55 ja, es geht um die Warnmeldungen.
Diese hatte ich aber erst mit der Adapter-Version 0.0.9. Vorher lief er ohne Meldungen.

[Rene55]

@mpf Nix dran zu machen, einfach laufenlassen und ignorieren. (Bis ich weiß, woran es liegt).

[Gaunt]

Gibt manchmal Tag da wird in der SolarmanApp eine erzeugte Leistung von 0W angezeigt. Bisher dachte ich an Serverwartung und daher keine Daten (daher auch raus aus der Cloud).
An genau so einem Tag kam diese Fehlermeldung "Data corrupt", liegt daher vermutlich nicht an dem Adapter sondern an dem Logger/Inverter.
Die Datenpunkte von diesem Adapter lieferten mir Werte mit Ausnahme von Strom der Paneele. Daher konnte scheinbar alles andere auch nicht mehr berechnet werden = 0W und "Data corrupt"

@rene55 said in [neuer Adapter] cloudfreie Auslesung von Deye-Invertern:

@Gaunt Diese Meldung wird generiert, wenn der Inverter keine plausiblen Daten liefert. Wie die Daten validiert werden weiß ich nicht. Für uns Benutzer heist das nur, dass der Adapter die Daten nicht übernimmt, damit kein Mist in den Datenpunkten landet.
Nach welchen Kriterien das erfolgt und wie oft diese Meldung erzeugt wird habe ich noch nicht sondieren können.

[Zeta1990]

Hallo,

Bei läuft der Adapter erstmal super.

Aber ich habe gemerkt das mein Log im Hintergrund zu gepflastert wird.

Gibt es da eine Lösung bereits für . Im Forum bis jetzt noch nicht gefunden.

Mit freundlichen Grüßen Zeta