evcc-io
Indicate protocol for devices
- 🔌 add
protocolfield to templates to distinguish different implementations for the same product (e.g. localapi & ocpp) - 🌟 presets in
defaults.yamlnow can haverequirementsandprotocol
TODOs
- [x] verify
evcc configureworks correctly - [x] config ui: generalize naming adjustment @naltatis
- [ ] decide multiple-protocol support @andig
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
Das Victron Thema hat sich erledigt: https://github.com/evcc-io/evcc/commit/260c13e6d402e51fa4f8fa9dba071af194ef0dbe
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.
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.
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.
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.
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?
Sollen wir hier fertig machen oder schließen? Ich nehme mal tentatively das backlog raus.
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)
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"?
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.