Im Unterverteiler einer Gewerbehalle hängt ein Drehstromzähler mit Modbus-RTU-Schnittstelle. Er kennt Energie, Leistung, Spannungen und Ströme, doch das nächste Netzwerkkabel liegt achtzig Meter entfernt. Genau für diese Lage ist RS485 zu LoRaWAN gedacht: Ein kleiner Konverter hängt als Modbus-Master am RS485-Bus, fragt die Register des Zählers zyklisch ab und schickt die Werte als kompakte Funknachricht über ein LoRaWAN-Gateway an deinen Netzwerkserver. Dort übersetzt ein Payload Codec die Bytes wieder in Kilowattstunden und Volt.
Ob das zuverlässig läuft, entscheidet fast immer die Konfiguration: serielle Parameter, Registeradressen, Datentypen, Byte-Reihenfolge, Abfrageintervall, Uplink-Größe und ein Decoder, der zur Kanalliste passt. Der Energiezähler dient dabei als durchgehendes Beispiel, der Milesight UC100 als Gerät für die Einrichtung.

Wie funktioniert ein RS485 LoRaWAN Konverter?
RS485 ist die physikalische Ebene: zwei verdrillte Adern, A und B, mit differenzieller Übertragung, robust gegen Störungen und bei niedrigen Baudraten bis etwa 1.200 Meter lang. Ein Standard-Bus verträgt 32 Lasteinheiten, an beiden Enden gehört ein Abschlusswiderstand von 120 Ohm. Auf diesem Draht läuft Modbus RTU, ein schlichtes Frage-Antwort-Protokoll. Der Master fragt, der adressierte Slave antwortet, und kein Gerät spricht ungefragt.
Dein Energiezähler ist in diesem Bild der Slave mit einer eigenen Adresse zwischen 1 und 247. Der Konverter übernimmt die Rolle des Masters. Er schickt etwa die Anfrage „lies ab Input-Register 0 zwei Register“ mit Funktionscode 04, bekommt vier Datenbytes zurück und legt sie in einem Kanal ab. Holding-Register liest er mit Funktionscode 03. Was die Bytes bedeuten, weiß der Konverter nicht von selbst. Das legst du in der Kanalkonfiguration fest, und genau deshalb ist die Registertabelle aus dem Handbuch des Zählers das wichtigste Dokument im ganzen Projekt.
Danach packt der Konverter die Werte in einen Uplink, ein Gateway reicht ihn an den Netzwerkserver weiter, etwa The Things Network oder ChirpStack, und der Codec zerlegt die Bytes. Jede Stufe kann einzeln scheitern. Ein empfangener Uplink beweist nur, dass die Funkstrecke funktioniert, nicht, dass der Zähler geantwortet hat.
LoRaWAN Modul mit RS485: fertiger Konverter oder WisBlock-Modul?
Für Modbus-Geräte mit dokumentierter Registertabelle reicht fast immer ein fertiger Konverter, den du konfigurierst statt programmierst. Ein selbst aufgebautes LoRaWAN Modul mit RS485 lohnt sich erst, wenn du eigene Logik brauchst. Die Tabelle vergleicht die gängigen Geräte nach den Punkten, die für die Konfiguration zählen.
| Gerät | Konfiguration | Modbus-Umfang | Versorgung | LoRaWAN-Klasse |
|---|---|---|---|---|
| Milesight UC100 | ToolBox-Software über USB-C, Downlink | 32 Kanäle, je 1 oder 2 Register | 5–24 V DC oder USB-C | fest Class C |
| RAK7431 | Konfiguration über USB, Downlink | bis 32 Abfragebefehle, je bis 128 Byte | 8–48 V DC | A, B oder C |
| Dragino RS485-LN | AT-Befehle, Downlink | 15 Befehle (AT+COMMAND1 bis F) | 7–24 V DC | A oder C, Standard C |
| RAK5802 auf WisBlock | eigene Firmware | so viel, wie du programmierst | über WisBlock Base | je nach Firmware |
Die Tabelle zeigt vor allem zwei Arbeitsweisen. Der Milesight UC100 arbeitet mit Kanälen, in die du Slave-ID, Startadresse, Datentyp und Byte-Reihenfolge einträgst. Der RAK7431 und der Dragino RS485-LN arbeiten näher am Rohprotokoll: Du hinterlegst die Modbus-Anfrage als Bytefolge und bestimmst, welche Bytes der Antwort in den Uplink wandern. Beim RS485-LN heißt das AT+DATACUT, für reine Modbus-RTU-Geräte gibt es ab Firmware 1.3 zusätzlich den Kurzbefehl AT+MBFUN.
Das RAK5802 ist dagegen kein Konverter, sondern ein RS485-Schnittstellenmodul mit dem Transceiver 3PEAK TP8485E für das WisBlock-System. Zusammen mit einer Base und einem Core wie dem RAK4631 entsteht ein Knoten, dessen Modbus-Abfrage, Payload-Format und Codec du selbst schreibst. Das lohnt sich, wenn du Werte vor dem Senden verrechnen oder den Knoten aus einer Batterie versorgen willst. Für den Energiezähler ist es meist mehr Aufwand als nötig.
Modbus Polling: Wie oft soll der Konverter die Register abfragen?
Beim Modbus Polling trennst du die Abfragerunde auf dem Kabel vom Meldeintervall über Funk. Der UC100 liest seine Kanäle laut Dokumentation im Takt des Reporting Interval, einstellbar von 1 bis 1.080 Minuten, ab Werk 20 Minuten. Der Dragino RS485-LN sendet ab Werk alle zehn Minuten (AT+TDC). Innerhalb der Runde regeln beim UC100 drei Werte das Timing: das Execution Interval zwischen zwei Kanalbefehlen (10 bis 1.000 ms), die Max Resp Time, also wie lange er auf eine Antwort wartet (10 bis 60.000 ms), und die Zahl der Wiederholungen (0 bis 5).
Rechne die Runde einmal durch. Bei 9.600 Baud dauert ein Byte rund eine Millisekunde. Eine Leseanfrage hat 8 Byte, die Antwort mit zwei Registern 9 Byte, zusammen also knapp 20 Millisekunden auf der Leitung plus die Reaktionszeit des Zählers. Sechs Kanäle mit 50 Millisekunden Abstand sind in unter einer Sekunde gelesen. Antwortet ein Gerät nicht, ändert sich das: Mit 1.000 Millisekunden Wartezeit und drei Wiederholungen kostet jeder tote Kanal vier Sekunden, sechs Kanäle desselben Zählers also 24 Sekunden. Setze die Wartezeit deshalb nicht unnötig hoch an.
Wie oft du abfragst, hängt an der Frage, die die Daten beantworten sollen. Für Verbrauchsauswertungen passt das in der Energiewirtschaft übliche 15-Minuten-Raster. Häufiger zu lesen hilft nur, wenn der Zähler seine Register häufiger aktualisiert und du kurze Lastspitzen sehen musst. Der Zählerstand selbst ist zudem kumulativ: Fällt eine Messung aus, liefert die nächste die verbrauchte Energie trotzdem nach.
Wie viele Modbus-Werte passen in einen LoRaWAN Uplink?
Weniger, als man denkt. Im europäischen Band EU868 darf die Nutzlast bei SF12 bis SF10 (DR0 bis DR2) höchstens 51 Byte groß sein, bei SF9 115 Byte und bei SF8 und SF7 222 Byte. Ein Konverter am Rand der Funkreichweite sendet mit SF12 und hat damit nur 51 Byte zur Verfügung.
Beim UC100 belegt jeder Kanal im periodischen Report einen eigenen Block: zwei Bytes Kennung (f9 73), ein Byte Kanal-ID, ein Byte Datentyp und dann die Daten. Ein INT16-Wert braucht damit 6 Byte, ein Float oder INT32 8 Byte, ein Double oder INT64 12 Byte. Bei SF12 passen also sechs Float-Werte in einen Uplink, das sind 48 Byte. Wie der UC100 reagiert, wenn mehr Kanäle konfiguriert sind, als beim aktuellen Spreading Factor in einen Uplink passen, beschreibt die Payload-Dokumentation nicht. Teste das mit voller Kanalliste. Der Dragino RS485-LN begrenzt in EU868 auf 51 Byte pro Uplink und kann mit AT+DATAUP=1 eine Abfrage auf bis zu 15 Uplinks verteilen.
Dazu kommt die Sendezeit. Ein Uplink mit 48 Byte Nutzlast belegt bei SF7 etwa 113 Millisekunden, bei SF10 rund 0,7 Sekunden und bei SF12 rund 2,8 Sekunden. The Things Network erlaubt im Fair-Use-Rahmen 30 Sekunden Sendezeit pro Gerät und Tag. Bei 96 Uplinks täglich, also alle 15 Minuten, sind das bei SF7 rund 11 Sekunden, bei SF10 schon rund 67 Sekunden und damit deutlich zu viel. Wenige gut gewählte Werte schlagen deshalb alle Register des Zählers.

Milesight UC100 einrichten: Wie konfigurierst du die Modbus-Kanäle?
Die Einrichtung läuft über die ToolBox-Software von Milesight. Du versorgst den UC100, verbindest ihn per USB-C mit dem Rechner, wählst den Typ „General“ und meldest dich mit dem Standardpasswort 123456 an, das du anschließend änderst. Unter den LoRaWAN-Einstellungen findest du die DevEUI des Geräts, die voreingestellte AppEUI 24E124C0002A0001, den Application Port 85 und die LoRaWAN-Version 1.0.2 oder 1.0.3. Die Geräteklasse ist fest auf Class C eingestellt.
Dann folgen die seriellen Grundeinstellungen, die exakt zum Zähler passen müssen: Baudrate zwischen 1.200 und 115.200, 8 Datenbits, 1 oder 2 Stoppbits und Parität keine, gerade oder ungerade. Die Modbus-Spezifikation sieht gerade Parität als Standard vor, viele Zähler kommen trotzdem mit 9.600 Baud 8N1 aus dem Werk. Maßgeblich ist, was am Zähler tatsächlich eingestellt ist.
Für jeden Messwert legst du einen Modbus-Kanal an. Du wählst eine von 32 Kanal-IDs, vergibst einen Namen wie „Wirkenergie gesamt“, trägst Slave-ID und Startadresse ein und wählst als Quantity 1 oder 2 Register. Beim Typ unterscheidest du Coil, Discrete, Input- und Holding-Register in 16, 32 und 64 Bit sowie als Float oder Double. Für 32-Bit-Werte stehen vier Byte-Reihenfolgen zur Wahl, dazu ein Häkchen für vorzeichenbehaftete Werte.
Die häufigste Stolperfalle ist die Adresse. Nennt die Registertabelle Input-Register in der Schreibweise 30001, ist die Protokolladresse 0 gemeint. Andere Hersteller zählen ab 1 statt ab 0. Mit der Fetch-Taste schickt die ToolBox eine Testabfrage und zeigt das Ergebnis direkt an. Liegt der Wert daneben, prüfst du zuerst Adresse und Byte-Reihenfolge. Klicke Fetch nicht in schneller Folge, sonst schlagen Abfragen bei langsamen Geräten fehl. Zum Schluss stellst du das Reporting Interval ein, für den Zähler etwa 15 Minuten.
Modbus Werte aus dem LoRaWAN Payload dekodieren: Wie geht das?
Der Uplink enthält keine Einheiten und Namen, nur Bytes. Die Übersetzung übernimmt ein Payload Codec, meist eine JavaScript-Funktion im Netzwerkserver. Milesight stellt für seine Geräte Decoder bereit, die du als Ausgangspunkt nehmen kannst. Entscheidend ist, dass der Codec dieselbe Kanalliste kennt wie die ToolBox, denn im Uplink steht nur die Kanal-ID.
Ein Beispiel: Der UC100 meldet den Zählerstand als f9 73 00 07 00 50 9a 44. Die ersten zwei Bytes f9 73 kennzeichnen Modbus-Kanaldaten. Das Byte 00 ist die Kanal-ID 0, in der ToolBox Kanal 1. Das Byte 07, binär 0000 0111, bedeutet: kein Vorzeichen, erstes Register, Typcode 00111 für Input_float. Die vier Datenbytes kommen in Little-Endian-Reihenfolge an. Rückwärts gelesen ergibt 44 9a 50 00 als Float den Wert 1234,5, also 1.234,5 kWh.
Fehler meldet der UC100 eigens: ff 15 00 heißt, das Lesen von Kanal-ID 0 ist fehlgeschlagen. Dein Codec sollte diese Meldung auswerten und den Kanal als ungültig markieren, statt den letzten Wert einfach weiterzuführen. Liefert ein Zähler Ganzzahlen mit Skalierungsfaktor, etwa Energie in 0,01 kWh als INT32, rechnest du den Faktor ebenfalls im Codec heraus. Stimmt ein Fetch-Wert aus der ToolBox mit dem dekodierten Wert überein, ist die Kette vom Register bis zur Datenbank geprüft.
Kannst du Modbus-Geräte per LoRaWAN Downlink steuern?
Ja, mit Grenzen. Trenne Downlinks, die den Konverter konfigurieren, von solchen, die beim Modbus-Gerät etwas schreiben. Den ersten Fall unterstützt der UC100 über Port 85. Der Befehl ff03 gefolgt von zwei Bytes Sekunden in Little-Endian setzt das Meldeintervall, ff03 84 03 entspricht 900 Sekunden, also 15 Minuten. Auch Kanäle lassen sich per Downlink anlegen, ändern und löschen.
Einen eigenen Befehl „schreibe Register X“ kennt der UC100 nicht. Dafür gibt es die Funktion Modbus RS485 Bridge LoRaWAN. Im aktiven Pass-through leitet der UC100 jeden Befehl, den der Server auf dem gewählten Port (2 bis 84 oder 86 bis 223) schickt, an den RS485-Bus weiter, das Gerät antwortet darauf. Im Two-way-Pass-through darf das RS485-Gerät auch von sich aus senden, dann sind die Modbus-Kanäle aber abgeschaltet. Den kompletten Modbus-Rahmen inklusive CRC baut deine Anwendung selbst, etwa mit Funktionscode 06 für ein einzelnes Register. Der Dragino RS485-LN macht das mit dem Downlink 0xA8 und schickt die Antwort des Geräts als Uplink zurück. Der RAK7431 leitet Downlinks ebenfalls an den Bus weiter.
Class C hält den Empfänger offen, trotzdem braucht ein Downlink Sekunden und kann verloren gehen. The Things Network erlaubt im Fair-Use-Rahmen zehn Downlinks pro Gerät und Tag. Prüfe jede Änderung durch ein anschließendes Lesen des Registers, und lege Schutz- oder Abschaltfunktionen nie auf eine Funkstrecke. Viele Energiezähler sperren Schreibzugriffe ohnehin oder erlauben nur einzelne Einstellungen.
Modbus über LoRaWAN: Was tun, wenn Messwerte fehlen?
Trenne zuerst Kabel und Funk. Kommen Uplinks an, aber mit der Fehlermeldung ff 15 und einer Kanal-ID, funktioniert die Funkstrecke und die Modbus-Abfrage scheitert. Am Gerät zeigt sich das durch eine langsam blinkende LED, die beim UC100 für „keine Daten von den Schnittstellen“ steht. Kommen gar keine Uplinks an, liegt das Problem bei Anmeldung, Gateway-Abdeckung oder Antenne.
Auf der Kabelseite prüfst du zuerst, ob A und B vertauscht sind, denn Hersteller beschriften die Adern nicht einheitlich. Stimmen Baudrate, Parität und Stoppbits mit dem Zähler überein? Ist die Slave-ID richtig und die Adresse nicht um eins verschoben? Liest du ein Input-Register, obwohl der Wert im Holding-Register liegt? Werte wie 1,4 × 10⁻⁴¹ oder riesige Zahlen deuten fast immer auf eine falsche Byte-Reihenfolge. Bei langen Leitungen oder hohen Baudraten schaltest du den eingebauten 120-Ohm-Abschluss des UC100 zu, und langsamen Geräten gibst du mehr Max Resp Time.
Auf der Funkseite dämpft ein Metallschrank stark, ein Test auf dem Schreibtisch sagt wenig über den Empfang im Verteiler. Für kurze Funklücken bietet der UC100 Data Storage und Data Retransmission. Das Gerät speichert Werte lokal und sendet verpasste Daten nach der Wiederverbindung nach, ab Werk im Abstand von 600 Sekunden. Dafür muss die Uhrzeit synchronisiert sein. Nachgesendete Daten kommen mit Zeitstempel in einem eigenen Format, das dein Codec ebenfalls verstehen muss. In der Anwendung markierst du veraltete Werte sichtbar, damit ein ausgefallener Messpunkt nicht wie ein stabiler Verbrauch aussieht.
RS485 LoRaWAN Konverter kaufen: Worauf solltest du achten?
Die Auswahl folgt direkt aus der Konfiguration. Zähle zuerst, wie viele Geräte und Register du lesen willst, und vergleiche das mit den Kanälen oder Abfragebefehlen des Konverters. Prüfe, ob er die Datentypen und Byte-Reihenfolgen deiner Registertabelle unterstützt, also Float, INT32 oder INT64. Kläre, wie du ihn einrichtest: Kanäle in einer Software sind schneller erledigt als Bytefolgen in AT-Befehlen, Bytefolgen sind dafür flexibler. Achte auf die Versorgung am Montageort, denn alle fertigen Konverter hier brauchen eine Gleichspannung. Wenn du Geräte per Downlink beschreiben willst, brauchst du Class C und eine Pass-through-Funktion. Denke an die Uplink-Größe bei SF12 und daran, ob es einen Payload Codec gibt, auf dem du aufbauen kannst. Speicher und Nachsenden schließen kurze Funklücken. Wenn du einen Konverter für RS485 zu LoRaWAN suchst, findest du unsere Geräte in der Kategorie Modbus.
FAQ zu RS485 zu LoRaWAN
Wie viele RS485 Geräte kann ein LoRaWAN Konverter abfragen?
Elektrisch verträgt ein Standard-RS485-Bus 32 Lasteinheiten. Der Milesight UC100 bietet 32 Kanäle und kann damit bis zu 32 Modbus-Geräte mit je einem Wert lesen, der RAK7431 bis zu 32 Abfragebefehle und der Dragino RS485-LN 15 Befehle. In der Praxis begrenzt meist die Uplink-Größe, wie viele Werte pro Meldung sinnvoll sind.
Wie lange hält die Batterie eines RS485 LoRaWAN Konverters?
Die hier genannten fertigen Konverter laufen nicht mit Batterie. Der UC100 braucht 5 bis 24 V Gleichspannung, der RAK7431 8 bis 48 V und der RS485-LN 7 bis 24 V. Im Class-C-Betrieb bleibt der Empfänger dauerhaft offen, das passt nur zu fester Versorgung. Batteriebetrieb ist mit RAK5802 und WisBlock möglich, wenn deine Firmware das Modul zwischen den Abfragen abschaltet.
Funktioniert RS485 zu LoRaWAN mit The Things Network?
Ja, alle genannten Konverter arbeiten mit Standard-LoRaWAN-Netzwerkservern wie The Things Network. Du legst das Gerät mit DevEUI, AppEUI und AppKey an und hinterlegst einen Payload Codec. Beachte die Fair-Use-Regel von 30 Sekunden Sendezeit pro Tag und zehn Downlinks pro Tag, die bei vielen Werten und hohem Spreading Factor schnell erreicht ist.