Indicate protocol for devices

[premultiply]

• 🔌 add protocol field to templates to distinguish different implementations for the same product (e.g. localapi & ocpp)
• 🌟 presets in defaults.yaml now can have requirements and protocol

TODOs

• verify evcc configure works correctly
• config ui: generalize naming adjustment @naltatis
• decide multiple-protocol support @andig

[naltatis]

Wo wir hier gerade beim Namensaufräumen sind. Wie unterscheiden sich denn die beiden Victron-Implementierungen?

Ist das eine die "Charging Station NS" und wenn ja welche? Oder sind das auch zwei unterschiedliche Implementierungen für das gleiche Gerät?

\cc @philipptrenz @andig

[naltatis]

Das Victron Thema hat sich erledigt: 260c13e

[andig]

Mir ist nicht so richtig klar, was wir hier erreichen wollen. Insbesondere: warum sollten wir zwei Implementierungen für eine Box anbieten? Auch bei diesem PR wäre es schön, ihn in kleinere Portionen zu zerteilen. Z.b. sind requirements von presets auch alleine nützlich.

[premultiply]

Hier kommen eine Ladung neue OCPP-Templates rein.
Gleichtzeitig die erforderlichen Umbauten um dies in UI, configure und Doku entsprechend schön aufzubereiten - auch wenn es stellenweise mehrere Wege gibt eine Box anzusprechen.

[andig]

auch wenn es stellenweise mehrere Wege gibt eine Box anzusprechen.

Das sollten wir nach Möglichkeit nicht tun. Lasst uns gerne diskutieren wo das absolut notwendig ist.

[premultiply]

Das wäre wenn überhaupt nur ein Sonderfall für Boxen die über mehrere Wege angesprochen werden können und dabei verschiedene Features haben (z.B. Keba und Sungrow). Steht hier nicht im Fokus.

Hier geht vor allem mal darum einheitlich anzeigen, suchen, sortieren und filtern zu können welche Box mit welcher Schnittstelle angesprochen/konfiguriert werden muss.

[philipptrenz]

Wo wir hier gerade beim Namensaufräumen sind. Wie unterscheiden sich denn die beiden Victron-Implementierungen?

Sorry für die späte Rückmeldung, bin gerade im Urlaub. Aber ja, so hätte ich es auch gelöst 👍🏼
Der Hinweis auf das notwendige Sponsorship muss noch entfernt werden, richtig?

[andig]

Sollen wir hier fertig machen oder schließen? Ich nehme mal tentatively das backlog raus.

[naltatis]

Protokoll wird nun im Dropdown angezeigt, wenn sonst nicht eindeutig.

@andig Wir haben mit dem "SG Ready" bei den WPs gerade ein ähnliches durcheinander (zumindest in der Darstellung). Hier ists aber weniger das technische Protokoll sondern eher der Betriebsmodus der die SG-Ready von den nicht SG-Ready-Geräten unterscheidet, richtig? Hier könnten wir auch noch mal über eine strukturiertere Erfassung (Flag/Attribut) nachdenken und die dann in Doku/Config UI Anzeigen sofern für den Endnutzer relevant. (out of scope für dieses Ticket)

[andig]

Was fehlt hier noch? Mir ist ehrlich gesagt nicht klar, wofür es "protocol" braucht und in welchen Fällen es hinzu gefügt wird oder eben nicht. Das ist eine gültige Auswahl für "protocol"?

[premultiply]

Um bei Chargern die über mehrere Protokolle implementiert wurden (z. B. auf Grund von von unterschiedlichen Funktionalitäten der Protokolle) dem Nutzer einen Indikator zu geben was er da genau konfiguriert (hat) bzw. einrichten muss.

[sourcery-ai]

Hey @premultiply - I've reviewed your changes - here's some feedback:

• Splitting every product model into its own entry increases YAML verbosity; consider if grouping closely related models might offer a better trade-off.
• Review the template file naming convention for consistency, particularly regarding the use of protocol prefixes like ocpp-.

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟡 Complexity: 1 issue found
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (complexity): Consider refactoring the inline preset merging logic into smaller helper functions to improve readability and reduce nesting.

The inline preset merging logic now handles several responsibilities at once. Consider breaking out the logic into small helper functions to reduce nesting and increase clarity. For example:

func mergePreset(t *Template, base PresetDefinition) error {
	// Merge params
	t.Params = append(t.Params, base.Params...)
	applyProtocol(t, base)
	applyDescription(t, base)
	appendRequirements(t, base)
	return nil
}

func applyProtocol(t *Template, base PresetDefinition) {
	if t.Protocol == "" && base.Protocol != "" {
		t.Protocol = base.Protocol
	}
}

func applyDescription(t *Template, base PresetDefinition) {
	if t.Requirements.Description.DE == "" &&
		t.Requirements.Description.EN == "" &&
		t.Requirements.Description.Generic == "" {
		t.Requirements.Description = base.Requirements.Description
	}
}

func appendRequirements(t *Template, base PresetDefinition) {
	for _, r := range base.Requirements.EVCC {
		if !slices.Contains(t.Requirements.EVCC, r) {
			t.Requirements.EVCC = append(t.Requirements.EVCC, r)
		}
	}
}

Then update your loop in ResolvePresets() to simply call:

if p.Preset != "" {
	base, ok := ConfigDefaults.Presets[p.Preset]
	if !ok {
		return fmt.Errorf("could not find preset definition: %s", p.Preset)
	}
	if err := mergePreset(t, base); err != nil {
		return err
	}
	continue
}

This refactor reduces inline complexity while keeping functionality intact.