Re: BMW i3 SOC [gelöst]
Verfasst: Sa Jan 01, 2022 6:31 pm
Empfehle download per Github Web-UI: https://raw.githubusercontent.com/snapt ... /index.php
Empfehle download per Github Web-UI: https://raw.githubusercontent.com/snapt ... /index.php
evchab hat geschrieben: ↑Sa Jan 01, 2022 6:27 pm mit der 250er ist ja das Problem scheinbar gelöst - leider geht damit Huawei PV und EVU nicht mehr
deshalb habe ich wieder auf die 249er umgestellt - damit funktioniert Huawei aber leider i3 SOC wegen der Änderung in der ../modules/i3_soc/Index.php
da ich mich mit git noch nicht beschäftigt habe (keine Zeit) könnte mir jemand die fertige die Datei index.php aus PR1836 zur Verfügung stellen
Empfehle download per Github Web-UI: https://raw.githubusercontent.com/snapt ... /index.php
Hallo,
Code: Alles auswählen
2022-01-01 20:19:32: **** Regulation loop start **** (LV1) at 70 main /var/www/html/openWB/regel.sh
2022-01-01 20:19:29: **** FATAL ********************************* (LV0) at 61 cleanup /var/www/html/openWB/regel.sh
2022-01-01 20:19:29: **** FATAL Regulation loop needs 17 seconds (LV0) at 60 cleanup /var/www/html/openWB/regel.sh
2022-01-01 20:19:29: **** FATAL ********************************* (LV0) at 59 cleanup /var/www/html/openWB/regel.sh
2022-01-01 20:19:29: Überschuss 0; mindestens 1400 (LV1) at 104 nurpvlademodus nurpv.sh
2022-01-01 20:19:29: uberschuss 0 wattbezug 0 ladestatus 0 llsoll 0 pvwatt 0 mindestuberschussphasen 1400 wattkombiniert 0 schaltschwelle 230 (LV2) at 578 main /var/www/html/openWB/regel.sh
2022-01-01 20:19:29: anzahlphasen 1 (LV1) at 577 main /var/www/html/openWB/regel.sh
2022-01-01 20:19:28: Timing Umschaltung: 240 / 720 (LV1) at 15 u1p3pswitch u1p3p.sh
2022-01-01 20:19:28: automatische Umschaltung aktiv (LV1) at 14 u1p3pswitch u1p3p.sh
2022-01-01 20:19:27: chargestatlp1 0 chargestatlp2 0 chargestatlp3 0 (LV1) at 1284 loadvars loadvars.sh
2022-01-01 20:19:27: plugstatlp1 0 plugstatlp2 0 plugstatlp3 0 (LV1) at 1283 loadvars loadvars.sh
2022-01-01 20:19:27: lp1enabled 1 lp2enabled 1 lp3enabled 1 (LV1) at 1282 loadvars loadvars.sh
2022-01-01 20:19:27: EVU 1:V/3A 2: V/2A 3: V/0A (LV1) at 1281 loadvars loadvars.sh
2022-01-01 20:19:27: lla3 0 llv3 239.0 llas13 llas23 soclp1 78 soclp2 (LV1) at 1280 loadvars loadvars.sh
2022-01-01 20:19:27: lla2 0 llv2 239.0 llas12 llas22 sofortll 32 hausverbrauch 0 wattbezug 0 uberschuss 0 (LV1) at 1279 loadvars loadvars.sh
2022-01-01 20:19:27: lla1 0 llv1 237.8 llas11 llas21 mindestuberschuss 1400 abschaltuberschuss 5 lademodus 2 (LV1) at 1278 loadvars loadvars.sh
2022-01-01 20:19:27: pv1watt 0 pv2watt pvwatt 0 ladeleistung 0 llalt 0 nachtladen 0 nachtladen 0 minimalA 6 maximalA 32 (LV1) at 1277 loadvars loadvars.sh
Jepp, sieht so aus, als hätte BMW jetzt das OAUTH für die von der openWB verwendete Client-ID abgeschaltet. Wenn man die von "get_remote_token" erhaltene Antwort ausgibt bekommt man:Sonnenjunky hat geschrieben: ↑So Feb 27, 2022 11:28 am es hat für mich den Anschein man kann hier wieder auf ungelöst stellen
Code: Alles auswählen
HTTP/1.1 401 Unauthorized
Date: Sun, 27 Feb 2022 11:39:21 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-CorrelationID: Id-e9621b62a5427ac155e5d9b8 0
Accept: */*
Client-Remote-IP: 192.168.44.67
Host: api-emea.bmwgroup.net
traceparent: 00-7aaf9e494ddb61cff561331c795208e3-9bcd78208641a77b-01
tracestate: f58cd63e-3d6bc570@dt=fw4;4;c9cac2a3;3e8ac;3;0;0;4c8;b773;2h01;3hc9cac2a3;4h03e8ac;5h01;7h9bcd78208641a77b
X-Cnection: close
X-dynaTrace: FW4;1030473072;4;-909458781;256172;3;-175319490;1224;69e4;2h01;3hc9cac2a3;4h03e8ac;5h01;6h7aaf9e494ddb61cff561331c795208e3;7h9bcd78208641a77b
X-dynaTrace-Application: v=2;appId=08f30ead0181b357;cookieDomain=bmwgroup.com;rid=-341007719;rpid=701263295;en=us2ag6dq
X-dynaTrace-RequestState: agentId=0x1d128e69c9cac2a3&pathDepth=1
X-ForgeRock-Transactionid: rrt-5504546912830388513-b-geu3-16468-13321564-1
X-ruxit-Apache-ServerNamePorts: customer.bmwgroup.com
Access-Control-Allow-Origin:
Access-Control-Allow-Headers: Authorization, Origin, X-c2b-Authorization, X-c2b-mTAN, X-Requested-With, X-c2b-Sender-Id, X-c2b-External-Id, Content-Type, Accept, Cache-Control, KeyId, x-dtc
Access-Control-Max-Age: 3628800
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE, HEAD
Referrer-Policy: strict-origin
{"error":"invalid_client","error_description":"Client authentication failed (unknown client)"}
Wie genau nutzt man genanntes Modul (Bimmer) und worin unterscheidet es sich von der Implementierung hier? Klar, BMW will seine Nutzer sicher identifizieren (OAUTH), hat Bimmer dies bereits (anders) integriert, oder nutzt eine andere ID? Wenn ja, dann könnte man doch einfach übernehmen , nein?bimmer_connected funktioniert weiterhin.
Möglicherweise wurden an der api die Sicherheitsanforderungen für die Authentifizierung erhöht.
Könnte bedeuten, dass die Implementierung erweitert werden müsste. Ich habe hier unabhängig von openWB bislang das hier benutzt (https://github.com/pboettch/bmw-connect ... r/bmwcd.py), was auch nicht mehr funktioniert. Dann bin ich zu bimmer_connected gewechselt und jetzt bekomme ich den SOC wieder.
Wie genau nutzt man genanntes Modul (Bimmer) und worin unterscheidet es sich von der Implementierung hier? Klar, BMW will seine Nutzer sicher identifizieren (OAUTH), hat Bimmer dies bereits (anders) integriert, oder nutzt eine andere ID? Wenn ja, dann könnte man doch einfach übernehmen , nein?bimmer_connected funktioniert weiterhin.
Möglicherweise wurden an der api die Sicherheitsanforderungen für die Authentifizierung erhöht.
Könnte bedeuten, dass die Implementierung erweitert werden müsste. Ich habe hier unabhängig von openWB bislang das hier benutzt (https://github.com/pboettch/bmw-connect ... r/bmwcd.py), was auch nicht mehr funktioniert. Dann bin ich zu bimmer_connected gewechselt und jetzt bekomme ich den SOC wieder.