WARP1 verliert WLAN und MQTT Einstellungen (2.1.4)

[Bratpfanne]

Liebes Tinkerforge Team,

nach dem Update von 2.1.3 auf 2.1.4 ist es nun mehrfach aufgetreten, dass meine WARP1 11kW mit SDM72DM-V2 die WLAN und MQTT Einstellungen verliert. Gesteuert wird sie über EVCC. Wenn ich dann händisch über das Fallback WLAN die Einstellungen neu setze, funktioniert es wieder.

Beim letzten Mal bin ich dann als erstes auf die 10.0.0.1/recovery gegangen und habe den debug report heruntergeladen. Dort sehe ich folgende Fehler:

               9877,275  Request 175: Exception code -1
              20304,528  Request 181: Exception code -1
              26211,158  Request 171: Exception code -1
              29833,437  Request 195: Exception code -1
              47014,880  Request 201: Exception code -1
              47337,043  Request 213: Exception code -1

Könnt ihr mit helfen, was ich verbessern kann, damit sie wieder stabil läuft?

Vielen Dank

Bratpfanne

debug-report-2023-09-08T06-20-24-360Z.txt

[MatzeTF]

Die gelegentlichen „Exception code -1“ sind kein Problem. Das bedeutet Nur, dass der Stromzähler manchmal nicht schnell genug antwortet.

Am Debug Report kann man leider nicht sehen, warum ein paar Einstellungen verloren gegangen sind. Bitte lade einen neuen Deport Report runter, wenn das Problem wieder aufgetreten ist und du dich mit dem Fallback-WLAN verbunden hast, also noch bevor du an den Einstellungen irgendwas geändert hast, um sie zu korrigieren.

[Waschy]

Habe / hatte heute zufällig auch das Problem, dass meine WARP (TINKERFORGE WARP2 CHARGER V2.1.4-64e60ce2) nicht mehr in WLAN zu finden war ... habe mich dann mit dem Build-In Access Point verbunden und mein Setup war weg ... Zuordnung zu NFC Tags, WLAN, MQTT ... so ziemlich alles. Habe aber leider kein Debug Log gezogen ... Zufall oder ein Problem?

[MatzeTF]

Da wir das hier heute auch schon einmal beobachtet haben, scheint das tatsächlich ein Problem zu sein. 😒

Beim nächsten Mal bitte auch direkt einen Debug Report runterladen.

[Bratpfanne]

Danke für die schnelle Antwort. Ich war der Meinung, dass der Debug Report direkt von der Recovery Seite mit dem Fallback AP kommt, ohne dass ich sonst etwas geändert habe. Später habe ich diesen noch gezogen, das war ebenfalls von der 10.0.0.1 aber der normalen Website, ohne recovery. Ich werde es das nächste Mal erneut versuchen.

debug-report-warp-SA8-2023-09-08T08-21-10-452.txt

[MatzeTF]

@Bratpfanne @Waschy Was für einen MQTT-Broker verwendet ihr? Ist das zufällig ioBroker?

[Bratpfanne]

Ja genau, ich nutze ioBroker.

[MatzeTF]

Dann ist das Problem wahrscheinlich folgendes:

Die Wallboxen bieten eine API an, über die auch Einstellungen zurückgesetzt werden können. Das Webinterface benutzt die z.B. für die „Zurücksetzen“-Buttons. Da die API für HTTP und MQTT gleich ist, kann man auch per MQTT seine Einstellungen zurücksetzen. Wenn man ein entsprechendes Paket zum Zurücksetzen hinschickt, macht das genau das, was man möchte. Bei MQTT-Nachrichten gibt es aber das „retain“-Flag, das dazu führt, dass eine Nachricht auf dem MQTT-Broker vorgehalten wird und beim nächsten Verbindungsaufbau gleich nochmal rausgeschickt wird. Eine Zurücksetzen-Nachricht mit „retain“-Flag würde dann bei jedem Neustart der Wallbox wieder die Einstellungen zurücksetzen. Da das dämlich ist, werden Zurücksetzen-Nachrichten mit „retain“-Flag rausgefiltert.

ioBroker hat nun leider zwei ungünstige Eigenschaften:

• Es werden leere Nachrichten mit „retain“-Flag für praktisch alle API-Endpunkte der Wallbox vorgehalten. Auch für die, von denen die Wallbox nie selbst etwas gesendet hat. Warum ioBroker das macht, wissen wir nicht.
• Manchmal, möglicherweise aufgrund einer uns unbekannten Einstellung im ioBroker, werden Nachrichten mit „retain“-Flag beim Verbindungsaufbau zweimal rausgeschickt: einmal mit „retain“-Flag und einmal ohne. Die erste Nachricht wird aussortiert, aber die zweite Nachricht sieht wie eine erwünschte Nachricht aus und wenn Zurücksetzen gewünscht wird, wird das halt gemacht.

Wenn es das ist, können wir da leider nicht viel machen. Das wäre dann ein ioBroker-Problem. Leider wissen wir bei beiden Punkte nicht, warum ioBroker das macht oder wie man es abstellen kann.

bearbeitet September 8, 2023 at 16:29 von MatzeTF

[Bratpfanne]

Danke für den Hinweis! Ich bin ja monatelang gut damit klar gekommen, also irgendetwas hat sich geändert. Ich habe nun testweise die vorherige Version 4.0.7 vom MQTT Adapter installiert und probiere es damit aus.

[Bratpfanne]

Falls noch jemand das Problem hat, das Downgrade hat nicht geholfen. Ich habe nun mosquitto als eigenen MQTT Server eingesetzt und ioBroker ist nur noch der Client. Damit läuft es hoffentlich stabil.

[rtrbt]

Falls sich da auf ioBroker-Seite nichts geändert hat, kannst du dessen MQTT-Broker weiterbenutzen, wenn du "Publish own states on connect" deaktivierst. Siehe z.B. hier:

Mit Mosquitto sollte es aber auf jeden Fall funktionieren.

[Waschy]

Am 8.9.2023 um 18:05 schrieb Bratpfanne:

Ja genau, ich nutze ioBroker.

Heute ist meine WARP2 wieder komplett ausradiert (:-((

Und bei mir ist es auch der ioBroker ... läuft aber eigentlich seit Anfang an problemlos ... erst mit 2.1.4 gibts die Probleme ... ich probiere mal "Publish own states on connect" zu deaktivieren

[Waschy]

Noch ein Punkt zu 2.1.4 ... nachdem meine Box seine Einstellungen vergessen hat stehe ich bei der Neueinrichtung vor einem weiterem Problem: die Box erkennt keine NFC-Tags mehr. Ich kann die mitgelieferten Tags sooft und solange an die Box halten wie ich will sie tauchen nicht in der Liste der zuletzt erkannten Tags auf. Hängen diese Problem zusammen? Oder ist das ein völlig eigener Punkt? Wie kann ich die Box dazu bringen wieder Tags zu erkennen? Ein optisches Feedback mittels LED wäre doch auch noch eine Idee - oder?

Edit: warum auch immer jetzt werden die NFC Tags wieder angezeigt ...

Edit2: ein Kollege hat seine WARP2 (v2.1.3) ebenfalls am MQTT im ioBroker .. da funktioniert noch alles ok .. das Problem ist wohl mit v2.1.4 gekommen

 

bearbeitet September 12, 2023 at 08:20 von Waschy

[MatzeTF]

On 9/11/2023 at 4:56 PM, Waschy said:

Edit2: ein Kollege hat seine WARP2 (v2.1.3) ebenfalls am MQTT im ioBroker .. da funktioniert noch alles ok .. das Problem ist wohl mit v2.1.4 gekommen

Frage dazu: Hattest du eine 2.1.3 am Laufen, bevor du das erste Mal auf 2.1.4 aktualisiert hast, oder hast du vorher ein paar Versionen ausfallen lassen?

bearbeitet September 12, 2023 at 09:33 von MatzeTF

[Waschy]

Am 12.9.2023 um 10:46 schrieb MatzeTF:

Frage dazu: Hattest du eine 2.1.3 am Laufen, bevor du das erste Mal auf 2.1.4 aktualisiert hast, oder hast du vorher ein paar Versionen ausfallen lassen?

Servus - ich hatte vorher ebenfalls die 2.1.3 und da lief noch alles wunderbar - ich mache die FW Updates immer recht regelmäßig.

[MatzeTF]

On 9/13/2023 at 11:38 AM, Waschy said:

Servus - ich hatte vorher ebenfalls die 2.1.3 und da lief noch alles wunderbar - ich mache die FW Updates immer recht regelmäßig.

Wir haben eine Möglichkeit für das Vergesslichkeitsproblem entdeckt, die aber eigentlich schon vor 2.1.3 bestanden haben sollte. Vielleicht hattest du da vorher einfach Glück gehabt.

Wir machen das Zurücksetzen von Einstellungen jetzt robuster und mit 2.1.5 sollte das Problem nicht mehr auftreten. Es wäre nett, wenn du deinen Kollegen, der ebenfalls ioBroker einsetzt, darauf hinweist, dass er 2.1.4 besser auslassen und auf 2.1.5 warten sollte. Wenn er 2.1.4 nutzen möchte, weise ihn bitte auf die ioBroker-Option hin, die man vorher ausschalten muss.

bearbeitet September 13, 2023 at 09:43 von MatzeTF

[Waschy]

Ja klar - danke !! Und mir 2.1.5 dann wieder auf den Default im MQTT Broker zurück gehen ?

[MatzeTF]

On 9/13/2023 at 2:55 PM, Waschy said:

Ja klar - danke !! Und mir 2.1.5 dann wieder auf den Default im MQTT Broker zurück gehen ?

Meinst du „Publish own states on connect“ wieder einschalten? Sollte dann auch okay sein, aber ich weiß nicht, wofür du das brauchen solltest. Ich würde es einfach auslassen. 😉

[Waschy]

Am 13.9.2023 um 15:40 schrieb MatzeTF:

Meinst du „Publish own states on connect“ wieder einschalten? Sollte dann auch okay sein, aber ich weiß nicht, wofür du das brauchen solltest. Ich würde es einfach auslassen. 😉

... einfach nur weil's der Default ist/war ?? Und natürlich um zu prüfen, ob der Bug dann auch behoben ist (;-)) Danke aber für die schnelle Analyse!

[OhhTii]

Zur Info, ich hatte das identische Problem.

Update auf 2.1.4 von der 2.1.3. iObroker mit MQTT Adapter v4.1.1 mit deaktivierter Option “States bei subscribe publizieren”.

Ca. 1 Woche nach dem Update fand evcc die WARP2 nicht mehr. Grund gelöschte WLAN Einstellungen.

Ich habe seit 1 /2 Wochen die Option “States bei subscribe publizieren” aktiviert, seitdem läuft es ohne Probleme.

[energie2023]

Ich nutze auch den ioBroker v6.10.1.
Meine WARP2 (V2.1.4-64e60ce2) hat sich nur mit dieser Version mit dem ioBroker verbunden.
Version MQTT Borker: 4.1.1.

Ich hatte bis jetzt kein Ungewöhnliches Verhalten am WARP2 feststellen können.

Anbei ein Screenshot meiner gesetzten MQTT-Parameter:

 

 

Der ioBroker bietet die Möglichkeit mehrere MQTT-Broker zu betreiben (jeder Broker auf einem anderen Port) (mqtt.0, mqtt.1, ....)
Vielleicht hilft es eine Optimierte Version vom MQTT-Broker für die WARP2 anzubieten.

bearbeitet October 22, 2023 at 17:10 von energie2023

[MatzeTF]

On 10/22/2023 at 7:06 PM, energie2023 said:

Der ioBroker bietet die Möglichkeit mehrere MQTT-Broker zu betreiben (jeder Broker auf einem anderen Port) (mqtt.0, mqtt.1, ....)

Vielleicht hilft es eine Optimierte Version vom MQTT-Broker für die WARP2 anzubieten.

Ich glaube nicht, dass das etwas verbessert, da die Implementierung von MQTT in ioBroker nicht standardkonform ist. Statt einem nicht standardkonformen Server mehrere nicht standardkonforme Server laufen zu lassen, macht meiner Meinung nach keinen Sinn. Was hilft, ist, den MQTT-Broker von ioBroker komplett zu deaktivieren und einen standardkonformen MQTT-Broker wie z. B. Mosquitto zu verwenden.

Die Optionen „nur bei Änderungen publizieren“, „eigene States beim Verbinden publizieren“ und „States bei subscribe publizieren“ sollte es genauso wenig geben wie „Standard-QoS“ und „Retain-Flag setzen“, da das MQTT-Protokoll exakt vorgibt, wie diese Fälle behandelt werden müssen. Dass es diese Optionen gibt, legt nahe, dass die ioBroker-Entwickler das MQTT-Protokoll anscheinend nicht richtig verstanden haben.