fronius.0.site.P_PV geht nicht auf 0W #315
Comments
|
@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) 0x10 - 00010000 - substitute value from controller 0x11 - 01000001 - general problem by instance 0x12 - 00010010 - instance not connected 0x44 - 01000100 - device 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: 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: |
|
@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. 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 |
Hallo Sorry, das versteh ich nicht. Hängt das mit meinem "0 Wert" zusammen?
Mit der letzten 1.x Version funktionierte es immer. 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. 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… |
hört sich gut an
Finde obiges besser |
Der "Hack" erscheint mir sehr sinnvoll. Die Quality ist nur bei Störungen sinnvoll. Und keine PV Produktion ist definitiv keine Störung. Ich gehe davon aus, dass es eine Liste von Abfragen gibt. Wenn man nun eine Konfig der Art abglegt: Abfrage1 "url/rest string" usw so kann man nach jedem Aufruf der Abfrage folgendes machen: Das würde dem Erwartungsverhalten entsprechen. |
Set values of objects to 0 if the API returns 'null' for the parameter
stimmt, so hab ich das nicht gesehen. |
|
@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. |
kann man das Update schon installieren? |
|
@Negalein Wenn du von meinem Github repos nkleber78/ioBroker.fronius installieren willst dann ja. Tester sind immer willkommen :) |
werde dann berichten, wenns finster ist. :) |
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... |
|
|
um 20:56 steht |
|
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... |
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: Site" : { 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 :( { 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: 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... |
|
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_PVam 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.
The text was updated successfully, but these errors were encountered: