fronius.0.site.P_PV geht nicht auf 0W about iobroker.fronius HOT 28 CLOSED

Wenn du von meinem Github repos nkleber78/ioBroker.fronius installieren willst dann ja. Tester sind immer willkommen :)

werde dann berichten, wenns finster ist. :)

from iobroker.fronius.

Issue geschlossen. Wird beim nächsten release integriert

from iobroker.fronius.

@Negalein Da ich die Objekte nun alle dynamisch parse und erstelle weiß ich jetzt nie genau was alles vorhanden ist bzw. war.

Was hälst du von der Idee die quality dafür zu verwenden und die quality lt. folgender Liste auf 0x42 zu setzen wenn die letzte aktualisierung des Datenpoints mehr als 2*aktualisierungsinterval ist. Z.b. wenn der Adapter alle 60s die daten abholt, würde nach 2min q auf 0x42 gesetzt. Das wäre dann ein generischer Ansatz. Einfach ohne zu wissen was es genau für ein Wert ist diesen auf 0 zu setzen ist glaub ich auch nicht so gut, denn dann hast du immer wieder im den Daten/Grafiken diese drops drin die eigentlich nicht existieren, sondern es fehlt einfach der wert...

q: Qualität – Nummer mit folgenden Zuständen:

0x00 - 00000000 - good (can be undefined or null)
0x01 - 00000001 - general bad, general problem
0x02 - 00000010 - no connection problem

0x10 - 00010000 - substitute value from controller
0x20 - 00100000 - substitute initial value
0x40 - 01000000 - substitute value from device or instance
0x80 - 10000000 - substitute value from sensor

0x11 - 01000001 - general problem by instance
0x41 - 01000001 - general problem by device
0x81 - 10000001 - general problem by sensor

0x12 - 00010010 - instance not connected
0x42 - 01000010 - device not connected
0x82 - 10000010 - sensor not connected

0x44 - 01000100 - device reports error
0x84 - 10000100 - sensor reports error

from iobroker.fronius.

Ich würde - sorry wenn ich das sage - die asuschließlich dynamische Bearbeitung der Datenpunkte in Frage stellen. Damit verlierst du die Möglichkeit sinnvolle ROLE Werte beim Objekt zu setzen. Auch kannst du dann ja wohl keine sinnvollen Einheiten setzen !? Es würde m.E. sinnvoll sein sehr wohl eine Liste der bekannten Datenpunkte im Adaptercode zu verwalten.

Liefert das Gerät neue, unbekannte Werte so können diese natürlich neu mit Role value angelegt werden. Der Umstand sollte dann gelogged werden damit man das in einer späteren Version erweitern kann. Damit bekommen User so rasch wie möglich neue Werte falls die Fronius so was liefert.

Und für Datenpunkte die zwar bekannt sind aber nicht geliefert wurden braucht man auch keinen State anzulegen - das wär schon OK. Damit gibts nur jene States die das konkrete Modell auch liefert.

Und die Aussage dass du nicht weißt was vorhanden ist / war bedeutet nur, dass du es dir nicht gemerkt hast :-), das wär aber immer möglich.

ABER zur PV Frage an sich:
Liefert der Fronius wirklich keinen 0 Wert sondern einfach "nichts" mehr? Kann ich mir irgendwie nicht vorstellen.
Wie sehen denn die Kommunikationspakete / Rest Daten aus? Steht da kein PV=0, PV='', ...?
Gibts dazu was in der API Spec ?

Meiner Ansicht nach muss der Wert bei der nächsten Abfrage auf null gehen genauso wie er auf 1 oder 124 wechselt. PV Leistung sollte keine heuristisch ermittelte Größe sein mit timeouts etc. Du weißt ja welche Abfrage zu gestartet hats und was die liefern soll. Oder ist die Api so unklar definiert dass nicht klar ist was der Aufruf xyz zurück liefert?

State ist hier nur zweite Wahl - weil der User erwartet dass er zu jedem Zeitpunkt eine PV Leistung lesen kann und die Auswertung aufwändig ist. Immerhin ist eben PV Leistung mit hoher Wahrscheinlichkeit jender Datenpunkt der am meisten in Scripts, Loggern und anderen Auswertungen verwendet wird um was anzuzeigen oder zu steuern.

Und noch was:
Im debug mode würde ich auch explizit den Request und den Response der Abfragen loggen damit man klar sehen kann, was das Device liefert.

from iobroker.fronius.

@mcm1957 Wir haben schon einige datenpunkte die wir aktiv setzen. Das ist auch notwendig da nicht bei allen Werten über die API auch Units dabei sind. Diese Objekte werden nur angelegt wenn sie tatsächlich über die API geliefert werden.
Bzgl. der Werte ist es wirklich so dass die API hier keine Werte mehr liefert. Das macht es leider auch nicht gerade einfacher :(

Im Debug / silly mode die ganzen Objekte zu liefern könnte man machen, führt aber zu extrem viel Log was ggf. auch unübersichtlich werden könnte. Aber du hast recht man könnte dann prüfen was tatsächlich geliefert wird

from iobroker.fronius.

@nkleber78

Was hälst du von der Idee die quality dafür zu verwenden und die quality lt. folgender Liste auf 0x42 zu setzen wenn die letzte aktualisierung des Datenpoints mehr als 2*aktualisierungsinterval ist.

Hallo

Sorry, das versteh ich nicht. Hängt das mit meinem "0 Wert" zusammen?

@mcm1957

Liefert der Fronius wirklich keinen 0 Wert sondern einfach "nichts" mehr? Kann ich mir irgendwie nicht vorstellen.
Wie sehen denn die Kommunikationspakete / Rest Daten aus? Steht da kein PV=0, PV='', ...?

Mit der letzten 1.x Version funktionierte es immer.
Sobald nichts mehr erzeugt wurde, stand im Wert eine 0.

Ich glaube, dass es dieses Problem aber auch mal in einer früheren V 1.x gab.

from iobroker.fronius.

@Negalein ja leider liefert die API den Wert nicht mehr wenn das Gerät den PV Betrieb einstellt. Dazu wurde im alten Code in einer der letzten Versionen ein spezieller Hack implementiert der den Wert, wenn nicht über die API geliefert, auf 0 gesetzt hat. Daher die Idee mit der quality…

from iobroker.fronius.

@nkleber78 ah, ok. Jetzt verstehe ich.
Das könnte ich versuchen.

Aber wo stell ich das ein? Im Adapter gibts dort nichts.

from iobroker.fronius.

Das müsste ich implementieren. Dann könnte der consumer auf die Qualität, q beim State, filtern. Ev. Könnte die Logik ja sogar kombiniert sein: wenn wert nicht verfügbar dann wird quality gesetzt, wenn das über einen definierten Zeitraum so ist, z.b. 5x Abfrageintervall dann auf 0 setzen. Oder koppeln an den Sonnenuntergang? Ich denke wir brauchen da eine klare Idee wie das sein sollte…

from iobroker.fronius.

Ev. Könnte die Logik ja sogar kombiniert sein: wenn wert nicht verfügbar dann wird quality gesetzt, wenn das über einen definierten Zeitraum so ist

hört sich gut an

Oder koppeln an den Sonnenuntergang

Finde obiges besser

from iobroker.fronius.

@Negalein ja leider liefert die API den Wert nicht mehr wenn das Gerät den PV Betrieb einstellt. Dazu wurde im alten Code in einer der letzten Versionen ein spezieller Hack implementiert der den Wert, wenn nicht über die API geliefert, auf 0 gesetzt hat. Daher die Idee mit der quality…

Der "Hack" erscheint mir sehr sinnvoll.
Wenn ich eine Abfrage stelle wo ich erwarte dass ein bestimmter Wert kommt und die Api liefert den nicht, sollte ich dieen Wert auch auf 0 (allenfalls null) setzen.

Die Quality ist nur bei Störungen sinnvoll. Und keine PV Produktion ist definitiv keine Störung.
99% der User werden nur den Wert ansehen. Niemand hat Lust in Scripts auch die qualioty zu prüfen. Ob vis die quality nativ mit einbeziehen kann weiß ich nicht. Und was history und co da speichern / anzeigen ist die nächste Frage.

Ich gehe davon aus, dass es eine Liste von Abfragen gibt. Wenn man nun eine Konfig der Art abglegt:

Abfrage1 "url/rest string"
state 1
state Paramater (Unit, role, ...)
state 2
state Paramater (Unit, role, ...)

usw so kann man nach jedem Aufruf der Abfrage folgendes machen:
-) gibt es eine Fehlermeldung von axios od dem Devise
bei allen zugehörigen states den q auf fehlerhaft setzen
-) komtm an sich eine gültige Antwort
alle Paramater auf die Übermittelten Werte setzen
alle anderen States auf 0 oder null (da könnte man drüber diskutieren oder den Wert in der Konfig festlgen) setzen

Das würde dem Erwartungsverhalten entsprechen.
Wenn jede Nacht bie PV ein Wert ungleich null steht - egal ob mit q0 oder einem anderern Wert - garantiere ich issues alle paar Wochen.

from iobroker.fronius.

Niemand hat Lust in Scripts auch die qualioty zu prüfen. Ob vis die quality nativ mit einbeziehen kann weiß ich nicht. Und was history und co da speichern / anzeigen ist die nächste Frage.

stimmt, so hab ich das nicht gesehen.
Da hast du mMn vollkommen recht.

from iobroker.fronius.

@mcm1957 Da muss ich dir recht geben mit der Quality. Das thema hat sich insofern etwas relativiert da die betroffenen Parameter in diesem fall tatsächlich immer in der API enthalten sind aber den Wert 'null' liefern. Nun werden parameter wenn sie 'null' liefern und das objekt existiert auf 0 gesetzt. Die anderen parameter wurden bereits im issue #87 behandelt und auch in die neue Struktur entsprechend übernommen.

from iobroker.fronius.

Nun werden parameter wenn sie 'null' liefern und das objekt existiert auf 0 gesetzt

kann man das Update schon installieren?

from iobroker.fronius.

@Negalein Wenn du von meinem Github repos nkleber78/ioBroker.fronius installieren willst dann ja. Tester sind immer willkommen :)

from iobroker.fronius.

Nun werden parameter wenn sie 'null' liefern und das objekt existiert auf 0 gesetzt.

funktioniert noch nicht.

Adapter zeigt noch 40 W

WebIF zeigt 0 W

Soll ich ein Issue auch auf nkleber78/ioBroker.fronius aufmachen, oder reicht es hier?

from iobroker.fronius.

@Negalein das passt hier. Ich verstehe es nur gerade nicht was da passiert. Hast du mir bitten den debug log? Dann kann ich versuchen das zu reproduzieren...

from iobroker.fronius.

Hast du mir bitten den debug log?

fronius debug.txt

from iobroker.fronius.

um 20:56 steht
2023-06-08 20:56:20.601 - �[34mdebug�[39m: fronius.0 (1504358) API Objekt P_PV is null, object site.P_PV will be set to 0! aber er macht es nicht.
Soll ich den DP mal löschen und vom Adapter neu anlegen lassen?

from iobroker.fronius.

DP neu anlegen hilft nicht. Aber die richtige instanz des adapters zu verwenden bei asynchronen prozessen hilft... Bitte nochmals meine Github version installieren. In meiner Simulation sieht es jetzt besser aus...

from iobroker.fronius.

In meiner Simulation sieht es jetzt besser aus...

YES, 0 W 😀

from iobroker.fronius.

planned for 2.0.2

from iobroker.fronius.

Ich hab heute das neue Update installiert, bei mir bleibt das Problem leider bestehen:
P_PV laut API liefert:

Site" : {
"E_Day" : 8925,
"E_Total" : 13737369,
"E_Year" : 7773993.5,
"Meter_Location" : "grid",
"Mode" : "meter",
"P_Akku" : null,
"P_Grid" : 200.90000000000001,
"P_Load" : -200.90000000000001,
"P_PV" : null,
"rel_Autonomy" : 0,
"rel_SelfConsumption" : null

In den Objekten wird derzeit noch ein alter Wert angezeigt:

Restart des Adapters brachte keinen Erfolg. Ich update gerade aber noch meinen SYMO 10.0.3M auf den aktuellsten Stand - kann mir aber nicht vorstellen, dass das was bringen soll.

Objektbaum löschen hat auch nichts gebracht - ich habe mein Backup für Version 1.x wieder eingespielt :(

@nkleber78 reopen?

from iobroker.fronius.

@Streifi89 Bitte stell den Adapter mal auf debug mode (ohne Neustart) und lass das mal für 10min laufen. Dann kannst du mir bitte mal den log hochladen. Lt. code sollte dieser fall korrekt zu einem 0 Wert führen...

from iobroker.fronius.

Hab ich gemacht, ist jetzt blöd, weil mit der alten Adapter-Version der Wert schon auf 0 gesetzt war. Macht aber nichts, denn P_GRID wird ebenso nicht mehr mit 2.0.1 aktualisiert :(

{
"Body" : {
"Data" : {
"Inverters" : {
"1" : {
"DT" : 232,
"E_Day" : 10674,
"E_Total" : 13748039,
"E_Year" : 7784669,
"P" : 0
}
},
"Site" : {
"E_Day" : 10674,
"E_Total" : 13748039,
"E_Year" : 7784669,
"Meter_Location" : "grid",
"Mode" : "meter",
"P_Akku" : null,
"P_Grid" : 215.40000000000001,
"P_Load" : -215.40000000000001,
"P_PV" : null,
"rel_Autonomy" : 0,
"rel_SelfConsumption" : null
},
"Version" : "12"
}
},
"Head" : {
"RequestArguments" : {},
"Status" : {
"Code" : 0,
"Reason" : "",
"UserMessage" : ""
},
"Timestamp" : "2023-10-09T20:29:37+02:00"
}
}

Es kommen auch neue Werte durch den Adapter:

Response to http://192.168.0.8/solar_api/v1/GetPowerFlowRealtimeData.fcgi: {"Body":{"Data":{"Inverters":{"1":{"DT":232,"E_Day":10674,"E_Total":13748039,"E_Year":7784669,"P":0}},"Site":{"E_Day":10674,"E_Total":13748039,"E_Year":7784669,"Meter_Location":"grid","Mode":"meter","P_Akku":null,"P_Grid":212.4,"P_Load":-212.4,"P_PV":null,"rel_Autonomy":0,"rel_SelfConsumption":null},"Version":"12"}},"Head":{"RequestArguments":{},"Status":{"Code":0,"Reason":"","UserMessage":""},"Timestamp":"2023-10-09T20:32:06+02:00"}}

Aber der Datenpunkt wird nicht aktualisiert. Und da vermute ich das Hauptproblem, dass die Datenpunkte nicht aktualisiert werden.

20:22 habe ich das Update gemacht. Seitdem werden diverse Datenpunkte nicht mehr aktualisiert:

Das gilt auch für:
fronius.0.powerflow.rel_Autonomy
fronius.0.powerflow.rel_SelfConsumption
fronius.0.powerflow.P_PV
fronius.0.powerflow.P_Grid

iobroker.2023-10-09.log.txt

Heißt für mich aber, dass ich vermutlich ein anderes Problem habe :-/

from iobroker.fronius.

Hallo @Streifi89 irgendwie glaub ich dass hier der Objektbaum bei dir nicht sauber ist. Powerflow gibt es im neuen Adapter 2.0 nicht mehr. Die Daten sind in der "site" und laut log werden die Daten auch zurückgesetzt...
2023-10-09 20:24:08.312 - �[34mdebug�[39m: fronius.0 (727) API Objekt P_Akku is null, object site.P_Akku will be set to 0!
2023-10-09 20:24:08.312 - �[34mdebug�[39m: fronius.0 (727) API Objekt P_PV is null, object site.P_PV will be set to 0!
2023-10-09 20:24:08.312 - �[34mdebug�[39m: fronius.0 (727) API Objekt rel_SelfConsumption is null, object site.rel_SelfConsumption will be set to 0!
kannst du das bitte nochmals prüfen? Bitte auch mit dem aktuellen Adapter arbeiten denn 2.0.1 hatte bugs in diesem Bereich die dann in der 2.0.2 gefixt wurden

from iobroker.fronius.

Du hast recht - ARGH! Sorry, nehme dann alles zurück. Stand aber auch nicht explizit im Changelog :( Danke trotzdem!

from iobroker.fronius.

Alles klar. Bin auch froh wenn der Adapter funktioniert wie er soll :)

from iobroker.fronius.