Modul: SolarEdge API Abruf

Begonnen von felixm, 03 August 2018, 18:49:41

Vorheriges Thema - Nächstes Thema

satprofi

Klappt bei mir leider nicht

STATE      ready


READINGS:
     2019-01-04 10:07:00   actionQueue     0 entries in the Queue
     2019-01-04 13:24:10   aggregates-Consumption-cumToday 15100
     2019-01-04 13:24:10   aggregates-Consumption-recent15min 157
     2019-01-04 13:24:10   aggregates-FeedIn-cumToday 0
     2019-01-04 13:24:10   aggregates-Production-cumToday 7547.98863787
     2019-01-04 13:24:10   aggregates-Production-recent15min 90.41368
     2019-01-04 13:24:10   aggregates-timeUnit QUARTER_OF_AN_HOUR
     2019-01-04 13:24:10   aggregates-unit Wh
     2019-01-04 12:42:40   lastRequestError connect to https://monitoringapi.solaredge.com:443 timed out
     2019-01-04 13:24:09   state           ready
     2019-01-04 13:24:09   status-grid_power
     2019-01-04 13:24:09   status-grid_status Error Reading Response
     2019-01-04 13:24:09   status-load_status Error Reading Response
     2019-01-04 13:24:09   status-pv_status Error Reading Response
     2019-01-04 13:24:09   status-storage_status No storage found
     2019-01-04 13:24:09   status-unit     Error Reading Response
     2019-01-04 13:24:09   status-updateRefreshRate Error Reading Response
   actionQueue:
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

leupin

#16
Nachdem bei mir die SolarEdgeAPI immer nach rund 8 Stunden zu einem Error 429 geführt hat (To many requests), obwohl das Intervall so gesetzt war, dass dies eigentlich nicht der Fall sein sollte,
habe ich jetzt die Abfrage mal wie folgt testweise auf HTTPMOD umgestellt:
define SolarEdge_KG2 httpmod none 0     (Abfrage nur mit einem Get-Request, nicht über ein vordefiniertes Intervall)

mit folgenden Attributen:

enableControlSet 1
get01Name SE_energies
get01URL https://monitoringapi.solaredge.com/site/{Meine Site-ID}/overview.json?api_key={Mein API Key}
reading01Name Energie_Total
reading01Regex "lifeTimeData":{"energy":([\d\.]+)
reading02Name Energie_LastYear
reading02Regex "lastYearData":{"energy":([\d\.]+)
reading03Name Energie_LastMonth
reading03Regex "lastMonthData":{"energy":([\d\.]+)
reading04Name Energie_LastDay
reading04Regex "lastDayData":{"energy":([\d\.]+)
reading05Name Current_Power
reading05Regex "currentPower":{"power":([\d\.]+)
stateFormat active
userattr get01Name get01URL reading01Name reading01Regex reading02Name reading02Regex reading03Name reading03Regex reading04Name reading04Regex reading05Name reading05Regex


Die Daten frage ich alle 7,5 Minuten über eine AT-Definition mit "get SolarEdge_KG2 SE_energies " ab.
Bis jetzt scheint es zu funktionieren, mal sehen, ob nach 8 Stunden wieder der Error 429 auftritt - dann müsste wohl etwas auf der SolarEdge-Monitoring Plattform faul sein, da ja mit 8 Abfragen pro Stunde entsprechend 192 Abfragen pro Tag die 300er-Limite absolut eingehalten wäre...

CoolTux

Hättest Du wie es üblich ist hier im Forum für den Code die Codetage verwendet, müsstest Du keine Lücken lassen wegen Smiley Gefahr  ;)
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

leupin

#18
Werde es mir für das nächste Mal merken und habe es oben angepasst ;) 8)

leupin

Bis jetzt funktioniert die Abfrage über httpmod bei mir problemlos (allerdings jetzt erst seit einem Tag) - stellt sich für mich die Frage, ob eine Abfrage mit der SolarEdgeAPI allenfalls vom Monitoring-Portal als mehrere Abfragen gezählt wird (Energie-Werte&Statuswerte - dafür gibt es nach meinem Dafürhalten in der API-Referenz keinen einzelnen Abfragebefehl oder dann habe ich ihn nicht gefunden...)
Mal schauen, ob es über httpmod weiter klappt...

felixm

#20
Hallo,

sorry das sich mich so lange nicht gemeldet habe, aber leider hat mein Broterwerb in den letzten Wochen sehr viel meiner Kapazität gefordert. Soviel dass bei mir hier auch nicht mehr alles so läuft wie geplant.
Das mit dem Fehler alle 8 Stunden kann sein, da in der Tat bei jeder Abfrage 2 einzelne Abfragen gestartet werden müssen. In der Testphase, als ich das Modul geschrieben habe , hat das allerdings noch zu keinen Fehlern geführt. Ich finde die Restriktionen der API da auch etwas eng, auf die Art und Wiese lässt sich ja nichts sauber loggen oder "Smart" steuern.
Wäre es eine Idee die Abfragen zu entkoppeln und die Summen seltener abzurufen als den Status?
Sonst bleibt uns wohl wirklich nur ModBus, der aber leider fürchte ich etwas komplizierter zu konfigureiren ist.

Gruß
Felix

//Nachtrag: bei mir läuft das Modul weiterhin auf Intevral auto und damit tagsüber alle 300sec, nachts alle 1200sec. Ich hatte damit in den letzten Monaten keinen Error 429 in den Logs finden können.

pizmus

Hallo Felix,

ich habe Dein Modul 70_SolarEdgeAPI aus github geladen. Es hat für mich im Prinzip auf Anhieb funktioniert. Danke für Deine Arbeit!
Ich habe ein paar Änderungen in meiner Kopie des Moduls gemacht:

1) Mein Inverter unterstützt das "status" API nicht. Der Inverter liefert in diesem Fall wie im API Handbuch beschrieben eine leere Datenstruktur zurück. Ich habe das Modul so geändert, dass es diesen Fall erkennt, eine Nachricht ins Logfile schreibt, keine Readings erzeugt, und zukünftige Abfragen des APIs unterdrückt.

2) Die "aggregates" Anfrage liefert die Energiemenge für jeden 15-Minuten-Zeitraum des Tages. Du verwendest das für das "cumToday" Reading. Den letzten Eintrag (für den gerade laufenden 15-Minuten-Zeitraum) verwendest Du für das "recent15min" Reading. Zusätzlich verwende ich den vorletzten Eintrag (für den letzten bereits beendeten 15-Minuten-Zeitraum) für das neue Reading "last15min". Dieses Reading wird für jeden 15-Minuten-Zeitraum einmal erzeugt.

3) Ich verwende die "auto"-Einstellung für das Intervall, um die Abfragen in der Nacht zu reduzieren. Allerdings hat meine SolarEdge Anlage Ost-Ausrichtung, so dass es morgens früher los geht. Ich habe den Startzeitpunkt für das engere Intervall nach vorne verlegt.

Pflegst Du das Modul noch weiter? Bist Du an den Änderungen interessiert?

Viele Grüße,
pizmus

kingmathers

Ich verwende das Modul nun auch seit einiger Zeit ohne Probleme, vielen Dank an dieser Stelle!

Ich hätte jedoch auch ein paar Vorschläge für Veränderungen, z.B. würde ich statt der cumToday Readings lieber einen fortlaufenden Zähler (lifetime) für Purchased etc. haben.

Arbeitest du an dem Modul noch weiter?
Raspberry Pi B+, FS20, 1-Wire, HM
FHEM Home Control (App für Windows 10): https://forum.fhem.de/index.php/topic,49891.0.html
FHEM Arduino Library: https://forum.fhem.de/index.php/topic,94093.0.html

weijers


Hallo,

Ich bin ein Mitglied von Solar Edge toegevoegd und werkt gedeeltelijk. Es ist al Helemaal Top. Het geen wat niet werkt is het volgende:

-status-grid_power
-status-grid_status
-status-load_status
-status-pv_status
-status-storage_status
-Status-Einheit
-status-updateRefreshRate

de melding die fhem terug geeft op bovenstaande is:
Fehler beim Lesen der Antwort

de dag opbrengst werkt wel.

Können Sie mir helfen?  ::)

Super bedankt alvast

felixm

Ja ich bin an den Änderungen interessiert und werde mich bemühen das Modul weiter zu pflegen. Ich hatte diese Nachrichten irgendwie übersehen.
Kannst du mir deinen Patch zur Verfügung stellen?

Lifetime Zähler sollte ja kein Problem sein,da müsste ich mal in die API schauen was die hergibt, dann wießrd das gelegntlih synchronisiert und ansonsten mit cumToday summiert.


Liebe Grüße

pizmus

Hallo Felix,
hier ist der Source Code.
Es könnte sein, dass damit das Problem von weijers gelöst ist, falls er nämlich einen Inverter hat, der das Status API nicht unterstützt.
Aus der Fehlerbeschreibung kann ich das aber nicht sicher herauslesen.
Gruß,
pizmus

felixm

Moin,
ich hab deine Änderungen erstmal gesichtet. Ist ja nichts großes. Ich werde das bei mir nochmal in Ruhe testen und in der Zeit die LifeTime Readings integrieren. Was meint ihr wie oft mssen die LifeTime Readings mit dem Server abgeglichen werden, In der Zwischenzeit kann man ja ohne Probleme intern hochzählen?

Gruß

pizmus

Danke für Deine Arbeit. Zu den Lifetime Readings habe ich keine Meinung. Gruß, pizmus

pizmus

Hallo felixm,

mir ist aufgefallen, dass das vorgeschlagene neue Reading aggregates-Production-last15min immer mal wieder Ausreißer hat. Heute war es wieder so weit, und ich habe mal die Rohdaten, die SolarEdge liefert, aufgezeichnet. Das Ergebnis: Die Antwort auf die "energyDetails" Query sieht nicht immer so aus, wie ich das erwartet hatte. Es gibt am Ende der Liste immer mal wieder einen Eintrag, der zwar einen Zeitstempel aber keinen Messwert hat. In einem Fall hatten sogar die letzten zwei Elemente keinen Messwert. Ich habe auch eine Situation am frühen Morgen gefunden, in der der Wert für einen 15-Minuten-Zeitraum nachträglich geändert bzw. nachgeliefert wurde!
Hier ein paar Beispiele:


05:57:10
{"date":"2019-06-02 04:45:00"},
{"date":"2019-06-02 05:00:00"},
{"date":"2019-06-02 05:15:00"},
{"date":"2019-06-02 05:30:00"},
{"date":"2019-06-02 05:45:00"}]}]}}

06:02:11
{"date":"2019-06-02 04:45:00"},
{"date":"2019-06-02 05:00:00","value":0.0},
{"date":"2019-06-02 05:15:00","value":0.0},
{"date":"2019-06-02 05:30:00","value":4.0},   <- geänderter Wert
{"date":"2019-06-02 05:45:00"},
{"date":"2019-06-02 06:00:00"}]}]}}              <- zwei aufeinander folgende Einträge ohne Wert

06:47:10
{"date":"2019-06-02 04:45:00"},
{"date":"2019-06-02 05:00:00","value":0.0},
{"date":"2019-06-02 05:15:00","value":0.0},
{"date":"2019-06-02 05:30:00","value":14.0},
{"date":"2019-06-02 05:45:00","value":42.0},
{"date":"2019-06-02 06:00:00","value":47.0},
{"date":"2019-06-02 06:15:00","value":110.0},
{"date":"2019-06-02 06:30:00","value":96.0},
{"date":"2019-06-02 06:45:00"}]}]}}


Dieses API ist nicht zuverlaessig, bzw. es ist nicht für die Anwendung geeignet, die ich im Kopf hatte. So wie Du es für das cumToday Reading verwendet hast wird das schon funktionieren, aber eine Aussage über die gerade vergangene Viertelstunde ist nicht sinnvoll. Ich rate Dir, das last15min Reading zu verwerfen. Ich glaube der Aufwand für Workarounds und die zusätzliche Komplexität sind nicht angemessen im Vergleich zum Nutzen.

Ich probiere jetzt den "currentPower" Wert aus dem "overview" API aus, denn das "currentPowerFlow" API wird ja von meinem Inverter nicht unterstuetzt. Das sieht bislang ganz brauchbar aus.

Viele Grüße,
pizmus



cocojambo

Hallo felixm,

habe dein Modul jetzt schon mal ein paar Tage im Einsatz. Das ist eine richtig gute Idee, bleibt aber leider sporadisch hängen. Heute ca.um 14.37 Uhr war wieder Schluß. Am Intervall kanns nicht liegen. Nach Neuladen des Moduls läuft es wieder, aber auch nicht dauerhaft. Eine Error Meldung gibs nicht. Kann man da was machen, um es zuverlässig zu verwenden. Vielleicht kann man ja auch die 15min Abfragen entfernen, wie pizmus auch schon meinte. Ich glaube da kann man nicht viel mit anfangen.
Alle Abfragen in der Hinsicht lassen sich mit dem statistic Modul gut lösen.

Würde mich freuen, wenn du es ans laufen kriegst. Kann man echt gut gebrauchen. Ein "list SolarEdgeAPI" habe ich mal angehangen, nachdem das Modul wieder hing.

Gruß aus Köln
Norbert


Internals:
   APIKEY     ###########################
   DEF        ######################### ###### auto
   FUUID      5d5bcf95-f33f-6f9b-0bd3-fbeacbb1b06299e1
   INTERVAL   auto
   NAME       SolarEdgeAPI
   NOTIFYDEV  global
   NR         1427
   NTFY_ORDER 50-SolarEdgeAPI
   PORT       80
   SITEID     771795
   STATE      ready
   TYPE       SolarEdgeAPI
   VERSION    0.0.1
   READINGS:
     2019-09-06 14:37:48   Bezug_heute     371
     2019-09-06 14:37:48   Einspeisung_heute 20730
     2019-09-06 14:37:48   Produktion_heute 26355
     2019-09-06 14:37:48   Verbrauch_heute 13309
     2019-09-03 14:20:29   actionQueue     0 entries in the Queue
     2019-09-06 14:37:48   aggregates-Consumption-cumToday 13309
     2019-09-06 12:48:06   aggregates-Consumption-last15min 277
     2019-09-06 14:37:48   aggregates-Consumption-recent15min 242
     2019-09-06 14:37:48   aggregates-FeedIn-cumToday 20730
     2019-09-06 14:32:48   aggregates-FeedIn-last15min 1490
     2019-09-06 14:37:48   aggregates-FeedIn-recent15min 910
     2019-09-06 14:37:48   aggregates-Production-cumToday 26355
     2019-09-06 10:33:14   aggregates-Production-last15min 327
     2019-09-06 14:37:48   aggregates-Production-recent15min 1016
     2019-09-06 14:37:48   aggregates-Purchased-cumToday 371
     2019-09-06 14:17:48   aggregates-Purchased-last15min 0
     2019-09-06 14:37:48   aggregates-Purchased-recent15min 0
     2019-09-06 14:37:48   aggregates-SelfConsumption-cumToday 7530
     2019-09-06 13:48:07   aggregates-SelfConsumption-last15min 379
     2019-09-06 14:37:48   aggregates-SelfConsumption-recent15min 242
     2019-09-06 14:37:48   aggregates-timeUnit QUARTER_OF_AN_HOUR
     2019-09-06 14:37:48   aggregates-unit Wh
     2019-09-05 23:49:10   lastRequestError 403
     2019-09-06 14:37:48   state           ready
     2019-09-06 14:37:48   status-grid_power -4.99
     2019-09-06 14:37:48   status-grid_status Active
     2019-09-06 14:37:48   status-load_power 0.74
     2019-09-06 14:37:48   status-load_status Active
     2019-09-06 14:37:48   status-pv_power 5.73
     2019-09-06 14:37:48   status-pv_status Active
     2019-09-06 14:37:48   status-storage_critical 0
     2019-09-06 14:37:48   status-storage_level 100
     2019-09-06 14:37:48   status-storage_power 0
     2019-09-06 14:37:48   status-storage_status Idle
     2019-09-06 14:37:48   status-unit     kW
     2019-09-06 14:37:48   status-updateRefreshRate 3
   actionQueue:
Attributes:
   group      Systemkontrolle
   room       System
   userReadings Verbrauch_heute {ReadingsVal("SolarEdgeAPI","aggregates-Consumption-cumToday","")},Einspeisung_heute {ReadingsVal("SolarEdgeAPI","aggregates-FeedIn-cumToday","")},Produktion_heute {ReadingsVal("SolarEdgeAPI","aggregates-Production-cumToday","")},Bezug_heute {ReadingsVal("SolarEdgeAPI","aggregates-Purchased-cumToday","")}



FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000