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

[poohnet]

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

[rtrbt]

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.

[rtrbt]

https://github.com/Tinkerforge/esp32-firmware/commit/b063b3bab67e54b956b93907a327126a9997b633 sollte das Problem fixen. Ich komme heute nicht mehr dazu die nächste Beta zu veröffentlichen, aber du baust ja eh aus Source ;)

[poohnet]

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!

 

[rtrbt]

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.

[poohnet]

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?

[rtrbt]

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.