Fehlerhafte Objektnamen im mqtt [gelöst]
-
Bei mir läuft eine Stromerfassung mit optischem Sensor -> Wemos D1 -> mqtt.
Alle 5sek werden vom Wemos 7 kurze Strings mit den Messdaten übertragen.
In der Objektübersicht im mqtt.0 finden sich immer wieder "verstümmelte" Einträge. (eigentlich sollten nur Datenpunkte in <iobroker.mqtt.0.Stromerfassung_49> beschrieben werden).
Wer weiß wodurch ? Verbindung ist mit ca -55dBm eigentlich gut.
-
@geschild sagte in [Fehlerhafte Objektnamen im mqtt](/post/
Wer weiß wodurch ? Verbindung ist mit ca -55dBm eigentlich gut.
Mit den wenigen Angaben ist eine Ermittlung der Ursache natürlich nicht möglich. Aber wenn ich wetten müsste, dann darauf, dass der Wemos einfach Müll sendet. Hast du mal einen MQTT Client wie „MQTT Explorer“ mitlaufen lassen? Dann siehst du ja, ob saubere Daten ankommen.
Was läuft auf dem Wemos?
Welcher Broker?
Welcher Adapter? -
@marc-berg
Der Wemos bekommt im Sekundentakt vom optischen Sensor ca. 450 Byte mit 9600 baud. Diese werden ausgewertet und die so ermittelten Messwerte gesendet. Dazwischen dümpelt der Wemos vor sich hin. Keine Interrupts meinerseits. Programmiert mit Arduino Ide, fürs mqtt wird die 'Pubsubclient' Bibliothek verwendet.Das 'publishen' der 6 Messwerte, je 5 bis 10 Byte, erfolgt ohne weitere delays dazwischen hintereinanderweg. Könnte es ein Problem sein, dass der Raspi (iobroker) noch an einem Telegram arbeitet und das nächste zu schnell danach kommt ?
Adapter: MQTT Broker/Client 4.0.7
-
@geschild sagte in Fehlerhafte Objektnamen im mqtt:
Das 'publishen' der 6 Messwerte, je 5 bis 10 Byte, erfolgt ohne weitere delays dazwischen hintereinanderweg. Könnte es ein Problem sein, dass der Raspi (iobroker) noch an einem Telegram arbeitet und das nächste zu schnell danach kommt ?
Zeig mal den Teil des Codes, in welchem die Werte published werden. Ich würde nach dem publish() zum Testen mindestens ein delay(200) einfügen, damit ein mögliches Disconnect nicht zu früh kommt. Ein anderes Problem könnte auch das zu häufige Aufrufen von MQTTclient.loop() sein, welches gern mal den Netzwerkstack überlastet.
-
Danke für deine schnelle Antwort.
Da alle Sekunde Daten vom Sensor kommen, habe ich erstmal nur delay(130) eingefügt, alle fehlerhaften Datenpunkte gelöscht und beobachte das mal.
Der entsprechende Code ist anbei. MQTTclient.loop() läuft noch zyklisch. Ich habe mehrere Geräte mit der gleichen "Standardsoftware" laufen. Die Probleme zeigen sich nur bei diesem. -
Das Problem scheint mir nicht zu sein, dass es direkt verstümmelt ist, sondern dass Du einen seriellen Datenstrom hast, den Du nicht richtig parsed - also Zeichen oder Merkmal, die den Datenstrom in sinnvolle Records trennen.
Das schaut doch teilweise wie eine Laufschrift aus, in der je nach Momentaufnahme verschiedene Teile eines Strings als topics verwendet werden. Also würde ich mal an der Stelle suchen - die die Informationen published und nicht auf der Empfängerseite.
@geschild sagte in Fehlerhafte Objektnamen im mqtt:
@marc-berg
Der Wemos bekommt im Sekundentakt vom optischen Sensor ca. 450 Byte mit 9600 baud. Diese werden ausgewertet und die so ermittelten Messwerte gesendet. Dazwischen dümpelt der Wemos vor sich hin. Keine Interrupts meinerseits. Programmiert mit Arduino Ide, fürs mqtt wird die 'Pubsubclient' Bibliothek verwendet.Das 'publishen' der 6 Messwerte, je 5 bis 10 Byte, erfolgt ohne weitere delays dazwischen hintereinanderweg. Könnte es ein Problem sein, dass der Raspi (iobroker) noch an einem Telegram arbeitet und das nächste zu schnell danach kommt ?
Adapter: MQTT Broker/Client 4.0.7
Wenn Du halt Node-Red nutzen würdest, dann hättest Du ein paar Optionen, wenn Du die serielle Node nutzt:
hier hast Du dann mehrere Optionen - Datensätze zu erstellen
-
Danke für deine Anregung aber, ich prüfe
A : Die Vollständigkeit der Startsequenz,
B : Die Anzahl der empfangenen Bytes und
C : Die Vollständigkeit der Endsequenz.Daraus ergibt sich, dass ein vollständiges Telegramm im Array ist. Bedingt durch die Struktur des SML Protokolls, sind gleiche Messwerte immer!! an der gleichen Stelle.
Somit ist ein detaillierteres parsen m.E. nicht notwendig.Nachtrag: 20.06.2023
Seitdem ich die publishes nicht mehr direkt hintereinander sende, sondern dazwischen ein delay(130) geschoben habe, ist der Fehler weg.
