NEWS
[Frage] Realisierung Adapter UDP Keba Wallbox
-
@sneak-l8 ```
Leider immer noch diese Fehler direkt nach dem Anstecken des KFZhost.raspberrypi 2025-04-02 12:48:53.291 error instance system.adapter.kecontact.0 terminated with code 6 (UNCAUGHT_EXCEPTION) host.raspberrypi 2025-04-02 12:48:53.291 error Caught by controller[1]: at Kecontact.handleJsonMessage (/opt/iobroker/node_modules/iobroker.kecontact/main.js:1191:22) host.raspberrypi 2025-04-02 12:48:53.291 error Caught by controller[1]: at Kecontact.checkWallboxPower (/opt/iobroker/node_modules/iobroker.kecontact/main.js:2252:51) host.raspberrypi 2025-04-02 12:48:53.291 error Caught by controller[1]: TypeError: authTimestamp.getTime is not a function host.raspberrypi 2025-04-02 12:48:53.290 error Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason: kecontact.0 2025-04-02 12:48:52.730 warn Terminated (UNCAUGHT_EXCEPTION): Without reason kecontact.0 2025-04-02 12:48:52.719 error authTimestamp.getTime is not a function kecontact.0 2025-04-02 12:48:52.719 error TypeError: authTimestamp.getTime is not a function at Kecontact.checkWallboxPower (/opt/iobroker/node_modules/iobroker.kecontact/main.js:2252:51) at Kecontact.handleJsonMessage (/opt/iobroker/node_modules/iobroker.kecontact/main.js:1191:22) kecontact.0 2025-04-02 12:48:52.715 error unhandled promise rejection: authTimestamp.getTime is not a function kecontact.0 2025-04-02 12:48:52.715 error Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().@gto Das ist komisch. Ich hab jetzt mal einen weiteren Debug-Eintrag gemacht, um zu sehen, was in authTimestamp drinsteht. Kannst Du mal schauen, was bei statistics.authPlugTimestamp steht? Vermutlich aktuell nichts (null), aber wenn der Abbruch auftritt. Das wäre hilfreich für die weitere Analyse.
Also bitte mal mit der Version von git.P.S. In Deinem Log steht auch Deine Email-Adresse drin. Solltest du vielleicht aus-x-en ...
-
@gto Das ist komisch. Ich hab jetzt mal einen weiteren Debug-Eintrag gemacht, um zu sehen, was in authTimestamp drinsteht. Kannst Du mal schauen, was bei statistics.authPlugTimestamp steht? Vermutlich aktuell nichts (null), aber wenn der Abbruch auftritt. Das wäre hilfreich für die weitere Analyse.
Also bitte mal mit der Version von git.P.S. In Deinem Log steht auch Deine Email-Adresse drin. Solltest du vielleicht aus-x-en ...
-
@sneak-l8 Ich habe nach nochmaliger Installation von git jetzt einen Versuch gemacht, es ist kein Fehler aufgetreten. Im statistics.authPlugTimestamp stehen Datum und Uhrzeit des Ansteckens. Die nächsten Tage teste ich weiter.
@gto Ok, danke. Dann hattest du evtl. doch noch nicht die korrigierte Version. Ich hab hauptsächlich das Log erweitert und nur neben "null" nun auch auf einen leeren String beim Auslesen vom state statistics.authPlugTimestamp abgefragt. Dann hätte er aber eigentlich schon beim auslesen abbrechen müssen.
-
@gto Ok, danke. Dann hattest du evtl. doch noch nicht die korrigierte Version. Ich hab hauptsächlich das Log erweitert und nur neben "null" nun auch auf einen leeren String beim Auslesen vom state statistics.authPlugTimestamp abgefragt. Dann hätte er aber eigentlich schon beim auslesen abbrechen müssen.
@sneak-l8 Ich habe heute Abend ein" komisches" Verhalten beobachtet.
-
Versuch: erst Auto angesteckt, danach Freigabe. Box wird grün, dann blau wie es sein sollte, das Auto hatte aber nie geladen. Beginn im LOG
-
Versuch: erst Freigabe, dann Auto angesteckt. Im Auto keine Ladung angezeigt, im Wallboxdisplay "Kabel anstecken" obwohl dieses im Auto verriegelt ist. STATE bleibt auf 2.
Log ab Zeile 1000
Findest du im LOG einen Fehler?
Könnte es sein, dass mein Auto die Ladung nicht einphasig mit 6A starten kann?
Wenn ich nach längerer Zeit die PV-Automatik deaktiviere, startet die Ladung mit voller Leistung, so wie es sein sollte. Ein Fehler bei der Autorisierung kann es dann ja nicht sein. Vielleicht doch nach dem Anstecken dreiphasig mit maximalen A starten? -
-
@sneak-l8 Ich habe heute Abend ein" komisches" Verhalten beobachtet.
-
Versuch: erst Auto angesteckt, danach Freigabe. Box wird grün, dann blau wie es sein sollte, das Auto hatte aber nie geladen. Beginn im LOG
-
Versuch: erst Freigabe, dann Auto angesteckt. Im Auto keine Ladung angezeigt, im Wallboxdisplay "Kabel anstecken" obwohl dieses im Auto verriegelt ist. STATE bleibt auf 2.
Log ab Zeile 1000
Findest du im LOG einen Fehler?
Könnte es sein, dass mein Auto die Ladung nicht einphasig mit 6A starten kann?
Wenn ich nach längerer Zeit die PV-Automatik deaktiviere, startet die Ladung mit voller Leistung, so wie es sein sollte. Ein Fehler bei der Autorisierung kann es dann ja nicht sein. Vielleicht doch nach dem Anstecken dreiphasig mit maximalen A starten?@gto sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
LOG.txt
Mein Auto (Polestar) lädt nicht, wenn er nach dem Anstecken keinen Strom bekommt. Aus dem Zustand bekommt man ihn auch nicht wieder raus, ohne ihn abzustecken. Erst wenn er im Zustand "charging" war, kann man die Box disablen.
Viellicht ist das bei dir ähnlich. -
-
@gto sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
LOG.txt
Mein Auto (Polestar) lädt nicht, wenn er nach dem Anstecken keinen Strom bekommt. Aus dem Zustand bekommt man ihn auch nicht wieder raus, ohne ihn abzustecken. Erst wenn er im Zustand "charging" war, kann man die Box disablen.
Viellicht ist das bei dir ähnlich. -
@fernetmenta hat deine Wallbox einen RFID-Leser?
@gto nein, ich habe das Scenario, das ich beschrieben habe, aber so getestet. Ich habe auch mal zugeschaut, wie mein Auto in einem Hotel angesteckt wurde. Die haben erst den Stecker rein und die Box dann mit einer Karte freigeschaltet -> Das Auto hat nicht geladen. Man musste erst die Box freischalten und dann einstecken. So wie an Bezahl-Ladesäulen.
-
@gto nein, ich habe das Scenario, das ich beschrieben habe, aber so getestet. Ich habe auch mal zugeschaut, wie mein Auto in einem Hotel angesteckt wurde. Die haben erst den Stecker rein und die Box dann mit einer Karte freigeschaltet -> Das Auto hat nicht geladen. Man musste erst die Box freischalten und dann einstecken. So wie an Bezahl-Ladesäulen.
@fernetmenta @gto
Eventuell liegt das am Auto? Wie schon vorher einmal geschildert, ich stecke immer vorher an und dann erst die Karte (egal ob zu Hause mit der Keba P30 X oder öffentlich) - habe eine Tesla. -
@fernetmenta @gto
Eventuell liegt das am Auto? Wie schon vorher einmal geschildert, ich stecke immer vorher an und dann erst die Karte (egal ob zu Hause mit der Keba P30 X oder öffentlich) - habe eine Tesla.Ich hatte früher ein Script, das nach dem Anstecken direkt PV automatics aktiviert hat. Das hat nicht funktioniert. Ich kann PV automatics erst aktivieren nachdem State in "charging" ist. Sonst denkt das Auto es läuft was schief, weil es keinen Strom bekommt, und schaltet auf Fehler.
-
@fernetmenta @gto
Eventuell liegt das am Auto? Wie schon vorher einmal geschildert, ich stecke immer vorher an und dann erst die Karte (egal ob zu Hause mit der Keba P30 X oder öffentlich) - habe eine Tesla. -
@sneak-l8 Ich habe heute Abend ein" komisches" Verhalten beobachtet.
-
Versuch: erst Auto angesteckt, danach Freigabe. Box wird grün, dann blau wie es sein sollte, das Auto hatte aber nie geladen. Beginn im LOG
-
Versuch: erst Freigabe, dann Auto angesteckt. Im Auto keine Ladung angezeigt, im Wallboxdisplay "Kabel anstecken" obwohl dieses im Auto verriegelt ist. STATE bleibt auf 2.
Log ab Zeile 1000
Findest du im LOG einen Fehler?
Könnte es sein, dass mein Auto die Ladung nicht einphasig mit 6A starten kann?
Wenn ich nach längerer Zeit die PV-Automatik deaktiviere, startet die Ladung mit voller Leistung, so wie es sein sollte. Ein Fehler bei der Autorisierung kann es dann ja nicht sein. Vielleicht doch nach dem Anstecken dreiphasig mit maximalen A starten?@gto Guten Morgen, wenn ich ins Log schaue, dann steht da noch Authreq = 1 (im State wäre das true). Das würde bedeuten, dass die Autorisierung noch nicht abgeschlossen ist. Komisch ist dann aber, warum currtime 6000 1 trotzdem akzeptiert wird.
Um 2025-04-03 19:34:45.666 erscheint aber der Debug-Hinweis, der erkennt, dass angesteckt und Autorisiert ist (authTimestamp is object).
Was mich weiter verwundet ist, wie aus dem nummerischen Wert von 1 dann das true im State werden soll.
Aber grundsätzlich schreibst Du ja, dass es funktioniert.
Aber laut Log war eben keine Freigabe zum Laden da ...
Um 19:34:56 ist dann die Freigabe da. Da sieht man dann auch, dass currUser = 1 ist. Das Laden ist also freigegeben. der "report 100" zeigt auch einen begonnenen Ladevorgang an.
Um 19:35:25.066 sieht man, dass jetzt auch weiterhin der Ladevorgang freigegeben ist (authTimestamp is object), aber es wird nicht versucht, die Ladung aufrecht zu erhalten, denn dann beendet er das Laden wieder.
Ich hab an dieser Stelle das Debug-Log nochmals erweitert um zu sehen, an was es liegt. Kannst Du nochmal testen? Es scheint an der Abfrage zum aufrechterhalten zu liegen, die nicht greift.An einer vertauschten Phase beim Anschluss kann es nicht liegen, weil die Steuerung der Wallbox ja auch auf Phase 1 liegen muss...
-
-
@gto Guten Morgen, wenn ich ins Log schaue, dann steht da noch Authreq = 1 (im State wäre das true). Das würde bedeuten, dass die Autorisierung noch nicht abgeschlossen ist. Komisch ist dann aber, warum currtime 6000 1 trotzdem akzeptiert wird.
Um 2025-04-03 19:34:45.666 erscheint aber der Debug-Hinweis, der erkennt, dass angesteckt und Autorisiert ist (authTimestamp is object).
Was mich weiter verwundet ist, wie aus dem nummerischen Wert von 1 dann das true im State werden soll.
Aber grundsätzlich schreibst Du ja, dass es funktioniert.
Aber laut Log war eben keine Freigabe zum Laden da ...
Um 19:34:56 ist dann die Freigabe da. Da sieht man dann auch, dass currUser = 1 ist. Das Laden ist also freigegeben. der "report 100" zeigt auch einen begonnenen Ladevorgang an.
Um 19:35:25.066 sieht man, dass jetzt auch weiterhin der Ladevorgang freigegeben ist (authTimestamp is object), aber es wird nicht versucht, die Ladung aufrecht zu erhalten, denn dann beendet er das Laden wieder.
Ich hab an dieser Stelle das Debug-Log nochmals erweitert um zu sehen, an was es liegt. Kannst Du nochmal testen? Es scheint an der Abfrage zum aufrechterhalten zu liegen, die nicht greift.An einer vertauschten Phase beim Anschluss kann es nicht liegen, weil die Steuerung der Wallbox ja auch auf Phase 1 liegen muss...
@sneak-l8 Die Phasenlage ist 100%ig korrekt.
Ich bin bald zu Hause und kann testen. Mein Verdacht nach liegt es eher daran, dass das Auto zum Beginn einen dreiphasigen Ladevorgang benötigt, zumindest hatte ich das in meinem Script so und es hat funktioniert. -
@sneak-l8 Die Phasenlage ist 100%ig korrekt.
Ich bin bald zu Hause und kann testen. Mein Verdacht nach liegt es eher daran, dass das Auto zum Beginn einen dreiphasigen Ladevorgang benötigt, zumindest hatte ich das in meinem Script so und es hat funktioniert.@Sneak-L8 : ich habe auch ab und an (genau habe ich noch nicht recherchiert) ein Problem beim Starten eine Session, wenn er dann gleich nur 1 Phasig loslegt - er lädt dann einfach nicht. Wenn er 3 Phasig startet, dann passt es. Kann man einen Switch einbauen, wo man auswählen kann, das er immer beginnt 3phasig zu laden?
-
@Sneak-L8 : ich habe auch ab und an (genau habe ich noch nicht recherchiert) ein Problem beim Starten eine Session, wenn er dann gleich nur 1 Phasig loslegt - er lädt dann einfach nicht. Wenn er 3 Phasig startet, dann passt es. Kann man einen Switch einbauen, wo man auswählen kann, das er immer beginnt 3phasig zu laden?
-
Mein Verdacht nach liegt es eher daran, dass das Auto zum Beginn einen dreiphasigen Ladevorgang benötigt
Wäre das nicht seltsam. Dann könntest du ja nie mit einem Ladegerät laden, dass nur eine Phase hat.
@fernetmenta Das sehe ich auch so.
Wie oben geschrieben, ich sehe, dass der Adapter bei meiner Steuerung den Ladevorgang gleich wieder einstellt, sobald die Autorisierung vorhanden ist. Deshalb hab ich die neue Version auf git gebaut. Die behebt den Fehler nicht, aber druckt mir ein paar mehr Infos in Debug-Log in der Hoffnung, dem Problem damit auf die Schliche zu kommen. -
@fernetmenta Das sehe ich auch so.
Wie oben geschrieben, ich sehe, dass der Adapter bei meiner Steuerung den Ladevorgang gleich wieder einstellt, sobald die Autorisierung vorhanden ist. Deshalb hab ich die neue Version auf git gebaut. Die behebt den Fehler nicht, aber druckt mir ein paar mehr Infos in Debug-Log in der Hoffnung, dem Problem damit auf die Schliche zu kommen.@sneak-l8 Hallo Sneak, ich habe jetzt ohne Sonne das ganz nochmals versucht.
Die Anzeige an der Box "Kabel anstecken kommt wohl, da STATE länger auf 2 bleibt und erst nach über einer Minute auf 3 springt. Das kommt wohl vom Auto und ich war bislang zu ungeduldig. Es scheint alles perfekt zu laufen.
Ein herzliches Danke -
@sneak-l8 Hallo Sneak, ich habe jetzt ohne Sonne das ganz nochmals versucht.
Die Anzeige an der Box "Kabel anstecken kommt wohl, da STATE länger auf 2 bleibt und erst nach über einer Minute auf 3 springt. Das kommt wohl vom Auto und ich war bislang zu ungeduldig. Es scheint alles perfekt zu laufen.
Ein herzliches Danke -
@gto Hm, komisch, die Logs gaben dir aber recht. Schicke gerne noch mal einen Auszug des Logs, wenn das Auto angesteckt und autorisiert ist, bis er die Minute mal geladen hat.
@sneak-l8 Ich bin mir sicher, dass das Verhalten vom Laderegler oder der Software des Autos kommt. Der verzögerte Ladebeginn tritt auf wenn erst angesteckt und dann autorisiert wird aber auch umgekehrt und auch wenn die PV-Automatik aus ist. Zum Ausschluss eines Adapterproblems habe ich auch einmal den Adapter deaktiviert und geladen, auch so vergeht die Minute bis zum Ladebeginn. Muss also das Auto sein.
Wann stellst du die aktuelle Git-Version auf stable? -
@tminimax Die Reihenfolge ist für mein Auto egal, sofern ich die PV-Automatik deaktiviert habe. Nur bei aktiver Automatik lädt er nicht ,weshalb ich glaube, dass das Problem vom einphasigen 6A-Start kommt.
@gto sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
@tminimax Die Reihenfolge ist für mein Auto egal, sofern ich die PV-Automatik deaktiviert habe. Nur bei aktiver Automatik lädt er nicht ,weshalb ich glaube, dass das Problem vom einphasigen 6A-Start kommt.
Hallo genau diesen Effekt habe ich auch, aber erst seitdem dich ich auf die 3.xx version umgestiegen bin.
Mit der 2.3.0 kannte ich den Fehler nicht.
Aktuell 3.1.0 ist kein Laden im Automatic möglich.
Da meine Keba P30 Box nach der ersten Autoriesierung nicht Läde und dann sich nicht mehr Autoriesieren läst.
Nur im nicht PV_Auomatik Modus Funktioniert die Karten :-( -
@gto sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
@tminimax Die Reihenfolge ist für mein Auto egal, sofern ich die PV-Automatik deaktiviert habe. Nur bei aktiver Automatik lädt er nicht ,weshalb ich glaube, dass das Problem vom einphasigen 6A-Start kommt.
Hallo genau diesen Effekt habe ich auch, aber erst seitdem dich ich auf die 3.xx version umgestiegen bin.
Mit der 2.3.0 kannte ich den Fehler nicht.
Aktuell 3.1.0 ist kein Laden im Automatic möglich.
Da meine Keba P30 Box nach der ersten Autoriesierung nicht Läde und dann sich nicht mehr Autoriesieren läst.
Nur im nicht PV_Auomatik Modus Funktioniert die Karten :-(@rolf-sauer Hast du mal die github-Version des Adapters versucht? Geht es damit wieder?
(Installation => im ioBroker oben in der Leiste das Icon mit der Sturmhaube anklicken (erweiterter Modus). Dann das Katzensymbol und im Reiter git "kecontact" eingeben)
967
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge