Drüben bei ISM-to-MQTT relay with RTL-SDR USB-Stick haben wir ein paar Schnipsel, wie sich mit Hilfe von GitHub - merbanan/rtl_433: Program to decode radio transmissions from devices on the ISM bands (and other frequencies) Wetterstationsdaten empfangen und nach MQTT konvergieren lassen.
Hier wiederum schauen wir, ob und wie so etwas auch mit “einer Geräteklasse kleiner” funktionieren kann. Die Idee ist, einen möglichen
@Andreas erzählte neulich noch von einem Repo, das @einsiedlerkrebs ausgegraben hatte. Es soll Funk von ner Wetterstation mit einem ESP32 und RFMxx einfangen und (per MQTT?) ins Netz weiterleiten können.
Ja, aber da haben wir auch noch nix handfestes für das Modul hier mit dem ESP32S3. Müsste man mal…
Hatte mit @Andreas am Telefon kurz darüber gequatscht, dann war meine Vorstellung weiter als die Realität, hab’s wohl falsch verstanden, dachte da gibt es irgendwo schon eine code base, wenn auch beta …
Es gibt GitHub - matthias-bs/BresserWeatherSensorReceiver: Bresser 5-in-1/6-in-1/7-in-1 868 MHz Weather Sensor Radio Receiver for Arduino based on CC1101 or SX1276/RFM95W und das sieht aus, als könnte es tun, nur leider nicht mit dem Heltec ESP32 Lora v3. Für den haben wir noch nix handfestes und ich bin mir nicht klar, ob ich lieber versuchen den mit Terkin zu betreiben um in der python domäne zu bleiben oder eben auf das Arduino repo zu gehen und dir platform da rein zu patchen. Könnte mir vorstellen, das es auf so einem TTGO ESP32 Lora eumel out of the box ins MQTT schreibt.
Etwas recht Ähnliches, allerdings mit reiferer library-Basis ist der Folgende. Hier hat jemand ausgewählte Betriebsarten und Protokolle der rtl_433 -lib genommen und sie auf eine kleinere Platform (ESP32 u. SX127x(RFM9x) bzw. CC1101) anstelle RTL2832-USB-Stick als HF-Basis portiert:
edit: das von @einsiedlerkrebs zitierte Projekt GitHub - matthias-bs/BresserWeatherSensorReceiver: Bresser 5-in-1/6-in-1/7-in-1 868 MHz Weather Sensor Radio Receiver for Arduino based on CC1101 or SX1276/RFM95W nutzt auch Teile der rtl_433-lib.
OpenMQTTGateway könnte noch von Interesse sein:
Braucht z.B. ein Heltec LoRa 433 Board als MQTT Gateway.
Website: https://docs.openmqttgateway.com/
Code: https://github.com/1technophile/OpenMQTTGateway
Das Ding unterstützt wohl auch 868 MHz und @einsiedlerkrebs hier taucht auch dein Heltec ESP32 Lora auf, Version ist allerdings unklar:
OpenMQTTGateway schaut sehr erwachsen aus, nutzt die von @weef gezeigte kanonische Bibliothek NorthernMan54/rtl_433_ESP, hat eine PlatformIO-Konfiguration schon mit dabei, und scheint eindeutig produktreif. Vielen Dank!
… nutzt die von @weef gezeigte kanonische Bibliothek von Northern Man.
Der Autor trägt dort auch persönlich bei, siehe Commits · 1technophile/OpenMQTTGateway · GitHub.
Das hier sind unsere Neuigkeiten zum Thema. Leider scheint der Heltec WiFi LoRa 32 v3 ungeeignet:
^^ Unabhängig davon…
… konnten wir aber in diesem Repository keine Dekodierungsroutinen für die Bresser Stationen finden, bzw. Ansätze, diese aus der rtl_433_ESP Bibliothek zu nutzen. OpenMQTTGateway scheint also wirklich ausschließlich eine Any-to-Any Funkgateway-Lösung zu sein, ohne dass es sich um weitere Details wie die Dekodierung der Daten kümmert? Eigentlich kaum vorstellbar…
Vielleicht ergeben sich hier gegensätzliche positivere Sichtweisen, aber bis dahin haben wir erstmal wieder mit BresserWeatherSensorReceiver weitergemacht, und zwar mit einem Pycom LoPy 1 aus dem Fundus von @einsiedlerkrebs, der einen SX1272 an Bord hat.
Hier war die Hauptg’schicht, dass der LoRa Chip des LoPy nicht am (aus Arduino Sicht) “Standard” SPI Port des ESP32 angeschlossen ist, so dass es die Möglichkeit geben muss, das entsprechende Busadapter Objekt des HAL, meist "SPI" genannt, passend zu konfigurieren und MISO MOSI CLK frei zu belegen. Das sah die dort verwendete Bibliothek RadioLib: Universal wireless communication library for Arduino leider out-of-the-box nicht vor.
Generell wollten wir mit PlatformIO arbeiten und haben daher ein separates Repository bresser-to-mqtt aufgemacht. Dort finden sich auch die aktuellen Ergebnisse der Arbeiten rund um den LoPy [2].
Heltec WiFi LoRa 32 v3 (HTIT-WB32LAF) ↩︎
Add initial support for Pycom LoPy (v1) by amotl · Pull Request #4 · daq-tools/bresser-to-mqtt · GitHub ↩︎
Ich glaube es war jene Stelle:
Weitere Details, welche Werte belegt werden müssen, kann @einsiedlerkrebs vielleicht noch nachträglich beitragen. Ich glaube sie stammen aus dem entsprechenden Pinbelegungsplan lopy-pinout.png.
RTL_433_ESP ist (bislang) für SX127x und CC1101, leider nicht für SX126x, daher bis auf Weiteres nicht für den Heltec WiFi LoRa 32 v3 (HTIT-WB32LAF).
Außerdem: die erwähnte Bresser-Station moduliert nicht in OOK/ASK, sondern FSK. RTL_433_ESP beherrscht OOK (also ASK), die Versuche des Autors mit FSK sind inzwischen zwei Jahre alt und wurden v.a. eingestellt, weil ihm kein Gerät mit FSK zum Testen zur Verfügung steht.
Dennoch enthält das letzte tag release v0.2.0 (gerade ein paar Tage alt) wieder den FSK-Modus (noch mehr oder weniger undokumentiert):
- Includes FSK decoders as an undocumented feature, as the receiver modules need tuning for FSK modulation, and testing.
Die OpenMQTTGateway-community wird sicher drängeln, daher wird aus rtl_433_ESP die FSK-Betriebsart bestimmt auch nicht mehr verschwinden.
Das hilft @einsiedlerkrebs beim HTIT-WB32LAF leider noch nicht, auch wenn mit FSK eine wichtige Voraussetzung erfüllt wäre.
Das verstehe ich nicht, denn es ist doch kein ESP32-S3 (da wäre es erklärlich), sondern ein ‘alter’ ESP32-D0 ?! das war Unsinn von mir; ich wollte schreiben:
“frei zu konfigurieren” verstehe ich nicht.
MOSI, MISO und SCLK sind intern fest verdrahtet (stellen den Kern des SPI peripheral dar), die müssen halt nur dem SX1272 im LoPy 1 entsprechend definiert und nicht mehr überschrieben werden. SS (oder CS), “LoRa IRQ” und “LoRa Reset” sind auch nicht frei, da auch mit dem SX1272-Modul verbunden.
Vielen Dank für die Recherchen und die Bestätigung, dass diese Betriebsart mit dem Heltec WiFi LoRa 32 v3 (HTIT-WB32LAF) derzeit nicht möglich ist, und dass es am SX126x liegt.
Wir könnten das ja per Software mglw. auch wieder zurückmappen, auch an RadioLib vorbei. @einsiedlerkrebs: Eigentlich sollte es reichen, die jeweiligen HAL Definitionen im Programmcode zu überschreiben, wenn das tatsächlich falsch in der Boarddefinition für das lopy Modell steht. Danke, @weef.
Zum Vergleich die Softwarebelegung beim LoPy4:
Was mich stutzig macht, ist, dass bei beiden “SX1276” dran steht. Wir dachten, der LoPy1 hätte einen SX1272 an Bord [1]. Mglw. ist es nur ein Tippfehler?
Scheint aber zu stimmen!? Warum geht das denn dann in der Praxis aufs falsche Kabel?
Das LoPy1 Specsheet [1] sagt das gleiche. Es haut also hin, was da in dem Arduino Header File steht [2] – bis auf den Schreibfehler bzgl. SX1276.
GPIO5 - SX1272 SCLK
GPIO27 - SX1272 MOSI
GPIO19 - SX1272 MISO
GPIO18 - SX1272 Reset
GPIO23 - SX1272 INT
GPIO17 - SX1272 CS
Als wir dran waren, haben wir gar nicht an die Boarddefinition gedacht, sondern hatten vor allem die Bibliotheken vor Augen. Und daher haben wir dann eben den Eingriff dort in RadioLib gemacht, und _spi->begin(li, la, lu); hingeschrieben, statt den Initialisierer, wie an dieser Stelle zu sehen, “leer” zu lassen.
Bleibt die Frage:
… also wer oder was definiert sonst irgendwo was um?
Danke Dir vielmals! Ich glaube wir müssen erst sehen, was @einsiedlerkrebs in den Initializer bei spi->begin(li, la, lu) de facto reingeschrieben hat, bevor wir weiter mutmaßen können, wie wo was falsch sein könnte. Vielleicht tut er uns auch nochmal die originale Fehlermeldung dazu. Das hilft auch ein wenig weiter, wenn man nur von der Ferne auf den Code schaut.
667c671
- _spi->begin();
---
+ _spi->begin(5, 19, 27);
Ich finde gerade nicht die Spur warum ich die dort eintrug.