@CGastager: Änderungen sind abgebracht und im Modulstore als Beta (v1.11) eingereicht
Moin,
unter den Wallboxen ist ein Gesamtverbrauch für jede RFID Karte. Ende Februar hat der sich das letzte mal bei mir aktuallsiert.
Gab es da evlt. in der Zeit ein Update, ich abe das nicht mehr im Kopf…
danke.
Das wir eigentlich nur gesteuert über die Einstellung in der Instanz „Speichern des Stromverbrauchs pro RFID“ und natürlich „Lade-Historie speichern“.
Natürlich nur dann, wenn neue Einträge in der Lade-Historie eingetragen werden.
Da hat sich auch in der letzen Monaten nichts dran geändert
Hmm, eigentlich hilft da nur ein Debug (aber lang genug muss er sein) von dem Ende eine Ladesession mit RFID.
Es werden ja nur die neuen Historieneinträge übernommen und natürlich insbesondere in diese Summenberechnung.
Identifiziert werden die Einträge an eine so.g „Session ID“, die in den Histriendaten enthalten ist laut Doku immer hochgezählt wird.
ID of the current charging session. This value will be assigned automatically and is not re- settable. This value is incremented session by session. Due to the high maximum value (over 4 billion possible IDs), the session ID can be considered unique.
Sollte - aus welchem Grund auch immer - eine Session ID verwendet werden, die in den im IPS gespeicherten Daten (du sicherst die anscheinend für 365 Tage) bereits enthalten ist, würde sie als „alt“ verworfen.
Im Debug finde das Ganze in der Rubrik GetChargingHistory statt
Eine alte Session erkennt man das daran, das dort ausgegeben wird: save_per_rfid: found old "Session ID" xxxx -> ignore
Das ist erstmal grundsätzlich normal, da ich immer die letzten 30 Einträge abrufe und daraus die neuen Einträge herausfische
Andere interessante Meldung wäre: save_per_rfid: "RFID tag" is empty -> ignore → dann wäre das Feld ‚RFID tag‘ leer … müsste man dann prüfen.
Sollte da aber stehen: save_per_rfid: tag=tttt, ident=ChargedEnergy_tttt, wird dieser Eintrag gespeichert, sprich der alte Wert dieser Variable gelesen, um dem Wert des Feldes ‚E pres‘ erhöht und zurück geschrieben.
okay, dann teste ich das, wird nur etwas dauern, da ich ja das Debug dann an haben muss wenn jemand dran hängt. am besten mache ich das selber, bin aber erst nächste Woche erst wieder bei den Wallboxen
Hallo Zusammen,
Seit irgendeinem Update merkt sich die Box nicht mehr die Ladeleistung. In der Vergangenheit habe ich einmal die Ladegeschwindigkeit z.B. auf 6kW gesetzt. Die Ladegeschwindigkeit blieb auch so lange gesetzt bis man sie geändert hat.
Heute ist es so, das nach jedem Ladevorgang die Ladegeschwindigkeit immer automatisch auf 11kW (maximum) springt und ich muss her gehen die Ladegeschwindigkeit wieder Manuell runter setzen.
Ist dieses Verhalten so gewollt ?
Gruß Stephan
Was meinst Du mit „Ladegeschwindigkeit“? Es gibt die Max. Ladeleistung in A und die Max. Energie in kWh.
Wenn es um die Leistung geht: ja, da wurde im Zuge der Umbauten des Moduls auf PV-Überschussladen gerade an der Ladeleistung was gemacht.
Unter anderem wurde aufgrund des Hinweises von Keba der Befehl zum Setzen der Leistung von curr (permanentes Setzen) auf currtimer ( Setzen für akt. Session) geändert. Keba rät davon ab, curr zu häufig zu benutzen, da da jedesmal in ein EEPROM gesichert wird,
Also ist es zwar nicht beabsichtigt, aber ein Nebeneffekt.
Mir ist allerdings dein Anwendungsfall auch nicht ganz klar - was ist der Grund, warum Du dauerhaft eine niedrige Ladeleistung einstellen möchtest?
Ich meinte natürlich Ladeleistung. In der Regel laden wir nur mit 6kw konstant damit die PV-Anlage länger unterstützen kann. Das Überschussladen nutze wir aktuell nicht weil beide Autos Tagsüber sowieso nicht da sind und wir erst immer nachmittags laden wenn ein Auto einen leeren Akku hat. Und ob das Auto dann um 23 Uhr oder morgens um 3 Uhr das Auto voll ist dann egal.
Wichtig ist nur das wir Nachmittags solange wie möglich, wenn wir laden, die PV-Anlage, die aktuell nur 4,9 kWp groß ist, Nachmittags / Abends nutzen.
Es kommt bei uns nur sehr selten so, das wir mit 11kW laden. Das machen wir nur wenn es mal dringend ist. Dann ist der Cupra innerhalb von 2,5 Stunden wider auf 80%.
Aber wie schon beschrieben ist es jetzt so, das sich nach dem Ladevorgang die Ladeleistung wieder auf Max. also 11Kw stellt und ich beim nächsten laden wieder von Hand reduzieren muss.
Gruß Stephan
PV-Überschussladen ist in diesem Modul auch eher die Möglichkeit, dynamisch die Ladeleistung anzupassen, ggfs. (bei entsprechender Hardware-Ausstattung) auch die Umschaltung 1/3 Phasen.
Richtiges Überschussladen braucht dann noch etwas/jemand, der die verfügbare Leistung entsprechend einstellt z.B. der Energieverbrauch Optimierer.
Auf Seiten des Moduls steht, wenn Du Variablen für die PV>>-Überschussleistung aktivierst, zusätzlich zwei Variablen zur Verfügung
- Verfügbare Überschussleistung
- Bereit zu Überschussladen
Die 2. Variable ist für Deinen Fall eher uninteressant (die gibt nur an, ob die WB auch Strom abnehmen könnte - Auto dran etc), mit der 1. Variable gibt man an, welche Leistung (in W), verbraten werden darf.
Aufgrund des Wertes und unter Berücksichtigung der Anzahl der Phasen des Netzanschlusses (in der Instanz-Konfiguration oder - wenn vorhanden - je nach Stand des Phasenumschalters).
6A wäre bei einem 3-Phasigen Anschluss 4140 W (6 * 230 * 3).
Sofern die Betriebsart auf Überschuss steht, wird dann der angegebene Wert umgerechnet und entsprechend die Maximale Stromstärke für den Ladevorgang justiert. (Sorry übrigens, ich hatte im vorigen Post die Angabe in Ampere als Leistung bezeichnet, war natürlich Stromstärke gemeint).
Steht die Betriebsart auf manuell, wird die manuell angegebene Stromstärke verwendet - also immer beginnend bei dem Wert, den die WB maximal unterstützt.
Ist also etwas anders als bisher, vom Ergebnis her (wenn ich Dich richtig verstanden habe) aber gleich.
vielen Dank für die schnelle Antwort. Ich musste gestern laden und habe dein Vorgehen ausprobiert. Dein Tipp hat funktioniert. Vielen Dank dafür 
1 „Gefällt mir“
Hallo, ich stehe gerade etwas auf dem Schlauch. Egel was ich mache, ich bekomme bei diesem Modul immer folgende Fehlermeldung:
Warning: Variablentyp und Profiltyp stimmen nicht überein in C:\ProgramData\Symcon\modules.store\demel42.keba.keconnect\KeConnectP30udp\module.php on line 427
Warning: Variablentyp und Profiltyp stimmen nicht überein in C:\ProgramData\Symcon\modules.store\demel42.keba.keconnect\KeConnectP30udp\module.php on line 435
(Code: -32603)
und es werden keine Daten ausgelesen (IP richtig, deinstalliert / installiert, ezc.)
Habt Ihr einen Tipp?
Schau doch mal in den Variablenprofilen nach dem Profil _ KebaConnect.MaxCurrent_.
Das sollte den Typ Float haben, war früher mal Integer.
Wenn das ein Integerprofil ist, bitte das Profil löschen und die Instanz neu anlegen
Vielen lieben Dank, das hat incl. „VARIABLENPROFILE ERNEUT EINRICHTEN“ geholfen.
Allerding bekomme ich jetzt eine Fehlermeldung
socket_recv(): Unable to read from socket [10060]: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat in C:\ProgramData\Symcon\modules.store\demel42.keba.keconnect\KeConnectP30udp\module.php on line 872
was meiner Meinung nach auf ein Timing-Problem hinweist? Alles ist per LAN (Kabel) angeschlossen.
Da deutet erstmal darauf hin, das die WB nicht erreichbar ist bzw. der Dienst auf der WB nicht aktiviert ist.
- Vermutung:
WB ist nicht korrekt eingerichtet
Dip-Schalter 1.3 in der Wallbox auf „On“ ist obligatorisch
-
Vermutung:
ein anderer Prozess blockiert den UDP-Port - kooperativ wäre es bei jeder Anfrage den Port zu öffnen und danach wieder zu schliessen (so macht das Modul das), wenn aber jemand den Port 7091 dauerhaft belegt … -
Vermutung:
ein anderer Prozess versucht per ModBus mit der WB zu kommunizieren (die WB kann nur das eine oder das andere)
Ich denke mal an der Konfig liegts nicht. IP-Adresse stimmt, UDP-DIP 1.3 ist auf ON und wenn ich das Testscript (weiter oben im Forum ausführe) bekomme ich ein:
„socket_recv(): 42 bytes, buf=“„Firmware“:„P30 v 3.10.53 (230713-211537)“
DEBUG sagt:
01.05.2024, 18:33:28 | ExecuteCmd | socket_recv() failed, reason=Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat
Das mit dem dauerhaften Belegen des Port wäre eine Möglichkeit. Bekomme ich das irgendwie raus, wer den Port ständig offen hält?
netstat -p UDP zeigt keine offenen UDP-Verbindungen
Irgendwie scheint das Modul auch ja zu kommunizieren. Wenn ich z.B. als zusätzliche Variable die Seriennummer mit reinnehme,
wird diese korrekt ausgelesen. Anschließend kommt wieder der
socket_recv(): Unable to read from socket [10060]: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat in C:\ProgramData\Symcon\modules.store\demel42.keba.keconnect\KeConnectP30udp\module.php on line 872
Am besten machst Du ein Debug der Keba-Instanz, ausreichend lang (unbedingt Limitierung im Debug erhöhen) und schickst ihn mir per PN.
Dann schaue ich mir das an.
Ein netstat auf dem Symcon-Rechner würde nur helfen, wenn der 2. Prozess auch auf diesem Rechner laufen würde.
Und ModBus machst du nicht? (zB mit Modul Energie-Verteilung)
Ein Timeout-Problem ist mir bisher nicht gemeldet worden.
Bestimmte Daten kommen eventuell pber die Broadcast-Socket (siehe Gateway der Instanz)
Hallo demel42,
ich kann mir die Frage inzwischen selbst beantworten. Mein Elektriker hat den DIP-Switch3 - entgegen meiner Vorgabe doch nicht auf „ON“ gesetzt. Als ich das DEBUG erstellt und dabei beobachtet habe, hat es bei „Dip-Switch 1=11000101, 2=00000000“ geklingelt.
Also das Ding nochmal aufgeschraubt und den DIP3 umgeswitcht.
By the way: Ist im KEBA-Manual für „Nicht-Elektriker“ wirklich missverständlich erklärt (siehe Bild)
Also „oben“ ist „OFF“ d.h. heißt „unten“
P.S. Danke für die Hilfe. Gebe gerne einen Kaffee aus (ernst gemeint) - gerne PN an mich.
Prima, das es jetzt funktioniert.
Was mich ja doch etwas verwundert ist, das er aber bestimmte Anfragen beantwortet hat, andere nicht (so dein Versuch mit dem Script und der Frage nach der Firmware bzw. die Meldung der Dip-Switches im Log.
Das ist vielleicht ein (verständliches) Missverständnis; ich kenne zwei Arten von Dip-Switches
- mit Schiebern
da gilt die Position, wo sich der Schieber befindet - mit Wippe
da gilt die Position, wo die Wippe eingedrückt ist
Und das ist dann u.U. etwas irritierend, da der hervorstehende Teil der Wippe auffällt und eventuell als relevante Position wahrgenommen wird.
In dem aktuelle Installationshandbuch (https://www.keba.com/download/x/44d3dc9e54/kecontactp30_ihde_web.pdf) ist das ein Ticken besser dargestellt (Seite 40), weil sowohl die Wippen- als auch die Schieber-Variante gezeigt werden
Ja, deshalb bin ich auch erst gar nicht auf die Idee gekommen, dass der Dip-Switch falsch gestellt ist. Bestimmte Anfragen wie die Seriennummer wurde ja ausgelesen. Ich dachte erst, wenn UDP deaktiviert ist, kann gar keine Kommunikation stattfinden. Naja - man lernt nie aus 