[Frage] Realisierung Adapter UDP Keba Wallbox
-
@gto Ich habe jetzt eine neue Version bereitgestellt, bei der zwei Dinge geändert wurden:
- ich merke mir bei jeder Berechnung der maximalen Ladeleistung bzw. Stromstärke die Werte des Energy-Meters und vergleiche die neuen Werte bei einer Änderung beim Energy-Meter mit diesen gemerkten Werten. Das hat den Vorteil, dass die Max-Prüfung auch dann durchgeführt wird, wenn der Energy-Meter ganz viele Änderungen in kleinen Schritten durchgibt und dadurch der Schwellwert bei jeden einzelnen Schritt nicht überschritten würde.
- Anstatt bei einer Überschreitung des Schwellwerts gleich die Prüfung durchzuführen, fordere ich erst den Report 3 an, der mit die aktuellen Werte zu Spannung, Stromstärke und Leistung der Wallbox gibt, um den Vergleich mit aktuellen Werten durchzuführen. Damit sollte das zeitlich Lack auf meiner Seite behoben sein.
-
@gto Als im Log sieht es gut aus. Bis auf die Ausnahme, dass ich gerundet und nicht abgerundet hab. Das habe ich gerade korrigiert.
Aber sonst passt die Berechnung im Log.
Bei Deiner Anzeige kann ich mir nur vorstellen, dass die Werte zu unterschiedlichen Zeitpunkten erfasst wurden und es dazwischen eine größere Änderung gab.
Max Amperage wird ja unabhängig von der max. zulässigen Ladestromstärke ermittelt und in den State eingetragen.
Schreib doch mal den Zeitstempel "lastUpdated" oder lastChanged" hinter die Anzeige. Dann sieht man, ob sie synchron sind. Gerade wenn der Fronius nur alle 10 Sekunden die werte liefert, dann hast du immer 10 Sekunden "Blindflug" hinsichtlich der Überschreitung der Ampere-Begrenzung ... -
@gto Als im Log sieht es gut aus. Bis auf die Ausnahme, dass ich gerundet und nicht abgerundet hab. Das habe ich gerade korrigiert.
Aber sonst passt die Berechnung im Log.
Bei Deiner Anzeige kann ich mir nur vorstellen, dass die Werte zu unterschiedlichen Zeitpunkten erfasst wurden und es dazwischen eine größere Änderung gab.
Max Amperage wird ja unabhängig von der max. zulässigen Ladestromstärke ermittelt und in den State eingetragen.
Schreib doch mal den Zeitstempel "lastUpdated" oder lastChanged" hinter die Anzeige. Dann sieht man, ob sie synchron sind. Gerade wenn der Fronius nur alle 10 Sekunden die werte liefert, dann hast du immer 10 Sekunden "Blindflug" hinsichtlich der Überschreitung der Ampere-Begrenzung ...@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 LOGDer 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 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 LOGDer 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.
-
@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 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.
-
@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. -
@gto gerne. Danke auch Dir für das ausführliche Testen! Dann lege ich mal ein neues Release an ...
@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 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
@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 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.
-
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
-
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
@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? -
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
-
@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?@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
-
@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 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 dedupedhab es zusammen gekürzt und die anderen Adapter weggelassen. Passt das?
-
@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...
-
@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...
@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... -
@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... -
@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 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
Foto um 18:43
415
Online32.7k
Users82.5k
Topics1.3m
Posts