[Frage] Realisierung Adapter UDP Keba Wallbox
-
@Sneak-L8
Bin jetzt wieder zuhause und habe festgestellt, dass das Laderelais des Passat GTE wohl zum 2. Mal hinüber ist.
Ich glaube jetzt auch die Ursache gefunden zu haben.
Zum Hintergrund:
Ich habe bisher immer über einen Solarlog die Laderegelung durchgeführt. Keba und Solarlog arbeiten eng zusammen und in der Applikation vom Solarlog gibt es die Unterstützung der Keba Wallbox:- Immer Laden
- Überschuss / Minimalladung
- Überschuss
- Keine Steuerung
Jetzt ist im kecontact Adapter ebenfalls die Laderegelung verfügbar (was toll ist!). Um aber Konflikte mit anderen Reglern zu vermeiden, sollte der kecontact Adapter auch in einen reinen passiven Modus zu schalten sein. (nur die Reports abfragen, in die Objekte eintragen und keinen curr Sollwert setzen)
Durch die unterschiedlichen Ladestrom Vorgaben wurde der Ladevorgang immer wieder nach der einstellbaren Abschaltverzögerung unterbrochen und wieder neu gestartet. Dieses oszillieren der Ladestromvorgaben muss verhindert werden.Außerdem wird in der neuesten Version des Keba UDP Programmers Guide V 2.01 darauf hingewiesen, dass der Stromwert während der Ladung mit currtime geändert werden soll. Das haben sie jetzt erheblich besser beschrieben, als in der alten Doku.
Unter 3.3.2 UDP command: curr steht z.B. "The only option to remove a curr setting without a restart is to over-
write it with a currtime command. In general, it is not recommended to use the curr command, since the current
can be easily controlled via the non-permanent currtime."Es wäre toll, wenn du die currtime Anforderung von Keba noch mal checken könntest.
Außerdem wären Einstelloptionen für den Adapter super:- einstellbare Leistung (als veränderbares Objekt - deckt maximale Leistung mit ab)
- PV geregelt
- keine Steuerung (nur Reports auslesen)
Gruß Hans
-
Hallo Hans,
so hatte ich das bisher noch nicht gesehen. Aber Du hast recht, solange ein Fahrzeug angesteckt ist, wird alle 30 Sekunden nachgeregelt. Entweder PV-abhängig von 0 (aus) bis maiximum oder einfach immer auf Maximum.
Da könnte ich tatsächlich noch einen Schalter einbauen (ich tendiere dazu, ihn der Konfigursation zu setzen und nicht als State), der dafür sorgt, dass grundsätzlich nichts geregelt wird und die Box sich passiv erhält.
Mir ist allerdings nicht klar, warum man immer currtime anstelle curr benutzen soll. Beide Kommandos führen doch zum selben Ergebnis und regeln auf dieselbe Art die Ladeleistung des Fahrzeugs.
Doku:
P30 complies with IEC 61851-1. This international standard requires a minimum
waiting time between two consecutive current changes. To fulfill this requirement,
all P30 will delay the execution of UDP commands requesting a
current change during a charging session. The affected commands are currtime
and curr. The request to stop charging via currtime 0 1 will not be
delayed and executed as soon as possible.Damit sollten zu viele Umschaltvorgänge o.ä. eigentlich ausgeschlossen sein.
Aber ich kann in der nächsten Version einfach anstelle curr currtime benutzen. Sollte ja dasselbe bewirken.Edit: V0.2.4 ist zum Testen online: https://github.com/Sneak-L8/ioBroker.kecontact
Viele Grüße
Sneak-L8 -
So, ich habe leider mit V0.2.5 wieder auf curr zurückwechseln müssen. Bei currtime wurde das minimale Laden nicht nach der eingestellten Mindesladedauer pausiert, weil der Ladebginn immer wieder neu gesetzt wurde. Ich vermute, weil eine Rückmeldung von der Wallbox mit 1 Sekunde Verzögerung kommt und aktuell noch ein Laden erkannt wird.
Vielleicht schreibe ich auch mal Keba direkt an und frage nach, warum man currtime vorziehen sollte.
Das muss ich mir genauer ansehen. Macht die Programmierung aber komplizierter. Aber der passive Modus ist jetzt möglich. -
Hallo Sneak-L8
die einzige Erklärung die mir dafür einfällt ist, das bei curr anders als bei currtime der Wert gespeichert wird und das wahrscheinlich zu einem Schreibvorgang auf einem internen Speicher führt. Je nach dem was hier verwendet wird (SD,SSD), kann man diese nicht unbegrenzt beschreiben. Wenn man jetzt aber ständig curr verwendet, wird dieser Speicher frühzeitig ausfallen.
Ist aber nur eine Vermutung von mir.
Wenn meine Vermutung richtig ist müsste currtime ständig neu gesendet werden, auch wenn sich der Wert nicht ändert. -
Hallo ArnoD,
ich glaube nicht, dass das Schreiben in einen SSD/SD-Speicher das Problem ist. Die Menge ist so klein und die Schreibzyklus nicht so exorbitant hoch, dass durch die autoamtische Verteilung auf den gesamten Speicher oft derselbe Bereich überschrieben wird.
Es ging hier ja auch eher un konkrete Fehler beim Fahrzeug bzw. dessen Bordlader. Das soltle man erst nehmen.
Ich habe Keba bereits angeschrieben und bin gespannt auf die Antwort. -
@Sneak-L8
Danke für die Einführung des passiven Modus. Jetzt funkt der kecontact Laderegler nicht mehr dazwischen, wenn ich mit dem Solarlog die Laderegelung realisiere.
Bin gerade dabei die PV Regelung des kecontact Adapters ausprobieren. Habe es bisher noch nicht hinbekommen.
Wird hier ein bestimmtes Energy-Meter benötigt?
Welche Einheit wird beim Objekt "Name des States für Netzbezug/Netzeinspeisung" verwendet, mW oder W?Wird bei der Stromvorgabe mit curr bei einer Wertänderung der Ladevorgang neu gestartet (Relaisklappern)?
Gruß Hans -
Hallo Hans,
Du kannst die Daten eines beliebigen EnergyMeters (EM) nehmen. Die erwartete Einheit sind Watt. Liefert Dein EM poitive und negative Werte, dann musst Du es nur einmal eintragen. Hat Dein EM getrennte State für positive und negative Werte (Netzbezug/Einspeisung), dann musst du beide angeben.
Mit dem curr-Kommando solltest Du keine Relasie hören, es ändert nur die Modulation des Signals, das ans Auto übertragen wird und mit dem mitgeteilt wird, wieviel Ampere sich das Fahrzeug an der Wallbox genehmigen darf.
Viele Grüße
Sneak-L8 -
Heute ist bereits die Antwort vom Keba-Support eingetroffen:
da der Befehl „curr“ permanent an der Wallbox gilt, sollte zum dynamischen regeln der Wallbox der Befehl „currtime“ benutzt werden.
Zu Problemen an der Fahrzeugelektronik sollte es nicht kommen.
Jedoch reagieren verschiedene Fahrzeugtypen bei zu häufiger Leistungsanpassung unterschiedlich bzw. reagiert das Fahrzeug darauf nicht mehr.Dann werden noch Mindestwartezeiten für Kommandos angegeben:
- 100ms zwischen zwei UDP-Kommandos
- 5s für die Wiederholung desselben Kommandos
- 2s nach dem Abschalten der Wallbox (z.B. ena 0)
Da ich nur alle 30 Sekunden eine neue Berechnung starte und max. zwei verschiedene Kommandos auf einmal sende (der Adapter verschickte dies dann immer in Abständen von 300ms), kann diese Anforderugn als eingehalten betrachtet werden.
D.h. so eine zwingende Begründung für currime anstelle curr gibt es nicht.
Daher lasse ich es erst mal bei 0.2.4a (sorry, ist nicht 0.2.5) bei der wieder curr benutzt wird. currtime kann ich mir mal noch genauer ansehen, sehe da jetzt aber keine Dringlichkeit. -
Wenn ich die Version https://github.com/Sneak-L8/ioBroker.kecontact über github installiere, dann ist der admin Bereich über meine IP Adresse 192.x.x.x:8081 nicht mehr erreichbar. Über iobroker.pro kann ich in den admin Bereich noch einsteigen und im log steht folgendes:
host.ioBroker-Rock 2020-07-01 16:57:47.551 error instance system.adapter.admin.0 terminated with code 1 (JS_CONTROLLER_STOPPED) host.ioBroker-Rock 2020-07-01 16:57:47.550 error Caught by controller[0]: at /opt/iobroker/node_modules/standard-as-callback/built/index.js:19:49 host.ioBroker-Rock 2020-07-01 16:57:47.549 error Caught by controller[0]: at tryCatcher (/opt/iobroker/node_modules/standard-as-callback/built/utils.js:11:23) host.ioBroker-Rock 2020-07-01 16:57:47.549 error Caught by controller[0]: at /opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:616:17 host.ioBroker-Rock 2020-07-01 16:57:47.548 error Caught by controller[0]: at /opt/iobroker/node_modules/iobroker.admin/main.js:265:30 host.ioBroker-Rock 2020-07-01 16:57:47.547 error Caught by controller[0]: at Array.forEach (<anonymous>) host.ioBroker-Rock 2020-07-01 16:57:47.547 error Caught by controller[0]: at /opt/iobroker/node_modules/iobroker.admin/main.js:268:22 host.ioBroker-Rock 2020-07-01 16:57:47.546 error Caught by controller[0]: at upToDate (/opt/iobroker/node_modules/iobroker.admin/main.js:223:16) host.ioBroker-Rock 2020-07-01 16:57:47.545 error Caught by controller[0]: at Function.gt (/opt/iobroker/node_modules/iobroker.admin/node_modules/semver/semver.js:683:10) host.ioBroker-Rock 2020-07-01 16:57:47.544 error Caught by controller[0]: at compare (/opt/iobroker/node_modules/iobroker.admin/node_modules/semver/semver.js:647:10) host.ioBroker-Rock 2020-07-01 16:57:47.543 error Caught by controller[0]: at new SemVer (/opt/iobroker/node_modules/iobroker.admin/node_modules/semver/semver.js:332:11) host.ioBroker-Rock 2020-07-01 16:57:47.541 error Caught by controller[0]: TypeError: Invalid Version: 0.2.4aAndere Version z.B 0.2.3 lassen sich nicht installieren. Ich muss den adapter löschen und die Version 0.1.0 installieren. Dann funktioniert wieder alles und ich kann den admin Bereich mit meiner IP Adresse erreichen.
Würde gerne aber meine PV Überschuß mit meiner wallbox verbinden.
Danke für Eure Hilfe. -
Also das sieht mir nach einem Fehler im Admin-Adapter aus. Er könnte aber vom Keb-Adapter ausgelöst worden sein, weil die Versions-Nr. 0.2.4a nicht ins Schema passt.
Ich habe daher die Version als 0.2.5 aktualisiert. Bitte mit dieser aktualisieren, um den Fehler im Admin-Adapter zu verhindern. -
@Sneak-L8 Hat funktioniert. Adapter lässt sich ohne Fehler installieren. Danke
-
Hallo Zusammen, ich interessiere mich auch für den Adapter. Hat schon einer die Daten in einer VIS dargestellt und würde die mal zeigen
Gruß Michael
-
Ich habe gestern und heute an einer neuen Version 0.3.0 gearbeitet, die nun currtime unterstützen wird. Bisher war diese noch nicht stabil, ich bin noch am Testen. Daher bitte mit Neuinstallationen des Adapters mal noch etwas warten ...
P.S. Sieht aber schon ganz gut aus. -
So, gerade mit der neuen Version erfolgreich PV-abhängig geladen, V0.5.0 scheint nun korrekt zu funktionieren. Link unverändert.
@Haki: wie gewünscht und von Keba empfohlen wird nun ausschließlich mit currtime anstelle curr und ena bei der PV-abhängigen Ladung und der Leistungsbegrenzung gearbeitet
Bitte gerne testen und melden, falls etwas nicht (mehr) funktioniert... -
Ich habe nochmal eine V0.3.1 nachgeschoben, bei der die "Unsitte", auch bei zu geringer PV-Leisterung trotzdem für die minimale Ladedauer ein Laden anzufangen, nun hoffentlich ausgemerzt sein sollte.
-
Und noch ein Update auf v0.3.2: die Wallbox geht sperrt das Laden nun im PV-abhängigen Laden, solange kein Fahrzeug angeschlossen ist. Sonst beginnt das Fahrzeug unweigerlich mit dem Ladevorgang bis zum ersten Mal eine Berechnung der verfügbaren Leistung erfolgt.
Da macht es beim Überschussladen mehr Sinn, erstmal zu sperren und bei Bedarf das Laden freizugeben.
Falls mit der neuen Version etwas nicht stimmt, bitte kurze Info. -
@Sneak-L8 sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
Und noch ein Update auf v0.3.2
Hi Sneak-L8
Wie ich sehe, bist du mit der Entwicklung des Adapters voran gekommen. Macht es Sinn, dass wir das wieder auf mein Repo zurück mergen (PR)? Ich werde wohl bald den Adapter in die Community verschieben und so könnten dann alle auf dieser Basis weiterarbeiten und der Adapter kann dann auch wieder standardmässig in ioBroker installiert werden.
/UncleSam
(zurück aus der Versenkung) -
@UncleSam Hallo UncleSam, freut mich, dass Du zurück bist "aus der Versenkung". Ich hatte vorhin noch gedacht: "Hm, was wohl aus meinem PR geworden ist bei UncleSam?". Daher meldest Du Dich gerade richtig.
Hatte auch überlegt, wie man ihn der Community nun allgemein zur Verfügung stellen könnte.
Prima, wenn Du das anschieben kannst!
Der PR ist schon älter, würde aber die neuen Commits mitnehmen, oder? -
Kann man über die Hercules Setup Routine auch ein script starten?
-
Hallo zusammen,
ich habe total vergessen hier zu erwähnen, dass der Adapter nun in der Tester-Rubrik zum Testen und Kommentieren gepostet wurde.
Das ist der erste Schritt auf dem Weg zu einem "offiziellen" Adapter, der dann direkt in ioBroker gefunden und installiert werden kann.
Weitere Diskussionen sollten wir dann dort weiterführen.
