You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Häufig wird evcc zusammen mit anderen Automatisierungs- und Monitoringsystemen verwendet, z.B. iobroker-Integration/Skriptsteuerung oder auch HEMS (SMA).
Sobald man nun neue Ladepunkte hinzufügt, muss man diese zwingend - um nicht alles andere kaputt zu machen - immer am Ende einfügen.
Alle API Zugriffe und auch MQTT Kommunikation beruhen auf dem Index der Loadpoints.
Es wäre zwar denkbar, dass man den "name" verwendet, aber auch der muss nicht zwingend stabil sein.
Was spräche dagegen, im yaml pro Loadpoint eine frei wählbare ID zu hinterlegen - sei es int oder guid oder string -
und - falls notwendig wegen Rückwärtskompatibilität - unter den globalen Einstellungen wählen muss ob mit ID oder Index gearbeitet wird?
The text was updated successfully, but these errors were encountered:
Mit Einführung der Config UI werden wir für alle Ladepunkte eine eindeutige Datenbank-ID bekommen. Diese sollten wir dann auch als Identifier in allen API verwenden.
Häufig wird evcc zusammen mit anderen Automatisierungs- und Monitoringsystemen verwendet, z.B. iobroker-Integration/Skriptsteuerung oder auch HEMS (SMA).
Sobald man nun neue Ladepunkte hinzufügt, muss man diese zwingend - um nicht alles andere kaputt zu machen - immer am Ende einfügen.
Alle API Zugriffe und auch MQTT Kommunikation beruhen auf dem Index der Loadpoints.
Es wäre zwar denkbar, dass man den "name" verwendet, aber auch der muss nicht zwingend stabil sein.
Was spräche dagegen, im yaml pro Loadpoint eine frei wählbare ID zu hinterlegen - sei es int oder guid oder string -
und - falls notwendig wegen Rückwärtskompatibilität - unter den globalen Einstellungen wählen muss ob mit ID oder Index gearbeitet wird?
The text was updated successfully, but these errors were encountered: