Datenakquise über MQTT klappt nicht

Hallo,

ich sende mittlerweile Daten in der Folgenden Form :

{“time”:2018-10-13T18:33:02Z,“weight”:33.0,“humidity”: 75.52}

(bis vorgestern konnte ich die transmission auch unter Wtee sehen, mittlerweile tut diese Seite nichts mehr

unter der ID 01CSG1YX22SR8RN89F4W4YZQPF . Allerdings kann ich nirgendwo ein Instantdashboard dafuer finden. Wahrscheinlich bin ich zu doof. Ich dachte unter Grafana sollte ein Dashboard zu meiner ID auftauche. Da sehe ich aber nichts :-(

Kann mir bitte jemand weiterhelfen ?

Viele Gruesse,
Rudi

Hallo Rudi,

wir helfen Dir gerne weiter.

/transmissions funktioniert nicht mehr

Läuft wieder, besten Dank für die Meldung!

Daten kommen nicht an

1. Problem auf dem Transportweg

Auf dem MQTT Bus kommen derzeit scheinbar noch überhaupt keine Daten an, das lässt sich z.B. per

mosquitto_sub -h swarm.hiveeyes.org -p 1883 -t 'hiveeyes/01CSG1YX22SR8RN89F4W4YZQPF/#' -v

nachvollziehen. Ich vermute hier ein Problem mit der Authentifizierung. Erst müssen wir die Daten auf den Bus bekommen, bevor wir weitersehen können.

Vielleicht kannst Du den Code zur Verfügung stellen, den Du verwendest, um die Daten auf den Bus zu publizieren?

2. Review Datenformat

Ich habe eine kurze Rückfrage zum Payload: Erzeugst Du die Daten über eine JSON Bibliothek? Mir fällt auf, dass a) das Feld “time” nicht als String übertragen wird und b) es Abweichungen im Spacing bei den Feldern “weight” vs. “humidity” gibt. JSON verzeiht zwar letzteres, das fehlende String Format beim “time” Feld ist jedoch unverzeihlich:

echo '{"time": 2018-10-13T18:33:02Z}' | jq .
parse error: Invalid numeric literal at line 1, column 23

Gültige Payloads können folgendermaßen aussehen:

{"time": "2018/10/13 21:09:59", "Gewicht": 50.916, "Aussen-Temperatur": 14.5, "Aussen-Feuchtigkeit": 99.9, "Spannung": 4.24}
{"time": 1539457735349986048, "temp1": 31.87, "temp2": 34.0, "temp3": 29.62, "temp4": 27.75, "temp5": 16.18, "temp6": 16.68}
{"weight":33.33,"temperature1":42.42,"humidity1":84.84,"battery_level":50}

Das Datenformat wird allerdings erst dann relevant, sobald wir das Transportproblem gelöst haben.


Viel Erfolg beim Debugging und bis gleich,
Andreas.

Hallo Andreas,

vielen Dank fuer den Hinweis auf das Fehlende String Format beim Timestamp. Ich erzeuge das JSON Format als einen String und send letztendlich einen String. Ich bin nicht sicher ob das in Ordnung ist, auf WTEE sehen die Eintraege jedoch identisch aus wie andere.

Was ich in der Zwischenzeit herausgefunden habe ist, dass keine Daten ankommen wenn ich unter meiner Imker ID send. Sobald ich auf Testdrive umstelle geht es. Ich muss gleich nochmal die ID und das Passwort pruefen, sollten aber OK sein weil ich mit Copy&Past uebernommen hatte.

Im Moment sollten Daten unter Testdrive ankommen, kannst Du bitte mal einen Blick drauf werfen ?

Vielen Dank fuer Deine schnelle Rueckmeldung!
Rudi

Ich denke ich weiss woran es liegt. Ich glaube ich habe ein Fehler in meinem Programm. Es scheint nicht an der Authentifizierung zu liegen.

Rudi

Hallo,

mein Problem mit dem Senden ist erstmal geloest. Die Daten kommen jetzt an.

Allerdings sehe ich noch kein Instand Dashboard.

Gruesse,
Rudi

Meine Daten tauchen immer noch nicht auf einem Instant Dashboard auf. Auf Wtee sehe ich

hiveeyes/01CSG1YX22SR8RN89F4W4YZQPF/sauerlach/s1/__json__ {"time":"2018-10-13T23:17:29Z","weight":33.0,"humidity":75.52}
hiveeyes/01CSG1YX22SR8RN89F4W4YZQPF/sauerlach/s1/__json__ {"time":"2018-10-13T23:17:44Z","weight":33.0,"humidity":75.52}

Sieht fuer mich in Ordnung aus.

Gruesse,
Rudi

MQTT Topic

Spezialfall "__json__" suffix

Die "__json__" Variante verwenden wir als Workaround nur bei Meßknoten, die nicht anders funken können (siehe Inbetriebnahme von node-wifi-mqtt-homie mit Hiveeyes Anbindung) und funktioniert nur im Verbund mit "data/__json__". Trick 17 ;].

Reguläres "data.json" suffix

Das MQTT topic suffix "data.json" ist besser. Für Dich sollte also z.B. dieses MQTT topic funktionieren:

hiveeyes/01CSG1YX22SR8RN89F4W4YZQPF/sauerlach/s1/data.json

Datenformat

Exzellent, das klappt nun:

echo '{"time":"2018-10-13T23:17:44Z","weight":33.0,"humidity":75.52}' | jq .
{
  "time": "2018-10-13T23:17:44Z",
  "weight": 33,
  "humidity": 75.52
}

Viele Grüße nach Sauerlach!

Noch ein kleiner Nachtrag zum Datumsformat.

Meßdaten mit Zeitstempel

Dein Zeitstempel um 23:17 MESZ/CEST wird momentan als "2018-10-13T23:17:29Z" übermittelt und ist damit inkorrekt repräsentiert, obwohl er korrekt aussehen mag. Er sollte entweder

  • "2018-10-13T21:17:29Z" (UTC) oder
  • "2018-10-13T23:17:29+0200" (Central European Summer Time, CEST, derzeit GMT+2 DST) lauten.

Ansonsten wird es Dir passieren, dass Du immer noch keine Daten zu sehen bekommst, da Du sie “in der Zukunft” übermittelst, in diesem Fall nämlich um 01:17 Uhr MESZ des nächsten Tages. Das ist ebenfalls ein sehr beliebter Fehler beim ersten Warmlaufen ;].

Beide Varianten sollten funktionieren, bevorzugt wird jedoch die erstere im UTC Format, siehe Coordinated Universal Time - Wikipedia oder Koordinierte Weltzeit – Wikipedia.

Meßdaten ohne Zeitstempel

Wahlweise kannst Du den Zeitstempel in Form des “time” Datenfeldes auch komplett weglassen, falls die Datenübermittlung ausschließlich in Echtzeit passiert. Dann wird automatisch die aktuelle Serverzeit für das Datum verwendet und das ist jederzeit “jetzt”.

Eigentlich musst Du den Zeitstempel nur dann explizit übertragen, wenn die Meßdaten nach der Erfassung irgendwo zwischengepuffert werden. Ansonsten ist die Übertragung ohne Zeitstempel deutlich komfortabler und automatisch immer korrekt, selbst wenn die lokale Systemzeit des Meßknotens falsch gesetzt sein sollte. Wir hörten davon, dass das vorkommen kann ;].


Viel Erfolg bei den letzten Schritten!

2 Likes

Hallo Andrea,

Danke fuer den Hinweis auf die Daten. Ich habe es gefixt und es klappt nun. Mir war es nicht klar dass ich keine Zeit mitsenden muss, da haette ich mir einiges an Arbeit sparen koennen. Naja, wenigstens was daraus gelernt. Ich lade es von time.nist.gov.

Ich sehe jetzt das Instant Dashboard. Allerdings tauchen darin keine Daten auf.

Erst gehe ich jetzt mal schlafen. Vielen Dank fuer Deine Hilfe. Ich weiss es sehr zu schaetzen!

Gruesse,

Rudi

Aktuelle Daten

Derzeit kommen scheinbar leider keine Daten von Dir.

Wo sind die Daten?

Wenn Du den Zeitfilter im Grafana entsprechend einstellst à la

image

bekommst Du die Daten tatsächlich zu sehen, sie sind in der Zukunft. Zwischen 02:15 und 02:20 Uhr UTC kamen ein paar durch, das war also zwischen 00:15 und 00:20 Uhr CEST.

In zwei Stunden solltest Du sie auch zu sehen bekommen ohne die Zeit zu verstellen. Falsch zeitgestempelt bleiben sie jedoch immer noch.

Voilà

Siehe sauerlach/s1 first attempt. Gratulation!


Have fun!

Hi Rudi,

mittlerweile scheinen die Daten Deines Meßknotens ordentlich anzukommen, siehe sauerlach/s1 for real.

Sehr schön! Wir wünschen Dir viel Freude bei der Benutzung des Systems.

Viele Grüße,
Andreas.

Hallo Andreas,

ja genau. Vielen Dank fuer Deine Hilfe. Ich bin gerade noch dabei die Hardware sauber herzurichten, damit ich das auch dann draussen aufstellen kann. Bislang sende ich nur Random Daten. Aber das klappt. Ohne Deine Hilfe haette ich wohl schon aufgegeben.

Gruesse,
Rudi

Hallo Rudi,

Wunderbar! Ja, wir wissen, dass wir die Dokumentation weiter verbessern müssen. Du bist zwar selbst schon sehr weit gekommen, aber genau jene Dinge (MQTT Topic, JSON Payload, Timestamp), in die Du reingelaufen bist, müssen wir hinsichtlich der Dokumentation besser berücksichtigen.

Dieser Beitrag wird uns dabei helfen. Danke für Deine Geduld und merci vielmals in den Süden!

Grüße,
Andreas.

Wenn Du dann in den Echtbetrieb übergehen willst, suche Dir einfach einen anderen Kanal (statt "s1") aus. Du kannst beliebige Kanäle mit Daten beschicken, die Verwaltung darüber hast Du komplett selbst in der Hand.

Auch wenn das vielleicht nicht ganz die richtige Stelle ist: Was ich einfach einmal loswerden möchte ist, daß der öffentliche Datenstream (Wtee) einfach super ist wenn man gerade dabei ist seine eigene Übertragung zu basteln!

1 Like