[Frage] Realisierung Adapter UDP Keba Wallbox

[gto]

@sneak-l8 Guten Morgen Sneak, habe gerade wieder einen Test laufen lassen.
Wenn die Ladelimitierung greift, wird die Ladung der geregelten Box unterbrochen und nach einigen Sekunden mit neuen Einstellungswerten neu gestartet.
Dies geschieht nicht, wenn das komplette System "Haus" stabil Strom bezieht. Sind aber dann Geräte ein und wieder mal ausgeschaltet kommt es zu Schwankungen der Last und die Box schaltet ständig ein/aus.
Sollte nicht nur die eingestellte Ladeleistung ohne Ladeunterbrechung reduziert werden?
ab 7:35:46 im LOG

LOG.txt

Der Ladevorgang startet einphasig und schaltet später auf dreiphasig. Kommt das von der Box oder vom Adapter?

Habe mir jetzt auch noch den Modbus-Adapter eingerichtet, jetzt kommen die Phasenwerte tatsächlich im Sekundentakt. Im LOG aber noch mit dem langsameren Froniusadapter.

[Sneak-L8]

@gto Danke fürs Log. Konnte noch einen Bug finden. Beim "Zwischenregeln" habe ich eine falsche Variable genutzt und die war immer 0. Daher wurde immer abgeschaltet. Sollte mit der neuen Version auf git korrigiert sein.

[gto]

@sneak-l8 Danke, morgen wird getestet

[gto]

@sneak-l8 Bei den heutigen Tests konnte ich keine Fehler erkennen. Es scheint alles top zu funktionieren.
Nochmals herzlichen Dank für Deine Bemühungen.

[Sneak-L8]

@gto gerne. Danke auch Dir für das ausführliche Testen! Dann lege ich mal ein neues Release an ...

[gto]

@sneak-l8 Hallo Sneak, ich habe doch noch etwas gefunden.
Folgendes Szenario:
An der geregelten Wallbox wird dreiphasig mit 16A bzw 10700W geladen
aktuelle PV-Leistung 1926W
Leistung aus Akku ins Hausnetz 7164W
Bezug aus dem Stromnetz am Foto (16:19)

Die Berechnung des Adapters liefert maxAmperage 43000mA, es dürften aber nur 27500mA sein.
Die Phasenwerte kommen aus dem Modbus-Adapter im Sekundentakt.
LOG.txt
Kann es sein, dass du die aktuelle Ladeleistung der geregelten Wallbox abziehst? Die maxAmperage darf sich aber nur auf die Phasenwerte beziehen, also die Leistung die noch aus dem Stromnetz entnommen werden darf (maxAmperage = max. Phasenlast - stärkste Phase).

Noch ein 2. Beispielfoto (scheint aber im LOG nicht auf) ohne Leistung aus Akku und PV

[Sneak-L8]

@gto Um 16:18:55 sehe ich: amperage of mains: 3870/4160/4540, amperage of charging station: 15750/15720/15683 => available: 43880/43560/43143

Am Hausübergabepunkt wird nur sehr wenig Strom gezapft, der Rest kommt aus der Batterie. In diesem Fall kannst du also an der Wallbox auch auf mehr als 32A gehen, weil die Batterie ja unterstützt und der Hausanschluss trotz hoher Ladung nicht überlastet wird.

32A - 3,8A + 15,7A => 43,9A

Warum sollte ich hier die Batterie nicht mit einrechnen? Die Werte sind mir ja auch gar nicht bekannt. Die Batterie ermöglicht dir somit, 32A plus Abgabestromstärke der Batterie zu laden.

[gto]

@sneak-l8 Denkfehler von mir, in maxAmperage hast du die mögliche Ladung der geregelten Box, egal mit wieviel sie gerade lädt. Darum stimmt die Berechnung auch wenn die ungeregelte Box lädt. Sorry

[hs911]

Hi zusammen,

ich habe heute von 2.3.0 auf 3.0.0 updaten wollen, allerdings terminiert sich der Adapter in der Folge immer selbst:

auf dem Host ist alles aktuell.. js-controller 7.06 und Node 20.18.2 sowie Admin auf 7.6.2... Ein Downgrade auf 2.3.0 hat das Problem sofort gelöst.

Ich gebe zu, dass ich mit SUSE ein bisschen ein exotisches OS habe, bisher gab es aber an keiner Stelle Probleme damit. Vielleicht wirklich irgendeine Unschärfe im Code?

Danke und Grüße

[Sneak-L8]

@hs911 ach, Du bist das. Habe von sentry schon eine Meldung erhalten.
Der init-Fehler kommt vom Übersetzungstool I18n. Ich muss mal schauen, warum das bei Dir nicht initialisiert ist.
Wenn Du die Einstellungen des Adapters öffnest, werden da die korrekten Texte (Beschriftungen) angezeigt? Deutsch oder englisch? Oder nur Platzhalter wie z.B. stateRegard?

[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.