Es gibt ja zu MQTT die Erweiterung MQTT-SN für Sensor Networks. Ein vereinfachtes MQTT Format, welches keinen TCP-IP Stack braucht und auch über einfache Funkverbindungen geht. Ich möchte nun für einige dumme Geräte mit ATmega328 und nRF24 Sender die einfachste Version davon verwenden, ohne Anmeldung, nur eine Richtung: Das Gerät sendet seine Daten mit Publish, und wenn da ein Empfänger ist, nimmt der die Daten an, sonst sind sie halt weg. Ein Handshake wird über die nRF24-Sender und Empfänger mit Auto-Acknowledge gemacht, also das Gerät bekommt schon mit, ob da ein Empfänger ist, aber das ganze MQTT Brimborium mit CONNECT, CONACK, DISCONNECT fällt halt weg. Wenn ich das richtig verstanden habe, muss dann eine Payload für die nRF24-Sender so aufgebaut sein: Byte 0 - Länge der Message** 1 - MessageType = 0x0C für Publish 2 - Flags = 0b01100010* 3,4 - TopicID = 2 vordefinierte Zeichen 5,6 - MsgID = 0x0000, nicht verwendet ab Byte 7 - Daten *) Flags: DUP=0, QoS=11 für AdhocTopic, Retain=0, Will=0, Clean=0, TopicIDType=10 für ShortTopic **) Da der nRF24 eh nur 32 Byte Payload kann, reicht ein Byte für die Länge. Nun wäre ja, da ich das MQTT-SN zu MQTT Gateway für den nRF24 Empfänger eh selber schreiben muss, das Datenformat eigentlich egal. Aber um kombatibel zu eventuellen Erweiterungen mit bidirektionalen Geräten mit aktiver Anmeldung zu sein, sollte das schon dem Standard entsprechen. Ist das soweit richtig? Und kennt jemand praktische Anwendungen für MQTT-SN? Ich hab zwar ettliche theoretische Abhandlungen gefunden, aber sobald es an die Umsetzung geht sind die dann immer zu Ende.
Gast
#5906398
Eine Prüfsumme oder CRC wäre auch sinnvoll, damit Übertragungsfehler nicht zum Fehlverhalten führen.
GEKU schrieb: > Eine Prüfsumme oder CRC wäre auch sinnvoll, damit Übertragungsfehler > nicht zum Fehlverhalten führen. Die CRC macht der nRF24. Stimmt die nicht, wird das Paket verworfen und kein Ackn gesendet.