RFM69 keten

../_images/IoT-keten-RFM691.png

De RFM69 keten

We gebruiken een eigen protocol voor de RFM69-radio: hiermee houden we de pakketten klein, en de software eenvoudig. Het binaire Cayenne Low Power Payload (LPP) formaat gebruiken we voor de payload.

Een lokale RFM69-WiFi-gateway zet dit RFM69/LPP-protocol om in het MQTT/JSON-protocol voor onze IoT-toepassingen.

Op het toepassingsniveau gebruiken we MQTT/JSON-berichten met dezelfde structuur, voor de WiFi- en voor de RFM69-knopen. We kunnen dan de berichten van de RFM69-IoT-knopen we op dezelfde manier verwerken als de berichten van de WiFi-knopen.

RFM69 protocol

We hebben in de RFM69-knopen te maken met de volgende protocolstack:

  • het hardware-protocol (RFM69 radio);

  • het protocol van de RFM69-library;

  • het protocol van de IoT-toepassing

../_images/IoT-rfm69-pakket.png

RFM69 pakket met LPP payload

Hardware-protocol

Het hardware-protocol zorgt voor:

  • het adresseren (destination), zenden en ontvangen van pakketten;

  • het controleren van de CRC (cyclic redundancy check, checksum): als deze klopt, concludeert de hardware dat het pakket correct ontvangen is;

  • het versleutelen en ontsleutelen van de payload (encryptie).

De zender en ontvanger gebruiken dezelfde sleutel voor de encryptie: deze moet van je te voren aan beide kanten instellen. In zo’n geval spreken we over een pre-shared key.

Een beveiligde internet-verbinding, zoals voor https, maakt gebruik van public-key encryptie. In dat geval heb je geen pre-shared keys nodig.

RFM69-library protocol

Het protocol van de RFM69-library voegt het adres van de afzender (source) toe aan het pakket, als eerste byte van de payload in het hardware-pakket. Het protocol van de RFM69-library noemen we hier het RFM69-protocol.

Het RFM69-protocol gebruikt 5-bits adressen (0..63) voor de knopen in het netwerk. De adressen 0, 61, 62 en 63 hebben een speciale betekenis. RFM69-adres 0 als destination is het broadcast address: alle IoT-knopen in het RFM69-netwerk ontvangen zo’n bericht.

De belangrijkste opdracht voor het zenden en ontvangen van een pakket zijn:

  • rf.receive(rxBuf, sizeof rxBuf);

    • het eerste byte van rxBuf geeft het adres van de afzender.

  • rf.send(dstNode, txBuf, len);

Toepassingsprotocol

Het toepassingsprotocol gebruikt de rest van de hardware-payload. Dit protocol gebruikt verschillende formaten voor uplink- en voor downlink-pakketten. We bespreken hier alleen de binaire formaten op basis van het Cayenne low power payload (LPP) formaat. Dit protocol noemen we hier het LPP protocol.

LPP uplink-berichten

De payload voor uplink-berichten bevat de volgende elementen:

  • port (1 byte): dit geeft aan welk protocol gebruikt wordt voor de payload; port=1 geeft het LPP-formaat aan.

  • nodeid (2 bytes): de identificatie van de knoop (gebruikt in het MQTT-topic);

  • counter (2 bytes): het volgnummer van het bericht; we gebruiken dit onder meer voor de veiligheid, om een replay attack te voorkomen.

  • LPP-payload, per sensor/actuator:

    • channel (1 byte): identificeert de sensor/actuator in de IoT-knoop;

    • type (1 byte):type van de sensor/actuator;

    • value (1 of meer bytes): de waarde(n) van de sensor (of actuator).

Voorbeelden van sensor/actuatorgegevens in LPP-formaat:

  • 0, 1, 1: channel=0 (LED 0), type=”dOut”, value=1 (“on”)

  • 3, 103, 0, 235: channel=3, type=”temperature”, value=235 (23,5 ‘C)

De waarde(n) van een sensor/actuator bestaat uit een reeks gehele getallen, van 1 of 2 bytes elk. Door gehele getallen te gebruiken voorkomen we onder meer het (dure) rekenen met floating point getallen in de IoT-knoop. Bovendien leveren de meeste sensoren een geheel getal als gemeten waarde: het werken met floating point getallen voegt niets toe.

De types en de interpretatie van de data staan beschreven in de Cayenne-documentatie, zie XXX

Enkele voorbeelden van veel voorkomende types sensoren en actuatoren:

LPP types

Sensor

Naam

Type

Hex

Bytes

Resolutie

Digitale input

dIn

0

0

1

1

Digitale output

dOut

1

1

1

1

Analoge input

aIn

2

2

2

0.01 Signed

Analoge output

aOut

3

3

2

0.01 Signed

Lichtniveau

illuminance

101

65

2

1 Lux Unsigned

Aanwezigheid

presence

102

66

1

1

Temperatuur

temperature

103

67

2

0.1 °C Signed

Rel. Luchtvochtigheid

humidity

104

68

1

0.5% Unsigned

Luchtdruk

barometer

115

73

2

0.1 hPa Unsigned

LPP downlink-berichten

De payload voor een downlink-bericht is erg eenvoudig:

  • port: geeft het toepassingsprotocol aan; port=1 staat voor de LPP payload;

  • de LPP-payload, per actuator:

    • channel (1 byte);

    • value (1 of 2 bytes)

  • een afsluiter (1 byte): 0xff (geen geldig channel)

We nemen hier het type van de actuator niet op: dit is in de knoop zelf bekend. Ook de nodeid is niet nodig: de IoT-knoop kent zijn eigen nodeid.

  • een counter (volgnummer) voor de veiligheid is wel nodig;???

Gateway

De gateway koppelt het RFM69-netwerk aan het internet, meer in het bijzondere aan de IoT-toepassing via het MQTT-protocol. Een RFM-IoT-knoop verstuurt RFM69-pakketten met daarin een IOT-toepassingspakket met een LPP-payload.

../_images/IoT-rfm69-keten-stacks.png

Protocol-stacks in de RFM69-keten

De omzetting tussen de beide protocollen bestaat uit twee onderdelen:

  • omzetten van de adressering: van RFM69-adres naar MQTT-topic (en omgekeerd);

  • omzetten van de payload: van RFM69-LPP-pakket naar MQTT-JSON bericht.

Opmerking: de omzetting van de adressering voor uplink-berichten is eenvoudig: de nodeid in het RFM69-LPP-pakket wordt ingevuld in het MQTT-topic node/<nodeid>/sensors.

Voor downlink-berichten is dit lastiger: in het IoT-toepassingsprotocol (MQTT/JSON) is het RFM69-adres onbekend. De gateway houdt daarom een tabel bij: nodeid -> RFM69-adres. Als de gateway een RFM69-LPP-bericht ontvangt (in het formaat hierboven) wordt deze tabel bijgewerkt. Als de gateway vervolgens een MQTT-bericht ontvangt voor een topic met de nodeid van een lokale node, wordt dit (na omzetting) verstuurd naar de bijbehorende RFM69-node.

Gateway versus bridge

We maken hier onderscheid tussen ‘’gateways’’ en ‘’bridges’’: een bridge verbindt netwerken met eenzelfde protocol(stack), een gateway verbindt netwerken met verschillende protocollen. De omzetting in een bridge is dan beperkt tot de gemeenschappelijke onderste laag van de protocollen. Bij een gateway moet je de hele protocolstack hierbij betrekken. Een gateway is vaak (aanzienlijk) complexer dan een bridge. Bovendien hebben veranderingen in de toepassing mogelijk gevolgen voor de gateway. Voor een bridge is de toepassing niet van belang. Overigens wordt deze terminologie, met een duidelijk onderscheid tussen bridge en gateway, niet overal op dezelfde manier gebruikt.

Ook als de IoT-knoop zelf de internet-protocolstack gebruikt kan het zinvol zijn om een bridge te gebruiken, om de lokale communicatie te scheiden van het publieke internet. Deze bridge kan er bijvoorbeeld zorgen voor de versleuteling van het verkeer naar het publieke internet.