Hallo Leute, ich brauche mal einen Rat von euch. Ich habe einen rPi, den ich gerne Offgrid installieren möchte. Ich möchte den rPi mit dem SX1262 LoRa HAT ausstatten, damit er Daten, die er sammelt, weiter übertragen kann. Ich selbst habe vor ein paar Tagen ein TTN Node bei mir aufgebaut, der auch soweit auch funktioniert. Bisher habe ich aber keine Erfahrungen damit gesammelt. Meine Frage ist nun: Macht es Sinn, sich am TTN zu beteiligen, wenn ich die Sensor-Daten übertragen möchte? Oder am Meshtastic Netzwerk? Ich habe einige Videos gesehen, wie einige Leute SSH-Sitzungen über LoRA durchführen. Wenn ich es richtig verstehe, kann ich es nicht machen, wenn ich mich an einem der Netzwerke beteilige. Bzw. ich weiß garnicht, ob ich den rPi überhaupt ins Meshtastic Netzwerk bekomme. Deshalb frage ich mich, ob es Sinn macht, sich überhaupt mit einem Netzwerk zu beschäftigen und nicht stattdessen ein eigenes privates Gateway zu erstellen.
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.
:
Bearbeitet durch User
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.
Jürgen schrieb: > 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. Also wenn ich das richtig verstehe unterstützt TTNv3 nach wie vor die LoRaWAN-Spezifikation 1.0.0 von 2015. Also wurde nie eine alte Version abgehängt, es funktioniert alles nach wie vor? "TTNv2" / "TTNv3" ist doch einfach nur die Software für Gateways und Server. Das Funkprotokoll ist davon doch unberührt, oder? Man muss halt nur die Gateways aktualisieren und neu einbinden/konfigurieren?
Niklas G. schrieb: > Jürgen schrieb: >> 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. > > Also wenn ich das richtig verstehe unterstützt TTNv3 nach wie vor die > LoRaWAN-Spezifikation 1.0.0 von 2015. Also wurde nie eine alte Version > abgehängt, es funktioniert alles nach wie vor? > > "TTNv2" / "TTNv3" ist doch einfach nur die Software für Gateways und > Server. Das Funkprotokoll ist davon doch unberührt, oder? Man muss halt > nur die Gateways aktualisieren und neu einbinden/konfigurieren? Du reißt meine Aussage aus dem Context. Es ging darum dass zur Zeit der Umstellung auf einmal alle einfachen Nodes nicht mehr gingen. Und als Antwort kam: "so ist das eben, basta, UTMS gibst auch nicht mehr". Klar waren die nicht ganz Standardkonform aber das wussten die wenigsten die nur die Arduino-Libs verwendet haben ohne sich tiefer einzuarbeiten. Ich hab mich damals aber sehr tief eingearbeitet und musste auch sehen wieviel Mist da an Libs auf Github rumschwirrt wo nicht mal die Frequenzen passen. Aber egal ich kritisiere die Politik von TTN erst die Leute zu ködern und dann ins offene Messer laufen zu lassen. Und ja, ich hab's ja verstanden, es war nicht komplett Protokollkonform. Also war es ein Fehler von TTN das am Anfang zuzulassen. Dann soll man aber auch bitte zu seinen Fehler stehen und nicht auf arroganter Art und Weise sagen: Ihr seid ja selbst schuld! Auf der anderen Seite stopfe ich und viele Andere das 868MHz Band auf den TTN Frequenzen genauso zu nur ohne das TTN damit was anfangen kann. Ist das jetzt besser? Man könnte ja noch gemeiner sein und genau die gleichen Frequenzen und das gleiche Protokoll verwenden mit eigenem simplen Empfänger. Dann würde TTN über alles mit dem Datenmüll belästigt ohne dagegen vorgehen zu können. Und um nochmal klarzustellen, ich selbst war von der Problematik nicht betroffen und jammere nicht deswegen. Mir geht es dabei ums Prinzip.
:
Bearbeitet durch User
Jürgen schrieb: > Aber egal ich kritisiere die Politik von TTN erst die Leute zu ködern Wurde denn irgendwo kommuniziert dass solche Nicht-Konformen Nodes explizit akzeptiert werden? Jürgen schrieb: > Man könnte ja noch gemeiner sein und genau die > gleichen Frequenzen und das gleiche Protokoll verwenden mit eigenem > simplen Empfänger Wenn ich das richtig verstehe wäre das nichtmal ein Problem für TTN, die TTN-Gateways würden den entsprechenden Traffic ignorieren. Sie würden nur etwas mehr Energie verbrauchen um die "sinnlosen" Pakete zu empfangen. Man könnte auch ein anderes Syncword nutzen. Im Endeffekt ist das dann auch nichts anderes als Rauschen/sonstige Frequenznutzer. Ich nehme da eher mit: Solange man LoRaWAN-konform ist (man kann ja sogar zertifizieren), funktionieren die Nodes langfristig.
Niklas G. schrieb: > Wurde denn irgendwo kommuniziert dass solche Nicht-Konformen Nodes > explizit akzeptiert werden? Sorry jetzt wird es albern. Sieh dir mal an was vor ein paar Jahren im Netz zu TTN und LoraWAN ab ging. Nicht nur im Netz auch in den Zeitschriften. Simple OneWay Nodes wo man hinsah. Sagt heute TTN dass es explizit in 5 Jahren noch geht und auch noch kostenfrei? Niklas G. schrieb: > Wenn ich das richtig verstehe wäre das nichtmal ein Problem für TTN, die > TTN-Gateways würden den entsprechenden Traffic ignorieren. Sie würden > nur etwas mehr Energie verbrauchen um die "sinnlosen" Pakete zu > empfangen. Man könnte auch ein anderes Syncword nutzen. Im Endeffekt ist > das dann auch nichts anderes als Rauschen/sonstige Frequenznutzer. Die TTN-Gateways können den Traffic nicht ignorieren solange das erste Paket Protokollkonform ankommt. Sie können es ja mangels Schlüssel nicht mal decodieren. Also wandert es erst mal bis in den zentralen Stack. Ja es wird sicher nichts in den Abgrund reißen aber das hätten die simplen Nodes auch nicht. Es ist einzig eine politische Entscheidung die korrekten ersten Pakete im Stack zu verwerfen und nicht mehr zuzuordnen.
Jürgen schrieb: > 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. Achso. Du machst Dir also aus Prinzip Probleme. Na gut, dann kann man da wenig argumentieren. Niklas G. schrieb: > Also wenn ich das richtig verstehe unterstützt TTNv3 nach wie vor die > LoRaWAN-Spezifikation 1.0.0 von 2015. Also wurde nie eine alte Version > abgehängt, es funktioniert alles nach wie vor? > > "TTNv2" / "TTNv3" ist doch einfach nur die Software für Gateways und > Server. Das Funkprotokoll ist davon doch unberührt, oder? Man muss halt > nur die Gateways aktualisieren und neu einbinden/konfigurieren? Ja, wobei selbst alte Gateways mit der V2-Konfiguration immer noch funktionieren. Geändert hat sich im Prinzip nur die URL, an die hochgeladen wird. Auf TTN-Seite wurde für V3 alles ordentlich konfiguriert, daher funktionieren jetzt halt keine Knoten mehr, die nicht spezifikationskonform sind. Früher haben die funktioniert, weil das Backend ignoriert hat, wenn an den Knoten gesendete MAC-Nachrichten nicht berücksichtigt wurden, jetzt wird der Knoten nach einigen gescheiterten Versuchen rausgeschmissen. Der kann natürlich weiterhin senden, aber TTN leitet die Nachrichten nicht mehr weiter. Das macht man gemeinhin so in Funknetzen, damit alle Knoten, die daran teilnehmen, sich auch entsprechend spezifikationskonform verhalten. Nicht konforme Knoten werden rausgeschmissen, indem ihre Nachrichten nicht mehr durchgeleitet werden, was dann die Leute, die diese Nachrichten weiterverarbeiten, dazu zwingt, den Knoten spezifikationskonform zu konfigurieren oder aus dem Netzwerk zu entfernen. Jürgen schrieb: > Aber egal ich kritisiere die Politik von TTN erst die Leute zu ködern > und dann ins offene Messer laufen zu lassen. Und ja, ich hab's ja > verstanden, es war nicht komplett Protokollkonform. Also war es ein > Fehler von TTN das am Anfang zuzulassen. Dann soll man aber auch bitte > zu seinen Fehler stehen und nicht auf arroganter Art und Weise sagen: > Ihr seid ja selbst schuld! Okay, was willst du sonst machen? Knoten, die nicht spezifikationskonform sind, zerstören auf lange Sicht das Netzwerk. Die Idee ist ja, ein Netzwerk zu betreiben und nicht eine verstreute Anzahl von Einzelstationen, da ist es dann eben wichtig, dass sich alle Knoten an die Spezifikation und an weitere Vereinbarungen halten. Man stand ja zum Fehler, es gab sogar eine Übergangszeit. Einige Leute aus der TTN-Community sind allerdings, das muss man zugeben, wahnsinnig ätzend und verderben einem echt die Laune. Die ignoriert man am Besten. > Auf der anderen Seite stopfe ich und viele Andere das 868MHz Band auf > den TTN Frequenzen genauso zu nur ohne das TTN damit was anfangen kann. > Ist das jetzt besser? Man könnte ja noch gemeiner sein und genau die > gleichen Frequenzen und das gleiche Protokoll verwenden mit eigenem > simplen Empfänger. Dann würde TTN über alles mit dem Datenmüll belästigt > ohne dagegen vorgehen zu können. Du bist da nicht der Einzige, es gibt einige kommerzielle LoRaWAN-Netze, z.B. zur Heizkostenverteilung, betrieben von Minol. Das ist überhaupt kein Problem, das sind einfach Störsignale, mit denen das Netz umgehen kann. Es ist aber ein Problem, wenn Geräte, die das Netz benutzen, nicht auf Steuernachrichten aus dem Netz reagieren. > Und um nochmal klarzustellen, ich selbst war von der Problematik nicht > betroffen und jammere nicht deswegen. Mir geht es dabei ums Prinzip. Haben wir verstanden. Kleiner Tip: Such Dir doch ein anderes Hobby, das nicht so schnellen technischen Veränderungen unterworfen ist, da ist das mit "aus Prinzip" dann deutlich einfacher. Mir und auch vielen Anderen ist es völlig klar, dass neuartige Technik einer gewissen Veränderung unterworfen ist, langfristige Kompatibilität ist nicht unbedingt gegeben, insbesondere nicht bei total abgespeckten, minimalistischen Lösungen. Natürlich ist es sehr ärgerlich, wenn jemand an einer schlecht erreichbaren Stelle einen Tx-only-Knoten installiert hat, in der Erwartung, der würde nun jahrzehntelang funktionieren. Andererseits muss man dann aber auch eine gewisse Unbedarftheit konstatieren, da kein anderes LoRaWAN-Netzwerk diesen Knoten akzeptiert hätte und man bei so schwierigen Situationen doch lieber einen Knoten nutzt, der spezifikationskonform ist. Der hätte ein paar Euro mehr gekostet, aber wäre dann auf jeden Fall langfristig zuverlässig. Niklas G. schrieb: > Jürgen schrieb: >> Aber egal ich kritisiere die Politik von TTN erst die Leute zu ködern > > Wurde denn irgendwo kommuniziert dass solche Nicht-Konformen Nodes > explizit akzeptiert werden? Es gab da schon einen ziemlichen Wildwuchs und lange Zeit wurde das geduldet, selbst die schlimmen Ein-Kanal-Basisstationen. Das hätte man so vielleicht nicht machen sollen, aber andererseits ist das immer ein gewisser Spagat: Um Leute dazu zu bringen, ein Community-Netzwerk aufzubauen, dürfen die Einstiegshürden nicht zu hoch sein. Entsprechende Hardware war einfach sehr teuer, die Netzabdeckung gering, da war es nicht schlimm, Leute einfach mit der Technik experimentieren zu lassen und Interesse zu wecken. Man konnte durch Missachtung einiger Protokollaspekte mit relativ kostengünstiger Hardware recht viel ausprobieren, das hat natürlich Interesse und Begeisterung geweckt. Es war aber von Anfang an klar, dass das nicht nachhaltig sein wird. Zumindest war es denen klar, die sich ein wenig mit der Materie beschäftigt und nicht einfach nur irgendwas nachgebaut haben. Das hätte deutlicher kommuniziert werden müssen, keine Frage. Mittlerweile ist die Hardware wirklich kostengünstig erhältlich. Man zahlt heute weniger für richtige LoRaWAN-Hardware als früher für eingeschränkte Hardware. Daher ist es absolut richtig, den Schritt zu gehen und zu fordern, dass die Knoten bitte LoRaWAN-Knoten sein sollen und nicht irgendetwas Anderes. > Ich nehme da eher mit: Solange man LoRaWAN-konform ist (man kann ja > sogar zertifizieren), funktionieren die Nodes langfristig. Ja. Jürgen schrieb: > Sorry jetzt wird es albern. Sieh dir mal an was vor ein paar Jahren im > Netz zu TTN und LoraWAN ab ging. Nicht nur im Netz auch in den > Zeitschriften. Simple OneWay Nodes wo man hinsah. Sagt heute TTN dass es > explizit in 5 Jahren noch geht und auch noch kostenfrei? Mir wäre ehrlich gesagt kein kommerzieller Hersteller von Knoten bekannt, der Tx-only-Knoten vertrieben hat. Das sollte einem dann doch ein wenig zu Denken geben. Wie gesagt, es ist ärgerlich, wenn der Eindruck entsteht, minimalistische Bastellösungen seien nachhaltig. TTN hätte diese Knoten schon viel früher rausschmeißen sollen und nicht erst mit der Umstellung auf V3. Jürgen schrieb: > Die TTN-Gateways können den Traffic nicht ignorieren solange das erste > Paket Protokollkonform ankommt. Sie können es ja mangels Schlüssel nicht > mal decodieren. Also wandert es erst mal bis in den zentralen Stack. Ja > es wird sicher nichts in den Abgrund reißen aber das hätten die simplen > Nodes auch nicht. Es ist einzig eine politische Entscheidung die > korrekten ersten Pakete im Stack zu verwerfen und nicht mehr zuzuordnen. Es ist keine "politische" Entscheidung, sondern eine Entscheidung, die dem Funktionieren des Netzwerks zugute kommt. Knoten, die sich nicht an das vereinbarte Protokoll halten, und dazu gehört eben auch, auf Uplink-Nachrichten zu reagieren, werden vom Netzwerk ausgeschlossen. Sonst kann ja jeder kommen, der nächste Knoten sendet immer nur auf einer Frequenz, der übernächste Knoten sendet immer mit SF12 und reagiert nicht auf ADR-Nachrichten, uswusf.; das sorgt alles dafür, dass das Netzwerk schlechter funktioniert, also werden diese Knoten rausgeworfen. Das ist keine "politische" Entscheidung, sondern eine technische Entscheidung. Technisch kann man natürlich, da die Knoten weiterhin empfangen und deren Nachrichten auch decodiert werden, einen Knoten nicht "rauswerfen", sondern höcshtns dafür sorgen, dass der Nutzer dieses Knotens dies entsprechend nicht mehr tun kann, was dazu führt, dass er, da er ja an der Nutzung des Knotens interessiert ist, diesen so einrichtet, dass er wieder spezifikationskonform ist.
:
Bearbeitet durch User
F. schrieb: > Der hätte ein paar Euro mehr gekostet, aber > wäre dann auf jeden Fall langfristig zuverlässig. Ich denke es ist alles zum Thema gesagt. Die Meinungen gehen auseinander, du kannst mich nicht bekehren und ich dich nicht, trotzdem alles ok. Ich investiere lieber in ein paar Euro weniger und kann für mich garantieren, dass alles solange läuft wie ich das will. Meinen Poolsensor nehme ich auch nicht mit in den Urlaub so dass mir das Netz keinen Mehrwert bringt. Also was soll's, wem TTN einen wirklichen Nutzen bringt der soll es machen. Einen Bienenwagen in der Pampa überwachen z.B. (wenn denn irgendwo ein Gateway vorhanden ist). Aber für stationäre Sachen die man in seinem Umfeld hat benutzt man besser ein locales Gateway ohne TTN oder ähnlich. Wie gesagt, dass ist meine Meinung und ich erhebe nicht den Anspruch dass andere sie zu ihrer machen.
Gottseidank habe ich mein gebrauchtes Microtik-Gateway schon vor Jahren zu einem besseren Preis verkauft, als ich neu zahlte. LoRaWAN brauche ich dank eigenem LoRa-Gateway und LoRa-APRS nicht mehr.
F. schrieb: > Es ist keine "politische" Entscheidung, sondern eine Entscheidung, die > dem Funktionieren des Netzwerks zugute kommt. Knoten, die sich nicht an > das vereinbarte Protokoll halten, und dazu gehört eben auch, auf > Uplink-Nachrichten zu reagieren, werden vom Netzwerk ausgeschlossen. > Sonst kann ja jeder kommen, der nächste Knoten sendet immer nur auf > einer Frequenz, der übernächste Knoten sendet immer mit SF12 und > reagiert nicht auf ADR-Nachrichten, uswusf.; das sorgt alles dafür, dass > das Netzwerk schlechter funktioniert, also werden diese Knoten > rausgeworfen. Das ist keine "politische" Entscheidung, sondern eine > technische Entscheidung. Einen Nachtrag habe ich aber noch. Ich will Sinn und Zweck des LoraWAN Standards nicht infrage stellen. Vieles was darin aber gemacht wird geht irgendwie davon aus, dass das Frequenzspektrum exclusiv für den Stack zur Verfügung steht. Dann hat der Zwang nach dieser Disziplin seine Berechtigung. Aber in einem öffentlichen Bereich wo es nur die bekannten Einschränkungen gibt, warum soll das den Stack in technischer Hinsicht aus der Bahn werfen wenn jemand nur auf einer Frequenz sendet oder immer mit SF12? Das darf er ja, anders wie beim Mobilfunk z.B., sowieso. Und wenn er das so will macht er es eben ohne TTN. Den Zwang den öffentlichen Frequenzbereich auch noch mit eigentlich überflüssigen Rückwärstpaketen zu fluten ist für alle kontraproduktiv. Das ist so als wenn man den Netzverkehr nur auf TCP beschränken würde obwohl UDP eindeutig die bessere Wahl wäre.
Spannende Diskussion, ich kann die Argumente von beiden Seiten verstehen. Im Endeffekt muss das jeder für sich entscheiden, ob er nur was für seinen Zweck bastelt oder den Mehraufwand betreibt und gleichzeitig was für die TTN Community tut... Der Vollständigkeit halber habe ich hier noch was gefunden, was das LoRa Physical Layer nutzt. Scheint aber leider auch eingeschlafen zu sein: https://www.radioshuttle.de/ Das im Betreff erwähnte Meshtastic ist nur eine Kommunikationslösung und hat nix mit Sensorknoten usw. zu tun, richtig? Hat sich damit schon jemand hier befasst?
Martin M. schrieb: > Das im Betreff erwähnte Meshtastic ist nur eine Kommunikationslösung und > hat nix mit Sensorknoten usw. zu tun, richtig? Hat sich damit schon > jemand hier befasst? Die Informationen dazu sind ein wenig von sehr viel Hype geprägt und wenig tatsächlicher Technikdiskussion. So wie ich das verstehe, ist Meshtastic ein Mesh-Netzwerk, das auf LoRa aufsetzt. Das ist erstmal spannend, da die Reichweite von LoRa recht hoch ist, ich persönlich sehe zumindest in Europa aber Probleme mit Sendezeitenbegrenzung im 868-MHz-Band: Es werden einfach nicht wahnsinnig viele große Nachrichten durchgeleitet werden können. Meshtastic dient vorwiegend der Text-Kommunikation zwischen Teilnehmern, es spricht aber auch wenig dagegen, da Sensordaten zu übertragen. Für besonders sinnvoll halte ich es indes nicht, da würde ich Lösungen bevorzugen, für die ich die ganze Middleware nicht mehr schreiben und einrichten muss (z.B. TTN). Das Problem bei Meshtastic ist allerdings, dass sich genügend Teilnehmer finden müssen, um die Nachrichten auch sinnvoll weiterzuleiten, sonst hast du eben auch nur sehr eingeschränkte Reichweite. Schaut man sich Meshtastic-Karten an, sieht es in Deutschland in vielen Gegenden sehr mau aus. Mesh-Netzwerke sind auch für Knoten hinsichtlich Energieverbrauch immer problematisch, da die einzelnen Knoten ständig empfangsbereit sein müssen und auch viel senden müssen. Für kleine Sensoren daher meines Erachtens nach eher ungeeignet, es sei denn, es läuft bereits Kommunikation mit einer Gruppe von Leuten über Meshtastic, die nun auch über dieses Medium Nachrichten von diesen Sensoren bekommen sollen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.