Forum: HF, Funk und Felder LoRA, Meshtastic, TTN, Helium?

Hallo Frank,
auch wenn deine Frage schon wieder eine Weile her ist, finde ich das 
Thema auch sehr spannend. Hatte mich ja vor einiger Zeit auch schon 
damit beschäftigt: Beitrag "Re: Was brauche ich für LoRaWAN?"

Nach den ersten Experimenten den Finestra Miner als TTN Gateway zu 
benutzen (siehe verlintker Thread) lag das Ding dann doch nur rum, 
weshalb ich jetzt mal versucht habe den im Originalzustand als Helium 
IOT Miner in Betrieb zu nehmen.
War jedenfalls ein ziemlicher Krampf, bis die Registrierung erfolgreich 
geklappt hat, aber das ist eine andere Geschichte...
Theoretisch sollte er jetzt aktiv sein, aber irgendwelche Ereignisse 
konnte ich noch keine sehen im Log.

Das wirft bei mir die Frage auf, was an diesem ganzen LoRa-Thema dran 
ist und schlägt damit die Brücke zu deinem Thread-Titel.
Hat jemand hier eine gute Übersicht, was in diesem (für mich irgendwie 
sehr) undurchsichtigen LoRa(WAN)-Feld tatsächlich geht?

- Wie verbreitet ist das TTN, bzw. wird das aktiv genutzt? Zumindest 
kann man da ja auf der Coverage Map was sehen: 
https://ttnmapper.org/heatmap/
- Helium: Nutzt das wirklich jemand, oder funktioniert das nur weil sich 
die ganzen Hotspots gegenseitig selbst bestätigen um Cryptowährung zu 
minen?
Auch hier ist theoretisch einiges los, aber was gibt es reale 
Nutzer?https://explorer.helium.com/
- Meshtastic höre ich heute zum ersten Mal. Hat anscheinend auch die 
schlechteste Abdeckung: https://meshmap.net/ - Weiß hier jemand mehr?

Sind das alles nur "Hobby"-Themen, von Leuten die Mitmachen, weil sie es 
spannend finden oder werden diese Netze auch wirklich genutzt?
Also z.B. auch von kommerziellen Anbietern oder machen die alle lieber 
ihr eigenes Ding, wo sie dann auch die Gateways teuer verkaufen können?

Für eine Empfehlung hinsichtlich des vielversprechendsten Netzes 
und/oder einen Überblick über die Lage an dieser nebulösen LoRaWAN-Front 
wäre ich auch sehr dankbar.

Nachtrag,
Habe hier folgenden Kommentar gefunden, der mein Bauchgefühl 
widerspiegelt:
https://www.reddit.com/r/LoRaWAN/comments/xhopj1/is_public_lorawan_ttn_dead_in_the_us/

LoRaWAN TTN is also pretty much useless in Europe. Coverage is bad, 
network is unreliable, the community is not helpful. The mapping of the 
network is done by an enthusiast who is begging for money. Utterly 
unprofessional.

I went from custom protocol + gateway design to TTN LoRaWAN, just for a 
test and it is useless. The whole chain is bad. The integrations are a 
bunch of one man band companies fighting for breadcrumbs, the mapper I 
already mentioned the coverage is atrocious and the firmware 
implementation ruins the devices low power performance. The TTN LoRaWAN 
network utterly failed in my eyes.

Too bad, but yet again it has been shown, that engineers are for 
engineering, leave the rest to other domains, and since TTN LoRaWAN is 
badly managed, it will ultimately pay with its demise.

And then there is the Ponzi scheme called Helium. I hope those guys 
choke on that stolen money.

EDIT: another thing, there is no real option as of now, other than 
implementing your own network. The drawbacks are of course the extra 
hassle and you will have to manage also your own internet connection. 
And pay for it. NB-iot is not so low cost, not that low power and the 
sim alone will cost you . LoRaWAN was a bright star that faded. To bad, 
had Great hopes for it.

Es gibt da ein paar Dinge, die zu klären sind.
LoRa ist erstmal nur eine Übertragungstechnik, nun kann man darauf ein 
Netzwerk (z.B. LoRaWAN) aufsetzen, das diverse Vorteile bietet, aber 
eben auch gewissen Einschränkungen unterworfen ist.
Hier in Europa hast du zunächst das "Problem," dass im 868-MHz-Band 
gesendet wird, wo du Einschränkungen hinsichtlich der Übertragungsdauer 
ausgesetzt bist. Echtzeit-SSH-Sitzungen empfehle ich daher nicht.

Wichtig bei der Entscheidung für eine Technologie ist die Frage, was du 
eigentlich damit machen willst. Willst Du weitere Sensoren installieren 
oder ist das lediglich als Punkt-zu-Punkt-Verbindung gedacht? Wie weit 
ist dein Raspi weg, auf welchen Spreading Factor musst du für eine 
zuverlässige Verbindung gehen? Willst du ggf. deine Infrastruktur 
anderen zur Verfügung stellen oder ist dir das egal? Wieviele Daten 
sollen überhaupt übertragen werden und wie oft?

Eine LoRa (ohne WAN)-Punkt-zu-Punkt-Verbindung eignet sich, wenn
- Du keine weiteren Sensoren/Knoten installieren willst
- Relativ viele Daten übertragen werden müssen, d.h. du hinsichtlich der 
Kanalbelegungsdauer nahe an die gesetzlichen Grenzen kommst
- Du Deine Infrastruktur nicht Anderen zur Verfügung stellen willst
- Du Kostengünstige Hardware verwenden willst, es reichen "einfache" 
LoRa-Funkmodule

Ein eigenes LoRaWAN (z.B. mit Chirpstack) eignet sich, wenn
- Du ggf. weitere Sensoren/Knoten installieren willst, aber alle im 
Umkreis deiner Basisstation
- Relativ viele Daten übertragen werden müssen, d.h. du hinsichtlich der 
Kanalbelegungsdauer nahe an die gesetzlichen Grenzen kommst. Beachte 
allerdings, dass der Uplink der Basisstation alle Knoten versorgen muss, 
daher ist es immer geschickt, möglichst wenige Nachrichten an die Knoten 
zu schicken
- Du Deine Infrastruktur nicht Anderen zur Verfügung stellen willst
- Du Bereits einen LoRaWAN-Konzentrator hast (ein einfaches 
LoRa-Funkmodul reicht für die Basisstation NICHT).
- Du Bereits fertige Integrationen nutzen willst (MQTT, etc.)

Ein Community-LoRaWAN (eigentlich gibt's da nur TTN) eignet sich, wenn
- Du ggf. weitere Sensoren/Knoten installieren willst, teilweise auch 
nicht mehr im Umkreis deiner Basisstation (aber in Reichweite anderer 
TTN-Basisstationen)
- Wenige Daten übertragen werden müssen (TTN hat eine Fair-use-policy, 
die die Datenmenge begrenzt. Das reicht oftmals aus, sollte aber 
beachtet werden. Verständlich, da ja alle das Netzwerk nutzen wollen)
- Du Deine Infrastruktur Anderen zur Verfügung stellen willst
- Du Bereits einen LoRaWAN-Konzentrator hast (ein einfaches 
LoRa-Funkmodul reicht für die Basisstation NICHT). Wenn Du ein 
"Single-Channel-Gateway" betreibst, bitte sei so gut und integriere es 
nicht in TTN. Single-Channel-Gateways sind keine gültigen 
LoRaWAN-Basisstationen, deren Betrieb sorgt leider hauptsächlich dafür, 
dass bereits existierende Knoten in der Umgebung nicht mehr richtig 
funktionieren.
- Du Bereits fertige Integrationen nutzen willst (MQTT, etc.)
- Du Dich nicht um Konfiguration und Einrichtung kümmern willst, das 
macht alles TTN.

Helium eignet sich generell nicht, das ist ein Krypto-Scam ohne 
Zuverlässigkeit, der mangels Wissen seitens der Betreiber der 
Basisstationen auch oftmals in gesetzlich nicht mehr zulässigen 
Bereichen betrieben wird. Sobald es sich nicht mehr lohnt, bricht das 
Netz zusammen. Finger weg.


Ich betrieb lange mehrere TTN-Basisstationen, jetzt ist es wegen Wegfall 
eines Aufstellungsortes leider nur noch eine.
Da kommt schon einiges zusammen, daher ist es verständlich, dass TTN die 
Datenmenge begrenzt. Für die meisten Anwendungen reicht es aber wirklich 
auch.
Es ist ein cooles Projekt, das aber leider durch Helium ziemlich gestört 
wurde: Anstatt idealistisch ein Netzwerk aufzubauen, das von der 
Community für die Community existiert, haben sich die Leute auf 
irgendeinen Kryptowährungs-Scheiß gestürzt und unter anderem Gateways 
auch sehr teuer gemacht. TTN ist, nunja, mal so, mal so. Teilweise ist 
die Netzabdeckung ganz brauchbar, teilweise überhaupt nicht vorhanden. 
So ist das eben bei Community-Projekten. Es wäre natürlich schön, wenn 
Du Dein Gateway für TTN verfügbar machst, um die Netzabdeckung zu 
verbessern. Vielleicht hilft dir ja die Liste oben bei der 
Entscheidungsfindung.

Martin M. schrieb:
> Habe hier folgenden Kommentar gefunden, der mein Bauchgefühl
> widerspiegelt:

Der Kommentar sieht Dinge ein wenig seltsam. Es ist nicht so leicht, 
Leute davon zu überzeugen, Ressourcen zu teilen und gerade Helium hat da 
durch den kommerzialisierten Aspekt ziemlich große Schäden angerichtet.
Die TTN-Community ist allerdings tatsächlich ziemlich ätzend, weil 
einige Leute mit Geltungsdrang meinen, die ganze Zeit die gleichen 
nervigen Kommentare absondern zu müssen, anstatt mal zu helfen.
Wer hier postet, dem dürfte das aber relativ egal sein.

F. schrieb:
> Es wäre natürlich schön, wenn
> Du Dein Gateway für TTN verfügbar machst, um die Netzabdeckung zu
> verbessern.

Danke für deine ausführliche Beschreibung, ist ein Ansporn das Gateway 
doch wieder auf Chirpstack umzuflashen.
Wenn ich das richtig in Erinnerung habe, war es damit ja sogar möglich 
ein eigenes Netz und TTN gleichzeitig zu betreiben über die 
Paketweiterleitung...

> Hier in Europa hast du zunächst das "Problem," dass im 868-MHz-Band
> gesendet wird, wo du Einschränkungen hinsichtlich der Übertragungsdauer
> ausgesetzt bist. Echtzeit-SSH-Sitzungen empfehle ich daher nicht.

Ich weiss nicht ob das ueberhaubt sinnvoll ist. Du kannst ja einfach mit 
deinem Handy oder Wlan ins Netzwerk gehen. Das Hauptmerkmal von Lora ist 
ja der geringe Stromverbrauch und das passt auch nur zu Anwendungen die 
ab und an wenige Daten uebertragen muessen, also mal sowieso fuer 
Batterieverbrauch optimiert sind.

Ich fand es im uebrigens interessant das man auf der Embedded diese 
Lora-Module wirklich an jeder Ecke gesehen hat! Ich hab mir auch mal 
3Stk zum rumspielen gekauft. Auch wenn es mich etwas verwundert hat weil 
man diesen SX1262 ja auch einfach selber auf eine Platine setzen kann. 
Man wuerde eigentlich denken das es da fertige Module gibt die einem den 
ganzen Umgang mit dem Protokoll abnehmen, also mit eignener MCU und 
nicht so einen Bullshit mit ESP32 oder Raspberry-Pico mit Python wo man 
einen Akku mit Raeder braucht. :-D

Ob man aber ein grosses Netzwerk braucht das sagen wir mal Weltweit oder 
wenigstens Deutschlandweit funktioniert, ich wage es zu bezweifeln. Wer 
etwas in seiner eigenen Bude machen will kann sich da auch den 
Empfaenger selber ins Netz haengen und wer als Firma mit einer gewissen 
Flaeche arbeitet wird sicher auch mit eigener Gegenstation arbeiten. 
Oder wollt ihr das der ganze Firmenkram ueber den Host des Rentner 
nebenan im Netz geht und ploetzlich alles ausfaellt wenn der in Urlaub 
faehrt?

Vanye

Vanye R. schrieb:
> Man wuerde eigentlich denken das es da fertige Module gibt die einem den
> ganzen Umgang mit dem Protokoll abnehmen

Für den STM32WL55/STM32WLE5, welcher das SX126x enthält, gibt es ein 
"LoRaWAN_AT_Slave" Example, da kann man per UART-Kommandos den 
LoRa-Client steuern. Allerdings kann man auch einfach gleich die ganze 
Anwendungsebene auf dem Controller laufen lassen, ohne externen 
Controller (der 55er hat ja extra dafür den 2. Kern). Da gibt's auch 
fertige Eval-Boards/Module.

Der ATSAMR34J18 ist so ähnlich.

Vanye R. schrieb:
> Ob man aber ein grosses Netzwerk braucht das sagen wir mal Weltweit oder
> wenigstens Deutschlandweit funktioniert, ich wage es zu bezweifeln

Was macht man wenn man ein sehr mobiles Gerät vernetzen möchte welches 
aber nur sehr wenig Energie und Platz zur Verfügung hat? Mobilfunk 
braucht viel Energie und die Module sind groß, LoRa wäre perfekt dafür 
wenn man eine gute Netzabdeckung hätte... SigFox ist da auch 
interessant, da steht immerhin eine Firma dahinter welche die 
Netzabdeckung vorantreibt.

> SigFox ist da auch interessant, da steht immerhin eine
> Firma dahinter welche die Netzabdeckung vorantreibt.

Ich dachte der Laden sei pleite und hoffe es auch. Denn wenn
es etwas nicht braucht dann sind da wieder mehrere Standards.

Vanye

LoRaWAN-Netzabdeckung gibt es sehr umfangreich von kommerziellen 
Anbietern, die lassen aber nicht alle Geräte rein. Fürs Selberbasteln 
daher eher wenig attraktiv.
So ein Community-Netzwerk wie TTN ist schon cool, weil es eben 
funktioniert. Schade, dass der Ausbau ein wenig stockt.
LoRa hat teilweise wirklich extreme Reichweite, aus dem vierten Stock 
mit einer hinter dem Fenster aufgestellten ordentlichen Antenne konnte 
ich einen ganzen Stadteil "versorgen" (sicher auch noch mehr, aber da 
waren leider Hindernisse dazwischen), mein jetziges Setup im ersten 
Stock kann (wie berechnet) auch noch mit strategisch plazierten Knoten 
in 30 km Entfernung kommunizieren und bei meinen Reichweitenmessungen 
kam es schon vor, mal Kontakt zu einem 50 km entfernten Gateway zu 
haben. Mit SF7 und normal großer externer Antenne am mobilen Knoten. Da 
reicht eine Standard-Antenne, wie man sie auch von WLAN-Routern kennt. 
Ist natürlich keine WLAN-Antenne, sondern eine für 868 MHz.

Nachteilig an TTN ist leider die sehr schwierige Netzabdeckungssituation 
und unzureichende Karten zur Netzabdeckung. Man kann das relativ gut 
berechnen, wenn Position, Höhe und Antennenparameter der Basisstation 
bekannt sind, doch diese Informationen gibt es kaum. Die Messungen im 
ttnmapper sind oft schlecht, da sie nicht korrekt durchgeführt wurden. 
Man sieht einige Ballons oder andere Flugzeuge, die durch ihre große 
Höhe natürlich von viel mehr Gateways gesehen werden. Es sind auch 
einige Messungen bei SF12 dabei, leider unterscheidet die 
ttnmapper-Software nicht nach Spreading Factor, daher ist das alles sehr 
unbefriedigend.
Auch ist die Position der TTN-Gateways üblicherweise nicht optimal. Die 
werden eben dort aufgestellt, wo Platz ist. Beim Indoor-Betrieb oder 
Betrieb niedriger als auf dem Dach wird viel Reichweite verschenkt. 
Andererseits ist das immer noch besser als gar keine Netzabdeckung.
Punktuell gibt es viele Gateways, wenn sich Leute dafür interessieren, 
an anderen Stellen wiederum ist nichts los, teilweise auch in großen 
Städten. Das ist ziemlich schade, denn es ist ein cooles Projekt. Gerade 
auch zum Experimentieren, es gibt einige wirklich kompakte Knoten, die 
man auch einfach mal eine Zeitlang draußen herumliegen lassen kann, um 
Messungen durchzuführen.

Ich war am Anfang auch mal sehr optimistisch bei TTN unterwegs, 
inzwischen habe ich das Aufgegeben. Irgendwann hat man mal die ganzen 
OneWay-Nodes ausgesperrt. Nur weil der Protokollstack so dämlich 
definiert ist, wird es nicht mehr zugelassen das simple Sensoren 
(Temperatur, Feuchte, Zählerstände u.s.w.) nur in eine Richtung senden. 
Es wird immer zwingend das ganze Protokoll in beide Richtungen gefahren 
und somit massenhaft unnütze Daten in die Luft geblasen. Dazu kommt noch 
die Unart simple ESP Gatewas zu betreiben die nicht alle Kanäle abdecken 
aber gleichzeitig Nodes mit dem Standardstack zu versehen der alle 
möglichen Kanäle auswürfelt. So entstehen aus wenigen Nutzbytes für eine 
simple Temperatur schnelle ein paar 100Byte.
Da macht es dann mehr Sinn nur Lora ohne WAN zu verwenden. Vor allem 
dann wenn keine anderen Gateways als die eigenen zur Verfügung stehen.

Jürgen schrieb:
> Ich war am Anfang auch mal sehr optimistisch bei TTN unterwegs,
> inzwischen habe ich das Aufgegeben.

TTN hat leider einen Fehler gemacht, der verständlich ist, aber lästig: 
Man hat anfangs eine üble und inkompatible Pseudo-LoRaWAN-Version 
zugelassen, die aber mit der damals verfügbaren Hardware sehr 
kostengünstig umzusetzen war.
Mittlerweile können echte LoRaWAN-kompatible Knoten kostengünstig 
umgesetzt werden, es besteht also einfach kein Bedarf mehr für eine 
abgespeckte LoRaWAN-Version für Bastler.

> Irgendwann hat man mal die ganzen
> OneWay-Nodes ausgesperrt. Nur weil der Protokollstack so dämlich
> definiert ist, wird es nicht mehr zugelassen das simple Sensoren
> (Temperatur, Feuchte, Zählerstände u.s.w.) nur in eine Richtung senden.
> Es wird immer zwingend das ganze Protokoll in beide Richtungen gefahren
> und somit massenhaft unnütze Daten in die Luft geblasen.

Knoten müssen Nachrichten empfangen können, damit deren Netznutzung 
gesteuert werden kann (ADR, etc.). Knoten, die das nicht können, sind 
halt nicht LoRaWAN-kompatibel.
Du musst da beachten, dass du potentiell nicht der einzige bist, der 
einen Knoten betreibt. Diese Steuerungsnachrichten sind ein wichtiger 
Teil des LoRaWAN-Netzwerkstandards. Da werden auch nicht "massenhaft 
unnütze Daten in die Luft geblasen," sondern ab und zu geschaut, wie 
weit der Knoten mit dem Spreading Factor heruntergehen kann (und somit 
weniger Zeit mit Senden verbringt, was den anderen Nutzern zugutekommt), 
damit Nachrichten immer noch ankommen.
Ich verstehe, dass es ärgerlich ist, wenn man sich mit Mühe und Not 
einen Sensor mit einem Attiny zusammengebastelt hat, der dann nicht mehr 
unterstützt wird, aber die entsprechenden Libraries waren von Anfang an 
experimentell und es war bekannt, dass diese nicht LoRaWAN-kompatibel 
sind. TTN hat das lange akzeptiert, entsprechende Knoten machen aber 
langfristig nur Probleme, daher war es die richtige Entscheidung, mal 
auf Einhaltung des LoRaWAN-Standards zu pochen.

> Dazu kommt noch
> die Unart simple ESP Gatewas zu betreiben die nicht alle Kanäle abdecken
> aber gleichzeitig Nodes mit dem Standardstack zu versehen der alle
> möglichen Kanäle auswürfelt. So entstehen aus wenigen Nutzbytes für eine
> simple Temperatur schnelle ein paar 100Byte.

Du würfelst da Dinge durcheinander.
LoRaWAN definiert bestimmte Kanäle, die abgedeckt werden müssen. Die 
schrecklichen Single-Channel-Gateways können das nicht, sind also nicht 
LoRaWAN-kompatibel. Es ist ein cooler Trick, sowas mal aufzubauen und 
überhaupt technische Machbarkeit einer Anwendung zu testen, aber für den 
Betrieb sind die völlig ungeeignet. Sie sind sogar recht problematisch, 
da LoRaWAN-kompatible Knoten durch diese Gateways ständig Nachrichten 
verlieren. Das LoRaWAN-Konzept sieht ja durchaus ein einigermaßen 
"stabiles" Netz vor, da ist ständiger Nachrichtenverlust relativ 
problematisch.
Daher ist es auch kein Problem, den Standard-Stack zu verwenden, der 
"alle möglichen Kanäle auswürfelt"--das ist eben der Standard. Wenn du 
kein LoRaWAN benutzen willst, dann benutze halt irgendein anderes 
Netzwerkprotokoll auf der LoRa-Übertragungsschicht.

> Da macht es dann mehr Sinn nur Lora ohne WAN zu verwenden. Vor allem
> dann wenn keine anderen Gateways als die eigenen zur Verfügung stehen.

Das sind völlig unterschiedliche Anwendungsszenarien. Mit LoRa musst du 
dich um alles Mögliche kümmern, bei LoRaWAN macht das das Gateway und 
die darauf laufende Netzwerksoftware. Wenn Du zwei Attiny-Sensoren 
auslesen willst mit einem ESP-basierten Gateway, bitteschön, tu Dir 
keinen Zwang an, aber da kann man TTN nicht sinvoll kritisieren, wenn 
sie darauf bestehen, ein bestimmtes Netzwerkprotokoll zu nutzen.
Das ist ernsthaft nur ein Problem für Gebastel, das nie 
LoRaWAN-kompatibel war. LoRaWAN-Module funktionieren immer noch.

> Das ist ernsthaft nur ein Problem für Gebastel, das nie
> LoRaWAN-kompatibel war. LoRaWAN-Module funktionieren immer noch.

Daher mein Einwand das es Module geben muss die das ALLES fuer einen
erledigen. Als Bastler, selbst als kleine 3-5Personen Firma willst
du dir diesen megakomplexen Kram einfach nicht antun.
Schliesslich wolltest du ja nur xyz uebertragen...

Vanye

Vanye R. schrieb:
> Daher mein Einwand das es Module geben muss die das ALLES fuer einen
> erledigen

Einfach mal "lora module at commands" Googlen?

Vanye R. schrieb:
> selbst als kleine 3-5Personen Firma willst
> du dir diesen megakomplexen Kram

Naja, man muss das nur als Library integrieren. Nur wenn man das nicht 
schafft braucht man ein separates Modul welches extern angesteuert wird.

Vanye R. schrieb:
> Daher mein Einwand das es Module geben muss die das ALLES fuer einen
> erledigen. Als Bastler, selbst als kleine 3-5Personen Firma willst
> du dir diesen megakomplexen Kram einfach nicht antun.
> Schliesslich wolltest du ja nur xyz uebertragen...

Die gibt's schon längst von verschiedenen Anbietern. Die sind natürlich 
ein wenig teuer, aber wenn Entwicklung Geld kostet, sehr empfehlenswert.
Eines der günstigsten Module dürfte das Modul von Seeed sein, das auf 
einem STM32WLE5JC basiert und standardmäßig mit AT-Firmware kommt. Das 
nennt sich seeed-LoRa-E5. Man kann es aber natürlich auch 
umprogrammieren und direkt auch die Anwendungslogik darauf ausführen, 
leistungsfähig genug ist der eingebaute STM32 allemal.
Ja, natürlich ist es lustig, mit einem Attiny und einem RFM95-Modul 
einen Knoten zu bauen, der Informationen ins TTN sendet, aber das ist 
einfach nicht LoRaWAN-Standard-kompatibel. Dass Netze solche Knoten 
irgendwann rausschmeißen, dürfte klar sein. Andere Netze lassen 
irgendwas Selbstgebautes erst gar nicht rein, sondern bestehen auf 
zertifizierte Hardware.

Ich finde es schade, dass dem TTN vorgeworfen wird, standardkonform sein 
zu wollen. Klar, da ist es nicht mehr mit einem 
20-Euro-Selbstbastel-"Gateway" getan, das Attiny-Sensoren versorgt, die 
keine Steuerungskommandos empfangen können. Aber mittlerweile sind 
richtige Gateways zu absolut hobbykompatiblen Preisen erhältlich (man 
dürfte mittlerweile wahrscheinlich mit "leicht gebrauchter" Hardware auf 
um die 30-40 Euro kommen können, mein letztes neues Gateway hat keine 
100 Euro gekostet). Auch LoRaWAN-Module und -stacks sind verfügbar; 
Heltec macht ASR6502-basierte und ESP32-basierte für einen günstigen 
Kurs, der STM32WL integriert das auch alles. Soweit ich weiß, gibt's da 
mittlerweile auch für alle Arduino- bzw. Platformio-Unterstützung, dem 
Bastelspaß steht also wirklich nichts entgegen.

Ich bin schon seit einer Weile dabei, aber moderne Hardware kann einfach 
problemlos den richtigen LoRaWAN-Stack ausführen, also sollte man die 
verwenden. Der Preis bewegt sich in Regionen, zu denen man früher die 
Hardware bekommen hat, die nur mit abgespeckten Stacks funktioniert und 
dann viele Features nicht unterstützt, teilweise auch wirklich 
notwendige Features. Die Entwicklung ist weder besonders kompliziert 
noch besonders teuer, die Beschwerden kommen einfach nur daher, weil TTN 
früher Knoten und Gateways akzeptierte, die nicht standardkonform waren 
und das mittlerweile eben nicht mehr tut.

F. schrieb:
> Das sind völlig unterschiedliche Anwendungsszenarien. Mit LoRa musst du
> dich um alles Mögliche kümmern, bei LoRaWAN macht das das Gateway und
> die darauf laufende Netzwerksoftware. Wenn Du zwei Attiny-Sensoren
> auslesen willst mit einem ESP-basierten Gateway, bitteschön, tu Dir
> keinen Zwang an, aber da kann man TTN nicht sinvoll kritisieren, wenn
> sie darauf bestehen, ein bestimmtes Netzwerkprotokoll zu nutzen.
> Das ist ernsthaft nur ein Problem für Gebastel, das nie
> LoRaWAN-kompatibel war. LoRaWAN-Module funktionieren immer noch.

Wieso darf man das nicht kritisieren? Der Protokolloverhead ist für 
simple Sensoren zu hoch. Das ist meine Meinung und da kann auch ein 
Schwätzer der jede andere Meinung als Bastelei abtut nichts ändern.

Wenn das TTN vernünftig wachsen würde könnte man sich eventuell darauf 
einlassen, hier tut sich aber seit Jahren nichts mehr. Ist auch gut so, 
da ist wenigstens halbwegs Ruhe im 868MHz Bereich.

F. schrieb:
> Ich finde es schade, dass dem TTN vorgeworfen wird, standardkonform sein
> zu wollen. Klar, da ist es nicht mehr mit einem
> 20-Euro-Selbstbastel-"Gateway" getan, das Attiny-Sensoren versorgt, die
> keine Steuerungskommandos empfangen können. Aber mittlerweile sind
> richtige Gateways zu absolut hobbykompatiblen Preisen erhältlich (man
> dürfte mittlerweile wahrscheinlich mit "leicht gebrauchter" Hardware auf
> um die 30-40 Euro kommen können, mein letztes neues Gateway hat keine
> 100 Euro gekostet).

Meins damals 160€ ohne den Raspi dazu und das war kein Gebastel. Die 
Nodes dazu STM32F07x+RFM95. Die hingen auch mal am V3 Stack und gingen. 
Lustig ist ja auch, dass die arroganten und hochnäsigen TTN Verfechter 
alles was ihnen nicht passt als Gebastel abtun, gleichzeitig gibt es 
vernünftig gepflegte Client-Libs nur für Bastel-Arduino. Meine gingen 
ohne diesen ganzen Overhead.
ATTiny oder änliches habe ich nie verwendet, die Zeit ist lange vorbei. 
Trotzdem hat sich TTN am Anfang der ganzen Leute bedient die auf dieser 
Basis "Gebastelt" haben und damit nicht unwesentlich zur Verbreitung 
beigetragen haben. Und daß man mit V3 das aussperrt was mal ging stand 
allerhöchstens im Kleingedruckten. Der Mehrheit wurde das erst bewußt 
als es nicht mehr ging. Und jeder der darauf reingefallen ist macht den 
Fehler nicht nochmal. Wer weiss wann mal wieder so geändert wird, dass 
man wieder alles nachziehen muss.

Trotzdem ist mein Weg für die ca. 25 Sensoren nur Lora. Da gibst dann 
einen simplen Empfänger dazu als Gateway in den CAN-Hausbus. Den Strom 
für den Raspi + Gateway spart man dabei auch und es funktioniert auch 
ohne Internet. Ich bin von TTN geheilt.

Jürgen schrieb:
> Trotzdem ist mein Weg für die ca. 25 Sensoren nur Lora. Da gibst dann
> einen simplen Empfänger dazu als Gateway in den CAN-Hausbus. Den Strom
> für den Raspi + Gateway spart man dabei auch und es funktioniert auch
> ohne Internet. Ich bin von TTN geheilt.

+5

Hab zwar keinen CAN-Hausbus, aber bei mir wird's vom privaten Gateway 
nach NodeRED eingespeist und funktioniert wunderbar.

Hallo Jürgen & Helmut,
wie habt ihr denn eure privaten Gateways realisiert, sprich welche 
Hardware & welche Software? Laufen die z.B. mit Chirpstack oder sind das 
proprietäre Lösungen?
Und habt ihr für eure LoRa Knoten dann ein Protokoll für euch selbst 
definiert oder verwendet ihr irgendeinen Standard?

So wie ich das verstanden habe bin ich ja wenn ich Chirpstack verwende 
trotzdem mehr oder weniger an das Protokoll vom TTN gebunden, deshalb 
würden mich eure schlanken (?) Varianten näher interessieren, um evtl. 
Sensoren rund ums Haus in den Homeassisstant einzuspeisen, ohne dafür 
stromfressende ESPs zu verwenden - früher hab ich das mal mit MySensors 
gemacht, aber das Projekt ist ja mittlerweile leider auch tot...

Martin M. schrieb:
> Hallo Jürgen & Helmut,
> wie habt ihr denn eure privaten Gateways realisiert, sprich welche
> Hardware & welche Software? Laufen die z.B. mit Chirpstack oder sind das
> proprietäre Lösungen?

Ich bin sicher kein Standard. Das ganze Spiel läuft seit 20 Jahren. Am 
Anfang gabs nur ein paar Temperatur/Feuchte Sensoren auf 868MHz. WS300 
hieß das Protokoll glaube ich, dann gab's mal eine Energiemonitor EM100 
(ELV?) sowie ein paar FS20 Komponenten. Das wird ueber einen separaten 
Empfänger gehändelt. Später kamen Sensoren mit RFM02 dazu (868MHz) FM.
In der Summe bedient heute ein stm32F103 (Bluepill) 4 RFM95s, einen 
analogen Empfänger für die alten Protokolle und einen EBYTE E32xx auf 
Uart-Basis.
2 RFM95 empfangen und senden Lora auf 868MHz und 434MHz. Eine empfängt 
das was die RFM02 senden (868MHz) und den 4. nehme ich um an diverse 
OBI(Pt2260), Intertechno und FS20 Steckdosen zu senden. Die RFM95 sind 
sehr universal und nicht nur für Lora geeignet. Die Datenpakete sind 
alle selbst definiert, aber das ist ja simpel für Sensoren die nur ein 
oder 2 Werte liefern.
Der Code ist ohne fremde Lib in C++ geschrieben. Ich werd mal ein paar 
Bilder machen.

Bei mir läuft's ähnlich wie bei Jürgen. Für Lora auf 868MHz verwende ich 
Arduino Pro Mini (ATmega328) ohne jeden Schnickschnack und ein 
LoRa-Modul dazu. Übertragungsprotokoll ist CayenneLPP, das die Werte 
nochmal schön packt und versorgt werden die Sensoren über Solarzellen 
(100*60mm, 6V, 100mA), einen Laderegler und ein LiPo-Pack mit 3Ah. Das 
reicht zum Senden alle Minuten auch im Winter über ohne Probleme. 
Akkuspannung wird natürlich auch übertragen. Akkuspannung ist immer 
zwischen 4.13V und 4.19V auch heute bei bewölktem Himmel und Regen. 
Sensoren und Prozessor werden in den Pausen schlafen gelegt. Das Gateway 
ist ein ESP32, der im Haus sitzt und auch noch die alten WS2000-Sensoren 
von ELV mit empfängt und decodiert und an den MQTT-Server (RasPi) 
schickt.

Jürgen schrieb:
> Wieso darf man das nicht kritisieren? Der Protokolloverhead ist für
> simple Sensoren zu hoch. Das ist meine Meinung und da kann auch ein
> Schwätzer der jede andere Meinung als Bastelei abtut nichts ändern.

Bitte lesen. Ich tue nicht jede andere Meinung als Bastelei ab. Ich 
kenne den Grund nicht, warum du keinen LoRaWAN-Stack in deine Projekte 
integrierst, der Hauptgrund war aber früher oft mangelnde 
Hardware-Ressourcen. Und da kann man eben nicht erwarten, dass 
unvollständige Implementierungen weiterhin akzeptiert werden.

Jürgen schrieb:
> Meins damals 160€ ohne den Raspi dazu und das war kein Gebastel. Die
> Nodes dazu STM32F07x+RFM95. Die hingen auch mal am V3 Stack und gingen.

Die Nodes gehen ja so lange, bis auf MAC-Kommandos lange genug nicht 
geantwortet wird. Insofern kein Wunder. Die Hardware ist ja aber da, um 
einen ordentlichen Stack umzusetzen. Warum machst du das nicht? Verstehe 
ich nicht.
Gebastel waren die IMST-basierten Gateways nicht, wohl aber die 
Single-Channel-Gateways mit ESP32, die wirklich sehr gerne genutzt 
wurden. Die haben auch nur Probleme gemacht, weil sie ebenfalls nicht 
dem LoRaWAN-Standard entsprachen.

> Lustig ist ja auch, dass die arroganten und hochnäsigen TTN Verfechter
> alles was ihnen nicht passt als Gebastel abtun, gleichzeitig gibt es
> vernünftig gepflegte Client-Libs nur für Bastel-Arduino. Meine gingen
> ohne diesen ganzen Overhead.

"Dieser ganze Overhead" nennt sich halt LoRaWAN. Wenn du ein 
Netzwerkprotokoll umsetzen willst, um an einem Netzwerk teilzunehmen, 
dann musst du auch den Anforderungen des Protokolls entsprechen, sonst 
stört das das ganze Netzwerk.

Du willst ja Interoperabilität und Kompatibilität, sonst würdest du dein 
eigenes Übertragungsprotokoll umsetzen. Das bedeutet dann aber auch, 
dass man halt in Gottes Namen auch Features implementiert, die man für 
die konkrete Anwendung nicht braucht, z.B. Nachrichten zu empfangen und 
zu verarbeiten.

> Trotzdem hat sich TTN am Anfang der ganzen Leute bedient die auf dieser
> Basis "Gebastelt" haben und damit nicht unwesentlich zur Verbreitung
> beigetragen haben.

Das war rückblickend natürlich eine dumme Idee.

> Und daß man mit V3 das aussperrt was mal ging stand
> allerhöchstens im Kleingedruckten. Der Mehrheit wurde das erst bewußt
> als es nicht mehr ging. Und jeder der darauf reingefallen ist macht den
> Fehler nicht nochmal. Wer weiss wann mal wieder so geändert wird, dass
> man wieder alles nachziehen muss.

Sauerei, UMTS ist auch abgeschaltet!
Legacy-Knoten, die nicht empfangen und daher auch nicht auf 
Netzwerksteuerungs-Kommandos reagieren, sind sehr selten (die kriegen 
keine Zertifizierung, es sind also ausnahmslos selbst gebaute Knoten) 
und sorgen echt nur für Probleme.
Es ist hingegen mittlerweile völlig unproblematisch und nicht einmal 
teuer, einfach Lösungen zu nutzen, die korrekt funktionieren. Bei dir 
ist es ja noch schlimmer: Du hast schon die Hardware dafür, warum läuft 
da nicht die Software drauf, die das ermöglicht?
Die "Transmit-only"-Knoten waren noch nie LoRaWAN-compliant. Das 
Protokoll ist schon darauf ausgelegt, dass auch noch alte Versionen 
unterstützt werden, sobald du also einmal einen Knoten hast, der LoRaWAN 
umsetzt, sollte der auch in absehbarer Zukunft noch funktionieren.

> Trotzdem ist mein Weg für die ca. 25 Sensoren nur Lora. Da gibst dann
> einen simplen Empfänger dazu als Gateway in den CAN-Hausbus. Den Strom
> für den Raspi + Gateway spart man dabei auch und es funktioniert auch
> ohne Internet. Ich bin von TTN geheilt.

Wenn das bei dir funktioniert, dann ist ja alles gut. Man muss ja auf 
LoRa kein LoRaWAN fahren. Aber jetzt rumzunerven, dass TTN so schlimm 
ist, weil sie irgendwann, als demonstriert war, dass sich ein solches 
Netz als Community-Leistung überhaupt aufbauen lässt, dazu übergegangen 
sind, nur noch Gateways und Knoten zu erlauben, die sich auch an LoRaWAN 
halten, um somit Störungen des Netzbetriebs zu minimieren, halte ich für 
unangebracht.


Es ist ja völlig in Ordnung, für Sensoren, die nur lokal genutzt werden, 
einfach eine eigene Infrastruktur aufzubauen und Übertragungsformate zu 
definieren, die extrem wenig Overhead haben. Aber das ist nicht der 
Anwendungsbereich eines WAN. Ich kann meine im TTN eingebundenen Knoten 
mitnehmen und sie funktionieren auch noch außerhalb der Reichweite 
meines Gateways (Netzabdeckung durch andere Gateways vorausgesetzt). 
Außerdem spare ich mir den Betrieb eigener Verteilungs-Infrastruktur, 
sondern kriege die Daten direkt in Formaten angeliefert, die ich 
verarbeiten kann. Ich betreibe eine Mischung aus kommerziellen Sensoren 
und selbst gebastelten Knoten, das funktioniert völlig problemlos. Wenn 
man das alles nicht braucht und auch keine Vorteile daraus ziehen kann, 
dann ist TTN natürlich nichts, aber die Kritik sollte sich dann doch 
bitte realistisch an tatsächlich kritikwürdigen Dingen orientieren. 
Davon gibt's genug, bisher habe ich diesbezüglich hier aber eher wenig 
gelesen.

F. schrieb:
> Die Nodes gehen ja so lange, bis auf MAC-Kommandos lange genug nicht
> geantwortet wird. Insofern kein Wunder. Die Hardware ist ja aber da, um
> einen ordentlichen Stack umzusetzen. Warum machst du das nicht? Verstehe
> ich nicht.

Ich habs gemacht, es ging vollständig und ich hatte selbst nur Nodes die 
das ganze Protokoll implementiert haben. Ich hab auch nicht gejammert 
dass es nicht geht. Trotzdem sei es mir erlaubt es Scheiße zu finden und 
meine Aktivitäten dahingehend einzustellen.

F. schrieb:
> aber die Kritik sollte sich dann doch
> bitte realistisch an tatsächlich kritikwürdigen Dingen orientieren.

Nichts anderes habe ich gemacht. Für lumpige 16bit Sensordaten ist mir 
der Protokolloverhead viel zu groß, da ca. 10 mal mehr in der Luft 
rumschwirren als nötig. Wenn andere das als nicht relevant empfinden 
akzeptiere ich das und will auch keinen bekehren.

F. schrieb:
> Sauerei, UMTS ist auch abgeschaltet!
Genau, ein paar simple Sensoren sollen aber einen längeren Lebenszyklus 
haben als schicke Handys. Und weil man sich bei TTN nicht darauf 
verlassen kann das es in 15 Jahren noch geht lasse ich das lieber ganz 
bleiben.

F. schrieb:
> Es ist hingegen mittlerweile völlig unproblematisch und nicht einmal
> teuer, einfach Lösungen zu nutzen, die korrekt funktionieren. Bei dir
> ist es ja noch schlimmer: Du hast schon die Hardware dafür, warum läuft
> da nicht die Software drauf, die das ermöglicht?

Nochmal zum Mitschreiben: Meine Knoten liefen V3 konform in beide 
Richtungen. Ich habe nie gesagt damit Probleme zu haben. Aber genau in 
der Zeit als ich das evaluiert habe kam die Diskussion darum hoch und 
das hat mir die Augen geöffnet.