Kategoriearchiv: Arduino

Allgemein, Arduino, Code, Home Assistant, KI generiert, WLAN

izar-Wasserzähler per Funk auslesen

Kommentar hinterlassen


Technische Funktionsbeschreibung (ESP32-S3 + SX1262, wM-Bus T1, ESPHome)

Hinweis: Dieser Artikel und auch der Code wurde mit Hilfe von KI geschrieben.

1. Überblick

Diehl-/Sappel-Izar-Wasserzähler mit Funkmodul senden ihre Zählerdaten selbstständig und unaufgefordert als wireless M-Bus-Telegramme (Modus T1, 868,95 MHz), ungefähr alle 8–10 Sekunden. Ein Empfänger muss daher nichts anfragen, sondern nur zuhören. Die hier beschriebene Lösung empfängt diese Telegramme mit einem Mikrocontroller-Board mit eingebautem LoRa-Funkchip, dekodiert sie und stellt die Werte als Sensoren in Home Assistant bereit.

Datenfluss:

  • Zähler sendet Telegramm (wM-Bus T1, 868,95 MHz, 100 kbit/s, 3-aus-6-Kodierung)
  • SX1262-Funkchip empfängt das Frame im FSK-Modus
  • ESPHome-Komponente wmbus_radio liest das Frame per SPI aus und prüft es
  • wmbus_common entschlüsselt und dekodiert es mit dem Izar-Treiber (aus dem Projekt wmbusmeters)
  • wmbus_meter ordnet das Telegramm anhand der Zähler-ID einem konfigurierten Zähler zu und liefert die Felder an Sensoren
  • ESPHome überträgt die Sensorwerte per Native API an Home Assistant

2. Hardware

Verwendet wird ein Heltec WiFi LoRa 32 V3 (ESP32-S3 mit eingebautem Semtech SX1262 und 0,96″-OLED). Ein externes Funkmodul ist nicht nötig. Wichtig ist eine auf 868 MHz abgestimmte Antenne.

Der Heltec V3 kommt fix & fertig verdrahtet, es ist also kein Löten etc. nötig, um diese Anwendung abzubilden.

FunktionGPIOHinweis
SPI SCK / MOSI / MISO9 / 10 / 11SPI-Bus zum SX1262
SX1262 CS (NSS)8
SX1262 RESET12
SX1262 BUSY13
SX1262 DIO1 (IRQ)14auf dem Board teils fälschlich als „DIO0“ beschriftet
Vext36active-low; versorgt Antennen-Verstärker und OLED, muss beim Booten eingeschaltet (LOW) werden
OLED I2C SDA / SCL / RST17 / 18 / 21optional, SSD1306 128×64, Adresse 0x3C
PRG-Taste0optional (z. B. Display-Seiten umschalten)

Board-Besonderheiten für die Funkkonfiguration:

  • rf_switch: true – DIO2 des SX1262 steuert den Antennen-Umschalter.
  • has_tcxo: true – der Quarzoszillator (TCXO) wird über DIO3 versorgt. Die Komponente setzt dabei fest 3,0 V, obwohl der TCXO für 1,8 V spezifiziert ist; in der Praxis funktioniert der Empfang, sollte aber geprüft werden.

Grundsätzlich funktioniert das Prinzip auch mit anderen Empfängern, die die Komponente unterstützt (z. B. ESP32 + CC1101 oder SX1276); dann ändern sich nur Pins und radio_type.

3. Software-Grundlage

Firmware ist ESPHome (Framework ESP-IDF). Die wM-Bus-Unterstützung kommt als External Component aus dem GitHub-Projekt SzczepanLeon/esphome-components, bestehend aus drei Teilen:

  • wmbus_radio – Treiber für den Funkchip (Frequenz 868,95 MHz, FSK, 100 kbit/s, Präambel-/Sync-Erkennung, Dekodierung 3-aus-6, CRC-Prüfung). Löst für jedes empfangene Frame den Trigger on_frame aus.
  • wmbus_common – Telegramm-Parser und Zählertreiber (portiert aus wmbusmeters), darunter der Treiber „izar“.
  • wmbus_meter – eine Instanz pro Zähler: filtert nach Zähler-ID und Treiber und stellt die dekodierten Felder als Sensor- bzw. Text-Sensor-Plattform bereit.

Verschlüsselung: Izar-Telegramme (Diehl „PRIOS“) sind mit einem LFSR-Verfahren verschleiert. Der Treiber bringt die öffentlich bekannten Diehl-Standardschlüssel mit – für diese Zähler muss kein individueller Schlüssel angegeben werden.

4. Zähler-ID

Jeder Zähler wird über seine achtstellige Zähler-ID (Adressfeld im Telegramm) identifiziert. Sie steht meist auf dem Funkmodul bzw. Typenschild. In der Konfiguration wird sie als Hex-Literal mit denselben Ziffern angegeben, also ID 12345678 → meter_id: 0x12345678 (die Adresse ist im Telegramm BCD-kodiert).

Unbekannte IDs lassen sich ermitteln, indem man im on_frame-Trigger den Telegramm-Header parst (Telegram::parseHeader) und die Adresse aller gehörten Frames loggt. Alle IDs, die nicht in der eigenen Liste stehen, werden in einem kleinen Ringpuffer gesammelt und gelegentlich als Text-Sensor gemeldet – so findet man Zähler in Reichweite, ohne die Home-Assistant-Datenbank zu fluten.

5. Gelieferte Werte pro Zähler

Feld (wmbus_meter)BedeutungEinheit
total_m3aktueller Zählerstandm³
last_month_total_m3Zählerstand am letzten Stichtag (Monatsende)m³
last_month_measure_dateDatum dieses StichtagsText (JJJJ-MM-TT)
remaining_battery_life_ygeschätzte Batterie-RestlaufzeitJahre
current_alarms / previous_alarmsAlarme aktuell / früher (Leck, Rückfluss, Manipulation, blockiert …)Text
rssi_dbmEmpfangsstärke des letzten TelegrammsdBm

Das Feld target_m3 liefern diese Zähler nicht (immer leer); es wird daher nicht verwendet. Zusätzlich lässt sich per Template-Sensor der Verbrauch seit dem Stichtag berechnen: (total_m3 − last_month_total_m3) × 1000 in Litern. Das Ergebnis sollte gerundet werden (roundf), da die Subtraktion zweier nahe beieinander liegender float-Werte sonst Nachkommastellen-Artefakte erzeugt.

6. Datenaufbereitung

Darstellung in Grafana des Monatsverbrauchs

Da jeder Zähler etwa alle 9 Sekunden sendet, würden ungefilterte Werte Home Assistant mit identischen Einträgen überschwemmen. Deshalb:

  • Numerische Sensoren: Filter delta (nur bei tatsächlicher Änderung senden, z. B. 0,5 Liter beim Zählerstand) plus heartbeat (z. B. alle 6 h den aktuellen Wert erneut senden, damit sichtbar bleibt, dass der Zähler noch empfangen wird).
  • Text-Sensoren (Alarme, Stichtag): kleiner Lambda-Filter, der nur bei geändertem Text weitergibt.
  • Für den Zählerstand: device_class water, state_class total_increasing – damit ist er direkt im Energie-Dashboard von Home Assistant als Wasserverbrauch nutzbar.
  • Optional: im on_telegram-Trigger des Zählers einen Zeitstempel „zuletzt empfangen“ setzen.

7. Robustheit: Funkstille-Watchdog

Beim SX1262 mit dieser Komponente ist ein Fehler bekannt, bei dem der Empfänger nach einiger Zeit ohne Fehlermeldung verstummt (Issue #318 im Komponenten-Projekt). Abhilfe: Im on_frame-Trigger wird bei jedem empfangenen Frame (egal von welchem Absender) millis() in einer globalen Variable gespeichert. Ein interval-Block prüft regelmäßig, ob seit mehr als 15 Minuten kein Frame mehr kam, und startet das Gerät dann neu. Da in der Regel mehrere Zähler in Reichweite senden, tritt eine echte 15-minütige Funkstille praktisch nie auf.

8. Minimal-Konfiguration (Kern)

Der folgende Ausschnitt zeigt nur die für das Auslesen nötigen Teile; WLAN, API, OTA usw. wie bei jedem ESPHome-Gerät ergänzen.


esp32:
  board: esp32-s3-devkitc-1
  variant: ESP32S3
  flash_size: 8MB
  framework:
    type: esp-idf

external_components:
  - source: github://SzczepanLeon/esphome-components@main
    components: [wmbus_radio, wmbus_common, wmbus_meter]

spi:
  clk_pin: GPIO9
  mosi_pin: GPIO10
  miso_pin: GPIO11

switch:
  - platform: gpio # Vext einschalten (active-low)
    id: vext_enable
    internal: true
    restore_mode: ALWAYS_ON
    pin: { number: GPIO36, inverted: true }

globals:
  - id: last_frame_millis
    type: uint32_t
    initial_value: '0'

wmbus_radio:
  radio_type: SX1262
  cs_pin: GPIO8
  reset_pin: GPIO12
  busy_pin: GPIO13
  irq_pin: GPIO14
  rf_switch: true
  has_tcxo: true
  on_frame:
    - then:
        - lambda: id(last_frame_millis) = millis();

wmbus_meter:
  - id: wasserzaehler
    meter_id: 0x12345678 # Zaehler-ID 12345678
    type: izar
    mode: [T1]

sensor:
  - platform: wmbus_meter
    parent_id: wasserzaehler
    field: total_m3
    name: "Wasser gesamt"
    unit_of_measurement: "m³"
    device_class: water
    state_class: total_increasing
    accuracy_decimals: 3
    filters:
      - delta: 0.0005
      - heartbeat: { period: 6h, optimistic: true }
  - platform: wmbus_meter
    parent_id: wasserzaehler
    field: rssi_dbm
    name: "Wasser RSSI"
    unit_of_measurement: "dBm"

interval:
  - interval: 1min # Funkstille-Watchdog
    then:
      - if:
          condition:
            lambda: return millis() - id(last_frame_millis) > 15UL*60*1000;
          then:
            - lambda: App.safe_reboot();

Weitere Zähler werden durch zusätzliche wmbus_meter-Einträge (je mit eigener meter_id) und zugehörige Sensoren ergänzt; ein Empfänger kann beliebig viele Zähler in Reichweite gleichzeitig auslesen. Bei mehreren Zählern bietet sich an, den Zähler-Block als ESPHome-Package mit vars (meter_id) einmal pro Zähler einzubinden.

9. Inbetriebnahme und Fehlersuche

  • Logger-Level zunächst auf DEBUG stellen: Jedes empfangene Frame erscheint mit RSSI; so sieht man, ob überhaupt Funkverkehr ankommt und welche IDs in Reichweite sind.
  • Empfangsstärke: ab etwa −100 dBm wird es unzuverlässig. Zähler in Schächten oder hinter Metall dämpfen stark – Antennenposition optimieren.
  • Kommen Frames an, aber keine Werte beim Zähler: meter_id prüfen (Hex-Schreibweise mit den Dezimalziffern der ID) und type: izar.
  • Kommt gar nichts an: Vext eingeschaltet? rf_switch/has_tcxo gesetzt? Antenne für 868 MHz angeschlossen?

Amateurfunk, APRS, Arduino, Code, HAMnet, Linux, LoRa

OTA Firmware update für ESP32 LoRa APRS iGate von OE5BPA und andere…

Kommentar hinterlassen

Ich setze seit kurzem die ESP32 basierenden Gateways (PoE-fähig!) für LoRa APRS auf 70cm von OE5BPA ein. Nachdem ich diese iGates nicht nur zu Hause betreibe, sondern auch bei Relaisstationen an exponierten Standorten installiere, ist mir wichtig, dass auch neue Entwicklungen dort genutzt werden können – das setzt voraus, dass ich die Konfiguration von der Ferne anpassen kann (das funktioniert wunderbar über FTP und ist von Peter OE5BPA bereits gut beschrieben worden) und auch Firmware Updates mit neuen Features von der Ferne installiert werden können. Dieses Feature nennt sich Firmware Update over The Air (kurz: FOTA- oder OTA-Update).

iGate bei 73% des Over The Air Firmware Updates

Eine Beschreibung der Hardware findet ihr hier auf meinem Blog. Da ich die Geräte über PoE nutze, gibt es hier für Interessierte eine Übersicht über PoE, die früher mal geschrieben habe.

iGate im (Test-)Betrieb

Nachdem ich kein Programmierer bin und auch mit der Entwicklungsumgebung Platformio (siehe auch https://platformio.org) noch nicht viel Erfahrung habe, war mir am Anfang nicht ganz klar, wie das FOTA/OTA funktioniert. Daher möchte ich es hier kurz beschreiben.

Im Wesentlichen basiert die Funktion auf Bibliotheken, die hier in der Dokumentation von Platformio beschrieben sind: https://docs.platformio.org/en/latest/platforms/espressif32.html#over-the-air-ota-update
Es wird also in der Firmware die Funktion verpackt, die über Platformio genutzt wird, um die Updates von der Ferne durchzuführen.

Welche Schritte sind für uns Benutzer nun also nötig, um ein Update durchzuführen?
Die Voraussetzung ist, dass die Umgebung so aufgesetzt ist, dass der Code fehlerfrei kompiliert, also alle Bibliotheken vorhanden sind uä. Damit wäre ja das Update über USB machbar. Wenn das klappt, prüft man die Einstellungen bzw. Konfiguration, die befinden sich in der Datei is-cfg.json.

Auch wenn man bisher noch kein Update Over the Air durchgeführt hat, ist es dennoch auf den iGates auf der Firmware aktiv. Es ist also möglich, einen Gateway, den man vor ein paar Wochen installiert hat, künftig OTA zu aktualisieren.

Wie geht das nun?
Ein Blick in die Datei platformio.ini, im Anfangsverzeichnis des Projekts, zeigt uns die Konfiguration:

# activate for OTA Update, use the CALLSIGN from is-cfg.h as upload_port:
upload_protocol = espota
upload_port = OE1SCS-12.local

Im Beispiel oben möchte ich den iGate „OE1SCS-12“ updaten, der sich bei mir im LAN befindet. Falls sich dein iGate auch im LAN befindet, brauchst du also nur ggf. die Kommentare rausnehmen und den Call deines iGates – gefolgt durch .local – ersetzen.

Peter hat die Konfiguration so gewählt, dass sich die Gateways mit dem mDNS-Namen (multicast DNS) unter dem Namen des iGate + .local registrieren. mDNS ist ein DNS-Dienst, der keine Server benötigt, sondern über Multicast (dafür nur im gleichen LAN) DNS-Namen ermöglicht. Ich kann also meinen Gateway auch über diese Adresse pingen:

mDNS im LAN funktioniert, ich kann mein iGate erreichen

Dazu muss natürlich die Konfiguration erstmal (vmtl. über USB) auf dem iGate aufgebracht sein, danach ist ein Update wie beschrieben möglich.

Wenn das klappt, kann ich in Platformio das „Alien“-Symobl auswählen und „Upload Filesystem Image“. Schon wird Platformio die aktuelle Version builden (quasi kompilieren) und über das Netzwerk upgraden:

OTA läuft

Im „Task“ Fenster bei Platformio (auch Konsole) genannt kann man den Status verfolgen:

Wenn die Meldung „SUCCESS“ auftaucht, war der Vorgang erfolgreich. Der iGate startet nun die neue Firmware und sollte in Kürze erreichbar sein.

Und wie funktioniert das über die Ferne?
Ganz einfach: man ersetzt in der platformio.ini den mDNS-Eintrag (in meinem Fall „OE1SCS-12.local“ durch die IP-Adresse des in der Ferne installierten iGates, speichert die Änderung und kann nun genauso von der Ferne das Update einspielen!
In meinem Fall sieht das dann so aus:

# activate for OTA Update, use the CALLSIGN from is-cfg.h as upload_port:
upload_protocol = espota
upload_port = 192.168.132.146

Amateurfunk, APRS, Arduino, Code, LoRa, Raspberry Pi, Unterwegs, WLAN

LoRa APRS Tracker auf ESP32 Basis

Kommentar hinterlassen

In meinem Blog habe ich häufig Raspberry-basierte Lösungen und Anwendungen beschrieben. In letzter Zeit (in den letzten 1-2 Jahren) entstehen in der Community aber immer mehr Lösungen auf Basis von ESP8266 bzw. dem quasi-Nachfolger ESP32, also basierend auf einem „Mikroprozessor“ und nicht einem vollständigen Linux-System, wie es beim Raspberry der Fall ist. Das finde ich sehr toll, weil damit die Pflege des vollständigen Linux-Systems hinfällig wird und ich leider auch schon viele SD-Karten tauschen musste, die mit der Zeit kaputt geworden sind. Immerhin sind die Rapsberrys oft im Außenbereich den Temperaturschwankungen und Änderungen der Luftfeuchtigkeit des Wetters und der Jahreszeiten ausgesetzt.

ESP32 basierter APRS LoRa iGate von OE5BPA

Als Client, Node, Tracker, Endgerät – wie auch immer man es nennen möchte – ist der ESP8266 schon länger im Einsatz. Neu ist, dass nun mit dem ESP32 Prozessor ein leistungsstarker Kern verfügbar ist, der auch Anwendungen ermöglicht, die früher einen Raspberry oder ähnliche Geräte erfordert hätten. Immerhin hat der im Jahr 2016 vorgsetellte ESP32 beeindruckende Leistungsdaten (für einen stromsparenden Mikroprozessor): 160 bis 240 MHz auf einer Dual-Core-Plattform mit 520 KB SRAM. Eingebaut sind WLAN (802.11 b/g/n) mit Bluetooth und zahlreiche Schnittstellen, auszugsweise zB.: GPIOs, 12bit ADC und 8bit DAC, SPI, I²S, I²C, UART, Unterstützung für SD/eMMC, Ethernet, CAN 2.0 uvm. Das Datenblatt gibt dazu mehr Auskunft.

Nachdem in diesem Leistungsbereich jetzt neue Anwendungen ermöglich werden, freut es mich besonders, dass Initiativen wie LoRa APRS davon profitieren und handfeste Lösungen auch für den Gateway-Einsatz (als iGate) verfügbar sind, aktiv entwickelt und laufend verbessert werden.

OM Andi OE1ROT stellt auf seinem Blog einerseits einen Tracker mit TTGO T-Beam (433 MHz!) vor, als auch die nun verfügbaren Gateways auf ESP32 Basis. Ich möchte hier in meinem Blog nicht nochmal alles beschreiben, Andi hat das bereits sehr ausführlich getan, daher verlinke ich diesmal nur zu seinem Eintrag:
https://www.aronaut.at/2020/11/lora-aprs-gateway-mit-esp32-boards/

Die Projekte werden auf Github in diesem Bereich gehostet: https://github.com/lora-aprs
Die iGate Software wird von Peter OE5BPA hier aktuell angeboten:
https://github.com/lora-aprs/LoRa_APRS_iGate

Die TTGO T-Beams sind zB. hier bei Amazon erhältlich: TTGO T-Beam ESP32 mit LoRa für 433 MHz (ggf. OLED Display nicht vergessen)

Arduino, Funkfeuer, Hausautomatisierung, Raspberry Pi, Unifi

Übersicht über Power over Ethernet (PoE)

9 Kommentare

Bei vielen Anwendungen nutze ich Power over Ethernet (= PoE). Ist doch praktisch: ein Netzwerkabel wird für die Anwendung oft sowieso benötigt, dann kann man es auch gleich nutzen, um das Endgerät mit Strom zu versorgen. Außerdem ist oft keine Steckdose, wo man sie benötigen würde. Ich habe grundsätzlich nur gute Erfahrungen damit gemacht, teilweise entstehen durch die Nutzung von PoE auch neue Möglichkeiten. Es gibt jedoch verschiedene Standards und Varianten – und die müssen zusammenpassen. Hier also eine kleine Übersicht, die meinen Wissensstand und meine Erfahrungen widerspiegeln.

Im Wesentlichen sehe ich zwei große Varianten an PoE:

  • Passives PoE und
  • PoE nach 802.3af oder 802.3at (auch aktives PoE genannt, bzw. PoE+ bei 802.3at)

Beachtet, dass diese Varianten nicht miteinander kompatibel sind.

Passives PoE

Bei passivem PoE werden mehrere Adern des 8-poligen-Gigabit-Ethernet-Kabels für die Übertragung von Strom genutzt. Meist werden die Adern 4+5 für + und 7+8 für – genutzt. Hier wird einfach Strom von einem Netzteil (auch Injector genannt) durchgeschickt. Grundsätzlich sollte man hier vorsichtig sein, dass man (a) die richtige PoE-Variante einsetzt, (b) die korrekte Spannung überträgt und (c) das Endgerät das unterstützt. Sonst könnte es passieren, dass eine Netzwerkkarte defekt wird, wenn ihr einfach über diese PINs der Strom geschickt wird.

Es gibt viele gängige Varianten, die sich meist durch die Spannung unterscheiden. Bei Ubiquiti und Mikrotik findet man meist 24V passive PoE, in anderen Anwendungen (zB. Videokameras) kommt oft 12V zum Einsatz. Vereinzelt sieht man 5V, hier habe ich die Erfahrung gemacht, dass bei größeren Kabellängen (bereits so ab 10m) der Spannungsabfall relevant wird, von 5V würde ich also abraten bei passive PoE.

In den meisten Anwendungen sieht man, dass ca. 2,1 bis max. 2,5 Ampere übertragen werden. Je nach Spannung kann man also leicht ausrechnen, wieviel Leistung mit dieser Variante zur Verfügung gestellt werden kann. Bei 24V mit 2,1A sind das bereits gut 50 Watt, bei 12V die Hälfte.

Passives PoE heißt also so, weil es einfach Strom durchschickt, ohne weiterer Überprüfung oder Logik.

PoE & PoE+ nach 802.3af und 802.3at

Man sieht an der Überschrift: diese Variante ist genauer standardisiert. Die IEEE hat im Standard 802.3af und 802.3at genau spezifiziert, wie PoE durch das Netzwerkkabel geschickt wird und viele Hersteller nutzen diesen Standard. Das erhöht natürlich die Kompatibilität und so wird es möglich, einen PoE-fähigen-Switch mit beliebigen Endgeräten zu verbinden.

PoE und PoE+ orientieren sich an 48V (Nominalspannung), tatsächlich sieht der Standard 36V bis 57V vor. Das ist schon vernünftig aufgrund der Robustheit bei längeren Ethernet-Verbindungen.

Meines Wissens nach unterscheiden sich PoE (IEEE 802.3af) und PoE+ (IEEE 802.3at) vor allem aufgrund der maximal vorgesehenen Leistung. Diese wird beim Anschluss des Kabels „detektiert“, dafür gibt es einen ausgeklügelten Mechanismus, der den Widerstand des Engerätes misst und darüber erfährt, welchen Standard und welche Leistungsklasse das Endgerät unterstützt. Tolle Sache, va. ist hier auch abgesichert, dass ein Endgerät ohne PoE-Funktion keinen Schaden nimmt und nicht einfach Spannung durchgeschickt wird, wie bei der passiven Variante.

Grundsätzlich würde ich, wenn möglich, dieser Variante von PoE den Vorzug geben.

Falls euch Details zu den Modi, Spannungen, der Detektion und den Leistungsklassen interessiert, möchte ich auf die Wikipedia-Seite verweisen, da diese sehr ausführlich darüber aufklärt: https://de.wikipedia.org/wiki/Power_over_Ethernet

Anmerken möchte ich noch, dass es auch bei IEEE 802.3af/at eine passive Variante gibt, dort werden die PINs 1+2 für + und 3+6 für – genutzt. Vor allem günstigere Injectoren und Splitter setzen darauf. Bisher habe ich keine Probleme damit gehabt. Splitter nach dem 802.3af/at-Standard haben in allen Kombinationen mit Injectoren & Switches funktioniert.

PoE bei Switches

Es gibt von verschiedenen Herstellern zahlreiche Switches, die PoE unterstützen. Die meisten setzen auch hier auf den 802.3af/at-Standard.

Ich finde es sehr praktisch, dass man von Switches aus direkt die Endgeräte mit Strom versorgen kann. Meistens sind diese Endgeräte WLAN Access Points oder IP Kameras. Ich nutze es aber auch gerne für Raspberry Pi oder Arduinos (und andere IoT-Geräte oder Sensoren).

Ein wesentlicher Vorteil hierbei ist, dass man am Switch (meist per Webinterface) den Port PoE-mäßig resetten kann. Wenn also eine IP Cam nicht mehr reagiert, kann ich bequem einen Restart auslösen. Das ist vor allem praktisch bei weit entfernten Standorten und erhöht die Betriebssicherheit immens. Manche Switches können auch Endgeräte per PING überwachen, und wenn diese ein paar Minuten nicht mehr erreichbar sind, resetten sie PoE am Port automatisch.

Bei einer Sache muss man jedoch achtgeben: PoE Switches haben meist ein „Power Budget“, also eine maximale Leistung (in Watt), die sie auf einzelnen Ports oder insgesamt(!) bedienen können. Es kann also sein, dass auf einem 24-Port-PoE-Switch, der zB. 70 Watt Power Budget unterstützt, nicht auf jedem Port eine Kamera mit PoE versorgt werden kann. Das sollte man sich vorher überlegen und danach den richtigen Switch mit der richtigen Leistung wählen.

PoE Adapter für DIY-Projekte

Ich werde oft gefragt, welche PoE-Injectoren (= führt die Spannung in das Netzwerkkabel und enthält manchmal direkt das Netzteil) ich verwende und wie ich die Endgeräte anschließe, zB. Raspberry PI.

Ich führe hier also ein paar Geräte an, die kostengünstig sind und mit denen ich gute Erfahrungen gemacht habe. Die Teile sind Großteils bei Amazon erhältlich oder – wenn man mehr Zeit für die Lieferung hat – auch bei Aliexpress.

PoE Injector & Splitter

zB. bei Amazon:


Amateurfunk, APRS, Arduino, Code, Funkfeuer, Linux, LoRa, Unterwegs

APRS über LoRa mit Dragino LoRa/GPS shield für 70cm-Band

13 Kommentare

In den letzten Monaten habe ich mich sehr viel mit LoRa und LoRaWAN beschäftigt. Bei den zahlreichen Treffen hat mir die Amateurfunk-Community erzählt, dass LoRa auch ein guter Ersatz für das FSK/AFSK basierte APRS sein könnte und an einer Implementierung arbeiten.

Das halte ich für eine tolle Idee! APRS hat mich – wie ihr an anderen Beiträgen meines Blogs erkennen könnt – schon immer sehr interessiert!

Es handelt sich also nur um den Ersatz der Modulation durch LoRa und nicht um eine vollwertige LoRaWAN-Implementierung, die ja auch das ganze Umfeld der Datenverarbeitung mit einschließen würde. Daher ist man auch hinsichtlich QRG (Frequenz) flexibel. Die Hardware für LoRa ist ja für 868 MHz, 433 MHz und 912 MHz erhältlich. Der Bereich um 912 MHz ist in der EU nicht frei nutzbar. Im „kommerziellen“ Einsatz (LoRaWAN) ist 868 MHz die Wahl für Europa.

Funkamateure sind sowieso im Bereich um 433 MHz „zu Hause“, das ja für viele Anwendungen als 70cm-Band bekannt ist und dort seitens Amateurfunk als Primärdienst genutzt werden kann.

Damit ist für mich die Trennung der Anwendungen und Frequenzen auch schlüssig umsetzbar:

  • LoRaWAN nutzen wir (kommerziell) auf 868 MHz und
  • LoRa für APRS im 430-439 MHz Bereich als Amateurfunkdienst!

APRS Tracker

Das Ziel ist also, einen APRS-Tracker zB. für’s Auto mit LoRa-Modulation im70cm-Band zu schaffen. Die Daten sollen dann wie andere APRS-Anwendungen über zB. aprs.fi zur Verfügung stehen.

Auf der Webseite von DJ7OO (http://www.kh-gps.de/lora.htm) wird sehr viel zu dem Thema erklärt. Die Software basiert auf Codeteilen, die von Stuart Robinson (ua. auf dieser Website https://www.rcgroups.com/forums/showthread.php?2454546-Arduino-LoRa-Long-Range-Lost-Model-Tracker) veröffentlicht wurden. Bitte beachtet die Lizenz, die hier kommerzielle Nutzung auch von Codeteilen ohne ausdrücklicher Zustimmung von Stuart untersagt.

Die meisten OMs haben ihre Sender auf Basis von Arduino Pro Mini erstellt. Dazu benötigt man noch ein paar Kleinteile, ua. ein GPS-Modul und den RFM98W LoRa-Chip.  Ich gestehe, das Löten vermeide ich, wenn es leicht möglich ist – daher habe ich nach einer andere Hardware-Lösung gesucht.

ohne löten: Dragino LoRa/GPS shield

Mit den LoRa/GPS-Shields von Dragino habe ich ja bereits in anderen Projekten gute Erfolge erzielt. Diese Shields sind natürlich auch für 433 MHz erhältlich. Ich kaufe übrigens meistens über Tindie. Es funktioniert zuverlässig, die Lieferung dauert ca. 3 Wochen:
https://www.tindie.com/products/edwin/loragps-shield-for-arduino/

Das Tolle ist, dass man dazu nur noch einen Arduino Uno benötigt, zusammensteckt und für viele Anwendungen eine fertige Lösung hat!

Als Basis für meinen Code habe ich die Version von Sascha (iot4pi.com) und Karl OE1KEB gewählt, die für den Arduino Pro Mini geschrieben ist:
https://github.com/IoT4pi/LoRa-APRS-Sender
(Den Link zu meinem Fork für’s Dragino LoRa/GPS findet ihr  unten.)

Die Software benutzt SoftSerial, um auf die GPS-Daten zuzugreifen. Dazu benötigt man zwei Jumper Wire Kabel (M-F). Am Dragino LoRa/GPS Shield werden die Jumper bei TX_GPS und RX_GPS entfernt und mit den digitalen Eingängen 3 und 4 verbunden werden.

Bitte beachtet, dass nur lizenzierte Funkamateure diesen Funkdienst benutzen dürfen, es wird auch ein Funkrufzeichen (Call) benötigt, das eingestellt werden muss!

Die von mir für das Dragino LoRa/GPS Shield abgeänderte Software findet ihr hier:

https://github.com/schulti/LoRa-APRS-Sender

Bitte ändert euren Call und ggf. die SSID („-12“)  in dieser Variable:

String Tcall="OE1SCS-12"; //your Call Sign

Die Software muss nun nur noch auf den Arduino raufgeladen werden und schon kann man testen. Der erste GPS-Fix dauert leider ein bißerl – da muss man etwas Geduld haben. An einer blinkenden LED sieht man, dass ein GPS-Fix vorhanden ist.

Ein Blick auf die Webseite https://aprs.fi hat den Tracker sofort gezeigt:

Auch die Rohdaten sehen vernünftig aus. Meine Pakete wurden von OE1XBR-10 empfangen:

Nun bin ich also zusätzlich zur 2m APRS Antenne über 70cm LoRa APRS unterwegs. Zusätzlich habe ich einen GPS Mapper für LoRaWAN (868 MHz):

Für’s Autodach habe ich eine Magnetfußantenne für 433 MHz und einen aktiven GPS-Empfänger bestellt. Das Shield hat eine GPS-Antenne eingebaut. Es schaltet von selbst um, sobald es erkennt, dass eine externe Antenne angesteckt wird.

Damit lassen sich ganz einfach Vergleichsfahrten zwischen den Technologien durchführen, zB: unten links LoRa-APRS-70cm mit APRS-2m im Vergleich (Argent Data OpenTracker+):

Einkaufsliste für den LoRa/GPS APRS Tracker

Die Bauteile sind um gesamt € 42,- erhältlich, um weitere €  15,- gibt’s die Antennen für’s Autodach dazu:

Optional:

Amateurfunk, App, APRS, Arduino, Code, Linux, LoRa, Smartphone, Unterwegs

LoRa Reichweite mit TTNmapper abschätzen

17 Kommentare

Nachdem wir jetzt auch einen Gateway fertig haben (ich werde in einem eigenen Beitrag berichten) und mehrere Sensoren funktionieren, wäre es doch mal interessant, die Reichweite der Signale kennenzulernen.

Grundsätzlich senden meine Sensoren bisher nur Messdaten, im Moment aber noch eher statische kurze Textmitteilungen. Was mir fehlt sind die GPS-Positionsdaten, damit ich feststellen kann, von welcher Position mit welcher Signalstärke Pakete empfangen wurden (RSSI).

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Bevor ich mich damit beschäftige, mit dem LoRa/GPS Shield auch die GPS-Daten mitzusenden, möchte ich mit ttnmapper.org mal die GPS-Daten dazuschummeln. TTNmapper hat einen super Ansatz dafür gewählt: in der Annahme, dass ich mein Smartphone (Android) und meinen Sensor bei mir habe (mit mir herumtrage oder in meinem Fall beides mit dem selben Auto unterwegs ist), ergänzt TTNmapper mit einer eigenen App einfach die GPS-Position vom Smartphone. Clever!

Funktionsweise

Klarerweise muss ich auf meinem Android Smartphone die App aus dem Play Store installieren. Danach melde ich mich in der App mit meinen Login-Daten bei The Things Network an und wähle aus meinen Applikationen und Devices den Sensor aus, mit dem ich aktuell messen möchte. (Falls jemand seine Logindaten nicht bekanntgeben möchte, kann man auch direkt die Zugangsdaten für den MQTT-Zugang des Device eingeben, das ist natürlich viel umständlicher, aber man muss die Zugangsdaten nicht eingeben).

Ab sofort höre ich jedesmal, wenn ein Paket angekommen ist (die App erfährt das über MQTT wirklich sofort) einen Ton.

Also habe ich eine kleine Magnetfußantenne für 868 MHz neben meine APRS-Antenne auf’s Auto montiert und die App bei meiner heutigen Ausfahrt mitlaufen lassen. Die Stromversorgung über 12V Anschluss auf einen Verteiler mit USB-Hub war zum Glück für Amateurfunkzwecke schon vorhanden und musste ich nur mehr dazustecken.

Es hat super funktioniert! Beim Starten des Motors ist sofort das erste Klingeln am Smartphone hörbar gewesen.

Nach einer kurzen Ausfahrt hat sich folgendes Bild ergeben:

An die Farbgebung muss man sich noch gewöhnen, zum Glück ist eine Legende dabei. Die besten Signalstärken sind rot, die schlechtesten grün und türkis/blau.

Erfreulicher Weise hat mich auch der Gateway von Peter im 2. Bezirk ein paar Mal empfangen.

Zum Vergleich: links die heutige Route über APRS protokolliert und rechts die Punkte, an denen LoRa-Pakete angekommen sind:

Amateurfunk, Arduino, Code, Linux, LoRa, Raspberry Pi

LoRa TTN Gateway Pakete mit tcpdump mitprotokollieren

Kommentar hinterlassen

Über die Schnittstellen bei TTN (The Things Network) kann man eine Menge Daten auslesen – natürlich die Inhalte (Payload) der Applikationen und einige technische Werte.

Konkret interessiert mich zB. der RSSI (Eingangssignalstärke) der vom LoRa Gateway empfangenen Pakete. Im Webinterface kann man in der TTN Console im Bereich Gateway mitschauen und erhält hübsche JSON-Objekte, in denen alles enthalten ist. Ich habe aber keine Schnittstelle gefunden, mit der ich es auslesen kann – weder live noch nachträglich (als gespeicherte Werte).

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Nachdem ich mir das Protokoll schon angeschaut habe, war mir klar, dass es die Daten unverschlüsselt überträgt. Es nutzt übrigens UDP für die Kommunikation zu den TTN Network Servern auf Port 1700.

Also habe ich meiner /etc/rc.local (vor dem „exit 0“!) folgenden Eintrag hinzugefügt:

/usr/sbin/tcpdump -Aq port 1700 >> /var/log/ttn-tcpdump-gateway.asc &

Damit wird nach jedem Reboot in die Datei /var/log/ttn-tcpdump-gateway.asc per tcpdump in ASCII die Inhalte aller Verbindungen zu Port 1700 gespeichert:

Mich interessieren eigentlich nur Übertragungen und Statusmeldungen. In beiden kommt „rx“ vor:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx

Die Meldungen beginnen immer mit 41 Zeichen (Byte) Header, die kann man wegschneiden:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx | cut -c 41-

Wenn nach „rxpk“, der Meldung für ein empfangenes Paket suche, erhalte ich nur Meldungen, die der Gateway über LoRa empfangen hat:

cat /var/log/ttn-tcpdump-gateway.asc | grep rxpk | cut -c 41-

Hier hat man nun je Zeile ein JSON-Objekt mit sämtlichen Details zur Kommunikation:

{"rxpk":[{"tmst":4242060820,"time":"2017-04-15T14:55:05.977557Z","chan":1,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":-10.5,"rssi":-115,"size":24,"data":"QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"}]}

wird zB. mit http://jsonviewer.stack.hu/ zu

{
  "rxpk": [
    {
      "tmst": 4242060820,
      "time": "2017-04-15T14:55:05.977557Z",
      "chan": 1,
      "rfch": 1,
      "freq": 868.300000,
      "stat": 1,
      "modu": "LORA",
      "datr": "SF9BW125",
      "codr": "4/5",
      "lsnr": -10.5,
      "rssi": -115,
      "size": 24,
      "data": "QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"
    }
  ]
}
Amateurfunk, App, Arduino, Code, Linux, LoRa, Raspberry Pi, Unterwegs

LoRa Sensor mittels Arduino und LoRa Shield

16 Kommentare

Über einen Freund bin ich vor ein paar Wochen auf das Thema LoRa bzw. LoRaWAN aufmerksam geworden.

Vor allem seit ich The Things Network (https://www.thethingsnetwork.org) kenne und somit über die Community eine Möglichkeit besteht, die Technologie sinnvoll zu nutzen, bin ich interessiert mich damit mehr zu beschäftigen.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Ein LoRa Sensor ist ein Endgerät, das über das LoRa-Protokoll in ein Netzwerk Informationen funkt. Empfangen werden die Pakete üblicherweise von einem Gateway. Bis zur Auswertung der Pakete sind noch Network Server und Application Server nötig, die in meinem Fall über TTN (The Things Network) bereitgestellt werden.

Da ich auch mit Freunden einen Gateway bauen möchte, brauchen wir natürlich einen LoRa Sensor, um unseren Gateway zu testen. Als günstige Variante habe ich Arduino + LoRa Shield für Arduino gefunden.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt und auf Twitter (@TTN_Vienna) für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Zutaten

Falls jemand entspannt an das Projekt herangeht und mit 5-6 Wochen Lieferzeit aus Shenzhen (China) kein Problem hat, gibt es das LoRa Shield auch kostengünstiger (€ 18,70 am 1.4.2017) über Tindie zu kaufen. Hier beachtet bitte, dass Shipping (+ € 6,12 nach Österreich) und ggf. Zoll dazukommen.

Bitte beachtet bei Bestellungen immer, dass ihr die 868 MHz-Variante auswählt! Nur diese darf in der EU betrieben werden bzw. wird hier funktionieren!

Von der Vorgehensweise halte ich mich an diese Anleitungen:

  1. ein tolles Youtube-Video, das genau den hier beschriebenen Aufbau erklärt: LoRa Node with Arduino and Dragino Shield connected to TTN LoRaWAN von Andreas Spiess
  2. Software (Arduino Sketch) „Hello World“ von https://github.com/SensorsIot/LoRa
  3. LMIC library von IBM, angepasst für Arduino: wird vom Arduino Sketch benötigt

Vielen Dank an die Kollegen von TTN Zürich, die diese Anleitungen und Programme zur Verfügung stellen!

Zusammenbau

Das LoRa Shield muss nun nur mehr auf den Arduino gesteckt werden. Die Antenne wird an den SMA-Anschluss geschraubt.

Konfiguration

Nun lädt man den Arduino Sketch („Hello World“, siehe Link oben) ins Arduino IDE und muss ein paar Werte anpassen. Dazu erstellt man eine „Application“ in der Console von TTN und legt ein Gerät („Device“) an. Eine Over-The-Air-Activation (OTAA) ist nicht möglich, daher muss man manuell ABP wählen und die Werte vom Webinterface abschreiben. Diese werden von TTN automatisch generiert.

  1. NWKSKEY: der Network Session Key muss im korrekten Format in die geschwungenden Klammern { } eingefügt werden.
  2. APPSKEY: ebenso der Application Session Key und zum Schluss die
  3. DEVADDR, also die Geräteadresse im korrekten Format.

TTN bietet im Webinterface übrigens die Werte bereits im richtigen Format an. Im Zweifelsfall muss man auf „< >“ klicken, dann werden die Werte in anderen Formaten dargestellt und können mit copy & paste übernommen werden. Das gewünschte Format ist „msb“.

Ansonsten musste ich keine weiteren Änderungen am Code durchführen.

Trotzdem habe ich den zu übertragenden Text von „HI“ auf „stefan test“ geändert: dazu habe ich die Payload in der Variable „message[]“ in Zeile 57 angepasst:

  // Payload to send (uplink)
  static uint8_t message[] = "stefan test";

Nun habe ich den Sketch kompiliert und auf den Arduino übertragen. Unmittelbar darauf hat er begonnen, alle 20 Sekunden kurz zu blinken, wodurch ich mich bestätigt gefühlt habe, dass es funktioniert und nun alle 20 Sekunden die Meldung „stefan test“ mittels LoRa übertragen wird.

Überprüfen am Gateway

Einen Gateway hatten wir parat und er hat sofort die Pakete empfangen. Über die „Traffic“ Funktion in der TTN Console kann man die ankommenden Pakete gleich sehen.

Man sieht hier mehrere Pakete, die im Abstand von ca. 25 Sekunden ankommen. Die Frequenz wechselt bei jedem Paket, weil mehrere Kanäle genutzt werden: 868,1 – 868,5 – 868,3 usw.

Folgendes JSON Objekt mit allen Details erhält man aus der TTN Console beim Gateway Traffic:

{
  "gw_id": "eui-b827ebfffe6f377d",
  "payload": "QI4cASaAaAABhVJosx+GBwUwHBqp4DGG",
  "f_cnt": 104,
  "lora": {
    "spreading_factor": 9,
    "bandwidth": 125,
    "air_time": 205824000
  },
  "coding_rate": "4/5",
  "timestamp": "2017-03-29T05:57:06.352Z",
  "rssi": -25,
  "snr": 11.2,
  "dev_addr": "26011C8E",
  "frequency": 868100000
}

Es enthält sämtliche Details zur Übertragung. Ein paar Werte möchte ich kurz hervorheben:

  • gw_id: zeigt die ID des Gateways, der das Paket empfangen hat
  • payload: sind die übertragenen Daten in verschlüsselter Form
  • f_cnt: ist der Counter und gibt die Anzahl der Pakete wider
  • lora.spreading_factor: zeigt hier den Spreading Factor 9, der im Sketch eingestellt ist
  • rssi: zeigt die Signalstärke des empfangenen Pakets am Gateway an (hier: -25 dbm)
  • snr: das Signal/Rausch-Verhältnis
  • dev_addr: die Geräteadresse, die von TTN vergeben wurde und ich als DEVADDR im Sketch hinterlegt habe.
  • frequency gibt die Frequenz in Hertz an

Wir sehen, dass das Paket einwandfrei übertragen wurde und sogar sehr gut (-25 dbm) empfangen wurde. Bei diesem Test war der Abstand vom Sensor zum Gateway aber auch im Bereich von 5 Metern.

Optimierungen

Als Spreading Factor ist 9 eingestellt. Um die Reichweite zu erhöhen, kann man auch zB. SF12 einstellen. Das geht im Arduino Sketch auf Zeile 90:

  // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
  LMIC_setDrTxpow(DR_SF9, 14);

Falls man die Pakete weniger oft übertragen möchte (alle 20 Sekunden ist zum Testen super, aber dauerhaft verbraucht es zu viel Airtime), kann das in Zeile 39 anpassen:

// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 20;