[Frage] Realisierung Adapter UDP Keba Wallbox
-
@lidaga So, dafür kannst du mal testen, wenn Du willst. Auf git steht eine neue Version, bei der man unter kecontact.0.automatic.limitCurrent eine Obergrenze (in mA) einstellen kann mit der geladen wird.
-
@sneak-l8 danke für die schnelle Rückmeldung. Mache ich, wenn ich das nächste mal vor Ort bin. Kann ein bisschen dauern. Musste gestern auch relativ viel Stadt Bezug erlauben, war zu spät dort. Dann ist es ohnehin schwer, alles sauber nachvollziehen zu können.
@betzi @BoKo @hardl Wenn Ihr mit der Deutschland-Edition mal wieder am Leden seid, könntet Ihr dann mal auf den state "state" schauen? Mich würde interessieren, welche Werte Ihr habt, wenn die Wallbox die Ladung freigibt, aber das Auto noch keine Lust hat zu laden. Also zu einem, weil z.B. eine Abfahrtzeit/Ladetimer eingestellt ist und das Fahrzeug noch nicht lädt und zum anderen, weil das Fahrzeug bereits vollgeladen ist.
Die Werte laut Doku von Keba sind:- 0 - Wallbox fährt gerade hoch
- 1 - Wallbox wartet auf Fahrzeug (nichts angesteckt)
- 2 - Fahrzeug angesteckt, aber Fahrzeug reagiert (noch) nicht (=> dieser Status könnte kommen, wenn das Auto noch nicht laden will)
- 3 - Fahrzeug lädt (spannend, ob der Status bei Euch auch kommt, wenn nicht geladne wird, aber geladen werden könnte (Auto stoppt Ladung oder ist bereits voll)
- 4 - Fehler (sollte nicht vorkommen)
- 5 - Unterbrechung wegen Hitze oder anderer Probleme (auch nicht im Fokus)
Wenn die Wallbox trotz fehlendem EnergyMeter erkennen würde, ob das Fahrzeug lädt oder nicht, würde das bei der aktuellen Überschuss berechnung helfen. Derzeit gehe ich ja davon aus, dass das Fahrzeug mit Phasen * current * 230 lädt, sobald die Wallbox freigegeben ist. Das kann dann dazu führen, dass die Stromstärke immer weiter erhöht wird, wenn das Fahrzeug entscheidet nicht zu laden. Denn ich rechne ja immer die theoretische Ladeleistung ein und käme so jedes Mal auf einen höheren Überschuss.
Nun würde ich zusätzlich prüfen, dass ein Fahrzeug angeschlossen ist und ggfs. auch "state = 3"....
Das bringt aber nur was, wenn die Wallbox das auch erkennt und im State zurückgibt. Daher wäre es prima, Ihr könntet mir da sagen, was im state "state" bei den entsprechneden Zuständen steht. -
@lidaga So, dafür kannst du mal testen, wenn Du willst. Auf git steht eine neue Version, bei der man unter kecontact.0.automatic.limitCurrent eine Obergrenze (in mA) einstellen kann mit der geladen wird.
-
@sneak-l8 Leider lädt er jetzt nicht, unten mal meine Einstellungen.
Ist die Automatik aus lädt er mit dem eingestellten Wert.
@lidaga Danke für den Hinweis. Ich hatte mal wieder einen ganz trivialen Fehler drin. Aber das Gute ist, dass man die auf Anhieb findet :-). Der Punkt hat dazu geführt, dass er als Maximum imm limitCurrent genommen hat, auch wenn es z.B. null war.
Das Ganze erklärt aber noch nicht so ganz, warum er bei PV-Automatik nicht lädt. Mein Auto ist gerade unterwegs um es testen zu können.
Kannst Du nochmal testen und auch die anderen States die nicht auf dem Screenshot dabei waren mit anschauen? Evtl. was im Log?
Du hast eine c-Series, oder DE-Edition? -
@lidaga Danke für den Hinweis. Ich hatte mal wieder einen ganz trivialen Fehler drin. Aber das Gute ist, dass man die auf Anhieb findet :-). Der Punkt hat dazu geführt, dass er als Maximum imm limitCurrent genommen hat, auch wenn es z.B. null war.
Das Ganze erklärt aber noch nicht so ganz, warum er bei PV-Automatik nicht lädt. Mein Auto ist gerade unterwegs um es testen zu können.
Kannst Du nochmal testen und auch die anderen States die nicht auf dem Screenshot dabei waren mit anschauen? Evtl. was im Log?
Du hast eine c-Series, oder DE-Edition? -
@sneak-l8 Ich hab eine c-Series. Leider ist das Auto gerade voll, werde erst morgen wieder laden (hab Nachtschicht). Sende dann einen Screenshot.
-
@betzi @BoKo @hardl Wenn Ihr mit der Deutschland-Edition mal wieder am Leden seid, könntet Ihr dann mal auf den state "state" schauen? Mich würde interessieren, welche Werte Ihr habt, wenn die Wallbox die Ladung freigibt, aber das Auto noch keine Lust hat zu laden. Also zu einem, weil z.B. eine Abfahrtzeit/Ladetimer eingestellt ist und das Fahrzeug noch nicht lädt und zum anderen, weil das Fahrzeug bereits vollgeladen ist.
Die Werte laut Doku von Keba sind:- 0 - Wallbox fährt gerade hoch
- 1 - Wallbox wartet auf Fahrzeug (nichts angesteckt)
- 2 - Fahrzeug angesteckt, aber Fahrzeug reagiert (noch) nicht (=> dieser Status könnte kommen, wenn das Auto noch nicht laden will)
- 3 - Fahrzeug lädt (spannend, ob der Status bei Euch auch kommt, wenn nicht geladne wird, aber geladen werden könnte (Auto stoppt Ladung oder ist bereits voll)
- 4 - Fehler (sollte nicht vorkommen)
- 5 - Unterbrechung wegen Hitze oder anderer Probleme (auch nicht im Fokus)
Wenn die Wallbox trotz fehlendem EnergyMeter erkennen würde, ob das Fahrzeug lädt oder nicht, würde das bei der aktuellen Überschuss berechnung helfen. Derzeit gehe ich ja davon aus, dass das Fahrzeug mit Phasen * current * 230 lädt, sobald die Wallbox freigegeben ist. Das kann dann dazu führen, dass die Stromstärke immer weiter erhöht wird, wenn das Fahrzeug entscheidet nicht zu laden. Denn ich rechne ja immer die theoretische Ladeleistung ein und käme so jedes Mal auf einen höheren Überschuss.
Nun würde ich zusätzlich prüfen, dass ein Fahrzeug angeschlossen ist und ggfs. auch "state = 3"....
Das bringt aber nur was, wenn die Wallbox das auch erkennt und im State zurückgibt. Daher wäre es prima, Ihr könntet mir da sagen, was im state "state" bei den entsprechneden Zuständen steht.@sneak-l8 Ich konnte den Test soeben durchführen.
während das Auto gerade lädt haben wir den "state" 3 und im Wallbox Webinterface steht bei Status "charging"
nachdem das Auto voll geladen ist, hat sich der "state" auf 2 geändert und im Wallbox Webinterface steht nun "plugged"
Weiterhin verhält es sich so wie von dir vermutet nachdem das Auto voll war ist der surplus immer weiter angestiegen auf sehr hohe Werte, im Prinzip nicht schlimm das Auto ist eh voll und will kein Strom mehr haben und die Wallbox bietet dann eben die vollen 16A an findet aber keinen Abnehmer dafür :-) -
@sneak-l8 Ich konnte den Test soeben durchführen.
während das Auto gerade lädt haben wir den "state" 3 und im Wallbox Webinterface steht bei Status "charging"
nachdem das Auto voll geladen ist, hat sich der "state" auf 2 geändert und im Wallbox Webinterface steht nun "plugged"
Weiterhin verhält es sich so wie von dir vermutet nachdem das Auto voll war ist der surplus immer weiter angestiegen auf sehr hohe Werte, im Prinzip nicht schlimm das Auto ist eh voll und will kein Strom mehr haben und die Wallbox bietet dann eben die vollen 16A an findet aber keinen Abnehmer dafür :-)@boko Vielen Dank für den Test. Dann probiere mal die neuste Version von git. Dort wird nun auf "state" abgefragt und ein laden nur bei 3 angenommen. Dann sollten die Werte im Rahmen bleiben.
Schön wäre noch zu wissen, wie es sich verhält, wenn Du (sofern möglich) am Auto eine Abfahrtszeit programierst, so dass es (noch) nicht lädt. Das müsste dann 2, 3 oder 4 sein...
-
@boko Vielen Dank für den Test. Dann probiere mal die neuste Version von git. Dort wird nun auf "state" abgefragt und ein laden nur bei 3 angenommen. Dann sollten die Werte im Rahmen bleiben.
Schön wäre noch zu wissen, wie es sich verhält, wenn Du (sofern möglich) am Auto eine Abfahrtszeit programierst, so dass es (noch) nicht lädt. Das müsste dann 2, 3 oder 4 sein...
@sneak-l8 Ich konnte kurz den Test mit der programmierten Abfahrtzeit machen, hier ist der State auf 2 genau wie wenn das Auto voll ist.
Der Test mit der neusten git Version unter genauer Beobachtung der Werte folgt noch, das konnte ich jetzt noch nicht durchführen. -
@sneak-l8 Ich konnte kurz den Test mit der programmierten Abfahrtzeit machen, hier ist der State auf 2 genau wie wenn das Auto voll ist.
Der Test mit der neusten git Version unter genauer Beobachtung der Werte folgt noch, das konnte ich jetzt noch nicht durchführen.So, hab jetzt mal noch schnell die P20 in die Liste der erkannten Wallboxen aufgenommen. Mit den OEM-Boxen von BMW ist es leider nicht ganz einfach an Infos zu kommen. Keba verweist hier an den OEM und gibt keine Infos zum Aufbau der Produkt-ID oder Firmaware heraus ...
-
Hallo,
erst einmal vielen Dank für den Adapter, super Arbeit!Ich habe gestern meine Wallbox bekommen und heute den Adapter installiert und eingerichtet.
Leider erhalte ich im Log Fehlermeldungen sobald ich die Ladeleistung per PV-Überschuss regeln möchte.Settings:
Protokoll:
Ich habe zwei States gewählt, die durch ein Skript sekündlich mit den aktuellen PV-Werten (Bezug/Einspeisung) versorgt werden.
Was mache ich hier falsch?
Vielen Dank im Voraus.
-
Hallo,
erst einmal vielen Dank für den Adapter, super Arbeit!Ich habe gestern meine Wallbox bekommen und heute den Adapter installiert und eingerichtet.
Leider erhalte ich im Log Fehlermeldungen sobald ich die Ladeleistung per PV-Überschuss regeln möchte.Settings:
Protokoll:
Ich habe zwei States gewählt, die durch ein Skript sekündlich mit den aktuellen PV-Werten (Bezug/Einspeisung) versorgt werden.
Was mache ich hier falsch?
Vielen Dank im Voraus.
@exc3pt10n Installiere bitte mal die neuste Version aus git. Tritt der Fehler damit auch noch auf? Falls ja, bitte den Adapter auf debug setzen und das Log schicken (entweder hier mit Spoiler-Funktion) oder direkt als private Nachricht (PN).
-
@Sneak-L8 leider tritt das Problem nach dem Update auf 1.2.2 immer noch auf.
Hier das entsprechende Log im Debug-Modus: iobroker.2021-08-05.log.html
@exc3pt10n Kann es sein, dass Deine Netzbezug/Einspeise-Werte die Du per Skript in die States schreibst nicht bestätigst? Dann stehen die Werte rot drin? Beim Schreiben per Skript sollte Du bei setState ein true oder ack:true mitgeben.
Ich denke, daher kommen die Meldungen. Ich werde diese aber künftig auch verhindern. Denn um unbestätigte Werte die nicht vom Adapter selbt kommen, muss ich mich ja eigentlich nicht kümmern. -
@exc3pt10n Kann es sein, dass Deine Netzbezug/Einspeise-Werte die Du per Skript in die States schreibst nicht bestätigst? Dann stehen die Werte rot drin? Beim Schreiben per Skript sollte Du bei setState ein true oder ack:true mitgeben.
Ich denke, daher kommen die Meldungen. Ich werde diese aber künftig auch verhindern. Denn um unbestätigte Werte die nicht vom Adapter selbt kommen, muss ich mich ja eigentlich nicht kümmern. -
@sneak-l8 In der Tat habe ich die Werte bisher nicht bestätigt, jedoch sind die Werte dennoch grün:
Für die beiden relevanten Werte habe ich die Bestätigung nun hinzugefügt, jedoch werden noch die gleichen Fehlermeldungen geworfen.
@exc3pt10n Hm, ist es möglich, dass Du den Wert erst ohne und dann mit Acknowledge setzt? Der Adapter reagiert immer sofort auf jede Änderung, dann wäre es erklärbar.
Aber ändere erstmal nichts und teste die neuste Version auf git. Ich ignoriere jetzt ein fehlendes Acknowldge von fremden States, dann sollten die Meldungen auf weg sein.
An alle: die Erkennung der P20 wurde wurde nun nochnlas verbessert, da ich von Keba die genaue Aufschlüsselung der Produkt-ID bekommen hbae und nun auch dort korrekt a/b/c/e/x-series erkenne. -
@exc3pt10n Hm, ist es möglich, dass Du den Wert erst ohne und dann mit Acknowledge setzt? Der Adapter reagiert immer sofort auf jede Änderung, dann wäre es erklärbar.
Aber ändere erstmal nichts und teste die neuste Version auf git. Ich ignoriere jetzt ein fehlendes Acknowldge von fremden States, dann sollten die Meldungen auf weg sein.
An alle: die Erkennung der P20 wurde wurde nun nochnlas verbessert, da ich von Keba die genaue Aufschlüsselung der Produkt-ID bekommen hbae und nun auch dort korrekt a/b/c/e/x-series erkenne. -
@exc3pt10n Hm, sieht soweit gut aus. Möglicherweise ist es aber so, dass in Skripten der Wert erst ohne und unmittelbar danach mit acknowledge gespeichert wird. Dann würde es das erklären. Müsste mir fast überlegen, ob ich nicht-bestätigte Werte überhaupt im Adapter übernehmen oder nicht besser auf deren Bestätigung warte...
Aber grundsätzlich ist das Problem der Fehlermeldungen gelöst und sehe jetzt auch keinen Bedarf, das näher untersuchen zu müssen. -
@exc3pt10n Hm, sieht soweit gut aus. Möglicherweise ist es aber so, dass in Skripten der Wert erst ohne und unmittelbar danach mit acknowledge gespeichert wird. Dann würde es das erklären. Müsste mir fast überlegen, ob ich nicht-bestätigte Werte überhaupt im Adapter übernehmen oder nicht besser auf deren Bestätigung warte...
Aber grundsätzlich ist das Problem der Fehlermeldungen gelöst und sehe jetzt auch keinen Bedarf, das näher untersuchen zu müssen. -
Habe gerade nochmal ein Bugfix zur v1.2.2 auf git gestellt. Die P30-Varianten wurden versehentlich nach dem Schema der P20 erkannt, was zu Fehlern führen konnte.
560
Online32.7k
Users82.4k
Topics1.3m
Posts