Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

Begonnen von ch.eick, 07 Oktober 2020, 16:09:12

Vorheriges Thema - Nächstes Thema

MichaelO

Moin Christian

Zitat von: ch.eick am 02 Januar 2023, 20:44:08
Es sind Watt, Wh werden es erst durch die Zeit :-)

Da muss ich leider klugschei...  8) Wenn dieser Wert die noch verfügbare Ladung im Speicher ist (und somit der Anteil an der Gesamtkapazität gemäß der ebenfalls angezeigten Prozentangabe SOC), dann sind es Wh. Die Angabe W bezieht sich auf die "Leistungsgeschwindigkeit", also die Leistungsabgabe zu einem bestimmten Zeitpunkt. Die Angabe Wh hingegen bezieht sich auf eine Energiemenge, also die Leistung, die für einen bestimmten Zeitraum zur Verfügung steht.

Zitat von: ch.eick am 02 Januar 2023, 20:44:08
Wenn man es direkt im RAW mit einträgt, ist es "setstate", ansonsten kann man es bei einem Absturz von FHEM auch mit einen setreading wieder mit den korrekten Werten aus der DbLog setzen. Dazu gab es im Thread auch schon mal eine Anleitung.

Ok, das wusste ich nicht. Bei mir waren die Readings garnicht vorhanden, ich habe sie dann erstmal manuell erzeugt und warte auf das erste Update der Statistiken, um zu sehen, ob dann alles passt.

Zitat von: ch.eick am 02 Januar 2023, 20:44:08
Wenn Du da die Kenntnisse hast könntest Du mir gerne mal eine Testversion schicken ;-)
Ich arbeite bereits mit jemandem aus dem Forum an einer KI Implementierung, die dann selber lernen sollte.

Sobald die Konfiguration grundsätzlich läuft und vernünftige Werte liefert, kann ich da gerne mal etwas spielen. Ich stehe zwar mit Perl mächtig auf dem Kriegsfuß, aber da muss man dann durch   ::) KI in fhem halte ich für gewagt und wäre da sehr gespannt, wie das Implementiert werden soll. Wäre sicher eine gute Sache.

ch.eick

Zitat von: MichaelO am 02 Januar 2023, 21:45:38
Da muss ich leider klugschei...  8) Wenn dieser Wert die noch verfügbare Ladung im Speicher ist (und somit der Anteil an der Gesamtkapazität gemäß der ebenfalls angezeigten Prozentangabe SOC), dann sind es Wh. Die Angabe W bezieht sich auf die "Leistungsgeschwindigkeit", also die Leistungsabgabe zu einem bestimmten Zeitpunkt. Die Angabe Wh hingegen bezieht sich auf eine Energiemenge, also die Leistung, die für einen bestimmten Zeitraum zur Verfügung steht.
Klugschei... akzepiert, ich schau es mir morgen mal an.

Zitat
Ok, das wusste ich nicht. Bei mir waren die Readings garnicht vorhanden, ich habe sie dann erstmal manuell erzeugt und warte auf das erste Update der Statistiken, um zu sehen, ob dann alles passt.
Das würde ich nicht machen, da dadurch ja dann auch falsch berechnete Werte in die DB geschrieben werden, die die Monks unter uns dann mühsam wieder korrigieren möchten.
Also besser den richtigen init Wert aus der DB suchen und eintragen, wir haben ja gerade erst Monatsanfang und Jahresanfang. Das zieht sich ansonsten ziemlich lange durch.
Such nochmal hier im Thread, oder es könnte auch schon im Wiki stehen, da bin ich mir aber nicht sicher.

Zitat
Sobald die Konfiguration grundsätzlich läuft und vernünftige Werte liefert, kann ich da gerne mal etwas spielen. Ich stehe zwar mit Perl mächtig auf dem Kriegsfuß, aber da muss man dann durch   ::) KI in fhem halte ich für gewagt und wäre da sehr gespannt, wie das Implementiert werden soll. Wäre sicher eine gute Sache.
Das mit der KI wurde auch schon mal im Thread von Peter angesprochen, da hatte ich nur viele andere Dinge im Kopf. Peter hat es auf einem anderen FHEM externen Rechner laufen.
Ich habe schon einige vorarbeiten für FHEM erledigt, aber die "Inteligenz" würde dann in einem Phyton Aufruf erledigt werden. So richtig habe ich es auch noch nicht verstanden :-)
Bei der Verarbeitung wird RandomForestRegressor() verwendet, was wohl gewichtete änliche Situationen vergleicht und daraus die zuerwartende Prognose Leistung ableitet. Als Quelle dient die Datenbank mit den geloggten DWD Daten und den Leistungswerten des WR zu diesem Zeitpunkt.


Es ist schön, wenn mal wieder jemand so genau in das ganze Konstrukt schaut, dadurch wird es für uns alle noch besser.

Vielen Dank
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Zitat von: MichaelO am 02 Januar 2023, 17:47:45
Nachdem ich nun langsam fast alles zum laufen bekommen habe
   2 x Plenticore mit 1x BYD
   Integration eines Fronius steht noch aus
Achtung, bei dem 3. WR wird es eventuell etwas schwieriger.
Ich habe dazu bereits mal etwas vorgearbeitet. Die Werte des Kostal Schwarms werden alle nicht korrekt sein, da Kostal nicht den dritten Wechselrichter im Schwarm kennt.
Hierzu habe ich einen Fake Wechselrichter integriert, der dem KSEM die fehlende Leistung unterjubelt. Dazu steht noch nichts im Wiki, aber hier im Thread.
Auch die ganzen Statistiken müssen dann in dem Fake WR nachgebildet werden, damit sie dann anschließend mit verechnet werden können.
An dem Projekt hätte ich auch sehr großes Interesse, was wir aber besser per PN/Mail bearbeiten sollten. Die Essence kommt dann wieder ins Forum und ins Wiki.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

MichaelO

Zitat von: ch.eick am 02 Januar 2023, 23:46:48
Achtung, bei dem 3. WR wird es eventuell etwas schwieriger.
...
An dem Projekt hätte ich auch sehr großes Interesse, was wir aber besser per PN/Mail bearbeiten sollten. Die Essence kommt dann wieder ins Forum und ins Wiki.

Ja, da hab ich dank der Vorarbeit dem KSEM schon den Fronius per Dummy unterjubeln können  8) Ich kenne die KSEM Problematik, insbesondere die bislang immer noch nicht vernünftig umgesetzte Schwarm-Anzeige von Kostal, das Problem, dass es keinen Wert für das AC-Äquivalent der PV-Leistung gibt etc. Von mir sind die Plenticore-Module der openWB, die hab ich damals implementiert, weil Kostal ... ach, das vergesse ich lieber wieder, sonst muss ich mich aufregen  :-X

Wegen der Statistiken im 3.WR muss ich mir die aktuelle Implementierung erstmal in Ruhe anschauen und entsprechend Zeit finden. Das ist ja auf einen Schwung so komplex, braucht etwas Zeit.


MichaelO

Seit gestern läuft ja soweit die Implementierung aus dem Wiki. Nun ist mir im Log aufgefallen, dass ich u. a. immer diesen Eintrag bekomme

2023.01.03 09:15:00 4: WR_1_API: BodyDecode is not decoding the response body (charset not found, bodyDecode defaults to none)

Und aus der Prognosenberechnung

2023.01.03 09:00:00 1: PERL WARNING: Argument "0.1\n0.1\n0.1\n0.1\n0.1\n0.1" isn't numeric in multiplication (*) at ./FHEM/99_myUtils.pm line 546.
was dieser Zeile entspricht:
$Solar_[$j]     = $Solar_[$j] * $Solar_Correction_Faktor_auto ;

Ist das normales Verhalten, oder stimmt da was nicht?

ch.eick

Zitat von: MichaelO am 03 Januar 2023, 09:33:41
Seit gestern läuft ja soweit die Implementierung aus dem Wiki. Nun ist mir im Log aufgefallen, dass ich u. a. immer diesen Eintrag bekomme

2023.01.03 09:15:00 4: WR_1_API: BodyDecode is not decoding the response body (charset not found, bodyDecode defaults to none)
Das wird aus dem HTTPMOD Modul kommen und mit der aktuellen Version zusammen hängen.
In dieser FVERSION 98_HTTPMOD.pm:0.265330/2022-10-13 kann ich die Meldung nicht sehen.

Zitat
Und aus der Prognosenberechnung

2023.01.03 09:00:00 1: PERL WARNING: Argument "0.1\n0.1\n0.1\n0.1\n0.1\n0.1" isn't numeric in multiplication (*) at ./FHEM/99_myUtils.pm line 546.
was dieser Zeile entspricht:
$Solar_[$j]     = $Solar_[$j] * $Solar_Correction_Faktor_auto ;

Ist das normales Verhalten, oder stimmt da was nicht?
Hast Du das hier auf 0 gesetzt?
setreading WR_1_config forecast_factor_autocorrection 0
Ich verwende die Autokorrektur momentan gar nicht mehr, weil bei mir das Ergebnis bisher super passt.
Am Anfang solltest Du das auch abgeschaltet lassen um die basis Werte zuerst optimal zu bestimmen. Das ist eine kleine Geduldsaufgabe für den Frühling/Sommer .
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Zitat von: MichaelO am 03 Januar 2023, 08:04:58
Wegen der Statistiken im 3.WR muss ich mir die aktuelle Implementierung erstmal in Ruhe anschauen und entsprechend Zeit finden. Das ist ja auf einen Schwung so komplex, braucht etwas Zeit.
Im Prinzip musst Du alle Werte des Fremd WR mit dem gleichen Namen wie beim Plenticore in das Fake Device bringen. Das hast Du ja schon für die Leistung gemacht.
Je nach dem was der Fremd WR eventuell an Statistiken liefert sind diese dann auch ins WR_3 Device zu mappen. Es sollte hinterher wie ein abgestrippter Plenticore aussehen.

Die Zusammenführung geschiet dann über das WR_1_API Device in den userReadings mit den SW_* readings.
Dort findest Du dann auch Dummy Strings, wie z.B. SW_*Pv[4-6]* , die den Schwarm dann wie einen einzigen WR erscheinen lassen sollen.
Somit müsstest Du aus dem Fremd WR folgende Werte Ermitteln, oder nachbilden:

Statistic_EnergyPv[1-n]_*       mappen auf [7-n] , die werden aber nicht wirklich weiter verwendet, sind aber eventuell schön in Graphen
Statistic_Yield_*

Eine Bestimmung des Yield, wenn es der WR nicht liefert könnte man nachbauen. Da gibt es glaube ich Beispiele von den SMA Kollegen im Wiki. Ich hatte mich darmals gefreut, dass das alles der Plenticore direkt selber liefert ;-)

Schickst Du mir dann mal die Umsetzung per PN vom Fronis zum WR_3 , dann könnte ich meinen Grundgedanken eventuell noch mit einfließen lassen, bevor das auch ins Wiki geht.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Hallo Michael,
was hälst Du denn von meiner integration der openWB ins FHEM, da Du ja aktiv bein openWB mitgemacht hast?

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

MichaelO

Zitat von: ch.eick am 03 Januar 2023, 10:37:45
Hast Du das hier auf 0 gesetzt?

Nein, war Standard 1 aus dem Wiki. Hab es jetzt auf 0 gesetzt. Wobei hier ja grundsätzlich was in der Subroutine nicht stimmt. Den Abschnitt der Berechnung mittels Reading einfach nur abzuschalten, löst ja das Problem des nichtnumerischen Ausdrucks nicht. Aber erstmal ist es jetzt auf 0.

Und dann habe ich bemerkt, dass zumindest bei mir im WR_1_API device keinerlei Battery_ Readings auftauchen. Nur Statistic_, SW_ und auth_. Im WR_1 device stehen etliche Battery_ readings. Muss man da noch was extra konfigurieren, dass die Readings auch im API-device landen. Ist mir erst aufgefallen, als ich im WR_1_Speicher_1 (auch wenn man den ja eigentlich nicht benötigt, aber interessehalber implementiert) gesehen habe, dass dort der EM_State nicht hingeschrieben wird und das stateformat sich auf "WR_1_API","Battery_EM_State" bezieht  :o

Wegen der Strings im Fake-WR schaue ich... der Rest ist ja drin für den KSEM

Muss man eigentlich für den SVG "Forcast" noch was speziell machen? Ich hab die Def (erstmal als einzigen SVG) aus dem Wiki einschl. GPLOT genommen. Das Diagramm wird angezeigt einschl. der Legende, aber es bleibt leer  ???

MichaelO

Zitat von: ch.eick am 03 Januar 2023, 11:11:12
Hallo Michael,
was hälst Du denn von meiner integration der openWB ins FHEM, da Du ja aktiv bein openWB mitgemacht hast?

VG  Christian

Soweit bin ich noch nicht. Ich hab bisher auch immer nur das GUI der openWB auf dem Tablet laufen und lange gehadert, die WR in fhem einzubinden, da mir die openWB bislang gereicht hat. Dann hatte ich die Integration eines Fake WR in den KSEM gesehen und nun wollte ich aber die Batteriesteuerung für eigene Zwecke nutzen (brauche kein 70%, hab einen FRSE verbaut und kann so 100% einspeisen) und deswegen jetzt mal angefangen, die tolle Vorarbeit zu nutzen.

Hab mir auch schon überlegt, ggf. dann fhem auch openWB steuern zu lassen. Mal sehen. Erstmal in kleinen Schritten voranschreiten  8) Ich hab für openWB ja auch Tibber implementiert, das nutze ich seit Jahreswechsel wieder, das müsste ja sonst auch noch in fhem. Und dazu dann insgesamt ein vernünftiges GUI - das sehe ich als größte Herausforderung. Mein restliches "Smarthome" steuere ich nur über DOIF. Schalter und irgendwas auf dem Tablet will ich nicht. Was nicht von alleine im Hintergrund geht, ist in meinen Augen nicht smart und kann auch sonst mit der Hand gesteuert werden.

ch.eick

Zitat von: MichaelO am 03 Januar 2023, 11:12:32
Nein, war Standard 1 aus dem Wiki. Hab es jetzt auf 0 gesetzt. Wobei hier ja grundsätzlich was in der Subroutine nicht stimmt. Den Abschnitt der Berechnung mittels Reading einfach nur abzuschalten, löst ja das Problem des nichtnumerischen Ausdrucks nicht. Aber erstmal ist es jetzt auf 0.
Ich denke, es wird an Deiner noch leeren Datenbank liegen.

Zitat
Und dann habe ich bemerkt, dass zumindest bei mir im WR_1_API device keinerlei Battery_ Readings auftauchen. Nur Statistic_, SW_ und auth_. Im WR_1 device stehen etliche Battery_ readings. Muss man da noch was extra konfigurieren, dass die Readings auch im API-device landen. Ist mir erst aufgefallen, als ich im WR_1_Speicher_1 (auch wenn man den ja eigentlich nicht benötigt, aber interessehalber implementiert) gesehen habe, dass dort der EM_State nicht hingeschrieben wird und das stateformat sich auf "WR_1_API","Battery_EM_State" bezieht  :o
Bei Dir werden die Battery_ readings noch nicht abgefragt, das geschieht über das WR_1_Speicher_1_ExternControl Device im Block 1_Status_WR_1_Speicher_1 .
Du kannst es aber manuell über die set Kommandos im WR_1_API Device anstoßen.

Das WR_1_Speicher_1  Device kann nur mit einem BYD HV Speicher funktionieren und ist komplett separat zu sehen. Damit wollte ich mal die einzelnen Speicher Module monitoren. Im stateFormat hole ich mir manchmal zugehörige Referentwerte aus anderen Devices, damit der Überblick besser ist.

Zitat
Wegen der Strings im Fake-WR schaue ich... der Rest ist ja drin für den KSEM

Muss man eigentlich für den SVG "Forcast" noch was speziell machen? Ich hab die Def (erstmal als einzigen SVG) aus dem Wiki einschl. GPLOT genommen. Das Diagramm wird angezeigt einschl. der Legende, aber es bleibt leer  ???
Da müsstest Du mal schauen, ob die reading Namen noch passen. Das ist altes Zeug aus den Anfängen, ich bin schon länger auf Grafana umgestiegen, da man dort auch Werte stapeln kann und alles
um einiges bessert aussieht. Nebenbei wird FHEM dann auch von den Diagrammen befreit, die bei mir die Anzeige ziemlich verlangsamt haben.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Zitat von: MichaelO am 03 Januar 2023, 11:18:45
Soweit bin ich noch nicht. Ich hab bisher auch immer nur das GUI der openWB auf dem Tablet laufen und lange gehadert, die WR in fhem einzubinden, da mir die openWB bislang gereicht hat. Dann hatte ich die Integration eines Fake WR in den KSEM gesehen und nun wollte ich aber die Batteriesteuerung für eigene Zwecke nutzen (brauche kein 70%, hab einen FRSE verbaut und kann so 100% einspeisen) und deswegen jetzt mal angefangen, die tolle Vorarbeit zu nutzen.

Hab mir auch schon überlegt, ggf. dann fhem auch openWB steuern zu lassen. Mal sehen. Erstmal in kleinen Schritten voranschreiten  8) Ich hab für openWB ja auch Tibber implementiert, das nutze ich seit Jahreswechsel wieder, das müsste ja sonst auch noch in fhem. Und dazu dann insgesamt ein vernünftiges GUI - das sehe ich als größte Herausforderung. Mein restliches "Smarthome" steuere ich nur über DOIF. Schalter und irgendwas auf dem Tablet will ich nicht. Was nicht von alleine im Hintergrund geht, ist in meinen Augen nicht smart und kann auch sonst mit der Hand gesteuert werden.
Okay,
das mit dem Smarthome sehe ich genauso, es ist für mich noch die letzte Optimierung oben drauf und ich mag es, wenn die Bedienung an einer Stelle möglich ist.
Bei der openWB und dem E-Auto wollte ich es auch gerne zusammen haben, da bin ich gerade auch an den Statistiken. Da man ja auch mal extern laden muss habe ich die Daten jetzt als WB_0 in die Datenbank geschrieben. Jetzt summiere ich das für den Vormonat und das Vorjahr auf, damit man mal den gesamt Verbrauch sehen kann. Die WB_0 wird dann wohl ein DbRep Device werden, das ist aber noch nicht ganz klar.
Schön finde ich auch den Luxus mit der Standheizung über den Kalender oder einen Timer, aber das hängt natürlich vom Fahrzeug ab, wie gut man das integrieren kann.

Mit Tibber habe ich mich auch bereits beschäftigt. Hast Du schon ein Device in FHEM und könntest mir die Berechnungsformel liefern?
Für meinen relativ geringen Netzbezug scheint sich das noch nicht zu lohnen. Ich müsste mit 2572 kWh/a alle Mehrkosten von Tibber rein holen, bevor ich dann was sparen könnte  :-\
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

MichaelO

Zitat von: ch.eick am 03 Januar 2023, 12:25:07
Mit Tibber habe ich mich auch bereits beschäftigt. Hast Du schon ein Device in FHEM und könntest mir die Berechnungsformel liefern?

Leider nicht, das hab ich nur in der openWB mit Python umgesetzt. Bei Tibber braucht man aber einen gültigen Account mit einem Token. Darüber lässt sich dann die Home-ID erlangen (falls man in seinem Account mehrere Häuser mit einem Tibber Vertrag hat) und dann erst bekommt man die Daten über deren API. Das war nicht ganz trivial umzusetzen, meine Implementierung in openWB dürfte aber für fhem nicht zutreffen. Ansonsten einfach mal auf https://github.com/snaptec/openWB/blob/master/modules/et_tibber/tibbergetprices.py schauen.

ch.eick

Zitat von: MichaelO am 03 Januar 2023, 12:34:19
Leider nicht, das hab ich nur in der openWB mit Python umgesetzt. Bei Tibber braucht man aber einen gültigen Account mit einem Token. Darüber lässt sich dann die Home-ID erlangen (falls man in seinem Account mehrere Häuser mit einem Tibber Vertrag hat) und dann erst bekommt man die Daten über deren API. Das war nicht ganz trivial umzusetzen, meine Implementierung in openWB dürfte aber für fhem nicht zutreffen. Ansonsten einfach mal auf https://github.com/snaptec/openWB/blob/master/modules/et_tibber/tibbergetprices.py schauen.
Hier ist mal mein Stand für die Tibber API, ohne eigenen Account, als Grundlage.

defmod EVU_Tibber HTTPMOD https://api.tibber.com/v1-beta/gql 0
attr EVU_Tibber DbLogExclude .*
attr EVU_Tibber comment Version 2022.12.12 13:00 \
https://developer.tibber.com/explorer
attr EVU_Tibber enableControlSet 1
attr EVU_Tibber get01Data { "query": "{viewer {home(id:\"%%homeID%%\") {currentSubscription {priceInfo {current {total energy tax startsAt}}}}}}" }
attr EVU_Tibber get01Header01 Content-Type: application/json
attr EVU_Tibber get01Header02 Authorization: Bearer %%token%%
attr EVU_Tibber get01Name 01_priceInfo
attr EVU_Tibber get01URL https://api.tibber.com/v1-beta/gql
attr EVU_Tibber get02Data { "query": "{viewer {home(id:\"%%homeID%%\") {currentSubscription {priceInfo {current {total energy tax startsAt} today {total energy tax startsAt} tomorrow {total energy tax startsAt}}}}}}" }
attr EVU_Tibber get02Header01 Content-Type: application/json
attr EVU_Tibber get02Header02 Authorization: Bearer %%token%%
attr EVU_Tibber get02Name 02_priceAll
attr EVU_Tibber get02URL https://api.tibber.com/v1-beta/gql
attr EVU_Tibber get03Data { "query": "{viewer {home(id:\"%%homeID%%\") {consumption(resolution: HOURLY, last: 100) {nodes {from to cost unitPrice unitPriceVAT consumption consumptionUnit}}}}}"}
attr EVU_Tibber get03Header01 Content-Type: application/json
attr EVU_Tibber get03Header02 Authorization: Bearer %%token%%
attr EVU_Tibber get03Name 03_consumption_hourly_100
attr EVU_Tibber get03URL https://api.tibber.com/v1-beta/gql
attr EVU_Tibber get04Data { "query": "{viewer {home(id:\"%%homeID%%\") {address {address1 address2 address3 postalCode city country latitude longitude} owner {firstName lastName contactInfo {email mobile}}}}}" }
attr EVU_Tibber get04Header01 Content-Type: application/json
attr EVU_Tibber get04Header02 Authorization: Bearer %%token%%
attr EVU_Tibber get04Name 04_address
attr EVU_Tibber get04URL https://api.tibber.com/v1-beta/gql
attr EVU_Tibber group PV Steuerung EVU
attr EVU_Tibber icon sani_pump
attr EVU_Tibber reading1JSON data_viewer_home_currentSubscription_priceInfo_current_total
attr EVU_Tibber reading1Name Strompreis
attr EVU_Tibber reading1OExpr $val*100
attr EVU_Tibber replacement01Mode reading
attr EVU_Tibber replacement01Regex %%token%%
attr EVU_Tibber replacement01Value token
attr EVU_Tibber replacement02Mode reading
attr EVU_Tibber replacement02Regex %%homeID%%
attr EVU_Tibber replacement02Value homeID
attr EVU_Tibber requestData { "query": "{viewer {home(id:\"%%homeID%%b\") {currentSubscription {priceInfo {current {total energy tax startsAt }}}}}}" }
attr EVU_Tibber requestHeader1 Content-Type: application/json
attr EVU_Tibber requestHeader2 Authorization: Bearer %%token%%
attr EVU_Tibber room Strom->Photovoltaik
attr EVU_Tibber showBody 1
attr EVU_Tibber showError 1
attr EVU_Tibber sortby 313
attr EVU_Tibber stateFormat {sprintf("Strompreis: %.2f ct/kWh", ReadingsVal($name,"Strompreis",0))}
attr EVU_Tibber verbose 0

setstate EVU_Tibber Strompreis: 630.11 ct/kWh
setstate EVU_Tibber 2022-12-15 14:49:29 Strompreis 630.11
setstate EVU_Tibber 2022-12-15 12:17:23 homeID 96a14971-525a-4420-aae9-e5aedaa129ff
setstate EVU_Tibber 2022-12-15 12:19:56 token 5K4MVS-OjfWhK_4yrjOlFe1F6kJXPVf7eQYggo8ebAE

Das stateFormat ist auch nur übernommen und sicherlich noch falsch :-)
Token und homeID sind von der Entwickler Seite, also öffentlich.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Moin zusammen,
da Michael ja fleißig Fehler sucht, kommt hier eine kleine Anpassung für das WR_1 Device.

Es hat sich im stateFormat nur die Einheit von Actual_Battery_charge_usable_P auf "Wh" geändert.

attr WR_1 stateFormat {\
my $DUMMY  = "";;\
\
my $Power          = ReadingsVal($name,"Actual_Battery_charge_-minus_or_discharge_-plus_P",0);;\
my $StatusSpeicher = ($Power < -10) ? "<span style='color:green'>Laden</span>" : ($Power > 15)?  "<span style='color:red'>Entladen</span>"  : "<span style='color:orange'>Standby</span>";;\
    $StatusSpeicher = $StatusSpeicher."<br>".ReadingsVal($name,"State_of_EM","n/a");;\
    $Power          = $Power." W";;\
\
\
my $Battery_temperature                  = sprintf("%.1f °C",ReadingsVal($name,"Battery_temperature",0));;\
    $Battery_temperature                  = ((ReadingsVal("WR_1_API","DigitalOutputs_ConfigurationFlags",0) == 9) ? "<span style='color:green'>Lüfter An </span><br>" : "<br>").$Battery_temperature;;\
\
my $Actual_Battery_charge_usable_P       = sprintf("%d Wh",ReadingsVal($name,"Actual_Battery_charge_usable_P",0));;\
         \
my $Act_state_of_charge                  = sprintf("%d %%",ReadingsVal($name,"Act_state_of_charge","0"));;\
my $SW_Total_DC_P_sumOfAllPVInputs       = sprintf("%d W",ReadingsVal($name,"SW_Total_DC_P_sumOfAllPVInputs","0"));;\
my $SW_Total_PV_P_reserve                = sprintf("%d W",ReadingsVal($name,"SW_Total_PV_P_reserve","0"));;\
\
my $SW_Home_own_consumption_from_PV      = sprintf("%d",ReadingsVal($name,"SW_Home_own_consumption_from_PV",0));;\
    $SW_Home_own_consumption_from_PV = ($SW_Home_own_consumption_from_PV >= 0) ? $SW_Home_own_consumption_from_PV." W" : "0 W";;\
my $SW_Home_own_consumption_from_Battery = sprintf("%d W",ReadingsVal($name,"SW_Home_own_consumption_from_Battery",0));;\
my $SW_Home_own_consumption_from_grid    = sprintf("%d W",ReadingsVal($name,"SW_Home_own_consumption_from_grid",0));;\
my $SW_Home_own_consumption              = sprintf("%d W",ReadingsVal($name,"SW_Home_own_consumption",0));;\
\
my $Total_Active_P_EM  = sprintf("%d",ReadingsVal($name,"Total_Active_P_EM",0));;\
my $StatusNetz         = ($Total_Active_P_EM < -10) ? "<span style='color:green'>Einspeisen</span>" : ($Total_Active_P_EM > 15)?  "<span style='color:red'>Netzbezug</span>"  : "<span style='color:orange'>Standby</span>";;\
    $Total_Active_P_EM  = $Total_Active_P_EM." W";;\
\
my $SW_Yield_Daily   = sprintf("%d kWh",round(ReadingsVal($name,"SW_Yield_Daily",0)/1000 ,0));;\
my $SW_Yield_Monthly = sprintf("%d kWh",round(ReadingsVal($name,"SW_Yield_Monthly",0)/1000 ,0));;\
my $SW_Yield_Yearly  = sprintf("%d kWh",round(ReadingsVal($name,"SW_Yield_Yearly",0)/1000 ,0));;\
my $SW_Yield_Total   = sprintf("%d kWh",round(ReadingsVal($name,"SW_Yield_Total",0)/1000 ,0));;\
\
my $Solar_Calculation_fc0_4h   = sprintf("%d kWh",round(ReadingsVal($name,"Solar_Calculation_fc0_4h",0)/1000 ,0));;\
my $Solar_Calculation_fc0_day  = sprintf("%d kWh",round(ReadingsVal($name,"Solar_Calculation_fc0_day",0)/1000 ,0));;\
my $Solar_Calculation_fc0_rest = sprintf("%d kWh",round(ReadingsVal($name,"Solar_Calculation_fc0_rest",0)/1000 ,0));;\
\
"<html><table border=2 bordercolor='darkgreen' cellspacing=0 style='width: 100%'>\
<colgroup>\
   <col span='1' style='width: 52%;;'>\
   <col span='1' style='width: 12%;;'>\
   <col span='1' style='width: 12%;;'>\
   <col span='1' style='width: 12%;;'>\
   <col span='1' style='width: 12%;;'>\
</colgroup>\
<tr><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'> </td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'></td><td style='padding-right:5px;;padding-left:5px;;font-weight:bold'></td><td style='padding-right:5px;;padding-left:5px;;text-align:center;;font-weight:bold'></td><td style='padding-right:5px;;padding-left:5px;;text-align:center;;font-weight:bold'></td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Wechselrichter / KSEM<dd>Max DC / PV Reserve / Netz Leistung</dd></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Total_DC_P_sumOfAllPVInputs."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Total_PV_P_reserve."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$StatusNetz."<br></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$Total_Active_P_EM."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Leistung<dd>von PV / von Batterie / vom Netz / ins Haus</dd></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Home_own_consumption_from_PV."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Home_own_consumption_from_Battery."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Home_own_consumption_from_grid."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Home_own_consumption."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Ertrag<dd>Tag / Monat / Jahr / Total</dd></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Yield_Daily."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Yield_Monthly."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Yield_Yearly."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$SW_Yield_Total."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Prognose<dd>Tag / 4 Stunden / Resttag</dd></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$Solar_Calculation_fc0_day."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$Solar_Calculation_fc0_4h."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$Solar_Calculation_fc0_rest."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$DUMMY."</td></tr>\
<tr><td style='padding-right:5px;;padding-left:5px;;text-align:left;;font-weight:bold'>Speicher<dd>Temperatur / nutzbare Ladung / Status / Leistung / akt. SOC</dd></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$Battery_temperature."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'><br>".$Actual_Battery_charge_usable_P."</td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$StatusSpeicher."<br></td><td style='padding-right:5px;;padding-left:5px;;text-align:center'>".$Power."<br>".$Act_state_of_charge."</td></tr>\
</table>\
</html>"\
}
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick