Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

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

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