MQTT-SN für dumme Geräte?

[Karl K. (karl2go)]

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.

[GEKU (Gast)]

Eine Prüfsumme oder CRC wäre auch sinnvoll, damit Übertragungsfehler 
nicht zum Fehlverhalten führen.

[Karl K. (karl2go)]

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.