MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054

[DerSeppel]

Hm, kann es sein dass "yum install gcc" eine alte version des GCC installiert? Mann könnte mal das file patchen und ein "
#include <stdint.h>" einfügen.

Anderer Ansatz:
Man könnte Edomi als Stack aufsetzen und dedizierte Container für MQTT, MySQL etc. erstellen. Wenn schon Docker, dann richtig Docker
Dann könnte man auf nen fertigen MySQL Container setzen und kann die services einzeln updaten.

[starwarsfan]

Hi

Ich nehme mal an in der lib_mysqludf_sys.c fehlt kein "#include <stdint.h>". Daher würde ich auf ein Problem in der Build-Umgebung tippen.

Das nehme ich auch an, da der Build für x86_64 problemlos funktioniert.

Wie sieht deine Umgebung aus? (OS, compiler, ...)?

Die Build-Umgebung wird so aufgebaut und ist damit erstmal identisch zur x86_64-Version. Gebaut wird dann schlussendlich hier, wobei in Zeile 25 der genannte Fehler auftritt. Das ist aber auch mehrheitlich identisch zur x86_64-Version.

[DerSeppel]

Wenn das nicht geht, bleibt mir wohl nichts anderes übrig, als das gesamte Mosquitto-MQTT aus dem ARM-Image zu entfernen...

Da sind grundlegende Standardtypen nicht bekannt. Ich nehme mal an in der lib_mysqludf_sys.c fehlt kein "#include <stdint.h>". Daher würde ich auf ein Problem in der Build-Umgebung tippen.
Wie sieht deine Umgebung aus? (OS, compiler, ...)?

[jonofe]

Zu den Fehlern hab ich auch keine Idee, allerdings wird das lib_mysqludf_sys nur für den MQTT Publish Server verwendet.
Die sonstigen MQTT Installationen würden dann zumindest Subscribe und Publish Clients ermöglichen, was auch in der Regel die wichtigsten MQTT LBS sind.

[starwarsfan]

Hallo miteinander,

beim Update des Docker-Images für ARM64v8 basierend auf CentOS8 stosse ich gerade auf das Problem, dass sich dieses lib_mysqldf_sys-Gedöns nicht kompilieren lässt. Hat das irgendwer schonmal gemacht?

Die entsprechende Cmdline sieht so aus:

gcc -march=armv8-a -DMYSQL_DYNAMIC_PLUGIN -fPIC -Wall -I/usr/include/mysql -I/usr/include/mysql/server -I. -shared lib_mysqludf_sys.c -o /tmp/Mosquitto-PHP/usr/lib64/mysql/plugin/lib_mysqludf_sys.so

Das knallt aber mit jeder Menge Fehler dieser Art:

/usr/include/mysql/server/m_ctype.h:73:3: error: unknown type name 'uint32'
   uint32 sort;
   ^~~~~~
/usr/include/mysql/server/m_ctype.h:108:3: error: unknown type name 'uint16'
   uint16 weight[MY_UCA_CONTRACTION_MAX_WEIGHT_SIZE];/* Its weight string, 0-terminated */
   ^~~~~~

Wenn das nicht geht, bleibt mir wohl nichts anderes übrig, als das gesamte Mosquitto-MQTT aus dem ARM-Image zu entfernen...

[starwarsfan]

Hi

stellst du dann wieder eine funktionierende voll ausgestattete LXC Version rein? Wäre toll

Natürlich, so ist der Plan.

[uzi10]

Hallo miteinander



Siehe Kommentar dort.

Btw: Die kommenden Docker- und LXC-Versionen werden direkt mit php 7.4 ausgerüstet.

stellst du dann wieder eine funktionierende voll ausgestattete LXC Version rein? Wäre toll

[kordnas]

Das ist genau der Effekt..

Aber wirklich haargenau der gleiche :-)

Danke

[starwarsfan]

Hallo miteinander

Das ist genau der Effekt, den ich hier schon beschrieben habe.

Siehe Kommentar dort.

Btw: Die kommenden Docker- und LXC-Versionen werden direkt mit php 7.4 ausgerüstet.

[NorbertB]

Das ist genau der Effekt, den ich hier schon beschrieben habe.

[kordnas]

Das lag dann nicht am Backup, denn PHP 5.4 ist wohl Standard bei CentOS7.
Erst das EDOMI Installationsskript macht das Update auf PHP7.2 und installiert das REMI-Repo.
Und da ist vermutlich was schiefgelaufen. Was weiß ich auch nicht, da auch die Option 2 die notwendigen CentOS7 Pakete installiert (also z.B. PHP7 und Remi-Repo)

Ich hab das jetzt noch mal ausprobiert, wieder über das install.sh Skript von edomi

Mit Option 2 (CentOS 7 von lokal) erscheint es mir, also zwar was mit dem Remi Repo gemacht wird, aber dann nicht versucht wird PHP 7 zu installieren. Ich sehe da nur PHP 5.4 ... schon installiert (siehe auch Log Datei)

Nach der Ausführung von Option 3 (CentOS 7 per Download), ist hinterher in der Tat PHP 7 installiert (auch hier die Log Datei im Anhang)

Grüße

P.S. PHP 7.2 hat wohl im Nov 2020 auch sein End of Life erreicht

[jonofe]

hoffe ich komme dahinter.

Wie oben erwähnt: Schau mal in die Broker Logs. Dann siehst du vermutlich den Unterschied.

[simonlaessig]

command.png
Komisch, bei NodeRed kann ich nämlich value und command auswählen, bei value macht er nichts, genauso wie wenn ich es von Edomi schicke, er führt es erst aus wenn ich command einstelle.
Irgendwie merkwürdig, hoffe ich komme dahinter.

[kordnas]

Ist eher ne ioBroker Frage glaub ich, aber ich weiß vielleicht warum. Edomi sendet 1/0, während ioBroker meiner Erinnerung nach was anderes erwartet. True/False? ON/OFF?

NodeRed macht die Konvertierung evtl. implizit?

[jonofe]

Es gibt keine Unterscheidung zwischen Value und Command bei MQTT.
Es gibt ein Topic und eine Payload. Und das ist genau das was der Publish Client dann sendet.

Du schickst ja auch nichts zu ioBroker, sondern zum MQTT Broker.
Wenn das im ioBroker nicht zum gewünschten Ergebnis führt, dann bildest du entweder den Topic falsch oder die Payload oder was anderes funktioniert in ioBroker nicht wie erwartet. Am besten vergleichst du im MQTT Broker Log was NodeRed im Vergleich zu EDOMI sendet. Wenn Topic und Payload (inkl. Retain/QoS) gleich sind, dann sollte ioBroker auch gleich drauf reagieren.