[Frage] Realisierung Adapter UDP Keba Wallbox

[mcm1957]

@hs911
Bitte logs immer als Text posten und nicht als Bildchen.

Kannst du mal schaun was du vom adapter-core installiert hast?
pi@pi4:/opt/iobroker $ cd /opt/iobroker
pi@pi4:/opt/iobroker $ npm ls @iobroker/adapter-core

[hs911]

@sneak-l8 ich habe nach dem Downgrade jetzt den Adapter noch mal aktualisiert, um nach den Antworten auf die von dir gestellten Fragen zu schauen. Nun startet er ohne Fehler. Warum wieso weshalb kann ich nicht sagen, aber zum Zeitpunkt des ersten Updates war js-controller noch auf 6.0.11..

Ich beobachte weiter

[mcm1957]

@hs911
Die Info bezüglich adapter-core wär trotzdem von interesse...

[hs911]

@mcm1957 kein Problem, gerne:

OpenSUSE:/opt/iobroker # npm ls @iobroker/adapter-core
iobroker@3.1.0 /srv/iobroker
├─┬ iobroker.admin@7.6.2
│ ├── @iobroker/adapter-core@3.2.3 overridden
│ └─┬ @iobroker/socket-classes@2.2.0
│   └── @iobroker/adapter-core@3.2.3 deduped
├─┬ iobroker.javascript@8.9.1
│ └── @iobroker/adapter-core@3.2.3 deduped
├─┬ iobroker.kecontact@3.0.0
│ └── @iobroker/adapter-core@3.2.3 deduped

hab es zusammen gekürzt und die anderen Adapter weggelassen. Passt das?

[mcm1957]

@hs911
Ja danke passt.
Adpater-core ist nun aktuell.

Das Problem könnte durch den js-controller 6 ausgelöst worden sein. Diese setzt aus kompatibilitätsgründen einen override auf adapter-core 3.1.2. Nur die ist zu alt für i18n Support und der Adapter spezifiziert zwar dass er 3.2.x braucht aber durch das Override überstimmt ihn der controller.

Um das zu verifiziern bräcucht ich / man ein System das noch js-controller 6 hat. Und zwar native js.controller 6 installiert bekan oder von js.controlle 5 auf 6 aktualisisert wurde - also KEIN System mit Downgrade des js-controllers von 7 auf 6.

Wenn ich richtig liege sollte der Adapter dort crashen. Und die npom Abfrage von adapter-code sollte ein 3.1.x zeigen...

[Sneak-L8]

@mcm1957 mit einem js-Controller 6 kann ich nicht dienen. Aber dann würde ich einen Check auf I18n === undefined machen und auf js-controller >= 7 hinweisen, oder?
Das mache ich im onReady(). Was kann ich da tun, um den Start des Adapters zu verhindern?
Wenn bisher da was schief läuft, dann mache ich nur einen return. Aber dann ist der Adapter erst mal da, nur tut er nichts...

[Sneak-L8]

@sneak-l8 Hab das jetzt mal so angepasst (auch Deine Issues, zumindest die ,die ich beeinflussen kann).

[mcm1957]

@sneak-l8 said in [Frage] Realisierung Adapter UDP Keba Wallbox:

@mcm1957 mit einem js-Controller 6 kann ich nicht dienen. Aber dann würde ich einen Check auf I18n === undefined machen und auf js-controller >= 7 hinweisen, oder?
Das mache ich im onReady(). Was kann ich da tun, um den Start des Adapters zu verhindern?
Wenn bisher da was schief läuft, dann mache ich nur einen return. Aber dann ist der Adapter erst mal da, nur tut er nichts...

Nö - die saubere Lösung ist in den dependencies js-controller 7 zu verlangen. Ein Hinweis im Adaptercode ist NICHT notwendig und nicht sinnvoll, dazu gibt es ja genau die dependency in io-package,json. Die verhindert die Installation und das Startup auf einem zu alten System

[Sneak-L8]

@mcm1957 Ah, da gibt es ja doch ne Option dazu. Welche Version sollte ich angeben? >=7.0.0 oder was Konkreteres?

[mcm1957]

@sneak-l8
Hab dir nen PR erstellt. Da sieht du die Anpassung.

>= 7.0. sollte an sich genügen. Persönlich setz ich aber immer die zur Zeit der Anpassung im STABLE verfügbare Version ein. 7.0.6 ist nun schon 96 Tage alt - also durchaus als stabil zu betrachten. Und innerhalb eine major Release sind js-controller Updates ja nur bugfixes und sollten sowieso zeitnahe erfolgen.

Man kann in io-package spezifizieren welche andere Adapterversion ein Adpater voraussetzt, zu 99% ist das js-controller und admin. Wenn die nicht passen gibts bei der Installation eine Meldung und der Adapter lässt sich auch nicht starten. Damit sieht der User dann dass er was tun muss.

[Sneak-L8]

@mcm1957 Genau diese Spezifikation hatte ich beim ersten Schauen nicht gefunden. Habe jetzt nicht Deinen PR akzeptiert, weil da noch eine Änderung in den Beschreibungen der README geändert wurde (vermutlich versehentlich). Hab es mit meinem nächsten Commit mitgemacht.

[gto]

@sneak-l8 Hallo Sneak, bei der Ladelimitierung habe ich keine Fehler mehr gefunden.
Jetzt aber das ABER: Ich habe gerade die PV-Automatik aktiviert, der Modus der Akkusteuerung ist 2, also erst Batterie laden. Trotzdem lädt das Auto bereits seit längerer Zeit mit 1,4kW obwohl der Akku nicht voll ist. Eigentlich sollte der Ladestrom jetzt angepasst werden, es regelt sich aber nur die Akkuladung (durch den WR).
Welche Information brauchst du zusätzlich um den Fehler zu finden?
LOG.txt
Eine andere Sache habe ich auch beobachtet, muss sie aber nochmals verifizieren, da ich in der Box noch etwas umgestellt habe: Wenn beim Anstecken des Fahrzeuges die PV-Automatik aktiviert ist aber zuwenig Strom für eine Ladung produziert wird, verfällt die RFID-Authorisierung nach etwa einer Minute. Startet man ohne Automatik und schaltet diese dann ein läuft es. Ich teste noch mehrere Abläufe mit einem Script, mit diesem schalte ich bei oben beschriebener Einstellung für eine Minute die Automatik aus und dann wieder ein.

[gto]

@sneak-l8 Es ist tatsächlich so, dass "kecontact.0.authreq" auf true springt wenn die PV-Automatik an ist und nicht sofort eine Ladung startet.
Was hältst du von einer Funktion (analog zu einer Standardfunktion bei der P30x) "Boost": Ladung mit voller Leistung nach dem Anstecken und RFID-Freigabe bei aktivierter PV-Automatik für eine einstellbare Zeit?

Mein Script als Zwischenlösung:

on({ id: 'kecontact.0.plug' /* Plug */, change: 'ne' }, async (obj) => {
  let value = obj.state.val;
  let oldValue = obj.oldState.val;
  if ((obj.state ? obj.state.val : '') == 7 && getState('kecontact.0.automatic.photovoltaics').val == true) {
    setState('kecontact.0.automatic.photovoltaics' /* photovoltaics automatic enabled */, false, true);
    timeout2 = setTimeout(async () => {
      timeout2 = null;
      setState('kecontact.0.automatic.photovoltaics' /* photovoltaics automatic enabled */, true, true);
    }, parseInt(60000));
  }
});

[Sneak-L8]

@gto Aktuell ist die Logik bei dieser Strategie recht träge. Wenn die Batterie gerade geladen wird, dann soll dieser Überschuss nicht fürs Laden des Autos genutzt werden. Das Auto wird aber nicht aktiv gedrosselt, um die Batterie stärker laden zu können.

Eine andere Vorgehensweise ist schwieriger. Bespiel:

• PV-Überschuss aktuell 5 kW
• Auto lädt mit 2kW
• Batterie mit 3kW
• Batterie kann mit 4kW laden

Man könnte die Batterie jetzt mit 4 kW laden. Das würde bedeuten, dass 1 kW PV-Überschuss ins Netz gedrückt wird, anstatt ins Auto. Macht das Sinn?

Beim zweiten Beispiel weiß ich nicht, wie sich die Batterie verhält (hab leider noch keine):

• Batterie könnte sogar 5kW laden

Lädt sie mit 3 kW, weil das Auto 2kW lädt oder ist sie schon so voll, dass die Ladeleistung der Batterie auf 3 kW gedrosselt ist? Dann würde dann Auto unnötig auf 2 kW Ladeleistung verzichten.

Wie bildet man diese Fälle sinnvoll ab?

[Sneak-L8]

@gto Ist das eine Funktion, die man oft braucht? Ich hab mir lieber ein Skript gemacht, das die PV-Automatik deaktiviert, wenn ich in der vis ein Ladeziel vorgebe. Wenn das erreicht ist, wird wieder auf Automatik zurückgeschalten (und der Mindest-SoC wieder gelöscht). Das geht über den Adapter nicht, weil er den SoC des angesteckten Fahrzeugs nicht kennt. Ein Konfig-Feld passt auch nicht, da ich ja nicht weiß, ob es immer das gleiche Auto ist.
Und das ist zu viel Sonderlocke, um es in den Adapter zu bauen.
Dein Skript tut ja, was es soll. Wenn sich andere auch für diese Boost-Option erwärmen können, würde ich es nochmal in Erwägung ziehen.

Der Zusammenhang mit dem 1. Satz Deines Posts ist mir allerdings nicht klar ...

[gto]

@sneak-l8 Die Formulierung des ersten Satzes und die Überleitung waren leider schlecht formuliert, es sollte kein Zusammenhang hergestellt werden.

Akku: Ich gebe dir recht, dass es eine schwierig zu steuernde Problematik ist. Bevor man ins Netz einspeist ist natürlich die Autoladung besser. Bis zu einem SOC von 95% (danach greift der Wechselrichter in den Akkuladestrom ein) könnte man aber vor der Steuerung der Box noch prüfen, ob die berechnete Boxladung + aktueller Akkuladung kleiner der maximalen Akkuladeleistung ist (in den Einstellungen bereits eingetragen). In diesem Falle dürfte das Auto nicht laden.

Die RFID-Problematik kann ich natürlich per Script lösen, es dürfte alle RFID-Nutzer betreffen, zumindest diejenigen, die eine P30x haben. Gerade in den Sommermonaten stellen sicher viele den Adapter auf Automatik und stecken das Fahrzeug an um den Überschuss sobald er vorliegt ins Auto zu speisen, gerade am Wochenende. Aktuell muss man aber immer kontrollieren, ob bereits PV-Überschuss vorliegt und dann die Kartenfreigabe durchführen. Macht man dies zu früh, geht die Freigabe nach kurzer Zeit verloren, ist man zu spät wird der PV-Strom ins Netz gespeist. Den KFZ-SOC benötigst du nicht.

Ich kann mir 3 Lösungen vorstellen:

1. Falls Wechsel des Wertes Plug auf 7 (KFZ angesteckt) und PV-Automatik = true und authreq = true die PV-Automatik auf false setzen und Warten bis authreq = false dann PV-Automatik wieder auf true

2. Falls Wechsel des Wertes Plug auf 7 (KFZ angesteckt) und PV-Automatik = true und authreq = true die PV-Automatik auf false setzen, für einen in den Einstellungen vorzugebenden Zeitraum warten und dann PV-Automatik wieder auf true setzen.

3. Du sendest bei aktiver PV-Automatik vor der Ladefreigabe den RFID neu.

LG Thomas

[Sneak-L8]

@gto Ok, verstehe.

Zum Akku: ist das bei allen Batterien so, dass sie erst ab 95% drosseln? Sonst müsste man das auch als Einstellung anbieten.
Dann bliebe der Logik unverändert, solange die Batterie einen SoC > dem vorgenannten Schwellwert ist.
Darunter wäre die Ladeleistung Surplus - Consumption + aktuelle Ladeleistung Wallbox + aktuelle Ladeleistung der Batterie - aktuelle Entladeleistung der Batterie + max. Ladeleistung der Batterie

Das bedeutet dann aber, dass das Auto ggf. nicht geladen und PV-Überschuss "verschenkt" (ins Netz gespeist) wird.

Ist das so richtig?

[Sneak-L8]

@gto Das mit der RFID muss ich mir noch in Ruhe anschauen. Ich tendiere dann aber dazu, mir die Freigabe zu merken und per Adapter automatisch für eine Freigabe zu nutzen. PV-Automatik ist ja für den User da und wenn ich da eingreife, dann würde der User-Wunsch ggf. überschrieben.

[gto]

@sneak-l8 zu RFID: Der letzte Freigabecode wird ja bereits unter kecontact.0.statistics.rfid_tag gemerkt. Diesen bei Wiederaufnahme der Ladung neu zu schicken ist sicherlich am elegantesten. Aber Achtung: Die Box gibt zum Adapter den RFID mit 2 angehängten 0er zurück die du wieder abschneiden musst. Diesbezüglich hattest du bereits weiter oben mit tminimax geschrieben.

zum Akku: Ein einstellbarer Schwellenwert wäre natürlich großartig, dann ist man auch zukünftig flexibel. Wer weiß schon wie die Batterien und Wechselrichter mit den Firmwareänderungen ihr Verhalten ändern.
Kannst du um keinen Strom zu verschenken eine Überprüfung einbauen, die bei Unterschreiten der 6A Ladeleistung des KFZ und laufender Ladung des Akkus anspricht und die Autoladung einphasig mit 6A weiterlaufen lässt?

[Sneak-L8]

@gto Die Logik für die Batterie-Strategie 2 habe ich jetzt mal angepasst. Die dt. Texte muss ich in Weblate noch überarbeiten, sind aber noch gesperrt. Sonst sollte es jetzt funktionieren.
Die Logik den Ladestrom für die Batterie dann doch zu begrenzen, habe ich erst mal außen vor gelassen. Da müsste ich tiefer eingreifen, weil die Routine isoliert die Batteriewerte rechnet. Jetzt bräuchte ich dort die Infos zum Ladevorgang (1p/3p, Mindeststromstärke).
Schauen wir erst mal, ob es so fukntioniert.