Sonnenbatterie Abfrage Api v2

Begonnen von Wondermusic, 02 Februar 2021, 11:10:27

Vorheriges Thema - Nächstes Thema

Wondermusic

Hallo zusammen,
ich würde gerne weitere Daten meiner Sonnenbatterie auslesen, deren Werte nur in der API v2 vorhanden sind. Leider scheitere ich über HTTPMOD diese Daten zu erhalten. Laut Dashboard/Software-Integration kann ich die gewünschte get Funktion nur mit einem Auth-Token abrufen was mittels curl von meinem FHEM- RPi in der console auch wunderbar funktioniert.

Der Aufruf erfolgt dort über: curl --header 'Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' http://192.168.x.xxx:80/api/v2/latestdata

Das Ergebnis der Abfrage sieht dann so aus:

{
  "Consumption_W": 0,
  "FullChargeCapacity": 0,
  "GridFeedIn_W": 0,
  "Pac_total_W": 0,
  "Production_W": 0,
  "RSOC": 0,
  "SetPoint_W": 0,
  "Timestamp": "2019-09-19 15:07:19",
  "USOC": 0,
  "UTC_Offet": 2,
  "ic_status": {
    "DC Shutdown Reason": {
      "Critical BMS Alarm": false,
      "Error condition in BMS initialization": false,
      "HW_Shutdown": false,
      "HardWire Over Voltage": false,
      "HardWired Dry Signal A": false,
      "HardWired Under Voltage": false,
      "Initialization Timeout": false,
      "Initialization of AC contactor failed": false,
      "Initialization of BMS hardware failed": false,
      "Initialization of DC contactor failed": false,
      "Initialization of Inverter failed": false,
      "Invalid or no SystemType was set": false,
      "Inverter Over Temperature": false,
      "Inverter Under Voltage": false,
      "Manual shutdown by user": false,
      "Minimum rSOC of System reached": false,
      "No Setpoint received by HC": false,
      "Shutdown Timer started": false,
      "System Validation failed": false,
      "Voltage Monitor Changed": false
    },
    "Eclipse Led": {
      "Pulsing Green": false,
      "Pulsing Orange": true,
      "Pulsing White": false,
      "Solid Red": false
    },
    "Flat Status": {
      "Auto Mode": false,
      "Error": false,
      "Full Charge Power": false,
      "Full Discharge Power": false,
      "Not Connected": false,
      "Spare 1": false,
      "Spare 2": false,
      "Spare 3": false,
      "Timeout": false
    },
    "MISC Status Bits": {
      "Discharge not allowed": false,
      "Min System SOC": false,
      "Min User SOC": false
    },
    "Microgrid Status": {
      "Continious Power Violation": false,
      "Discharge Current Limit Violation": false,
      "Low Temperature": false,
      "Max System SOC": false,
      "Max User SOC": false,
      "Microgrid Enabled": false,
      "Min System SOC": false,
      "Min User SOC": false,
      "Over Charge Current": false,
      "Over Discharge Current": false,
      "Peak Power Violation": false,
      "Protect is activated": false,
      "Transition to Ongrid Pending": false
    },
    "Setpoint Priority": {
      "BMS": false,
      "Energy Manager": false,
      "Flat": false,
      "Full Charge Request": false,
      "Inverter": false,
      "Min User SOC": false,
      "Trickle Charge": false
    },
    "System Validation": {
      "Country Code Set status flag 1": false,
      "Country Code Set status flag 2": false,
      "Self test Error DC Wiring": false,
      "Self test Postponed": false,
      "Self test Precondition not met": false,
      "Self test Running": false,
      "Self test successful finished": false
    },
    "nrbatterymodules": 0,
    "secondssincefullcharge": 0,
    "statebms": "not ready",
    "statecorecontrolmodule": "config",
    "stateinverter": "not ready",
    "timestamp": "Thu Jan 1 01:00:00 1970"
  }
}


Kann ich das doch irgendwie über HTTPMOD machen, JsonMod verwenden (wobei ich das damit auch nicht hinbekommen habe) oder über die 99_myUtils Daten in einen Dummy schreiben lassen?

Bitte um Hilfe, denn ich komme einfach nicht weiter.

Gruß,
Richy



LÖSUNG: Vielen Dank an ch.eick!

Sinn und Zweck des defines ist, den Zustand der Eclipse in fhem darzustellen. Wenn ein Fehler in der sonnen Batterie auftritt, kann an den Readings abgelesen werden was der Fehler ist und ggf. sonnen so bei der schnelleren Fehlersuche geholfen werden.
Eine weitere Möglichkeit wäre nun sich auch über z. B. Telegram eine Nachricht zuschicken zu lassen, falls ein Fehler in der Batterie auftritt um schnell handeln zu können.

Den Auth- Token findet man im Dashboard der sonnen Batterie unter dem Link: http://192.168.x.xxx/dash/#/software-integration


define solar_status HTTPMOD http://192.168.x.xxx:80/api/v2/latestdata 900

attr solar_status alias sonnenBatterie Zustand
attr solar_status devStateIcon 1000:sonnen_icon@green 0100:sonnen_icon@orange 0010:sonnen_icon@white 0001:sonnen_icon@red
attr solar_status enableControlSet 1
attr solar_status extractAllJSON 1
attr solar_status get01Header01 Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
attr solar_status get01Name LatestData
attr solar_status get01URL http://192.168.x.xxx:80/api/v2/latestdata
attr solar_status group Strom
attr solar_status httpVersion 1.1
attr solar_status icon sonnen_logo
attr solar_status requestHeader01 Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
attr solar_status room Solar
attr solar_status showError 1
attr solar_status stateFormat {sprintf("%d%d%d%d", ReadingsVal($name,"ic_status_Eclipse_Led_Pulsing_Green",0), ReadingsVal($name,"ic_status_Eclipse_Led_Pulsing_Orange",0), ReadingsVal($name,"ic_status_Eclipse_Led_Pulsing_White",0), ReadingsVal($name,"ic_status_Eclipse_Led_Solid_Red",0))}



RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

ch.eick

Hi,
Du solltest die Verbindung am besten im Browser, oder mit Burp tracen, dann siehst Du alle notwendigen Header, die Du für HTTPMOD benötigst.
Der Login wird dann mit sid* nachgebildet. Erst wenn der Login funktioniert kannst Du mit json, oder einzel readings die Daten lesen.

Dann bitte mit verbose 5 die Logmeldungen, bereinigt von anderen Devices,  als Datei anhängen.

Gruß
   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

Wondermusic

Hallo Christian,

ich hoffe ich habe das richtige, denn davon habe ich leider nicht wirklich Ahnung. Was meinst Du mit tracen? Burp habe ich mir angesehen, ist aber für mich leider völlig unverständlich.
In Firefox habe ich mal unter Entwickleroptionen die angehängten Bilder gefunden.

Wenn ich unter attr "sid[0-9]*Header.*" auswähle und im Feld "Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" eingebe, erhalte ich diese Fehlermeldung: solar_test: bad attribute name 'sid[0-9]*Header.*' (allowed chars: A-Za-z/\d_\.-).
Selbst wenn ich nur den die Zahlen hinter "Auth-Token: " eingebe erhalte ich diese Meldung.

Und das Log sagt folgendes:

2021.02.02 12:02:03.502 4: solar_test: GetUpdate called (update)
2021.02.02 12:02:03.502 4: solar_test: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 300.0 sec at 12:07:03.502, interval 300
2021.02.02 12:02:03.504 5: solar_test: AddToQueue adds type update to URL http://192.168.x.xxx:80/api/v2/lastestdata, no data, no headers, retry 0, initial queue len: 0
2021.02.02 12:02:03.504 5: solar_test: HandleSendQueue called from AddToSendQueue, qlen = 1
2021.02.02 12:02:03.504 4: solar_test: HandleSendQueue sends update with timeout 2 to http://192.168.x.xxx:80/api/v2/lastestdata, No Data, No Header
2021.02.02 12:02:03.527 5: solar_test: ReadCallback called from __ANON__
2021.02.02 12:02:03.528 4: solar_test: Read callback: request type was update retry 0,
header: HTTP/1.1 404 Not Found
Date: Tue, 02 Feb 2021 11:02:03 GMT
Content-Type: application/json
Content-Length: 25
Connection: close, body length 25
2021.02.02 12:02:03.528 5: solar_test: Read callback: body
{"error":"404 Not Found"}
2021.02.02 12:02:03.528 4: solar_test: BodyDecode found no charset header (bodyDecode was set to auto)
2021.02.02 12:02:03.528 4: solar_test: extracted JSON values to internal
2021.02.02 12:02:03.528 5: solar_test: GetCookies is looking for Cookies
2021.02.02 12:02:03.528 5: solar_test: ExtractSid called, context reading, num 0
2021.02.02 12:02:03.529 4: solar_test: checking for redirects, code=404, ignore=0
2021.02.02 12:02:03.529 4: solar_test: no redirects to handle
2021.02.02 12:02:03.529 5: solar_test: Read callback sets LAST_REQUEST to update
2021.02.02 12:02:03.529 5: solar_test: CheckAuth decided no authentication required
2021.02.02 12:02:03.530 5: solar_test: Read sets reading error to value 404 Not Found of JSON error
2021.02.02 12:02:03.530 5: solar_test: Read starts parsing response to update with defined readings:
2021.02.02 12:02:03.530 4: solar_test: Read response matched 1, unmatch 0 Reading(s)
2021.02.02 12:02:03.530 5: solar_test: Read response to update matched error
2021.02.02 12:02:03.540 5: solar_test: HandleSendQueue called from ReadCallback, qlen = 0
2021.02.02 12:02:03.541 5: solar_test: HandleSendQueue found no usable entry in queue
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

ch.eick

Zitat von: Wondermusic am 02 Februar 2021, 12:15:23
ich hoffe ich habe das richtige, denn davon habe ich leider nicht wirklich Ahnung. Was meinst Du mit tracen? Burp habe ich mir angesehen, ist aber für mich leider völlig unverständlich.
In Firefox habe ich mal unter Entwickleroptionen die angehängten Bilder gefunden.

Wenn ich unter attr "sid[0-9]*Header.*" auswähle und im Feld "Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" eingebe, erhalte ich diese Fehlermeldung: solar_test: bad attribute name 'sid[0-9]*Header.*' (allowed chars: A-Za-z/\d_\.-).
Selbst wenn ich nur den die Zahlen hinter "Auth-Token: " eingebe erhalte ich diese Meldung.
Okay, bitte verstehe mich jetzt nicht falsch.
Anhand Deine Antwort erkenne ich, dass Du noch sehr viele Grundlagen benötigst, was nicht böse gemeint ist.
Nur wirst Du so die Aufgabe nicht lösen können, da es schon etwas komplexer sein wird.

Eventuell meldet sich ja noch jemand, der bereits die Grundlagen in einem HTTPMOD Device für Dich gelöst hat. Mit den Grundlagen könnte man Dich dann weiter durchleiten.

Die Informationen aus dem Firefox wären schon mal an der richtigen Stelle entnommen, das hilft Dir dann später weiter. Burp ist wirklich etwas für fortgeschrittenere. Bei den Entwickler Optionen siehst Du die Kommunikation, die der Browser mit dem Endgerät durchführt. Dort siehst Du dann Header, die z.B. als sid01Header1, sid01Header2,.. gesetzt werden.

Das könnte dann so aussehen und ist nur als Beispiel hier angegeben.

...
attr PV_Anlage_1_Speicher_1 sid01ParseResponse 1
attr PV_Anlage_1_Speicher_1 sid01Header Authorization: Digest username="installer", realm="%auth_realm%", nonce="%auth_nonce%", uri="/asp/RunData.asp", algorithm="MD5", response="%auth_response%", opaque="%auth_opaque%", qop="auth", nc="00000001", cnonce="d789ea5b7e9a2377"
attr PV_Anlage_1_Speicher_1 sid01URL http://%IP-Address_BYD%/asp/RunData.asp
...


Bitte hab etwas Geduld, bis sich jemand mit einer Solarbatterie meldet und Dir Seine Konfiguration schickt.

Viele Grüße
   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

Du könntest mal hiermit beginnen, was in etwa dem Curl entspricht.


# Die ersten Attribute sind allgemeiner Art und Du kannst die später dann auch testweise, eins nach dem anderen entfernen.
attr solar_test authRetries 1
attr solar_test enableControlSet 1
attr solar_test enableCookies 1
attr solar_test handleRedirects 1
attr solar_test httpVersion 1.1

# Das ist, dass Du etwas mehr sehen kannst
attr solar_test showBody 1
attr solar_test showError 1

# Versuche zuerst einfach ein get, dann kann man sehen, ob ein Login notwendig ist
allr solar_test get01URL http://192.168.x.xxx:80/api/v2/lastestdata
attr solar_test get01Header01 Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# Die Header mit accept, könnten auch wichtig sein, wenn Du das weg lässt, wird zuerst mal ein Default verwendet.

Gruß
   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

Hi,
es scheint sich niemand zu melden :-)
Bist Du schon weiter gekommen?
Gruß
   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

Wondermusic

Hi Christian,

ich hatte bisher noch keine Zeit. ;-)

Ich habe nun alles so angegeben wie Du geschickt hast, aber leider bekomme ich noch keine Werte und die Rückmeldung das der Zugriff nicht autorisiert ist.
Hier das list von solar_test:
Internals:
   BUSY       0
   DEF        http://192.168.x.xxx:80/api/v2/latestdata
   FUUID      60192fff-f33f-0e0f-2bca-b378a38e0c10b462
   Interval   300
   MainURL    http://192.168.x.xxx:80/api/v2/latestdata
   ModuleVersion 4.0.17 - 31.12.2020
   NAME       solar_test
   NOTIFYDEV  global
   NR         1123
   NTFY_ORDER 50-solar_test
   STATE      ???
   TYPE       HTTPMOD
   httpbody   {"error":"401 Unauthorized"}
   value     
   HttpUtils:
     NAME       
     addr       http://192.168.x.xxx:80
     auth       0
     buf       
     code       401
     compress   1
     conn       
     data       
     displayurl http://192.168.x.xxx:80/api/v2/latestdata
     header     
     host       192.168.x.xxx
     httpheader HTTP/1.1 401 Unauthorized
Date: Wed, 03 Feb 2021 09:33:09 GMT
Content-Type: application/json
Content-Length: 28
Connection: close
     httpversion 1.1
     hu_blocking 0
     hu_filecount 1
     hu_port    80
     hu_portSfx
     ignoreredirects 1
     loglevel   4
     path       /api/v2/latestdata
     protocol   http
     redirects  0
     timeout    2
     url        http://192.168.x.xxx:80/api/v2/latestdata
     sslargs:
   QUEUE:
   READINGS:
     2021-02-03 10:33:09   error           401 Unauthorized
   REQUEST:
     context    reading
     data       
     header     
     ignoreredirects 0
     num        0
     retryCount 0
     type       update
     url        http://192.168.x.xxx:80/api/v2/latestdata
   defptr:
     readingBase:
       error      reading
     readingNum:
       error      0
     readingOutdated:
     requestReadings:
       update:
         error      reading 0
Attributes:
   authRetries 1
   disable    0
   enableControlSet 1
   enableCookies 1
   extractAllJSON 1
   get01Header01 Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
   get01URL   http://192.168.x.xxx:80/api/v2/latestdata
   handleRedirects 1
   httpVersion 1.1
   room       Solar
   showBody   1
   showError  1
   verbose    5


und die Meldung im Log:

2021.02.03 10:32:55.298 5: solar_test: attr solar_test get01URL http://192.168.x.xxx:80/api/v2/latestdata
2021.02.03 10:32:55.364 5: solar_test: UpdateHintList called
2021.02.03 10:32:55.365 5: solar_test: UpdateHintList: setlist = interval reread:noArg stop:noArg start:noArg clearCookies:noArg upgradeAttributes:noArg storeKeyValue
2021.02.03 10:32:55.365 5: solar_test: UpdateHintList: getlist =
2021.02.03 10:33:03.561 3: solar_test: no valid interval specified, use default 300 seconds
2021.02.03 10:33:03.561 3: solar_test: Defined with URL http://192.168.x.xxx:80/api/v2/latestdata and interval 300 featurelevel 6
2021.02.03 10:33:03.562 4: solar_test: UpdateTimer called from DefineFn with cmd start sets timer to call update function in 220.5 sec at 10:36:44.078, interval 300
2021.02.03 10:33:03.713 5: solar_test: UpdateHintList called
2021.02.03 10:33:03.713 5: solar_test: UpdateHintList: setlist = interval reread:noArg stop:noArg start:noArg clearCookies:noArg upgradeAttributes:noArg storeKeyValue
2021.02.03 10:33:03.713 5: solar_test: UpdateHintList: getlist =
2021.02.03 10:33:08.470 5: solar_test: set called with reread
2021.02.03 10:33:08.470 4: solar_test: GetUpdate called (reread)
2021.02.03 10:33:08.471 5: solar_test: AddToQueue adds type update to URL http://192.168.x.xxx:80/api/v2/latestdata, no data, no headers, retry 0, initial queue len: 0
2021.02.03 10:33:08.471 5: solar_test: HandleSendQueue called from AddToSendQueue, qlen = 1
2021.02.03 10:33:08.471 4: solar_test: HandleSendQueue sends update with timeout 2 to http://192.168.x.xxx:80/api/v2/latestdata, No Data, No Header
2021.02.03 10:33:09.406 5: solar_test: ReadCallback called from __ANON__
2021.02.03 10:33:09.407 4: solar_test: Read callback: request type was update retry 0,
header: HTTP/1.1 401 Unauthorized
Date: Wed, 03 Feb 2021 09:33:09 GMT
Content-Type: application/json
Content-Length: 28
Connection: close, body length 28
2021.02.03 10:33:09.407 5: solar_test: Read callback: body
{"error":"401 Unauthorized"}
2021.02.03 10:33:09.407 4: solar_test: BodyDecode found no charset header (bodyDecode was set to auto)
2021.02.03 10:33:09.407 4: solar_test: extracted JSON values to internal
2021.02.03 10:33:09.407 5: solar_test: GetCookies is looking for Cookies
2021.02.03 10:33:09.408 5: solar_test: ExtractSid called, context reading, num 0
2021.02.03 10:33:09.408 4: solar_test: checking for redirects, code=401, ignore=0
2021.02.03 10:33:09.408 4: solar_test: no redirects to handle
2021.02.03 10:33:09.408 5: solar_test: Read callback sets LAST_REQUEST to update
2021.02.03 10:33:09.408 5: solar_test: CheckAuth decided no authentication required
2021.02.03 10:33:09.409 5: solar_test: Read sets reading error to value 401 Unauthorized of JSON error
2021.02.03 10:33:09.409 5: solar_test: UpdateReadingList created list of reading.* nums to parse during getUpdate as
2021.02.03 10:33:09.410 5: solar_test: Read starts parsing response to update with defined readings:
2021.02.03 10:33:09.410 4: solar_test: Read response matched 1, unmatch 0 Reading(s)
2021.02.03 10:33:09.410 5: solar_test: Read response to update matched error
2021.02.03 10:33:09.421 5: solar_test: HandleSendQueue called from ReadCallback, qlen = 0
2021.02.03 10:33:09.421 5: solar_test: HandleSendQueue found no usable entry in queue


Zitat von: ch.eick am 02 Februar 2021, 13:07:55
Okay, bitte verstehe mich jetzt nicht falsch.
Anhand Deine Antwort erkenne ich, dass Du noch sehr viele Grundlagen benötigst, was nicht böse gemeint ist.
Nur wirst Du so die Aufgabe nicht lösen können, da es schon etwas komplexer sein wird.

Nein, alles gut. Mein Problem liegt einfach darin, dass ich mit solchen Sachen noch nie viel anfangen konnte.
Ich habe es schon zig mal versucht mich da rein zu denken, was aber leider einfach nicht klappen will.

Ich bin daher immer sehr froh wenn sich jemand "meiner erbarmt" und mir auf diesem Wege weitergeholfen werden kann.  :D

Gruß,
Richy
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

Benni

Zitat von: Wondermusic am 02 Februar 2021, 11:10:27
Hallo zusammen,
ich würde gerne weitere Daten meiner Sonnenbatterie auslesen, deren Werte nur in der API v2 vorhanden sind. Leider scheitere ich über HTTPMOD diese Daten zu erhalten. Laut Dashboard/Software-Integration kann ich die gewünschte get Funktion nur mit einem Auth-Token abrufen was mittels curl von meinem FHEM- RPi in der console auch wunderbar funktioniert.

Hi Richy,

ich rufe aktuell Daten von meiner Sonnenbatterie über api V1 ab (http://192.168.x.xxx:8080/api/v1/status), das geht ohne Token.

Woher bekommt man den Token für die Authorisierung, dann könnte ich das bei mir mal ausprobieren. Allerdings erhalte ich aktuell erwartungsgemäß, bei Aufruf des Api V2, ohne Token einen "error 401 unauthorized"

gb#



Benni

Hier mal noch die Rohdefinition meines HTTPMOD-Devices für den API V1-Abruf:


defmod pvaBattery HTTPMOD http://<YourBatteryIP-Here>:8080/api/v1/status 15
attr pvaBattery alias Sonnenbatterie
attr pvaBattery alignTime 00:00
attr pvaBattery enforceGoodReadingNames 1
attr pvaBattery event-on-change-reading .*
attr pvaBattery event-on-update-reading Consumption_W,Production_W,GridFeedIn_W,uCharging,uDischarging,USOC,BatteryCharging,BatteryDischarging,Pac_total_W
attr pvaBattery extractAllJSON 1
attr pvaBattery group Solar
attr pvaBattery handleRedirects 1
attr pvaBattery icon measure_battery_0
attr pvaBattery oldreadings GridFeedIn_W
attr pvaBattery stateFormat USOC %
attr pvaBattery userReadings uCharging:BatteryCharging.* {(ReadingsVal($name,'BatteryCharging','x') eq 'true') ? 1:0 },\
uDischarging:BatteryDischarging.* {(ReadingsVal($name,'BatteryDischarging','x') eq 'true') ? 1:0},\
uGridFeedIn_Abs_W:GridFeedIn_W.* {abs(ReadingsNum($name,'GridFeedIn_W',0))},\
uPac_total_Abs_W:Pac_total_W.* {abs(ReadingsNum($name,'Pac_total_W',0))},\
uReturnCode:ReturnCode.* {my $rc=ReadingsNum($name,'ReturnCode',-1);; return $rc==0?'success':($rc==5?'invalid request path':($rc==13?'internal error':($rc==16?'invalid http method':'unknown')))}


<YourBatteryIP-Here> muss natürlich durch die passende IP deiner Batterie ersetzt werden ;)

ch.eick

Moin,

Dein Header wird nicht verwendet :-)

2021.02.03 10:33:08.471 5: solar_test: AddToQueue adds type update to URL http://192.168.x.xxx:80/api/v2/latestdata, no data, no headers, retry 0, initial queue len: 0
2021.02.03 10:33:08.471 5: solar_test: HandleSendQueue called from AddToSendQueue, qlen = 1
2021.02.03 10:33:08.471 4: solar_test: HandleSendQueue sends update with timeout 2 to http://192.168.x.xxx:80/api/v2/latestdata, No Data, No Header


Bitte ändere Dein define, da steht die default Abfrage , die bei Dir alle 300 Sekunden ausgeführt wird. Das stört etwas beim Testen.
Die URL kann bleiben, aber das 300 ersetze einfach durch 0 , dann wird das erstmal nicht ausgeführt.

Gib dem get01 noch einen Namen

attr solar_test get02Name LatestData

Danach erscheint, wenn Du im Device bist dieser Name im Pulldown Menü bei get solar_test . Dort kannst Du es dann manuell ausführen und der get01Header01 wird auch verwendet.
Später, wenn Du weißt, welche Header benötigt werden kannst Du es auch mit getHeader für alle Anfragen setzen. get01Header* wird nur verwendet, wenn Du das get01 mit dem Namen LatestData aufrufst.

Wie bei der api/v1 kannst Du auch schon mal das setzen

attr solar_test extractAllJSON 1
attr solar_test alignTime 00:00


Gruß
   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

#10
Zitat von: Benni am 03 Februar 2021, 11:06:44
Hier mal noch die Rohdefinition meines HTTPMOD-Devices für den API V1-Abruf:

defmod pvaBattery HTTPMOD http://<YourBatteryIP-Here>:8080/api/v1/status 15

Ich denke 15 Sekunden ist recht häufig bei der Abfrage, ich bin bei einem anderen Speicher auf 6 Minuten gegangen und das liefert eigentlich ausreichend Daten.
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

Wondermusic

#11
Zitat von: ch.eick am 03 Februar 2021, 12:33:48
Moin,

Dein Header wird nicht verwendet :-)

Bitte ändere Dein define, da steht die default Abfrage , die bei Dir alle 300 Sekunden ausgeführt wird. Das stört etwas beim Testen.
Die URL kann bleiben, aber das 300 ersetze einfach durch 0 , dann wird das erstmal nicht ausgeführt.

Gib dem get01 noch einen Namen

attr solar_test get02Name LatestData

Danach erscheint, wenn Du im Device bist dieser Name im Pulldown Menü bei get solar_test . Dort kannst Du es dann manuell ausführen und der get01Header01 wird auch verwendet.
Später, wenn Du weißt, welche Header benötigt werden kannst Du es auch mit getHeader für alle Anfragen setzen. get01Header* wird nur verwendet, wenn Du das get01 mit dem Namen LatestData aufrufst.
Gruß
   Christian

Habe das define geändert und eine "0" hinter das def gesetzt.
Aber leider hat der erste Versuch zu keinem Ergebnis geführt.

Danach habe ich aus
attr solar_test get02Name LatestData
attr solar_test get01Name LatestData

gemacht und es hat funktioniert.
Nun würde ich gerne haben, dass die Daten alle 15 Minuten abgeholt werden... Muss ich dann hier was ändern oder mache ich das dann über ein periodisches at- Kommando?


@Benni
Zitat von: Benni am 03 Februar 2021, 10:59:25
Hi Richy,
ich rufe aktuell Daten von meiner Sonnenbatterie über api V1 ab (http://192.168.x.xxx:8080/api/v1/status), das geht ohne Token.
Woher bekommt man den Token für die Authorisierung, dann könnte ich das bei mir mal ausprobieren. Allerdings erhalte ich aktuell erwartungsgemäß, bei Aufruf des Api V2, ohne Token einen "error 401 unauthorized"
gb#

EDIT:
Ich rufe ja derzeit die Hauptdaten über die v2 ab, was einwandfrei funktioniert. (http://192.168.x.xxx:80/api/v2/status - Für die Abfrage wird kein Auth-Token benötigt)
Latestdata aus der v2 enthält allerdings Daten, die ich in der v1 nicht bekommen - hauptsächlich den Zustand der Batterie, bzw. über mögliche Fehlermeldungen.
Das würde ich gerne haben, da ich keinen direkten Zugriff auf die Hardware habe, weil sie im Versorgungsraum steht, der nur über die Anliegerwohnung zu erreichen ist.

Den Token kannst Du über das Dashboard Deiner Batterie herausfinden: http://192.168.x.xxx/dash/#/software-integration
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

ch.eick

Zitat von: Wondermusic am 03 Februar 2021, 13:31:07
Habe das define geändert und eine "0" hinter das def gesetzt.
Nun würde ich gerne haben, dass die Daten alle 15 Minuten abgeholt werden... Muss ich dann hier was ändern oder mache ich das dann über ein periodisches at- Kommando?

Das übernimmt den Header für alle Abfragen, die Du noch machen möchtest

attr solar_test getHeader01  Auth-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
deleteattr get01Header01


Beim define kannst Du 900 anstelle der 0 eintragen, dann wird die URL alle 15 Minuten gestartet. Es muss aber das getHeader01 gesetzt sein.
Somit hättest Du dann eine dauernde Status Abfrage.
Die readings aus dem json kann man auch noch namentlich anpassen.
Wenn noch andere get möglich sind hast Du jetzt ja ein Muster, und kannst auch unterschiedliche Header verwenden.
Mit dem set wären dann noch Veränderungen möglich, falls die API das her gibt.

Es wäre schön, wenn Du die entgültige Definition als RAW hier reinstellen würdest, oder eine Wiki Seite dazu schreibst.

Viel Spaß
   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

Wondermusic

Den getHeader01 habe ich so drin stehen, aber dann bekommen ich wieder ein 401 Unauthorized error wenn ich das Interval hoch stelle.
Per get Befehl wird alles ohne den unauthorized error durchgeführt.
Für die Aktualisierung habe ich mir temporär einen at- define eingerichtet was die Daten alle 15 Minuten abholt.

Set- Befehle gibt es bei der sonnenBatterie nicht, das nennt sich da PUT und POST, allerdings für Einstellungen die kein Mensch (Otto-Normal-Verbraucher) kennt...

Wenn alles läuft wollte ich die komplette Deffinition hier noch mal posten, kann es aber auch gerne ins WIKI schreiben.  :)
RPi 3B+ FHEM-Server mit HM-MOD-RPI-PCB
RPi2 mit HM-MOD-RPI-PCB
HM-CFG-LAN
RPi 4 mit ioBroker
>100 HM Sensoren & Aktoren, div. ESP8266 via mqtt, ems-esp

ch.eick

Zitat von: Wondermusic am 03 Februar 2021, 14:48:39
Den getHeader01 habe ich so drin stehen, aber dann bekommen ich wieder ein 401 Unauthorized error wenn ich das Interval hoch stelle.

Sorry, es ist nicht getHeader01 sondern

requestHeader.*          Define an additional HTTP Header to set in the HTTP request
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