Chargers, type: custom, zusätzliche Variable: identifiers

[Alumno666]

Ich nutze schon seit längerem eine Wallbox des Types custom. Es klappt soweit sehr gut :-) Danke an das Team!
Nun haben wir ein zweites EV und es wäre schön, wenn eine Fahrzeugerkennung mittels der RFID-Tags möglich wäre. Die Kommunikation mit der WB geht per Modbus-TCP. Es fehlt quasi ein Plugin, das den Identifier auslesen könnte, ich stelle mir das z.B. mit folgendem Code vor:

chargers:

• type: custom

…

identifiers: # ermitteln der RFID token ID
  source: modbus
  uri: 192.168.xxx.xxx:502
  register:
    address: xxx
    type: input  # read a holding register
    decode: uint16 # oder 32 oder 64, je nachdem, was geht - ich bin mir nicht sicher, in der Modbus Bibliothek fehlt ja wohl die Eigenschaft "char"

Was haltet Ihr davon?

Es grüßt Alumno666

[StefanSchoof]

Wenn ich mit meinem geringen Go Kenntnissen auf

evcc/charger/charger.go

Line 104 in c89bfcc

var identify func() (string, error)

schaue könnte es sein, dass es das schon gibt und identify heißt.

[Alumno666]

Hallo @StefanSchoof
nochmals danke für den Hinweis - es hat etwas gedauert, bis mir die Tomaten von den Augen gerutscht sind. Das Problem ist halt sehr oft vor der Tastatur und nicht dahinter ;-)
Es muss an dieser Stelle natürlich "identify" heissen und nicht "identifiers".

So sieht der Teil für den Charger nun aus, und syntaxmäßig läuft das durch.

identify: # ermitteln der ID des RFID tag
source: modbus
uri: 192.168.xxx.xxx:502
register:
address: 1000
type: input
decode: uint16s # Typ "char" gibt's ja nicht

Den ganzen String bräuchte ich nicht, ich denke, die ersten 2 Bytes sollten für meine Anwendung ausreichen.

@andig Leider gibt es jetzt noch einen Modbus-Fehler die Abfrage: modbus: exception '2' (illegal data address), function '4')

Wenn ich die Adresse vom PC aus mit einem Modbus-Tester abfrage, funktioniert das einwandfrei, egal ob als Input- oder Holding-Register. Könnte das an der unpassenden Dekodierung liegen?

Gruß

[Alumno666]

Hallo @StefanSchoof,
hm, sehr interesant... Danke für den Hinweis. Ich kann zwar kein GO aber mit meinen bescheidenen Programmierkenntnissen vermute ich ebenfalls, dass es vielleicht den ganzen Code für mein Problem schon gibt? Die Frage wäre, und da fehlt mir der Blick auf das große Ganze, ob ich die Funktion "identify" irgendwie auch über die YAML-Datei aufrufen kann und ich sehe ebenfalls nicht, ob diese Funktion dann tatsächlich auch mittels Modbus die Daten in die richtige Variable schreibt, die ich über den "normalen" Weg in der YAML-Datei mittels "identifiers" abrufen kann.. Ich habe dazu nix in der Dokumentation gefunden. Wie gesagt, der Gesamtblick fehlt mir, aber vielleicht hat da ja jemand einen Hinweis für mich.

[andig]

Hier steht alles was es zu konfigurieren gibt:

evcc/charger/charger.go

Lines 30 to 45 in c89bfcc

	func NewConfigurableFromConfig(ctx context.Context, other map[string]interface{}) (api.Charger, error) {
	var cc struct {
	embed `mapstructure:",squash"`
	Status, Enable, Enabled, MaxCurrent provider.Config
	MaxCurrentMillis *provider.Config
	Identify, Phases1p3p *provider.Config
	Wakeup *provider.Config
	Soc *provider.Config
	Tos bool
	// optional measurements
	Power *provider.Config
	Energy *provider.Config
	Currents, Voltages []provider.Config
	}

Alle mit * sind optional.

In

evcc/charger/charger.go

Lines 103 to 110 in c89bfcc

	// decorate identifier
	var identify func() (string, error)
	if cc.Identify != nil {
	identify, err = provider.NewStringGetterFromConfig(ctx, *cc.Identify)
	if err != nil {
	return nil, fmt.Errorf("identify: %w", err)
	}
	}

siehst Du, dass das konfigurierte identify einen String zurück geben muss.

Die Logik ist auch bei Zählen, Tarifen und Fahrzeugen identisch.

[Alumno666]

Hallo @andig,
hm... dazu müsste ich dann aber das Programm ergänzen und neu kompilieren - oder?
Oder gäb's eine Möglichkeit das mit JS irgendwo dranzuhäkeln?

[andig]

ich bin mir nicht sicher, in der Modbus Bibliothek fehlt ja wohl die Eigenschaft "char"

@Alumno666 was brauchst Du denn- einfach eine Anzahl Bytes oder muss damit noch was passieren? Leading/Trailing Zeros und Spaces abschneiden?

Tatsächlich kann das Modbus Plugin das schon:

var _ StringProvider = (*Modbus)(nil)

// StringGetter implements StringProvider
func (m *Modbus) StringGetter() (func() (string, error), error) {
	op, err := m.reg.Operation()
	if err != nil {
		return nil, err
	}

	return func() (string, error) {
		b, err := m.readBytes(op)
		if err != nil {
			return "", err
		}

		return strings.TrimSpace(string(bytes.TrimLeft(b, "\x00"))), nil
	}, nil
}

Was fehlt Dir da? Ich würde das Trim nach rechts noch ergänzen (#17413).

[Alumno666]

Hallo @andig ,
es ist kurios, ich habe den Raspi neu gestartet und mit der Dekodierung

decode: uint16s

läuft die Abfrage nun durch. Im Trace wird

charger vehicle id: C5

angezeigt. Und das sind die beiden ersten ASCII-Zeichen des Tags, auch in der richtigen Reihenfolge, soweit sieht es gut aus.

Spontan fällt mir dazu allerdings ein, dass in meinem Fall die Bytes im Register vertauscht sind. Es wäre gut, wenn in deinem Plugin so ein (Sonder-)Fall auch bedacht wäre.
Danke und Grüße

[Johannes-288]

Hallo @Alumno666, ich versuche seit einigen Tagen eine Ladestation von Schrack, die ich mit ESPHome und Modbus RTU ansteuern kann, mit EVCC zu verbinden. Mit der Variante Custom und den Langzeit-Token hab ich bereits das Auto im EVCC in Betrieb. Leider funktioniert dies mit der Wallbox nach der Doku nach nicht. Kannst du deinen Custom-Wallbox-Code-Ausschnitt mir zeigen, damit ich um auf meinen Fehler komme?

[Alumno666]

Hallo @Johannes-288,

hier der Ausschnitt meiner Konfiguration:

chargers:

type: custom

name: Wallbox
status:
  source: modbus
  uri: 192.168.2.xxx:502
  timeout: 3s
  register:
    address: 501
    type: input
    decode: int16
enabled:
  source: modbus
  uri: 192.168.2.xxx:502
  register:
    address: 805
    type: holding
    decode: uint16
enable:
  source: modbus
  uri: 192.168.2.xxx:502
  register:
    address: 805
    type: writesingle
    decode: uint16
maxcurrent:
  source: modbus
  uri: 192.168.2.xxx:502
  register:
    address: 802
    type: writesingle
    decode: uint16

Vielleicht hilft es dir weiter.

edit: die Formatierung ist nur in der Vorschau korrekt - hm...
edit: jetzt im zweiten Versuch ist die Formatierung besser...