openWB Forum

Zeitladen über Mitternacht


Wr haben einen günstigeren Nachtstromtarif, deshalb habe ich ein Zeitfenster (22-9 Uhr) unter Termine-Laden (auf der Hauptseite mit den Zanhrädchen) angelegt. Um 10 sek nach Mitternacht stoppt die Ladung.
Eine Workaround ist, ein zweites Zeitfenster nach MItternacht anzulegen

Vergabe einer ID kann nicht konfiguriert/beeinflusst werden.

Wenn ich einen neuen Ladepunkt oder ein neues Fahrzeug konfiguriere wird automatisch eine neue ID angelegt.

Das hat den Nachteil, dass ich nicht festlegen kann welche Wallbox der lp1, lp2, ... ist.

In meinem Fall gibt es keinen lp1 sondern nur einen lp2 und lp3 in der Übersicht.

Ob jetzt aber die Heidelberg1 der lp2 ist kann man nur raten.

Bei der Konfiguration eines Fahrzeugs das gleiche Problem.
Ich hatte mein Fahrzeug konfiguriert, gelöscht und neu eingerichtet.
Jetzt hat dieses Fahrzeug die ID 2, ein Fahrzeug mit der ID 1 gibt es nicht.

Die Anzeige in der GUI ist damit verwirrend.
Die MQTT Schnittstelle, in der die ID fest im Pfad verwendet wird, ist damit auch schwer zu betreiben, weil sich schnell die ID z.B. durch löschen und neu anlegen verändern kann.

Ja, das ist richtig, die IDs können nicht beeinflusst werden. Was aber auch okay ist, die spielen für uns im Grunde keine Rolle.
Die Hauptseite muss noch überarbeitet werden, das steht auf der Agenda. Was wir aktuell haben ist die Variante 'quick&dirty' - z.b. noch ohne Unterstützung der vergebenen Namen für Ladepunkte und Fahrzeuge im Diagramm. All das kommt noch.

Habe gerade versucht openWB2.0 noch einmal neu aufzusetzen (wegen Solaredge Problemen).
Habe hierzu das Image aus dem Forum heruntergeladen.
Hat soweit alles geklappt mit Stand der SW vom 10.11.22.
Aktualisierungsversuche auf neuere Versionen klappen nicht. Version vom 10.11. wird weiterhin als aktuellste Version angezeigt.
Ps Zumindest klappt mit dieser Version aber die PV Anzeige etc. bei mir...

schau' mal was im Entwicklungszweig eingestellt ist, womögilch steht die Box auf Beta.

Vielen Dank Martin, das war es.
Gut zu wissen fürs nächste Mal.

Leider habe ich jetzt wieder die Probleme mit den Anzeigen ...
viewtopic.php?p=76547#p76547

Nun gut, war ein Versuch, ob sich bei mir ein Fehler eingeschlichen hat.

PS:ein Rückschwenk im "Entwicklungszweig" auf die Beta Version vom 10.11.2022 lässt das System abstürzen = Neuinstallation erforderlich ( wie vielleicht zu erwarten )

mrinas hat geschrieben: ↑Sa Dez 10, 2022 1:36 pm Ja, das ist richtig, die IDs können nicht beeinflusst werden. Was aber auch okay ist, die spielen für uns im Grunde keine Rolle.
Die Hauptseite muss noch überarbeitet werden, das steht auf der Agenda. Was wir aktuell haben ist die Variante 'quick&dirty' - z.b. noch ohne Unterstützung der vergebenen Namen für Ladepunkte und Fahrzeuge im Diagramm. All das kommt noch.

Noch ein Problem mit den IS: Wenn via MQTT Daten geschrieben werden bevor in openWB das Objekt konfiguriert ist, wird diese ID blockiert und es geht dann einfach mit der nächsten weiter.

Beispiel Fahrzeuge:
Das Standard-Fahrzeug hat in MQTT die ID = 0
openWB/set/vehicle/0/get/soc

Über MQTT werden Daten zu ID = 2 übermittelt, z.B. openWB/set/vehicle/2/get/soc

Wenn ich jetzt erst ein neues Fahrzeug konfiguriere bekommt dieses Fahrzeug die ID = 3

Was hinter der ID1 und ID2 als Konfiguration steckt ist unklar.
Diese beiden IDs sind einfach jetzt immer blockiert/reserviert.

Beheben kann man das nur durch komplettes neuaufsetzen.

Aus meiner Sicht ist das schon ein Problem, weil ständig die MQTT Schnittstelle angepasst werden muss und wehe man vergisst etwas, z.B. die MQTT Schnittstelle starten bevor das Fahrzeug konfiguriert ist. Dann ist die ID vergeben und kann nicht mehr verwendet werden.

hannesrh hat geschrieben: ↑Di Dez 13, 2022 9:02 am Aus meiner Sicht ist das schon ein Problem, weil ständig die MQTT Schnittstelle angepasst werden muss und wehe man vergisst etwas, z.B. die MQTT Schnittstelle starten bevor das Fahrzeug konfiguriert ist. Dann ist die ID vergeben und kann nicht mehr verwendet werden.

Das hat mich in ca. 1 Jahr bisher einmal getroffen, dass ich in einem NR Flow die ID ändern musste.
Lösung: Die ID in eine flow-Variable gelegt: Pflege an einer Stelle.

Wenn ich das Problem häufiger hätte würde ich die IDs und Namen per MQTT aus der 2.0 holen
und eine Liste mit dem Mapping anlegen.

rleidner hat geschrieben: ↑Di Dez 13, 2022 9:18 am Wenn ich das Problem häufiger hätte würde ich die IDs und Namen per MQTT aus der 2.0 holen und eine Liste mit dem Mapping anlegen.

Da wäre es doch perspektivisch geschickter, bei der Konfiguration auf Eindeutigkeit der Namen zu prüfen und auf die Namen zu publishen. Oder man konfiguriert je ID noch ein MQTT-Topic, auf das gepublisht wird. (Wenn keins gepflegt ist, dann wird die ID genommen, so machen es die Shellies ja auch)

Gero hat geschrieben: ↑Di Dez 13, 2022 9:35 am

rleidner hat geschrieben: ↑Di Dez 13, 2022 9:18 am Wenn ich das Problem häufiger hätte würde ich die IDs und Namen per MQTT aus der 2.0 holen und eine Liste mit dem Mapping anlegen.

Da wäre es doch perspektivisch geschickter, bei der Konfiguration auf Eindeutigkeit der Namen zu prüfen und auf die Namen zu publishen. Oder man konfiguriert je ID noch ein MQTT-Topic, auf das gepublisht wird. (Wenn keins gepflegt ist, dann wird die ID genommen, so machen es die Shellies ja auch)

Perspektivisch stimme ich Dir zu - kommt halt auf die Entwickler-Kapa und die Prioritäten an.
Wenn es mir dringend wäre, würde ich erst mal die Liste(n) nach extern holen.