[Frage] Realisierung Adapter UDP Keba Wallbox
-
@gto Die Wallbox selbst wird über den Adapter weiterhin wie in der Urpsrungsversion (Skript) angesprochen. Es sind dieselben Berechnungen angestellt worden, um die Ladeleistung zu setzen (Ok, manche Berechnung wurde mit der Zeit noch optimiert).
Und richtig, nur regulate und switch ändern den Ladevorgang. Beim Skript hab es noch keine Möglichkeit, eine Meldung anzuzeigen.
Die Möglichkeit über einen neuen State Text an der Wallbox anzuzeigen kam erst in einer späteren Version des Adapters hinzu, der dann bereits selbst die PV-abhängige Ladesteuerung implementiert hatte. -
@Haki Hallo Hans,
Max Current ändere ich nicht. Das lese ich nur aus. Ich meine, der ist sowieso read-only, weil "max curr" über Dip-Schalter ander Wallbox eingestellt wird.
Ich nutze nur "enable" und "curr".
Zum Testen kann man den Adapter gerne im Debug-Modus betreiben. Dann gibt er relativ viel aus. Vor allem auch, wenn er die Ladeleistung der Box ändert oder die Ladung startet/beendet.
Ich vermute, dass sich die Ladeleistung ändert, ohne dass es zu einem Debug-Log kommt. Dann wird die Ladeleistung durch andere Umstände verändert. Was für eine P30 ist es denn genau (c-Serie, x-Serie, ...)? -
@Sneak-L8 es ist die b-series
KC-P30-EC240122-E00
Firmware P30 v 3.10.7 (191213-101735) .
Wird bei dir curr n gesetzt, selbst wenn die PV Regelung abgeschaltet ist?
Falls ja auf welchen Wert? Und könnte man diesen Wert vielleicht als Objekt während der Laufzeit im Adapter einstellbar machen?
Gruß Hans -
@Sneak-L8
Danke für deine Antwort. Ich glaube meinen Fehler gefunden zu haben:
Als dein Adapter neu war konnte dieser ja nicht korrekt gestartet werden. Daher hatte ich am Laptop eine iobroker-Versioin zum Testen installiert. Diese war nicht beendet, also haben 2 iobroker die Wallbox gesteuert, das muss schief gehen. Entschuldige die Umstände die ich dir bereitet habe. -
@gto kein Problem. Ist doch super, wenn die Ursache gefunden wurde. So ist nun auch die Lösung dokumentiert und es bleibt keine Frage offen, ob der Adapter korrekt funktioniert.
-
@Haki nein, curr regelt nur die Leistung, mit enable wird die Ladung aktiviert und beendet.
Wenn keine lastabhängigen Werte hinterlegt sind, dann sollte auch kein curr gesendet werden. Wenn Du "nur" maximale Leistung wählst, dann wird curr mit dem Wert max curr gesendet -
@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...
