Daten von Enphase PV einlesen (CURL API JSON)

[Fonzo]

Wie sieht es bei dir aus? So kostenlos meine ich...

Was soll die Frage konkret? Ist Dir das auf Github genug oder soll ich jetzt alle Skripte posten, die ich jemals kostenlos anderen zur Verfügung gestellt habe?

Und der Fragesteller interessiert immer noch nicht bei falschen Aussagen.

Wenn es für den Fragesteller von Interesse sein sollte, was es offensichtlich zur Zeit nicht ist, weil er kein OAuth2 braucht, dann kann er sich ja dann in die Dokumentation des jeweiligen Herstellers einlesen. Er wird dann schon feststellen was im Detail notwendig ist und das es mit Deinen allgemeinen Aussagen nicht weit her ist. Ich habe aber ehrlich gesagt keine Lust ewig über OAuth 2 zu diskutieren, vor allem weil Du dies offensichtlich selber noch nicht mit größeren Herstellern und deren APIs benutzt hast.

[Henke]

Deine Aussage wird nicht richtig. Da gibt es nix zu diskutieren.
Was ich gemacht habe mit OAuth 2 kannst du wohl kaum beurteilen.
Es gibt in der Medizin Anwendungsbereiche bei denen man keine Api nutzt, sondern direkt über http das aufbaut. Das ist wesentlich komplexer als die Weichei Api Calls. Daher ist für mich die Grundlegende Doku interessanter als die Angaben eines Herstellers.

[Fonzo]

Deine Aussage wird nicht richtig. Da gibt es nix zu diskutieren.
Was ich gemacht habe mit OAuth 2 kannst du wohl kaum beurteilen.

Es gibt auch nichts zu diskutieren, mit jemanden der offensichtlich keine Ahnung hat, was größere Hersteller bei OAuth 2 Authentifizierung genau verlangen bzw. das dort eben eine Redirect URI hinterlegt werden muss, damit die App am Schluss auch vom Hersteller final freigegeben wird. Aus Deinen persönlichen Aussagen kann man zumindest beurteilen, dass Du Dich bisher weder mit OAuth 2 bei Amazon, Legard, Signify, Husquvarna, Spotify usw. näher auseinander gesetzt hast, geschweige denn eine funktionierende OAuth 2 Anbindung geschrieben oder anderen zur Verfügung gestellt hättest, sonst wüsstest Du wie jeder andere, der eine App mit OAuth2 bei diesen Herstellern eingereicht hat und der das schon mal genutzt hat, das Du bei jedem dieser Anbieter eine Redirect URL anzugeben hast, bei der Applikation Form des jeweiligen Herstellers. Aber jammere ruhig weiter rum, wenn es Dir persönlich Spaß macht, die Hersteller werden wegen Dir das nicht ändern. Da es da nichts zu diskutieren gibt, sondern das einfach Fakten bzw. Anforderungen der jeweiligen Hersteller sind, bin ich bei diesem Thema dann auch raus. Für wen es von Interesse sein sollte, der findet ja die entsprechenden Information beim Hersteller der jeweiligen API.

Es gibt in der Medizin Anwendungsbereiche bei denen man keine Api nutzt

Schön für Dich, die Nutzer hier nutzen aber Dinge im Bereich IOT / AV und wohl weniger Medizin, daher ist auch nur das relevant, was Hersteller in dem Bereich eben erwarten.

[Henke]

Vollkommener Schwachsinn, den du hier verzapfst. Wer keine Ahnung hat, wird ziemlich klar.

OAuth 2 braucht (immer) eine Domain oder die Cloud... Blödsinn!

Eine Dokumentation von einem Protokoll hat nichts, aber auch gar nichts mit den Zertifizierungsvorgaben bestimmter Hersteller zu tun.
OAuth 2 benötigt keine fixe IP. Punkt, kein Gegenbeweis erbracht, Referenz dazu, wie es dynamisch genutzt wird habe ich geliefert.
Geht ein Hersteller hin und legt eine Schicht darüber hat das nichts mit dem Protokoll zu tun und auch nichts mit der falschen Aussage.
Was ist so schwierig daran diesen Unterschied zu erkennen?

Die anderen Punkte:
Javascript sollte über NeoServer genutzt werden, weil das der Grund ist warum es auf der CCU vorhanden ist. Vollkommen schrag und noch nicht mal als Argument ernstzunehmen.

[Fonzo]

Eine Dokumentation von einem Protokoll hat nichts, aber auch gar nichts mit den Zertifizierungsvorgaben bestimmter Hersteller zu tun.

Jetzt schreibe ich doch wieder was, weil Du anscheinend nicht in der Lage bist, dass Protokoll mal genau zu lesen, siehe RFC 6749 Punkt 3.1.2, genau das haben die Hersteller eingebaut und das verlangen diese eben auch.
Jetzt habe ich dem aber auch nichts mehr hinzuzufügen und bin endgültig aus dem Thema hier raus.

[Henke]

Wo bitte steht da was von fester IP oder Cloud?

Der Link öffne auf 3.1.2 und ich gehe davon aus, das du den meinst.
Bei 3.2.1 käme es eher zu einer Diskussion über 2.3.

Unter 3.1.2 lese ich sogar "or when making the authorization request.", das bedeutet, wenn ich mich mit meinen token anmelde, kann ich den "client's redirection endpoint" angeben.
Dynamisch, je nach Sitzung, nicht gespeichert beim Generieren des token.
Aber so können wir gerne diskutieren. Fakten und Referenz.

[Fonzo]

Wo bitte steht da was von fester IP oder Cloud?

Nochmal zum mitdenken, wenn der Hersteller der API verlangt, das die Redirect URI fest beim Hersteller hinterlegt wird, dann ist diese nun mal fest und nicht änderbar, auch nicht dynamisch. Ich habe auch nie was von fester IP geschrieben, sondern nur von einer Domain. Von mir aus kann das auch ein Dyn DNS Anbieter sein, sollte der Hersteller so eine URL akzeptieren. Eine IP Adresse kannst Du da so oder so nicht bei so einem Hersteller hinterlegen, sondern nur eine URI.

Ein HmIP-CCU3 ist von sich aus nicht per fester URI aus dem Internet erreichbar. Wenn man das erreichen will, kann man das sicher machen, erfordert aber eben Aufwand und ein gewisses Verständnis. Vor allem machen das viele Nutzer grundsätzlich falsch, wegen fehlendem Wissen bzw. Fahrlässigkeit bei der Sicherheit. Viele, die das nur im Ansatz versuchen, wie man immer mal wieder an HmIP-CCU3 sieht, sind dann die Nutzer, die mal wieder so auf die schnelle per Portweiterleitung eine HmIP-CCU3 ins Internet stellen, was wegen Sicherheit vollkommen ausgeschlossen ist und auch mehrfach vom Hersteller davon abgeraten wird.

Der Fragesteller hat explizit nach einer einfachen Lösung gefragt, wenn man denn OAuth2 nutzten wollen würde und dann auch die HmIP-CCU3 sicher aus dem Internet erreichbar machen muss, fällt das zumindest für mich nicht mehr unter ganz einfach.

Ich weis auch nicht wo Du gelesen hast, das man den NEO Server zwingend nutzen sollte. Ich habe nur festgestellt, dass der schnellste und einfachste Weg ist mit JavaScript das JSON zu verarbeiten. Eine Möglichkeit besteht darin, das Javascript eben im NEO Server direkt auszuführen. Du bevorzugst offensichtlich einen anderen Weg, ist auch ok. Es gibt viele Wege zu einem Ziel.

Das einzige an dem man nichts ändern kann sind nun mal die Vorgaben, die die Hersteller machen, die so eine API anbieten, da muss man sich einfach nach dem richten, was der Hersteller vorgibt bzw. auch in den Bedingungen vorgibt, das man die API überhaupt benutzen darf.

Gute Nacht.

[Henke]

Und wieder am abdriften. Konzentration auf die Doku. Das scheint hier ein klassisches Problem zu sein. Passen einem die Argumente/Beweise nicht, wird wieder ein Spezialfall ala Fliege/Scheiße oder Hersteller/verlangt herangezogen.
Und bleib mal bitte sachlich. Zum mitdenken?

[Fonzo]

Konzentration auf die Doku.

Ja, dann mach das doch mal, im RFC 6749 steht

Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration).

Du meinst, nur weil dort steht, das die Redirect URI auch in der Theorie im Request übergeben werden kann, setzen das dann auch alle Hersteller, die eine OAuth 2 Authentifizierung verlangen, so um? Es steht deutlich da or during client registration, genau das erfordern eben zumindest die Hersteller, bei denen ich mich persönlich mit OAuth 2 auseinander gesetzt habe bzw. eine Anbindung über OAuth 2 für eine Hersteller API geschrieben habe, diese erfordern gleich während der Client Registrierung, dass die Redirect URI beim Hersteller fest hinterlegt wird. Dies kann man wie Du Schwachsinn finden, dass der Hersteller der API so was verlangt, was im RFC 6749 so festgelegt ist, ändern wird der Hersteller das sicher nicht wegen Dir.

Passen einem die Argumente/Beweise nicht

Nur weil mir selber was vielleicht nicht passt, werde ich selber das zumindest nicht ändern, was im Ermessen des Herstellers liegt, weder der Fakt, dass der Hersteller eQ-3 sich entschlossen hat eine HmIP-CCU3 nicht selber an das Internet anzubinden noch die Tatsache, das die Hersteller, bei denen ich bisher OAuth 2 genutzt habe, alle verlangen eine feste Redirect URI während der Client Registrierung beim Hersteller zu hinterlegen.
Ich richte mich, wenn ich so was benutzen will, einfach nach den realen Anforderungen des Herstellers der API.

Und bleib mal bitte sachlich.

Ich würde jetzt mal einfach behaupten, ich bin und bleibe sachlich, was man bei Deinem hier benutzten Tonfall und Ausdrucksweise nicht unbedingt sehen kann. Das lesen eines Protokolls setzt auch voraus, dass man dies dann auf den konkreten Fall eines Herstellers, dessen API man Zugriff erhalten will und dem benutzten Gateway, in dem Fall eine HmIP-CCU3, überträgt und versteht was dies konkret bedeutet.
Wenn ein Hersteller, der zu nutzenden API eine feste Redirect URI verlangt zu hinterlegen, der Hersteller eQ-3 des Gateways, das man nutzt aber keine feste Redirect URI für das Gateway selber einem zur Verfügung stellt, hat man eine Herausforderung, die es zu lösen gilt, wenn man die API eines solchen Herstellers benutzen will.
Wie man es dann schafft die HmIP-CCU3 per fester Redirect URI für den Hersteller der API erreichbar zu machen, ist jedem selber überlassen.

[Henke]

Hersteller,Hersteller,Hersteller
Fliege,Fliege,Fliege

Es ist irrelevant, was ein Hersteller macht oder verlangt, wenn man eine allgemeine Aussage über das Protokoll trifft.

OAuth 2 braucht (immer) eine Domain oder die Cloud... Blödsinn!

Hersteller xy verlangt bei OAuth 2 eine einmalige Registrierung. Richtig, wenn xy das so verlangt.

Ganz simpel.