Mikrotek Setup in der TTN

version 0.1

Author

Chris Reudenbach

Hier folgt eine basale Anleitung für den Betrieb eines MikroTik-LoRaWAN-Gateways (RBwAPR-2nD) über WLAN mit TTN (EU1) sowie der Einbindung der Sensoren Dragino PS-LB, Dragino DDS-75LB und Seeed SenseCAP S2120. Die konkreten Decoder sind nicht enthalten aber auf dem Gateway bereits aktiv. Zusätzlich werden praxistaugliche Wege zum Dauerbetrieb (Storage, MQTT→CSV/DB, InfluxDB/Grafana) und No-Code-Speicherung (Webhooks) skizziert. Beispiele und Snippets sind so gehalten, dass sie direkt übernommen werden können.

1 TTN Community Cloud

The Things Network (TTN) ist ein öffentliches, community-betriebenes LoRaWAN-Netz: Gateways sammeln Funksignale aller angemeldeten Sensoren und leiten sie über einen zentralen Netzwerkserver an eigene Anwendungen weiter. Daher muss kein eigener LoRaWAN-Server aufgesetzt werden – Geräte registrieren, Schlüssel hinterlegen, und die Daten erscheinen (best-effort, kostenlos) und sind in der TTN-Console und per MQTT/Webhooks verfügbar.

1.1 Warum TTN Community Cloud ?

  • LoRaWAN Netzwerkbetrieb: Network-/Join-/Application-Server, Device-Registry, Session-Keys, RX1/RX2-Downlink-Scheduling.

  • Protokoll & Funk-Optimierung: ADR, MAC/PHY-Updates, Region/Frequency-Plans, Duty-Cycle-Handling.

  • Skalierung & Verfügbarkeit: Clusterbetrieb, Load-Balancing, Wartung/Upgrades im Hintergrund.

  • Sicherheit: TLS, Key-Handling, Rechte/Rollen, Abuse-/Rate-Limit-Schutz.

  • Integrationen: MQTT, Webhooks, HTTP/gRPC-APIs, Payload-Formatter, Storage-Forwarding.

  • Observability: Basis-Monitoring/Logs (Live Data, Events), Fehlerpfade sichtbar ohne eigenes Monitoring.

  • Roaming/Weitverkehr: Packet Broker-Anbindung (Gateways/Netze übergreifend), ohne eigene Peering-Pflege.

  • *TTN Community für ~1000 Sensoren:**

    • 0 € & wartungsfrei, sofort startklar, bewährte Defaults.
    • Skaliert bei Intervallen 1–60 min problemlos.
    • Ops-Aufwand ≈ 0 im Vergleich zu self-hosted.

  • Alternative Clouds:

    • Loriot / Actility (Cloud): gemanagt, kostenpflichtig, SLA.
    • AWS IoT Core for LoRaWAN: pay-as-you-go, tiefe AWS-Integration.
    • ChirpStack (self-hosted): Lizenz 0 €, aber voller Betriebs-/Sicherheits-/HA-Aufwand.

2 Setup Mikrotek Fast Track

2.1 Script hochladen

2.2 Script importieren

  • In WinBox → New Terminal ausführen:
  /import file-name=gisma_base2.rsc

2.3 Funktion testen

  • WLAN/DHCP:
  /interface wireless monitor wlan1 once
  /ip dhcp-client print detail
  /ping 8.8.8.8 count=4
  • LoRa :
  /lora print detail
  /tool sniffer quick port=1700

2.3.1 Im einzelnen: MikroTik-Konnektivität, MAC-Zugriff und Hotspot-Einstellungen

2.3.2 Hardware-Aufbau

  • MikroTik RBwAPR-2nD mit Netzteil/PoE versorgen.
  • Ethernet vom PC/Laptop an ether1 des MikroTik stecken.
  • Optional: LoRa-Antenne montieren und fest verschrauben.

2.3.3 Erstverbindung per WinBox (Layer-2 / MAC)

  • WinBox starten → Neighbors: RBwAPR sollte automatisch erscheinen.
  • Verbinden über MAC Address (funktioniert ohne IP).
  • Login: ab Werk admin (ggf. ohne Passwort) → bei erster Anmeldung Passwort setzen.
  • Bei älteren QuickSet-Resten: System → Reset Configuration (ohne Default-Skripte), danach erneut per MAC verbinden.

2.3.4 Hotspot-/WLAN-Voraussetzungen

  • Band: 2,4 GHz (802.11b/g/n). Station-Pseudobridge ist bei 5 GHz oft nicht zuverlässig.
  • Sicherheitsmodus: WPA2-PSK (empfohlen), Kennwort ohne Sonderfälle.
  • SSID: sichtbar, statischer Name (keine Auto-Umschaltung).
  • Kanalbreite: 20 MHz genügt; Auto-Kanal ist ok.
  • Captive Portal: deaktivieren. Portale blockieren Headless-Geräte.
  • MAC-Filter: falls aktiv, MAC von wlan1 freigeben (siehe Interfaces → wlan1).
  • DHCP am Hotspot: aktiv, ausreichend Adressbereich (z. B. 192.168.1.100–200).
  • Internet-Durchleitung (NAT) im Hotspot aktiv lassen.

2.3.5 WLAN-Client (GUI-Weg, WinBox)

  1. Wireless → Security Profiles
    • WPA2-PSK mit Kennwort anlegen/ändern.
  2. Wireless → wlan1
    • Mode: station-pseudobridge
    • Band: 2ghz-b/g/n
    • SSID: Hotspot-SSID eintragen
    • Apply, dann Enable.
  3. Bridge
    • Bridge → + bridgeLocal anlegen.
    • Bridge → Ports: wlan1 und ether1 zur bridgeLocal hinzufügen.
  4. DHCP-Client
    • IP → DHCP Client → +
      • Interface: bridgeLocal, Enabled.
  5. DNS (optional)
    • IP → DNS: Public Resolver (z. B. 8.8.8.8, 1.1.1.1), „Allow Remote Requests“ aktivieren.

2.3.6 Kontrolle & Umstieg auf IP-Zugriff

  • IP-Bezug prüfen: IP → DHCP Client zeigt „bound“ mit zugewiesener IP.
  • Routing/Internet testen: New Terminal → /ping 8.8.8.8 count=4
  • Danach in WinBox statt über MAC über die IP verbinden (stabiler, schneller).

2.3.7 Tests (Terminal, minimal)

/interface wireless monitor wlan1 once
/ip dhcp-client print detail
/ping 8.8.8.8 count=4
/ip route print
/ip dns print

👉 Damit ist die Konfiguration in einem Rutsch aufgespielt.

3 Die Langversion falls es klemmt

3.1 Topologie und Begriffe

Kurzüberblick über alle Bausteine (Sensoren, Gateway, Netzwerk, TTN, Decoder) und wie sie zusammenspielen. Begriffe werden so eingeführt, dass die folgenden Schritte leichter nachvollziehbar sind.

3.1.1 Gesamtbild

Eine End-to-End-Skizze vom Sensor (LoRaWAN) bis zur Datennutzung (Speicher/Visualisierung). Hilft, die Rolle jeder Komponente zu verstehen.

%%{init: {'themeVariables': { 'fontSize': '12px' }}}%%
flowchart TB
  A["Sensor<br/>(LoRaWAN, EU868)"]
  B["LoRa-Gateway<br/>MikroTik RBwAPR-2nD"]
  C["WLAN-Hotspot<br/>(Internet)"]
  D["TTN (EU1)"]
  E["Decoder<br/>(in TTN Application)"]
  F["Ablage / Visualisierung<br/>(Storage / MQTT / DB / Grafana / No-Code)"]
  A --> B --> C --> D --> E --> F

3.1.2 MikroTik als WLAN-Client

Der MikroTik wird als WLAN-Station betrieben, nicht als Access Point. So hängt er sich in ein vorhandenes WLAN ein und leitet LoRaWAN-Pakete ins Internet.

  • Der MikroTik arbeitet nicht als Access Point, sondern als Station im WLAN (vergleichbar mit einem Laptop).
  • Der Modus station-pseudobridge sorgt dafür, dass WLAN und Ethernet im selben Layer-2-Segment erscheinen (Broadcast-Domain geteilt).

3.1.3 Bridge (bridgeLocal)

Eine Layer‑2‑Bridge, die wlan1 und ether1 zu einem logischen Switch verbindet. Der DHCP-Client sitzt auf der Bridge, damit die IP für beide Ports gilt.

  • Die Bridge bündelt Interfaces zu einem logischen Switch (hier: wlan1 + ether1).
  • DHCP-Client hängt auf der Bridge und bezieht die IP vom Hotspot.

3.1.4 „Alte Reste“

Werkseinstellungen/QuickSet legen oft Regeln an, die im Client-Betrieb stören. Dieser Abschnitt erklärt, was entfernt bzw. nicht benötigt wird.

  • Werkseinstellungen/QuickSet hinterlassen oft DHCP-Server/NAT/Firewall-Regeln, die im Client-Betrieb stören können.
  • Nach Reset wird nur das Nötige konfiguriert (WLAN-Client, Bridge, DHCP-Client, DNS).

3.1.5 Sensoren/Decoder (ohne Details)

Überblick, welche Geräte eingebunden werden und wo deren Decoder liegen (TTN Application oder per Device-Override).

  • Dragino PS-LB und Dragino DDS-75LB werden identisch (OTAA) aufgenommen; Decoder unterscheiden sich, sind aber in der TTN-Application bereits aktiv.
  • SenseCAP S2120 nutzt proprietäre Payloads (typisch FPort 199); der Decoder ist in der Application hinterlegt.
  • Verwaltung: Application → Payload formatters (Uplink); auf Wunsch device-spezifisch via Device-Override.

3.2 MikroTik – Soll-Konfiguration (WLAN & Bridge & LoRa)

Schritt‑für‑Schritt‑Konfiguration des MikroTik: WLAN-Client, Bridge, IP/DNS und LoRa‑Gateway‑Weiterleitung zu TTN EU1.

Die folgenden Snippets setzen die bekannte funktionierende Basis um (WLAN-Client auf SSID „GISMA-NET“, WPA2-PSK, Pseudobridge, TTN EU1/UDP, EU-868).

3.2.1 WLAN-Security

Sicherheitsprofil für WPA/WPA2‑PSK. Hinterlegt Schlüssel und Cipher.

/interface wireless security-profiles set [find default=yes] \
    mode=dynamic-keys \
    authentication-types=wpa-psk,wpa2-psk \
    unicast-ciphers=tkip,aes-ccm \
    group-ciphers=tkip,aes-ccm \
    supplicant-identity=MikroTik \
    wpa-pre-shared-key=36171669 \
    wpa2-pre-shared-key=36171669

3.2.2 WLAN als Client (Pseudobridge)

Versetzt wlan1 in den Station‑Modus mit Pseudobridge, um im gleichen Layer‑2 wie der Hotspot zu sein.

/interface wireless set [find default-name=wlan1] \
    band=2ghz-b/g/n \
    wireless-protocol=802.11 \
    mode=station-pseudobridge \
    ssid=GISMA-NET \
    frequency=auto \
    disabled=no

3.2.3 Bridge + Ports

Erstellt bridgeLocal und fügt wlan1 und ether1 als Ports hinzu.

/interface bridge add name=bridgeLocal
/interface bridge port add bridge=bridgeLocal interface=wlan1
/interface bridge port add bridge=bridgeLocal interface=ether1

3.2.4 IP-Bezug & DNS

Aktiviert einen DHCP‑Client auf der Bridge und setzt Resolver für DNS.

/ip dhcp-client add interface=bridgeLocal disabled=no
/ip dns set allow-remote-requests=yes servers=8.8.8.8,1.1.1.1

3.2.5 LoRa – TTN EU1 (Semtech UDP) & EU-868

Aktiviert das eingebaute LoRa‑Gateway, stellt EU‑868 ein und konfiguriert den Semtech‑UDP‑Forwarder zu TTN EU1.

/lora disable 0
/lora set 0 servers="TTN V3 (eu1)" channel-plan=eu-868 \
    network=public forward=crc-valid,crc-error
/lora enable 0

Prüfung:

Schnelle Checks: LoRa‑Status und ob UDP‑Pakete auf Port 1700 rausgehen.

/lora print detail
/tool sniffer quick port=1700

3.3 WinBox/Terminal – Diagnoseleitfaden

Sammlung typischer Diagnose‑Befehle, um WLAN, IP‑Vergabe, Routing und LoRa‑Weiterleitung zu prüfen.

3.3.1 WLAN & IP

Befehle zum Scannen/Überwachen des WLANs und zum Prüfen der IP‑Konfiguration/Konnektivität.

  • WLAN-Scan:
  /interface wireless scan wlan1
  • Monitor des Clients (Status, Kanal, Rauschpegel):
  /interface wireless monitor wlan1
  • DHCP-Client-Status:
  /ip dhcp-client print detail
  • Routing:
  /ip route print
  • Konnektivitätstest:
  /ping 8.8.8.8

3.3.2 Bridge/Ports

Druckt Bridge und Port‑Zugehörigkeiten, um Fehlverdrahtungen auszuschließen.

/interface bridge print
/interface bridge port print

3.3.3 LoRa-Gateway

Prüft LoRa‑Gateway‑Parameter (EUI, Server, Plan) und ob Forwarder‑Traffic sichtbar ist.

  • Status/EUI/Server/Plan:
  /lora print detail
  • UDP-Forwarding sichtbar?
  /tool sniffer quick port=1700

3.3.4 Export/Sicherung

Exportiert die Konfiguration textuell (Backup der Einstellungen) bzw. erstellt ein binäres Voll‑Backup.

  • Terse-Export (menschenlesbar):
  /export terse
  • Binary-Backup (voll):
  /system backup save name=running.backup

3.4 TTN-Konsole – Gateway, Application, Geräte

Schritte in der TTN‑Konsole: Gateway registrieren, Application anlegen, Geräte per OTAA hinzufügen und Decoder prüfen.

3.4.1 Gateway

Registrierung des Gateways in TTN inkl. Cluster und Frequency‑Plan.

  • Registrierung mit Gateway-EUI (siehe /lora print detail).
  • Cluster: eu1.cloud.thethings.network.
  • Frequency Plan: EU_863_870_TTN.

3.4.2 Application & Geräte (OTAA)

Geräte anlegen (OTAA‑Daten), Decoder aktivieren/prüfen und Live‑Daten kontrollieren.

  • Application (z. B. gisma-hydro-testbed) vorhanden.
  • Geräte hinzufügen (PS-LB, DDS-75LB, S2120): DevEUI, JoinEUI/AppEUI, AppKey (jeweils 16 Byte Hex).
  • Decoder sind aktiv (Application-Ebene bzw. Device-Override).
  • Kontrolle unter End device → Live data: Uplinks sichtbar, decoded_payload gefüllt.

3.5 Datenablage – einfache Wege ohne eigenen Server

Drei niedrigschwellige Optionen, um Daten ohne eigene Server‑Software zu speichern (Storage, MQTT→Datei, Webhooks).

3.5.1 TTS-Storage (eingebaut, “kein Server nötig”)

TTN‑interner Speicher mit einfachem HTTP‑Abruf (NDJSON). Ideal für erste Tests/Archivierung.

Aktivierung: Application → Integrations → Storage → Enable.

Abruf (NDJSON):

APP_ID="gisma-hydro-testbed"
REGION="eu1"
API_KEY="NNSXS***api_key***"

curl -s -H "Authorization: Bearer $API_KEY" \
"https://${REGION}.cloud.thethings.network/api/v3/as/applications/${APP_ID}/packages/storage/uplink_message?limit=100" \
> uplinks.ndjson

Nach CSV destillieren (allgemein):

jq -r '
  .end_device_ids.device_id as $id
  | .received_at as $ts
  | .uplink_message.f_port as $fport
  | (.uplink_message.decoded_payload // {}) as $dec
  | [$ts,$id,$fport,($dec|tostring)]
  | @csv
' uplinks.ndjson > uplinks.csv

Hinweis: Speicherfrist je nach Tarif begrenzt → regelmäßig abholen.

3.5.2 MQTT → Datei/CSV (ohne Programmierung)

Abonnieren des TTN‑MQTT‑Feeds und direkte Umwandlung in CSV mit jq.

Abonnieren:

APP_ID="gisma-hydro-testbed"
REGION="eu1"
API_KEY="NNSXS***api_key***"

mosquitto_sub -h "${REGION}.cloud.thethings.network" -p 8883 \
  -u "${APP_ID}" -P "${API_KEY}" --cafile /etc/ssl/certs/ca-certificates.crt \
  -t "v3/${APP_ID}@ttn/devices/+/up" > live.ndjson

On-the-fly CSV:

mosquitto_sub ... | jq -r '
  .end_device_ids.device_id as $id
  | .received_at as $ts
  | .uplink_message.f_port as $fport
  | (.uplink_message.decoded_payload // {}) as $dec
  | [$ts,$id,$fport,($dec|tostring)]
  | @csv
' >> live.csv

3.5.3 No-Code via Webhooks

Weiterleitung der Uplinks per HTTP an Dienste wie Make.com, n8n oder Zapier, die ohne Programmierung in Tabellen/DBs schreiben.

  • Application → Integrations → Webhooks → Add → „Custom“ oder Vorlage.
  • Ziel-URL eines Make.com, n8n Cloud oder Zapier Flows eintragen.
  • JSON in Google Sheets, Airtable, Notion oder S3/Datenbank speichern.

3.6 Dauerbetrieb – robuste Pipelines (MQTT→DB, Grafana)

Produktionsreife Wege, um kontinuierlich Daten zu sammeln, in eine Zeitreihendatenbank zu schreiben und mit Grafana zu visualisieren.

3.6.1 Minimal-Python (MQTT→CSV/JSON)

Kleines Python‑Skript mit paho-mqtt, das Uplinks liest und als CSV/JSON speichert.

# mqtt_to_csv.py
import ssl, json, csv
from paho.mqtt.client import Client

APP_ID  = "gisma-hydro-testbed"
REGION  = "eu1"
API_KEY = "NNSXS***api_key***"
TOPIC   = f"v3/{APP_ID}@ttn/devices/+/up"
BROKER  = f"{REGION}.cloud.thethings.network"

def on_connect(c,u,f,rc):
    c.subscribe(TOPIC, qos=0)

def on_message(c,u,msg):
    up = json.loads(msg.payload.decode())
    ts  = up.get("received_at")
    dev = up.get("end_device_ids",{}).get("device_id")
    fpt = up.get("uplink_message",{}).get("f_port")
    dec = up.get("uplink_message",{}).get("decoded_payload", {})
    with open("uplinks.csv","a",newline="") as f:
        csv.writer(f).writerow([ts,dev,fpt,json.dumps(dec,ensure_ascii=False)])

cli = Client(client_id=APP_ID)
cli.username_pw_set(APP_ID, API_KEY)
cli.tls_set(cert_reqs=ssl.CERT_REQUIRED)
cli.on_connect = on_connect
cli.on_message = on_message
cli.connect(BROKER, 8883, keepalive=60)
cli.loop_forever()

Start:

pip install paho-mqtt
python mqtt_to_csv.py

3.6.2 InfluxDB v2 + Grafana (Docker-Variante)

Stack aus InfluxDB (Zeitreihendatenbank), Telegraf (Ingest/Parsing) und Grafana (Dashboards) als Docker‑Compose.

docker-compose.yml (Beispiel, lokal)

version: "3.8"
services:
  influxdb:
    image: influxdb:2
    ports: [ "8086:8086" ]
    volumes: [ "influx:/var/lib/influxdb2" ]
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=admin
      - DOCKER_INFLUXDB_INIT_PASSWORD=adminpass
      - DOCKER_INFLUXDB_INIT_ORG=gisma
      - DOCKER_INFLUXDB_INIT_BUCKET=lorawan
  telegraf:
    image: telegraf:1.29
    depends_on: [ influxdb ]
    volumes:
      - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
  grafana:
    image: grafana/grafana:10
    ports: [ "3000:3000" ]
    volumes: [ "grafana:/var/lib/grafana" ]
volumes:
  influx:
  grafana:

telegraf.conf (MQTT→InfluxDB Line Protocol)

[agent]
  omit_hostname = true

# TTN MQTT input
[[inputs.mqtt_consumer]]
  servers = ["ssl://eu1.cloud.thethings.network:8883"]
  topics  = ["v3/gisma-hydro-testbed@ttn/devices/+/up"]
  username = "gisma-hydro-testbed"
  password = "NNSXS***api_key***"
  data_format = "json"
  json_time_key = "received_at"
  json_time_format = "2006-01-02T15:04:05Z07:00"
  # Felder extrahieren
  json_string_fields = ["uplink_message.decoded_payload"]

  # Umformung per tagexclude/fieldpass kann nach Bedarf ergänzt werden

# InfluxDB v2 output
[[outputs.influxdb_v2]]
  urls = ["http://influxdb:8086"]
  token = "admin:adminpass"      # bei Influx v2 Setup eigenen Token verwenden
  organization = "gisma"
  bucket = "lorawan"

Grafana:

Visualisierungsschicht. In Grafana die InfluxDB‑Datenquelle setzen und Panels für relevante Messreihen anlegen.

  • Datenquelle InfluxDB v2 auf http://influxdb:8086, Org/Bucket/Token setzen.
  • Dashboard erstellen; z. B. Messungen pressure_cmH2O, distance_cm, battery, temperature (abhängig von Decoderfeldern in decoded_payload).
  • Alternativ: TTN → InfluxDB Cloud per Webhook-Vorlage (Konsole → Integrations → Webhooks → InfluxDB Cloud).

3.7 Betriebshilfen (Auto-Heal, Checks)

Zusatzfunktionen für stabilen Dauerbetrieb: automatischer WLAN‑Reconnect und korrekte Systemzeit.

3.7.1 Netwatch (WLAN neu verbinden bei Ausfall)

Überwacht einen Zielhost und startet wlan1 neu, wenn keine Verbindung besteht.

/tool netwatch add host=8.8.8.8 interval=60s timeout=5s \
    up-script="" \
    down-script="/interface wireless disable wlan1; :delay 2s; /interface wireless enable wlan1"

3.7.2 NTP & Zeitzone (Logs mit korrekter Uhrzeit)

Stellt Zeitzone und NTP‑Server ein, damit Logs/Zeitstempel stimmen.

/system clock set time-zone-name=Europe/Berlin
/system ntp client set enabled=yes primary-ntp=1.1.1.1 secondary-ntp=8.8.8.8

3.8 SenseCAP-Besonderheiten (ohne Decoder-Code)

Hinweise zu Pairing, FPorts und Decoder‑Einsatz für den SenseCAP S2120.

  • Pairing/BT-PIN: häufig 000000.
  • DevEUI/JoinEUI/AppKey: auf Label, App oder Herstellerportal.
  • FPort: typischerweise 199.
  • In TTN Gerät anlegen (OTAA) → Live Data prüfen → decoded_payload wird angezeigt (Decoder ist bereits aktiv).
  • Bei fehlender Decodierung: Application-Level Decoder prüfen; falls mehrere Hersteller parallel verwendet werden, device-spezifische Overrides setzen.

3.9 Dragino PS-LB & DDS-75LB (ohne Decoder-Code)

Kurzanleitung für die Aufnahme per OTAA und Decoder‑Kontrolle der Dragino‑Geräte.

  • Beide über OTAA identisch aufnehmen (DevEUI/JoinEUI/AppKey).
  • Decoder unterscheiden sich (Druck vs. Distanz) – bereits aktiv.
  • Kontrolle via Live Data; Werte erscheinen im decoded_payload.
  • Typischer FPort 2 (Herstellerdoku beachten).

3.10 FAQs & Troubleshooting

Kurze Checkliste typischer Fehlerbilder und ihrer Ursachen.

  • Uplinks kommen nicht in TTN an: /lora print detail (Enabled?), /tool sniffer quick port=1700 (UDP-Traffic?), /ip dhcp-client print (IP bekommen?), /ping 8.8.8.8.

  • WLAN sichtbar, aber keine IP: Bridge-Ports korrekt? DHCP-Client auf bridgeLocal? WPA-Key/SSID korrekt? monitor wlan1 zeigt „searching-for-network“ → Kanal/Entfernung prüfen.

  • Decoder greift nicht: FPort prüfen; Application-Decoder vs. Device-Override; für SenseCAP meist Port 199.

  • Speicherung/Visualisierung fehlt: Storage aktivieren oder MQTT→CSV/DB/Grafana implementieren (siehe Kapitel 5 & 6).

3.10.1 To-Do-Leitfaden

Minimalliste, um schnell von „Gerät online“ zu „Daten gesichert und sichtbar“ zu kommen.

  1. TTN Storage aktivieren und per HTTP + jq regelmäßig ziehen (Archiv/CSV).
  2. Für Live-Dashboards MQTT → InfluxDB → Grafana (Docker-Stack) oder Webhook → InfluxDB Cloud/Datacake/Ubidots.
  3. Netwatch auf dem MikroTik setzen (WLAN-Selbstheilung).
  4. Binary-Backup auf dem MikroTik anlegen und extern sichern.

3.11 Anmerkungen

Ergänzende Hinweise zur Konfiguration und zum Betrieb (EU‑868, Semtech‑UDP, Datenpfade) in kompakter Form.

  • Die Decoder für PS-LB, DDS-75LB und SenseCAP S2120 sind in der TTN-Application hinterlegt und aktiv.
  • Der MikroTik arbeitet im WLAN-Client/Pseudobridge-Modus, erhält IP per DHCP auf bridgeLocal und forwardet LoRa-Pakete via Semtech-UDP (Port 1700) an TTN EU1 mit EU-868 Frequency-Plan.
  • Daten können über Storage/MQTT/Webhook ohne eigenen Server gespeichert und mit Grafana visualisiert werden.

3.12 Downloads & Handbücher

3.12.1 MikroTik

3.12.2 Dragino (PS-LB/LS & Co.)

3.12.3 Seeed SenseCAP S2120

3.12.4 The Things Network (TTN)