Kategoriearchiv: Code

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?

Allgemein, Code, Firewall, Linux

qemu-guest-agent für pfSense (ab Version 2.6.0) und pfSense+

Kommentar hinterlassen

Ich betreibe eine pfSense-Firewall, hinter der meine Services betrieben werden, die ich für meine Hobbies benötige. Die pfSense wickelt auch andere nützliche Dienste, wie SSL Offloading inkl. ACME-Client für automatischen Zertifikatstausch bei Let’s Encrypt ab oder Loadbalancing für zB. meinen RabbitMQ-Cluster.

Die pfSense läuft als Virtuelle Maschine (VM) auf einem Proxmox Host. Bisher war leider keine ordentliche Implementierung des qemu-guest-agent verfügbar, mit dem einige Management-Funktionen der virtuellen Umgebung auch für die PFsense nutzbar sind.

Seit Version 2.6.0 ist nun ein Paket verfügbar, das sich – zwar nicht über das Webinterface alleine – aber immerhin „ordentlich“ (in meiner Definition) installieren und betreiben lässt, sehr gut funktioniert und mit sinnvollem Aufwand zu installieren ist.

Mehr Infos zum qemu-guest-agent gibt es ua. hier:

Meine Anleitung stützt sich – neben meinen Erkenntnissen – auf diese Artikel:

Schritt für Schritt durch die Installation

1) öffne die Console und gib folgendes Kommando für die Installation ein:

pkg install qemu-guest-agent

2) man benötigt das Paket „Shellcmd“, um beim Booten den automatischen Start des qemu-guest-agent einzurichten. Die Installation erfolgt über das Webinterface:
2a) unter System / Paketverwaltung das Paket „Shellcmd“ installieren.
2b) nun ist unter Dienste / Shellcmd möglich, dieses Kommando hinzuzufügen, das ab sofort bei jedem Reboot den Dienst startet:

service qemu-guest-agent start

3) in der Datei /etc/rc.local (in manchen Anleitungen steht /etc/rc.conf.local, für pfSense+ ist es /etc/rc.conf) muss man nun folgende Zeilen einfügen:

qemu_guest_agent_enable="YES"
qemu_guest_agent_flags="-d -v -l /var/log/qemu-ga.log"

Damit ist die Installation abgeschlossen! Nach einem Reboot sollte der Dienst starten bzw. laufen und scheint bei mir in der Proxmox-Umgebung auch sofort auf.

4) als letzter Schritt wird empfohlen, in den Erweiterte Einstellungen / System Feinabstimmung („Tunables“) folgenden Eintrag hinzuzufügen:

  • Abstimmungsname: virtio_console_load
  • Wert: YES

Hinweis zu Fehlermeldung

Sollte (ist bei pfSense+ aufgetreten) in der Logdatei qemu-ag.log folgendes zu finden sein, dann ist der Qemu-Guest-Agent bei er VM noch nicht aktiv:

1680079085.256215: debug: disabling command: guest-fstrim
1680079085.256276: critical: error opening channel: No such file or directory
1680079085.256287: critical: error opening channel
1680079085.256293: critical: failed to create guest agent channel
1680079085.256300: critical: failed to initialize guest agent channel

Vielen Dank an Alexander Grümmer für die Ergänzungen, die er mir im März 2023 für pfSense+ geschickt hat, nachdem dort kleinere Anpassungen notwendig waren.

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)

Allgemein, App, Code, fhem, Hausautomatisierung, Linux, Smartphone, WLAN

IoT und Hausautomatisierung mit Sonoff

2 Kommentare

Vor einigen Monaten bin ich von einem Freund auf die Produkte von Sonoff aufmerksam geworden. Die Geräte von Sonoff sind sehr preiswert und ermöglichen das Schalten von Verbrauchern, Auslesen von Sensorwerten und Messwerten.

Das Besondere dabei: die Geräte nutzen WLAN für die Kommunikation. Dafür wird der ESP8266 Chip verwendet, den viele schon aus der IoT („Internet of Things“)-Welt kennen. Es gibt neben der Sonoff-Software auch alternative Open Source-Projekte, mit denen die Geräte unabhängig von der „Sonoff-Cloud“ betrieben werden können. Beispielsweise verwende ich die TASMOTA-Software, um meine Sensoren und Aktoren von Sonoff mit FHEM zu nutzen. Der Austausch der Informationen funktioniert dabei mittels MQTT, wodurch man sehr flexibel ist – auch bei der Integration mit anderen Systemen.

Kurzer Überblick

Die Sonoff-Produkte senden ihre Daten entweder über ein eigenes Protokoll im 433-MHz-Bereich oder über WLAN. Ich konzentriere mich hier auf die WLAN-Nutzung, da sich damit für mich mehr Anwendungen realisieren lassen.

Schalter

Zum Schalten von 230 Volt-Endgeräten gibt es mehrere Möglichkeiten:

Schalter mit Messfunktion

Diese Produkte ermöglichen das Schalten abhängig von Temperatur und Luftfeuchtewerten bzw. melden den Energieverbrauch.

Für die Nutzung der Temperatur- & Luftfeuchtemessung gibt es drei Sensoren, die an den TH10 oder TH16 angeschlossen werden:

  • DS18B20: Außensensor aus rostfreiem Stahl
  • AM2301: Innensensor mit Temperatur- & Luftfreuchtesensor
  • Si7021: Innensensor mit hochpräzisem Temperatur- & Luftfreuchtesensor

Touch

Mit diesen kapazitativen Schaltern kann man Kommandos an die Haussteuerung senden oder Schalter bedienen.

Es gibt noch etliche weitere Produkte von Sonoff. Stöbert doch einfach mal! Beim Kauf empfehle ich darauf zu achten, ob das Teil über WLAN oder 433 MHz zu betreiben ist, damit alle Produkte zueinander kompatibel sind.

Software / Firmware

Falls ihr die Geräte werden nach dem Kauf mit der Original-Software betreiben möchtet, gibt es eine entsprechende Smartphone-App für die Konfiguration. Die Daten landen in der Sonoff-Cloud und können dort mit Diensten wie zB. Alexa oder IFTTT verknüpft werden. Natürlich ist man hier von der Cloud abhängig.

Als Alternative kann ich die Software TASMOTA empfehlen. Man muss zwar einmalig jedes Gerät mit TASMOTA flashen (ein TTL-Konverter mit 3,3V wird benötigt), ist dann jedoch unabhängiger. Man kann Schaltbefehle über ein Webinterface steuern oder das Gerät per MQTT an eine Haussteuerung oä. anbinden. Für diese Variante hat man zwar ein bißerl mehr Aufwand, ist aber unabhängiger.

Details zu TASMOTA und dem Flashen dieser Firmware gibt es hier:
https://github.com/arendst/Sonoff-Tasmota/wiki

Allgemein, Amateurfunk, APRS, Code, Linux, LoRa, Raspberry Pi, WLAN

LoRa APRS Gateway mit Raspberry Pi Zero W

3 Kommentare

In einem anderen Beitrag habe ich darüber berichtet, dass wir erfolgreich über LoRa-Modulation APRS-Pakete gesendet haben und wie ein APRS-Tracker mit Arduino zu bauen und programmieren ist.

Nun habe ich von Sascha (www.iot4pi.com) ein fertiges, von ihm konstruiertes Board, für einen LoRa APRS Gateway bekommen. Wie er diese Boards erstellt und zusammenbaut, hat er übrigens auf seiner Seite näher beschrieben:
www.iot4pi.com/de/bau-des-lora-gateway-shield

Die Software, das Image für die SD-Karte (ich habe ein 8 GB-Karte zur Hand), findet ihr hier zum Download:
www.iot4pi.com/de/raspberry-pi-projekte-software/lora-aprs-gateway

Nachdem man die SD-Karte in den Raspberry gesteckt und das Gehäuse mit dem Raspberry darin geschlossen ist, bootet man den Raspberry zum ersten Mal.

Ich habe in der /etc/network/interfaces sofort eine statische IP-Adresse eingetragen.

Die Konfiguration des Gateways fwird in der Datei /home/pi/iot4pi/APRS.conf vorgenommen. Im Wesentlichen muss man nur folgende Zeilen anpassen:

APRS_IS_CALL:OE1SCS-10
APRS_IS_PASSCODE:12345
LATITUDE:4811.48N
LONGITUDE:01623.23E

Wichtig ist auch, dass man zur Netzwerkanbindung das WLAN am Raspberry Zero W konfigurieren muss. Dazu tragt man in der Datei /etc/wpa_supplicant/wpa_supplicant.conf folgende Zeilen ein:

country=AT
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
    ssid="meinwlan"
    psk="meinpasswort"
}

Da der Gateway nicht für den Außeneinsatz geeignet ist, habe ich mir eine kleine flache Fensterdurchführung zugelegt, mit der ich die Antennenleitung ans Fensterbrett bekomme und dort mit einer 70cm-Magnetfußantenne für 433 MHz verbinde.

Einkaufsliste LoRa APRS Gateway auf Raspberry Pi Zero W

Optional, für den Anschluss an einen Monitor:

Allgemein, Code, Linux

WordPress Updates über Kommandozeile

Kommentar hinterlassen

Mittlerweile nutze ich für mehrere Projekte WordPress. Ich bin recht zufrieden, die Blogs laufen teilweise schon fast 3 Jahre und ich habe kaum Probleme.

Leider laufe ich immer wieder in Probleme beim Update über das Webinterface. Eine Alternative scheint zu sein, Updates per Kommandozeile auszuführen. Dazu gibt es das Werkzeug „wp-cli“, das ich hier kurz vorstellen möchte.

Installation von wp-cli

Das Werkzeug wird von dieser Adresse gedownloadet und getestet: https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
$ php wp-cli.phar --info

Wenn alles OK ist, installiere ich es als /bin/wp und setze das Execute-Bit:

$ chmod +x wp-cli.phar
$ sudo mv wp-cli.phar /bin/wp

Nun kann ich es systemweit als „wp“ aufrufen. Für Aktionen sollte es als User laufen, mit dem auch WordPress betrieben wird. Dazu starte ich es über sudo und mit Hinweis auf den Installationspfad der WordPress-Dateien:

root@wp:~# sudo -u wp -i wp --path=/var/www/html --info
PHP binary: /usr/bin/php5
PHP version: 5.5.9-1ubuntu4.22
php.ini used: /etc/php5/cli/php.ini
WP-CLI root dir: phar://wp-cli.phar
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /home/wp
WP-CLI packages dir: 
WP-CLI global config: 
WP-CLI project config: 
WP-CLI version: 1.4.1

Updates

Updates spiele ich nun mit Hilfe von wp-cli ein. Damit lassen sich auch mehrere Updates über mehrere Installationen automatisieren. Mit dem Suffix „–all“ muss man nicht einzeln die Plugins anführen, sondern kann alle Plugins in einem Durchgang aktualisieren.

Plugins kann man mit diesem Kommando auf einmal updaten:

sudo -u wp -i wp --path=/var/www/html plugin update --all

Themes werden auf diesem Weg alle aktualisiert:

sudo -u wp -i wp --path=/var/www/html theme update --all

Und die Core Version von WordPress wird mit diesem Kommando auf den neuesten Stand gehoben:

sudo -u wp -i wp --path=/var/www/html core update

 

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, Code, Linux, LoRa, Raspberry Pi

günstiger 1ch LoRa Gateway: RFM95W direkt zu Raspberry verkabelt

3 Kommentare

Obwohl ich der Meinung bin, dass vollwerte LoRaWAN-kompatible Gateway wirklich Sinn ergeben, beschäftige ich auch mit den preiswerten Single Channel (1ch) Gateways. Für Entwicklungen zu Hause ist das ja eine günstige Option.

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!

Hier habe ich eine Anleitung gefunden, mit der tatsächlich um € 13,90 für das LoRa-Modul ein Raspberry Pi supereinfach zu so einem 1ch-Gateway wird: https://www.hackster.io/ChrisSamuelson/lora-raspberry-pi-single-channel-gateway-cheap-d57d36

Achtung, die Anleitung im Link oben empiehlt die Änderung zur amerikanischen Frequenz (902,3 MHz). In Europa bleiben wir bei 868,1 MHz! (Das ist eh der Standardwert) In meiner Anleitung ist auch die IP-Adresse der europäischen Server von TTN enthalten.Die Schritte sind recht einfach:

  • Man bestellt das LoRa RFM95W-868S2 Transceiver Modul.
  • man teilt 4 Jumper Wire Kabel in der Hälfte, sodass auf einer Seite eine Buchse (female) und auf der anderen Seite der blanke Draht ist.  7 davon lötet man an diese Position am Transceiver Modul: DI00, 3.3V, MISO, MOSI, SCK, RESET, NSS und GND (neben MISO)
  • Als Antenne verwenden wir hier zwei Drähte, die 83mm Länge haben und an die Positionen ANA und GND (neben ANA!) gelötet werden. Als Draht wird ein 18ga empfohlen, das ist in unseren Breiten ein 1mm Drahtstück.
  • Nun verbindet man diese mit den PINs am Raspberry GPIO:
    3.3V -> PIN1, GND -> PIN6, DI00 -> PIN7, RESET -> PIN11, NSS -> PIN22, MOSI -> PIN19, MISO -> PIN21 und SCK -> PIN23
  • jetzt kann auch schon die Software installiert werden. Es wird git, wiringpi und der Code für den Single Channel Gateway benötigt:
sudo apt install git wiringpi
git clone https://github.com/tftelkamp/single_chan_pkt_fwd
  • im raspi-config-Tool muss nun die SPI-Schnittstelle aktiviert werden (im Menü „Interfacing Options“ -> „SPI“:
sudo raspi-config
  • nach einem Reboot (wird von raspi-config vorgeschlagen) konfiguriert man die Einstellungen in der main.cpp des single_chan_pkt_fwd Codes:
// Set location
float lat=48.1906;
float lon=16.3867;
int alt=200;

/* Informal status fields */
static char platform[24] = "1ch Gateway";
static char email[40] = "meine@email.adresse";
static char description[64] = "RFM95W directly wired";

// define servers
#define SERVER1 "52.169.76.203"
  • Der Code kann nun mit make compiled werden:
make
  • Nun können wir den Gateway das erste Mal starten:
./single_chan_pkt_fwd
  • Die EUI, die hier gezeigt wird, müssen wir nun bei der Console von TheThingsNetwork als EUI eines neuen Gateways eintragen. Dieser wird sofort angezeigt und übermittelt auch auf Anhieb die Daten, die er empfangen hat.

Ich lege mir meist noch ein Startkommando zurecht, bei dem ich auch den Output in die Datei /var/log/ttn-single-chan-pkt-fwd.log schreibe. Dazu füge ich in der /etc/rc.local folgendes hinzu (am Ende, aber vor dem „exit 0“):

/home/stefan/single_chan_pkt_fwd/single_chan_pkt_fwd >> /var/log/ttn-single-chan-pkt-fwd.log 2>&1

Nach einem Reboot wird so die Software automatisch ausgeführt und ein Logfile angelegt.

Amateurfunk, Code, Linux, LoRa, Raspberry Pi

GPS am Dragino LoRA HAT

2 Kommentare

Mit dem Dragino LoRa GPS HAT auf meinem Raspberry Pi 2 betreibe ich einen Single Channel Gateway, wie in meinem anderen Beitrag beschrieben.

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!

Nun möchte ich auch die GPS-Funktion ausprobieren! Vielleicht kann ich es zur Zeitsynchronisierung nutzen? Naja, vielleicht im Vergleich zu NTP für meine Anforderungen etwas viel Aufwand. Aber schauen wir mal…

Als Antenne verwende ich eine Magnetantenne (für zB. Autos) mit 3m Kabel.

Die serielle Schnittstelle ist am Raspberry mit der Console belegt und muss erst freigegeben werden, bevor wir GPS-Daten empfangen können:

In der Datei /boot/cmdline.txt entfernen wir den Eintrag für

console=/dev/ttyAMA0

Danach beenden und deaktivieren wir das Service für die serielle Ausgabe:

# systemctl stop serial-getty@ttyAMA0.service
# systemctl disable serial-getty@ttyAMA0.service

Nun installieren wir gpsd & Co:

# apt-get install gpsd gpsd-clients python-gps

Folgende Zeilen bleiben in meiner /etc/default/gpsd als Konfiguration:

START_DAEMON="true"
USBAUTO="true"
DEVICES=""
GPSD_OPTIONS="/dev/ttyAMA0"
GPSD_SOCKET="/var/run/gpsd.sock"

Nach einem Reboot kann ich cgps aufrufen:

An diesen Anleitungen habe ich mich orientiert:
für Raspberry Pi 2
für Raspberry Pi 3 funktioniert es ein bißerl anders.