Keba Wallbox welches Modell

kurzer Zwischenstand: heute hat der Elektriker die Box fertig gemacht, ich konnte die interne Wallbox-Webseite aufrufen - d.h. ich kann loslegen.
Ich werde mich mal etwas genauer einlesen, Modbus hatte ich noch nie was mit zu tun.

Also klar, ich brauche eine IO-Client-Instanz zur Low-Lebel-Komunikation mit der Wallbox. Aber so wie es in der Symcon-Doku steht muss man einen Modbus-Splitter benutzen und pro Variable ein Modbus-Device. Nur will ich ja zumindestens alle Variablen direkt im Modul selber pflegen. Egal, mal lesen …

demel

Hallo,

so, ich habe die allerseits Version KEBA KeConnect P30 in dem Modulstore als Beta eingestellt (daher genau nach diesem Namen suchen).

Instanz ganz normal anlegen, er fragt dann Splitter- und IO-Instanz ab, Angaben siehe README.md

Es ist zur Zeit realisiert
a) nur lesen, die schreibenden Zugriffe kommen noch
b) es werden alle Variablen zyklisch abgefragt
=> hier kann ich mir vorstellen, das bestimmte Variablen währen des Ladens häufiger abgefragt werden, andere Variablen eher sehr selten. Grund: lt. Doku sollte man zu häufiges Abfragen vermeiden und jede Variable ist ja ein eigener Abruf. Was haltet ihr davon?
c) ich habe die Bezeichnungen so gewählt und die Profile so aufgebaut, wie mir das sinnvoll erschien. Da ich aber mit E-Mobilität bisher noch keiner Erfahrungen habe, muss das nicht wirklich sinnig sein.
Ich kann das nur trocken testen, weil ich zwar die Wallbox angeschlossen habe, aber noch kein E-Auto, das dauert sicherlich noch mit März.

Wenn ihr also Fehlermeldungen / Verbesserungswünsche habt, nur zu

demel

Hallo Demel,

erstmal vielen Dank das du dir die Mühe machst ein Modul zu erstellen.
Ich habe es installiert und die Installation lief Fehlerfrei.

Was mir im ersten Schritt aufgefallen ist, das die Gesamtenergie nicht stimmt. Hier müsste das Komme um eine Stelle versetzt werden.

Dann habe ich eine Verständnis Frage, wo bei ich dazu sagen muss das ich mich mit Mode-Bus nicht auskenne. Warum fragst du die Werte zyklisch ab? Wenn ich, wie im Post von 7weazel7 anlege, bekomme ich immer Werte geliefert sobald sich etwas ändert.

Gruß Stephan

PS: Freue mich schon auf die Funktion das Laden abschalten zu können damit man gezielt laden kann wenn die PV-Anlage Strom liefert.

ok, sollte hoffentlich jetzt erledigt sein

Tja, gute Frage, ich habe gaaaanz viel Ahnung von Modbus :blush: (nachdem mur @paresy gestern auf die Sprünge geholfen hat, habe ich mich voran getastet), aber so wie ich die Doku verstehe, ist ModBus schon so, das man abfragen muss. Ich kenn das Script/Anleitung von @7weazel7 nicht, wo steht das? dann kann ich schauen, wie er es da macht bzw. eventuell kann er auxh selbst einen Hinweis geben.

ja unbedingt. Ich muss noch etwas schauen, wie man so ein Register schreibt. Ich kann es ja noch nicht ausprobieren, aber mit etwas Glück kann ich da morgen eine Funktion für machen und dann kannst du testen …

demel

Melde mich morgen früh :slight_smile:

Habe das aus Beitrag #3 bzw. von hier

ich habe mir gerade mal die Screenshots angeschaut, bei den Variablen steht Aktualisierungsintervall 1000ms, d.h. jede
ModBus-Variablen-Instanz aktualisiert sich jede Sekunde, macht also den Abruf, den ich meinte.
In der Keba-ModBus-Doku steht aber etwas davon, das man nur alle 0,5s Register auslesen soll

The recommended timing invervals for reading registers is >0.5 sec. For data, which does not change on a frequent basis, higher intervalls are recommended. The recommended timing intervall for writing registers is >5 sec, to avoid stressing of the charging station.

Wie genau man das auch immer nehmen muss, es gibt m.E. hier 3 Gruppen von Variablen/Registern

  • die sich nie (Modell, Seriennummer, …) / so gut wie nie (Firmware-Version) ändern
    => Abruf sehr selten oder manuell
  • Variable, die permanent überprüft werden müssen (Lade- und Kabel-Status sowie Fehler)
    => jede Sekunde
  • Variablen, die nur eng überwacht werden müssen, wenn man lädt, sonst eigentlich seltenst/gar
    => 1s beim Laden, sonst zB alle 5 Minuten

das ist so meine Idee dazu …

demel

Hallo @demel42, deine Idee der Abfrage-Intervalle finde ich sehr gut :slight_smile: Wird aber bestimmt nicht leicht dies mit Timern umzusetzen. Frägst du den Splitter auch schon so schön über Datenblöcke ab? (Keine Ahnung ob es da Modulfunktionen gibt)

Aber theoretisch würde es ja reichen den Ladestatus/Kabelstatus sekündlich abzufragen und dann daraus resultierend die Intervalle in der Datenblockabfrage zu verändern.

Zu den Variablenprofilen hätte ich noch folgendes:
KebaConnect.CableState
Bei Wert 3 und 7 „verriegelt“ bitte richtig schreiben
KebaConnect.ChargingState
Bei Wert 2 „bereit zum Laden“
KebaConnect.Error
Bei Wert 0 finde ich persönlich „Kein Fehler“ oder „Alles in Ordnung“ besser

Ich teste weiter. Vielen Dank schon einmal. Der Rest sieht echt klasse aus.

Grüße weazel

das habe ich nicht verstanden. Ih frage Register für Register mit ModBus-FuncCode 3 ab. Die Abfrage geht über den Splitter, der für mich das LowLevel-Handling übernimmt. Ist so echt easy.

so hab ich mir das gedacht, wobei ich vermutlich bei dem sekündlichen Zyklus alle Variablen im IPS überprüfe und ggfs. die Variablen, deren Aktualisierung zu alt ist, auch abfrage.

nur ein kleiner Test, ob das jemand liest :smiley:

demel

Nachtrag zu den Fehlern: gibt es zu den Fehlercodes eigentlich Texte? Ich habe den Keba-Support gestern mal angeschrieben, ob es eine Liste gibt …

Okay, keine Ahnung wie das bei der Modulentwicklung funktioniert. Ich meine nur, dass bevor man in den Einstellungen ganze Datenblöcke abgefragen konnte die Einzelabfrage ziemlich unperformant war. Aber du machst das bestimmt richtig. Hast dich ja mit paresy abgestimmt :slight_smile: Muss mir dein Modul mal anschauen, könnte ich für meine KEBA Heizung auch brauchen :wink:

:smiley:

Hab da auch nichts gefunden

wo stellt man denn diese Datenblöcke ein?

Auf dem Splitter gibt es eine Expertenoption

aha, da muss ich mal nachhaken.

@paresy: ist das etwas, was in eine Modul auch sinnvollerweise berücksichtigt werden sollte? Hat das eine Änderung in der Kommunikation mit dem ModBus-Partner zur Folge oder dient das mehr zur Reduzierung der Last innerhalb vom IPS?

Hallo demel,

jetzt wo du es geschrieben hast mit den 1000ms habe ich es auch gesehen. :see_no_evil:
Danke für den Hinweis.

Das mit den drei Gruppen gefällt mir auch sehr gut :+1:

Gruß Stephan

Ein Zwischenstand:
ich habe ein zusätzliche Modul gemacht, nun auf Basis von UDP, Grund:

  1. das UDP-Interface bietet laut Doku mehr Funktionen und Informationen
  2. die kontinuierliche Abfrage des Status kann unterbleiben, weil die WallBox Broadcasts schicken soll
    „schicken soll“ ist genau ich das, was ich mangels Stromer noch nicht testen kann

Von daher wäre es nicht schlecht, wenn das jemand installieren würde und z.B. mal etwas lädt.
Bitte vor dem Laden den Instanz-Debug aktivieren, Limitierung auf deutlich hoch setzen und so oder so, gerne mir den Debug schicken.
Wenn es funktionier sollten sich die Stati (Lade- und Kabel-Status) automatisch ändern und ChargedEnergy sollte ebenfalls automatisch aktualisiert werden.
Im Debuglog sollte so etwas wie „broadcast message“ erscheinen.
Das Abfrage-Intervall im Moduls selbst habe ich erstmal recht hoch (60 min) gesetzt, weil ich nach keine Ahnung habe, ob / wie häufig man das doch aktualisieren sollte.

Wenn das funktioniert würde ich die ModBus-Variante nicht weiter entwicklen und demzufolge wieder löschen.

demel

Wie erstelle ich die UDP-Instanz? Bei mir wird da immer ein ModBus-Instanz erstellt. Finde keine Option eine UDP-Instanz anzulegen.

wenn du bei Erstellen der Instanz nach Keba suchst, werden eigenloch uwei Einträge angezeigt, KeConnectP30 und KeConnectP30udp

demel

… mist, hatte nicht comittet, moment … ok. ist jetzt im Modulstore /beta … sorry

Wann sollten da sich die Variablen aktualisieren? Auch wenn ich die Funktion KebaConnect_UpdateData ausführe aktualisiert sich noch nichts.
Instanz:

TXT: 22.11.2021, 20:48:54 |          CheckAction | action=Array<LF>(<LF>    [creation] => 1637610355<LF>    [cmd] => report 2<LF>    [exec_ts] => 1637610474<LF>)<LF>
HEX: 22.11.2021, 20:48:54 |          CheckAction | 61 63 74 69 6F 6E 3D 41 72 72 61 79 0A 28 0A 20 20 20 20 5B 63 72 65 61 74 69 6F 6E 5D 20 3D 3E 20 31 36 33 37 36 31 30 33 35 35 0A 20 20 20 20 5B 63 6D 64 5D 20 3D 3E 20 72 65 70 6F 72 74 20 32 0A 20 20 20 20 5B 65 78 65 63 5F 74 73 5D 20 3D 3E 20 31 36 33 37 36 31 30 34 37 34 0A 29 0A 
TXT: 22.11.2021, 20:48:54 |          CheckAction | new_actions#5
HEX: 22.11.2021, 20:48:54 |          CheckAction | 6E 65 77 5F 61 63 74 69 6F 6E 73 23 35 
TXT: 22.11.2021, 20:49:54 |          CheckAction | action=Array<LF>(<LF>    [creation] => 1637610355<LF>    [cmd] => report 2<LF>    [exec_ts] => 1637610474<LF>)<LF>
HEX: 22.11.2021, 20:49:54 |          CheckAction | 61 63 74 69 6F 6E 3D 41 72 72 61 79 0A 28 0A 20 20 20 20 5B 63 72 65 61 74 69 6F 6E 5D 20 3D 3E 20 31 36 33 37 36 31 30 33 35 35 0A 20 20 20 20 5B 63 6D 64 5D 20 3D 3E 20 72 65 70 6F 72 74 20 32 0A 20 20 20 20 5B 65 78 65 63 5F 74 73 5D 20 3D 3E 20 31 36 33 37 36 31 30 34 37 34 0A 29 0A 
TXT: 22.11.2021, 20:49:54 |          CheckAction | no answer to command "report 2" started 2021-11-22 20:47:54
HEX: 22.11.2021, 20:49:54 |          CheckAction | 6E 6F 20 61 6E 73 77 65 72 20 74 6F 20 63 6F 6D 6D 61 6E 64 20 22 72 65 70 6F 72 74 20 32 22 20 73 74 61 72 74 65 64 20 32 30 32 31 2D 31 31 2D 32 32 20 32 30 3A 34 37 3A 35 34 
TXT: 22.11.2021, 20:49:54 |          CheckAction | new_actions#4
HEX: 22.11.2021, 20:49:54 |          CheckAction | 6E 65 77 5F 61 63 74 69 6F 6E 73 23 34 
TXT: 22.11.2021, 20:50:30 |            AddAction | cmd=report 1
HEX: 22.11.2021, 20:50:30 |            AddAction | 63 6D 64 3D 72 65 70 6F 72 74 20 31 
TXT: 22.11.2021, 20:50:30 |            AddAction | cmd=report 2
HEX: 22.11.2021, 20:50:30 |            AddAction | 63 6D 64 3D 72 65 70 6F 72 74 20 32 
TXT: 22.11.2021, 20:50:30 |            AddAction | cmd=report 3
HEX: 22.11.2021, 20:50:30 |            AddAction | 63 6D 64 3D 72 65 70 6F 72 74 20 33 
TXT: 22.11.2021, 20:50:30 |          CheckAction | action=Array<LF>(<LF>    [creation] => 1637610355<LF>    [cmd] => report 3<LF>    [exec_ts] => 0<LF>)<LF>
HEX: 22.11.2021, 20:50:30 |          CheckAction | 61 63 74 69 6F 6E 3D 41 72 72 61 79 0A 28 0A 20 20 20 20 5B 63 72 65 61 74 69 6F 6E 5D 20 3D 3E 20 31 36 33 37 36 31 30 33 35 35 0A 20 20 20 20 5B 63 6D 64 5D 20 3D 3E 20 72 65 70 6F 72 74 20 33 0A 20 20 20 20 5B 65 78 65 63 5F 74 73 5D 20 3D 3E 20 30 0A 29 0A 
TXT: 22.11.2021, 20:50:30 |             SendData | request data {"DataID":"{8E4D9B23-E0F2-1E05-41D8-C21EA53B8706}","Buffer":"report 3","ClientIP":" XXX.XXX.XXX.XXX","ClientPort":7090,"Broadcast":false}
HEX: 22.11.2021, 20:50:30 |             SendData | 72 65 71 75 65 73 74 20 64 61 74 61 20 7B 22 44 61 74 61 49 44 22 3A 22 7B 38 45 34 44 39 42 32 33 2D 45 30 46 32 2D 31 45 30 35 2D 34 31 44 38 2D 43 32 31 45 41 35 33 42 38 37 30 36 7D 22 2C 22 42 75 66 66 65 72 22 3A 22 72 65 70 6F 72 74 20 33 22 2C 22 43 6C 69 65 6E 74 49 50 22 3A 22 20 31 30 2E 32 31 2E 32 30 2E 32 38 22 2C 22 43 6C 69 65 6E 74 50 6F 72 74 22 3A 37 30 39 30 2C 22 42 72 6F 61 64 63 61 73 74 22 3A 66 61 6C 73 65 7D 
TXT: 22.11.2021, 20:50:30 |          CheckAction | new_actions#7
HEX: 22.11.2021, 20:50:30 |          CheckAction | 6E 65 77 5F 61 63 74 69 6F 6E 73 23 37 
TXT: 22.11.2021, 20:51:30 |          CheckAction | action=Array<LF>(<LF>    [creation] => 1637610355<LF>    [cmd] => report 3<LF>    [exec_ts] => 1637610630<LF>)<LF>
HEX: 22.11.2021, 20:51:30 |          CheckAction | 61 63 74 69 6F 6E 3D 41 72 72 61 79 0A 28 0A 20 20 20 20 5B 63 72 65 61 74 69 6F 6E 5D 20 3D 3E 20 31 36 33 37 36 31 30 33 35 35 0A 20 20 20 20 5B 63 6D 64 5D 20 3D 3E 20 72 65 70 6F 72 74 20 33 0A 20 20 20 20 5B 65 78 65 63 5F 74 73 5D 20 3D 3E 20 31 36 33 37 36 31 30 36 33 30 0A 29 0A 
TXT: 22.11.2021, 20:51:30 |          CheckAction | new_actions#7
HEX: 22.11.2021, 20:51:30 |          CheckAction | 6E 65 77 5F 61 63 74 69 6F 6E 73 23 37 
TXT: 22.11.2021, 20:52:30 |          CheckAction | action=Array<LF>(<LF>    [creation] => 1637610355<LF>    [cmd] => report 3<LF>    [exec_ts] => 1637610630<LF>)<LF>
HEX: 22.11.2021, 20:52:30 |          CheckAction | 61 63 74 69 6F 6E 3D 41 72 72 61 79 0A 28 0A 20 20 20 20 5B 63 72 65 61 74 69 6F 6E 5D 20 3D 3E 20 31 36 33 37 36 31 30 33 35 35 0A 20 20 20 20 5B 63 6D 64 5D 20 3D 3E 20 72 65 70 6F 72 74 20 33 0A 20 20 20 20 5B 65 78 65 63 5F 74 73 5D 20 3D 3E 20 31 36 33 37 36 31 30 36 33 30 0A 29 0A 
TXT: 22.11.2021, 20:52:30 |          CheckAction | no answer to command "report 3" started 2021-11-22 20:50:30
HEX: 22.11.2021, 20:52:30 |          CheckAction | 6E 6F 20 61 6E 73 77 65 72 20 74 6F 20 63 6F 6D 6D 61 6E 64 20 22 72 65 70 6F 72 74 20 33 22 20 73 74 61 72 74 65 64 20 32 30 32 31 2D 31 31 2D 32 32 20 32 30 3A 35 30 3A 33 30 
TXT: 22.11.2021, 20:52:30 |          CheckAction | new_actions#6
HEX: 22.11.2021, 20:52:30 |          CheckAction | 6E 65 77 5F 61 63 74 69 6F 6E 73 23 36 
TXT: 22.11.2021, 20:53:30 |          CheckAction | action=Array<LF>(<LF>    [creation] => 1637610474<LF>    [cmd] => report 1<LF>    [exec_ts] => 0<LF>)<LF>
HEX: 22.11.2021, 20:53:30 |          CheckAction | 61 63 74 69 6F 6E 3D 41 72 72 61 79 0A 28 0A 20 20 20 20 5B 63 72 65 61 74 69 6F 6E 5D 20 3D 3E 20 31 36 33 37 36 31 30 34 37 34 0A 20 20 20 20 5B 63 6D 64 5D 20 3D 3E 20 72 65 70 6F 72 74 20 31 0A 20 20 20 20 5B 65 78 65 63 5F 74 73 5D 20 3D 3E 20 30 0A 29 0A 
TXT: 22.11.2021, 20:53:30 |             SendData | request data {"DataID":"{8E4D9B23-E0F2-1E05-41D8-C21EA53B8706}","Buffer":"report 1","ClientIP":" XXX.XXX.XXX.XXX","ClientPort":7090,"Broadcast":false}
HEX: 22.11.2021, 20:53:30 |             SendData | 72 65 71 75 65 73 74 20 64 61 74 61 20 7B 22 44 61 74 61 49 44 22 3A 22 7B 38 45 34 44 39 42 32 33 2D 45 30 46 32 2D 31 45 30 35 2D 34 31 44 38 2D 43 32 31 45 41 35 33 42 38 37 30 36 7D 22 2C 22 42 75 66 66 65 72 22 3A 22 72 65 70 6F 72 74 20 31 22 2C 22 43 6C 69 65 6E 74 49 50 22 3A 22 20 31 30 2E 32 31 2E 32 30 2E 32 38 22 2C 22 43 6C 69 65 6E 74 50 6F 72 74 22 3A 37 30 39 30 2C 22 42 72 6F 61 64 63 61 73 74 22 3A 66 61 6C 73 65 7D 
TXT: 22.11.2021, 20:53:30 |          CheckAction | new_actions#6
HEX: 22.11.2021, 20:53:30 |          CheckAction | 6E 65 77 5F 61 63 74 69 6F 6E 73 23 36 

UDP Socket

TXT: 22.11.2021, 20:50:30 | TRANSMIT [ XXX.XXX.XXX.XXX:7090] | report 3
HEX: 22.11.2021, 20:50:30 | TRANSMIT [ XXX.XXX.XXX.XXX:7090] | 72 65 70 6F 72 74 20 33 
TXT: 22.11.2021, 20:50:30 |               QUEUED | Backlog: 2
HEX: 22.11.2021, 20:50:30 |               QUEUED | 42 61 63 6B 6C 6F 67 3A 20 32 
TXT: 22.11.2021, 20:53:30 | TRANSMIT [ XXX.XXX.XXX.XXX:7090] | report 1
HEX: 22.11.2021, 20:53:30 | TRANSMIT [ XXX.XXX.XXX.XXX:7090] | 72 65 70 6F 72 74 20 31 
TXT: 22.11.2021, 20:53:30 |               QUEUED | Backlog: 3
HEX: 22.11.2021, 20:53:30 |               QUEUED | 42 61 63 6B 6C 6F 67 3A 20 33 
TXT: 22.11.2021, 20:55:30 | TRANSMIT [ XXX.XXX.XXX.XXX:7090] | report 2
HEX: 22.11.2021, 20:55:30 | TRANSMIT [ XXX.XXX.XXX.XXX:7090] | 72 65 70 6F 72 74 20 32 
TXT: 22.11.2021, 20:55:30 |               QUEUED | Backlog: 4
HEX: 22.11.2021, 20:55:30 |               QUEUED | 42 61 63 6B 6C 6F 67 3A 20 34 

das ist wirklich komisch, wenn ich auf dem UDP-Socket zB „report 1“ schicke, bekomme ich einen Haufen Daten zurück.
Du hast doch auch ein P30-Modell?

Ah, was ist deine IPS-Version?
paresy hatte das was zu UDP und Broadcast gesagt … das funktionier ab 6.0?

demel

Jup (KC-P30-EC240122-E00)

Aktuelle 6er Version.

Muss morgen mal prüfen ob ich den UDP DIP-Switch noch umgelegt habe :slight_smile: Für Modbus musste man das glaube nicht.