Jump to content

WARP1 verliert WLAN und MQTT Einstellungen (2.1.4)


Bratpfanne

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Edited by MatzeTF
Link to comment
Share on other sites

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

 

Edited by Waschy
Link to comment
Share on other sites

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?

Edited by MatzeTF
Link to comment
Share on other sites

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.

Edited by MatzeTF
Link to comment
Share on other sites

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. 😉

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

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:

 

iobroker-mqtt.png

 

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.

Edited by energie2023
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...