BMW i3 SOC [gelöst]

[truckl]

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

[Andyme]

Könntest du den aktuellen nightly nochmal versuchen. Da wurde am Huawei Teil gearbeitet. Es fehlen aber noch Feedbacks.

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

[evchab]

Empfehle download per Github Web-UI: https://raw.githubusercontent.com/snapt ... /index.php

vielen Dank - hat geklappt

"HIER WERDEN SIE GEHOLFEN"

[evchab]

Könntest du den aktuellen nightly nochmal versuchen. Da wurde am Huawei Teil gearbeitet. Es fehlen aber noch Feedbacks.

Hallo,
habe mal Update auf 250er gemacht keine EVU Daten vom Huawei
Debug Log

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

[Sonnenjunky]

es hat für mich den Anschein man kann hier wieder auf ungelöst stellen

App My BMW funktioniert

[truckl]

es hat für mich den Anschein man kann hier wieder auf ungelöst stellen

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:

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)"}

Das interessanteste ist wohl das JSON in der letzten Zeile "unknown client".

Leider bin ich kein OAUTH-Experte und hab keine Ahnung welche IDs bei OAUTH zu was dienen und mit was überein stimmen müssen.

Und ehrlich gesagt hab ich keine Muse mehr mich damit nochmal mit dem Reverse-Engeineering zu befassen nur um es wieder für ein paar Wochen zum Laufen zu kriegen.

Es sei denn ich bekomme von BMW (oder wem auch immer) die Doku des aktuellen API um zu verstehen was man da tut und es von Grund auf korrekt zu implementieren.
Aber vermutlich ist das ein Firmengeheimnis und ändert sich absichtlich regelmäßig. Sonst könnte ja Jedermann viel zu einfach den SOC abfragen oder gar die BMW-App nachbauen

Mein nächste Auto wird, nach aktuellem Stand der Dinge, auch kein BMW mehr sein.

[zergchen]

Zitat aus SoC Kategorie:

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?

[Sonnenjunky]

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?
[/quote]

Genau - "könnte man doch einfach"

Kannst du das mal bitte schnell erledigen ?

[zergchen]

War ja garnicht verächtlich gemeint... Nur, was sprich dagegeben, bimmer_connected für den SoC BMW zu nutzen?

[Sonnenjunky]

gar nichts spricht dagegen, aber dazu braucht´s halt jemanden der sich einerseits damit befasst, anderseits auch weis was er macht damit es wieder klappt.

Einen Experten braucht´s also, aber mit einfach so ist da eben rein gar nichts.

Somit hoffe ich es findet sich ein Wissender der sich der Sache annimmt damit wir wieder Freude mit der tollen Funktion haben.