Request to implement entity cable ampere code"cbl"

[miwi73]

I am using this at the moment with the IOBroker Go-E adapter to differentiate between the cars that are charging as the cables we are using have different ampere. In IOBroke there is an entity that is called cbl. Is it already included in this adapter and I just have not seen it or is there a chance to implement it? Thanks miwi

[marq24]

It's already exit - you just need to activate it in the HA UI... Cable maximum current

[miwi73]

Über die html api kommt der Amperewert des Kabels {"cbl":32} . Die Entität "sensor.goe_200100_cbl" bleibt aber bei unknown. Ich habe den Wert aber in der Ladestromlimitliste "sensor.goe_200100_cll" gefunden und extrahiere in mit einem Template-Helfer.

[marq24]

kannst Du so gut sein einmal mit dem DebugLog Options starten und prüfen, dass das kein Fehler intern irgendwoe gelogged wird? - also wenn die API {"cbl":32} liefert, dann sollte das auch im entsprchenden Sensor ankommen... AKA, wörks fine in my office .... mhhhh

[miwi73]

Here we go:

2026-01-19 17:01:11.801 DEBUG (MainThread) [custom_components.goecharger_api2.pygoecharger_ha] going to request 17 keys from go-eCharger@http://192.168.178.30
2026-01-19 17:01:11.855 DEBUG (MainThread) [custom_components.goecharger_api2.pygoecharger_ha] read 17 values from go-eCharger@http://192.168.178.30
2026-01-19 17:01:11.855 DEBUG (MainThread) [custom_components.goecharger_api2] Finished fetching goecharger_api2 data in 0.054 seconds (success: True)
2026-01-19 17:01:16.294 DEBUG (MainThread) [custom_components.goecharger_api2.pygoecharger_ha] going to request 59 keys from go-eCharger@http://192.168.178.30
2026-01-19 17:01:16.371 DEBUG (MainThread) [custom_components.goecharger_api2.pygoecharger_ha] [missing fields: 3 -> ['ccu', 'rfb', 'rst']] - not all requested fields where present in the response from from go-eCharger@http://192.168.178.30
2026-01-19 17:01:16.371 DEBUG (MainThread) [custom_components.goecharger_api2.pygoecharger_ha] going to request 72 keys from go-eCharger@http://192.168.178.30
2026-01-19 17:01:16.447 DEBUG (MainThread) [custom_components.goecharger_api2.pygoecharger_ha] [missing fields: 1 -> ['hsa']] - not all requested fields where present in the response from from go-eCharger@http://192.168.178.30
2026-01-19 17:01:16.447 DEBUG (MainThread) [custom_components.goecharger_api2] Finished fetching goecharger_api2 data in 0.153 seconds (success: True)
2026-01-19 17:01:16.447 DEBUG (MainThread) [custom_components.goecharger_api2.pygoecharger_ha] going to request 15 keys from go-eCharger@http://192.168.178.30
2026-01-19 17:01:16.498 DEBUG (MainThread) [custom_components.goecharger_api2.pygoecharger_ha] [missing fields: 12 -> ['ccrv', 'fwc', 'c0i', 'c1i', 'c2i', 'c3i', 'c4i', 'c5i', 'c6i', 'c7i', 'c8i', 'c9i']] - not all requested fields where present in the response from from go-eCharger@http://192.168.178.30
2026-01-19 17:01:16.499 INFO (MainThread) [custom_components.goecharger_api2.pygoecharger_ha] read_versions(): '59.4' FirmwareVersion detected -> 'cards' list is present
2026-01-19 17:01:16.499 INFO (MainThread) [custom_components.goecharger_api2] active cards ['1']

[miwi73]

cbl wird dort nicht genannt, aber der state bleibt bei unknown. Wie geschrieben, behelfe ich mir mit der cll Entität. Das funktioniert auch.

[marq24]

Danke für Dein FEEDBACK - ich bin DUMM und es braucht ein Update - sorry - ich habe zwar eine Entify definiert - aber keinen Abfrage-Key für die API hinterlegt...

[miwi73]

Dafür sind die Nutzer ja da. Ist wohl auch keine gängige Entität. Für den Tesla könnte ich auch Werte der Tesla Integration nehmen, aber der Opel Corsa meiner Tochter ist leider "dumm". Somit behelfe ich mir mit dem jeweiligen Ladekabel um festzustellen welches Auto lädt.

Anderes Thema: Ich möchte zukünftig weg von der nativen Go-E Handyapp. Aktuell habe ich 3 Ladeszenarien:

• PV Überschussladen
• AdHoc laden
• Nacht laden
  Hierzu habe ich mir einen Helfer mit den 3 Optionen gebaut und steuere diesen über Knöpfe auf dem Dashboard.
  AdHoc bedeutet laden mit vollen 11kW sobald das Fahrzeug eingesteckt ist. Nacht laden bedeutet, dass das Fahrzeug zu irgendeiner Tageszeit eingestöpselt wird, das Laden aber erst nach 0:00 Uhr beginnt und spätestens um 5:00 Uhr beendet wird (Octopus Go Nachttarif).
  Hier möchte ich mir jetzt Automationen schreiben, welche die Entitäten Deiner Go-E Integration entsprechend der 3 Szenarien umstellt.
  Welche Werte muss ich zum PV Überschussladen in den Entitäten anwählen und welche zum Adhoc / Nachtladen?

Danke für die Hilfe,

Michael

[marq24]

Ich muss gestehen, ich mach das inzwischen alles über EVCC und damit wären dann auch Deine 3 Modi direkt abgefrühstückt... ich kann aber verstehen, da für den goE Chrager ein EVCC Sponsor Token nötig ist, dass das nicht unbedingt der Weg für Dich ist.

[miwi73]

Ich habe einen weiteren, kleinen Bug gefunden. Die Anzahl der Phasen (pnp) steht immer bei 0. Erneut nicht tragisch, da ich mir hier auch über einen Helfer bei überschreiten von 6A auf Phase 3 sind 3 Phasen aktiv, bauen kann. Diesen Wert brauche ich für meine Visualisierung, da ich gerne anzeigen möchte mit wievielen Phasen gerade geladen wird.

[marq24]

der Wert dürfte nur übertragen werden wenn ein Auto angeschlossen ist? Hier finde ich zumindest erstmal keinen Hinweis, das der Wert nicht von der API abgefragt werden würde... Also anders als beim cbl (da war der key ja nicht in der Query...) pnp steckt aber schon drin... Liefert die lokale API ggf keinen Wert? [bzw 0] ?!

[miwi73]

Getestet während das Auto geladen hat. Testweise zwischen 1 und 3-phasigen Laden gewechselt. Wert bleibt dauerhaft bei 0.

[marq24]

... wie gesagt, diesmal steckt der KEY in dem request an die API mit drin - sieht für mich von REMOTE so aus, als würd die API einfach keinen passenden Wert zurück liefern ?!

[miwi73]

Ok. Dann halt der Umweg über die Abfrage der Stromstärke auf Phase 3. ;)

[marq24]

ich wäre aber schon Neugierig, was die API bei dem Key zurück gibt (ich kann das erst am Wochenende selber testen)... Also klar, wenn die API immer 0 liefert, dann würde ich ggf den Sensor auch einfach wieder rauswerfen - weil "no data = no value for the user"