Closed Negalein closed 1 year ago
@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
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.
@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
@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.
@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…
@nkleber78 ah, ok. Jetzt verstehe ich. Das könnte ich versuchen.
Aber wo stell ich das ein? Im Adapter gibts dort nichts.
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…
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
@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.
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.
@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.
Nun werden parameter wenn sie 'null' liefern und das objekt existiert auf 0 gesetzt
kann man das Update schon installieren?
@Negalein Wenn du von meinem Github repos nkleber78/ioBroker.fronius installieren willst dann ja. Tester sind immer willkommen :)
Wenn du von meinem Github repos nkleber78/ioBroker.fronius installieren willst dann ja. Tester sind immer willkommen :)
werde dann berichten, wenns finster ist. :)
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?
@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...
Hast du mir bitten den debug log?
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?
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...
In meiner Simulation sieht es jetzt besser aus...
YES, 0 W 😀
Issue geschlossen. Wird beim nächsten release integriert
planned for 2.0.2
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?
@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...
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
Heißt für mich aber, dass ich vermutlich ein anderes Problem habe :-/
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
Du hast recht - ARGH! Sorry, nehme dann alles zurück. Stand aber auch nicht explizit im Changelog :( Danke trotzdem!
Alles klar. Bin auch froh wenn der Adapter funktioniert wie er soll :)
mir ist soeben aufgefallen, dass
fronius.0.site.P_PV
am Abend nicht auf 0 geht. Steht bei mir gerade um 23 Uhr auf 38 W. Der Wert ist seit 20:59 stehen geblieben.Vers.: 2.0.1
Mit Vers. 1.x funktionierte es.
Im WebIF wird aktuell auch keine Erzeugung angezeigt.