Jump to content

ESP32-Brick: evtl. Bug im MQTT-Modul?


Recommended Posts

Guten Abend zusammen,

ich würde gerne ein ConfigRoot-Objekt per MQTT setzen und habe dies wie folgt implementiert:

ConfigRoot values;
values = Config::Object({
  {"power", Config::Float(0.0)},
  {"energy_rel", Config::Float(0.0)},
  {"energy_abs", Config::Float(0.0)}
});

...

api.addCommand("meter/set_values", &values, {}, [this]() {}, true);

 

Allerdings erhalte ich im Log des ESP32-Ethernet-Bricks folgende Fehlermeldung, wenn ich das Topic per Node-RED sende:

2022-03-19 19:31:54,741  MQTT: Ignoring message with payload length 51 for topic warp2/XSS/meter/set_values. Maximum length allowed is 48.

Anscheinend spielt hier die Anzahl der übertragenen Nachkommastellen eine Rolle, denn wenn ich diese verändere, dann verändert sich auch die Payload-Length in der Meldung entsprechend und mit lediglich einer Nachkommastelle funktioniert das Ganze dann richtig.

Als Workaround habe ich jetzt erstmal einen Dummywert in das Objekt aufgenommen, dann klappt's auch mit der gewünschten Anzahl Nachkommastellen.

Vielleicht könnt ihr das bei Gelegenheit ja mal prüfen...

Besten Dank und Gruß Thomas

Link to comment
Share on other sites

Das Problem scheint zu sein, dass die maximal erlaubte Payloadlänge anhand des JSON-Objekts berechnet wird, in das geparst werden soll. Das ergibt aber keinen Sinn, weil die Größe der geparsten Struktur im Speicher etwas anderes ist als die Länge des Strings, der geparst werden soll. Einfachstes Beispiel sind in der Tat Nachkommastellen bei Float: 123.456789 ist geparst ja nur sizeof(float) == 4 groß, als String aber 10 Byte. Der Bug ist bisher nicht aufgetreten, aber seit https://github.com/Tinkerforge/esp32-firmware/commit/2bbae07c68bb581b06edf182765926984b97e639 ist die Größenberechnung aggressiver, deshalb fällt das jetzt auf.

Ich muss im MQTT-Modul also konsequenter unterscheiden, was String-Längen und was JSON-Strukturgrößen sind. Ich gebe Bescheid, wenn es wieder funktionieren sollte.

  • Thanks 1
Link to comment
Share on other sites

Moin @rtrbt,

besten Dank. Ja, das Problem ist tatsächlich gelöst, d. h. die drei Floats kommen jetzt korrekt an.

Dafür gibt es aber einen neuen Bug 🙃

MQTT: Recv buf is 2048 bytes. meter/set_all_values requires 3656. Bump MQTT_RECV_BUFFER_SIZE! Not subscribing!

 

Link to comment
Share on other sites

Hm das ergibt Sinn. In dem Commit habe ich ja einen neuen Config-Visitor eingebaut, der abschätzt wie lang bei einem API-Aufruf der Payload (in String-Länge) werden kann. Das brauche ich um zu prüfen, ob der MQTT-Empfangsbuffer groß genug für alle registrierten APIs ist. Wenn das nicht der Fall ist kommt genau die Fehlermeldung die du hast.

Floats können sehr lang werden (JSON limitiert das übrigens nicht, aber sinnvollerweise nimmt man nur Gleitkommazahlen die in den Zieltyp passen an). FLT_MAX liegt bei ~ 3*10^38, deshalb habe ich das mit 42 abgeschätzt (für noch das - den . usw.). Ich würde bei näherer Betrachtung aber nicht erwarten, dass jemals jemand absichtlich einen Float mit mehr als ~20 Zeichen Länge überträgt. Das ist nur gefährlich wenn irgendwo nicht darstellbare floats erzeugt werden, z.B: 0.1 + 0.2 ergibt auf vielen Plattformen 0.30000000000000004 und das sind schon 19 Zeichen.

meter/set_all_values müsste ja ein Array aus 85 Floats übertragen, 85*42 = 3570, dazu kommen noch die Kommata usw.. Ich werde die Schätzung mal aggressiver machen, z.B. auf 20 statt 42 Zeichen. Das dürfte ein Anwender kaum bei allen 85 Floats ausreizen.

https://github.com/Tinkerforge/esp32-firmware/commit/2139d012a06f04854b80d3a99d19be771d71f3b3

Du bekommst nach der Änderung vermutlich noch folgende Warnung:

MQTT: Recv buf is 2048 bytes. meter/set_all_values requires 1871. Maybe bump MQTT_RECV_BUFFER_SIZE?

Das ist aber nur die abgeschwächte Form, die API funktioniert trotzdem. Du solltest es dann nur nicht mit dem Whitespace übertreiben ;)

Langfristig sollte das MQTT-Modul mit fragmentierten Nachrichten umgehen können (https://github.com/Tinkerforge/esp32-firmware/issues/117), dann löst sich das Problem von alleine.

Link to comment
Share on other sites

Danke @rtrbt, das sieht jetzt in der Tat sehr gut aus 👍

Ich erhalte zwar die von dir genannte Warnung, da sich die meisten übertragenen Werte aber eher im ein- bis dreistelligen Bereich bewegen (und ich die Anzahl der Nachkommastellen in Node-RED ja ggf. auch noch begrenzen kann), passt das m. E. so...

Gruß Thomas

P. S. Soll ich mich bei solchen Themen weiterhin im Forum melden oder lieber per GitHub-Issue?

Link to comment
Share on other sites

Gut zu hören :)

39 minutes ago, poohnet said:

Soll ich mich bei solchen Themen weiterhin im Forum melden oder lieber per GitHub-Issue?

Wie es dir passt. Im Forum kann man eher mal eine Textwand schreiben, dafür kann man Issues sinnvoll in den Commit-Messages verlinken. Ich habe da erstmal keine starke Präferenz.

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.

 Share

×
×
  • Create New...