MQTT ich verzweifle langsam

[Gero]

Jetzt habe ich auch dein Problem verstanden. Und ich habe nun auch verstanden, woher die „nach 5 Minuten verworfen“-Logik herkommt. Interessanterweise ist das ja auch die Schnittstelle der pro und ist von openWB entworfen worden. Selbst wenn Gründe dafür sprechen, das Token nicht irgendwann zu löschen hätte man ja durchaus eine Quittierung so wie du es vorgeschlagen hast, vorsehen können.

So bleibt halt nur, dass der Abholer das Token nach 5 Minuten als nicht vorhanden interpretiert.

Aber sind wir hier nicht in einem MQTT-Thread?

[kaindl]

So bleibt halt nur, dass der Abholer das Token nach 5 Minuten als nicht vorhanden interpretiert.

Wie soll der Abholer das machen? Er bekommt ja keinen Timestamp dazu. Würde er nach jeder Änderung des Tokens diesen nach 5 Min verwerfen, kann der Token nicht 2 Mal hintereinander laden, denn der Abholer sieht ja nicht, wenn der Token erneut gesendet wird.
-> die Logik zum Verwerfen kann für die modbus-Schnittstelle *nur* in der openWB als secondary umgesetzt werden, zumindest solange die modbus-Schnittstelle nicht um den Timestamp oder eine Quittierungsmöglichkeit erweitert wird.

Aber sind wir hier nicht in einem MQTT-Thread?

Das stimmt, sorry. Ich bin über diesen Thread gestolpert, als ich nach dem Problem gesucht habe, weil der vorletzte Beitrag von SpaceUnicorn soch auf das Problem mit evcc bezog und hab mich dann dran gehängt :/

[Gero]

Eine neue 5-Minuten-Periode könnte ja mit jedem Ab- oder Anstecken beginnen. Validiert werden muss ja nur einmal. Vielleicht wirdndas Token ja auch beim Abstecken gelöscht?
Das nur mal als Idee, wie es ohne Timestamp gehen könnte. Wie gesagt: könnte. Ich hab‘ mich mit der modbus-Steuerung noch nicht detailliert beschäftigt. Bin da nur interessierter Laie.

[kaindl]

Ja, ich fände eine Umsetzung durch die openWB als Secondary auch deutlich besser, als zusätzliche Register dafür auf modbus einzuführen.
Aktuell wird leider auch beim Abstecken nichts verworfen. Aber das wäre auch das, was ich als sinnvoll ansehen würde:
Nach dem Scan nach 5 Minuten verwerfen, wenn nicht angesteckt wird, ansonsten beim Abstecken verwerfen...

Aaaber, und damit der Bogen zurück zum Thread :
Damit wäre das Verhalten auf modbus und mqtt sehr unterschiedlich und das müsste auch innerhalb der openWB passend nachgehalten werden: für die mqtt-Schnittstelle wäre der Token noch gültig, weil noch nicht quittiert, für modbus aber nicht mehr, weil älter als 5 Minuten. Das kann eigentlich nur fehleranfällig werden -> deshalb sollte es wohl eher auf dem modbus analog zum mqtt Timestamp und quittieren geben...

[SpaceUnicorn]

Den Vorschlag für ein äquivalentes Verhalten von mqtt und modbus unterstütze ich, aber als ich mit das letzte Mal die mqtt topics angeschaut habe, ist der timestamp kontinuierlich aktualisiert worden, was auch dort eine clientseitige Prüfung sehr erschwert.
Ich habe mir jetzt erst einmal mit einem kleine Python-Script ausgeholfen, das sich bei einer Änderung des gescannten RFID Tags den Zeitstempel selbst speichert und in Abhängigkeit vom Plugstate (nicht eingesteckt nach 5min, nach dem Ausstecken nach 30 sec) per API den RFID Tag resettet. Es wäre aber super, wenn dies von der secondary OpenWB selbst erledigt wird (auf modbus und mqtt), oder zumindest die erforderlichen Daten und Methoden auf allen Kanälen bereitstellt.

[openWB]

Magst du mal ein issue bei github aufmachen?
Modbus greift ohnehin nur auf die interne MQTT Struktur zu.
Den reset kriegen wir da mit rein.
Oder gern nen PR, hier ungefähr müsste das wohl hin:
https://github.com/openWB/core/blob/216 ... er.py#L151


Das die secondary das selbst macht sehe ich nicht.
Reset ist Aufgabe des Masters.

[kaindl]

Ich habs mir gerade mal ein bisserl angeschaut, ob ich da direkt was hinbekomme, was ich in einen PR packen kann, aber leider festgestellt: da scheint mehr nicht zu passen bei dem Thema.
Für MQTT ist der Timestamp zwar dokumentiert, wird aber nicht veröffentlicht. Der Timestamp wird nur in der Logik als Master verwendet, die eben auch das Verwerfen nach 5 Minuten und die Verarbeitung mit dem gesteckt-Status macht. Die können wir für den secondary aber nicht direkt verwenden, weil die nur greift, wenn die Tokens auch in der openWB registriert sind, was ja als secondary gar nicht geht.

Während ich analysiert und getestet habe, ist mir aber noch was aufgefallen:
RFID und RFID_Timestamp sind im MQTT auf den einzelnen Ladepunkten verortet, auf dem modbus ist der RFID auch für jeden Ladepunkt definiert. Nur last_tag ist global, der aber wieder keinen Timestamp hat.
Damit die Tags den Ladepunkten zugeordnet werden können, müsste die Logik aber doch auf der secondary laufen, denn sie muss ja vor dem publish stehen, ohne den ein Master ja gar nichts tun kann.
-> Ich werd morgen doch erst mal einen issue aufmachen, in dem das Ziel diskutiert und festgelegt werden kann, vorher macht es keinen Sinn, etwas zu implementieren....

[Gero]

Am schönsten wäre es ja, wenn der plug_state bei der Gelegenheit auch einen timestamp bekommen würde. Dsnn könnte man zu Zuodnung zwei timestamps der selben lokalen Uhr miteinander vergleichen, um eine Zuordnung von eingesteckten Auto und RFID-Tag herzustellen. Aber halt! Wie ist das mit den Secondariss ihne RFID-Leser? Da wird an der Primary gescannt. Und da kann ja auch gerade nichts eingesteckt sein. (Das ist eventuell das Argument gegen zu viel Logik in der Secondary, da ich vermute, dass die Primary softwaretechnisch wie eine Secondary angesteuer wird) Aktuell ist es ja so, dass nach dem Einstecken urgendwo (auch an anderen secondaries?) ein RFID-Tag gesucht wird, um es letzten plug_state zuzuordnen. Das aktuell schwierige ist ja, zwei scans des selben Tags auseinanderzuhalten. (Also den Scan von letzter Woche von dem gerade eben)

Es ist mal wieder nicht einfach, wenn man genauer hinkuckt….


Edit: im Sinne von Einheitlichkeit und Wahlfreiheit der Schnittstelle, wäre es in meinen Augen sehr sinnvoll, über MQTT die selben Daren anzubieten wie über modbus. Wobei sich mir natürlich die Frage stellt, ob die Steuerung einer Secondary so wahlfrei denn sein muss. Das ist aber eine andere Frage.

[openWB]

Modbus ist nur relevant wenn die openWB im secondary Modus ist und es keinen openWB Primary gibt.

[kaindl]

https://github.com/openWB/core/issues/2832 ist erstellt