Seit dem ersten Dezember gibt es bei TTN nur noch V3. Da sind jetzt einige Fallstricke eingebaut, die für mich ein nogo sind. z.B. 1. TX-only Nodes werden ausgesperrt. Das sind z.B. alle die die tinyLora lib verwenden. Als Begründung wird angegeben, dass TTN zwingend über den Rückkanal die Parameter der Node (RX1 delay, Frequenzen u.s.w. ) einstellen will. Werden diese MAC-Commandos nicht bearbeitet, nimmt TTN die Packete der Node irgendwann nicht mehr an. 2. Das RX1 Delay wurde auf 5s verlängert. Das heißt nach dem Senden muss eine Node anstelle der bisherigen 1s + 1s jetzt 5s + 1s auf Empfang bleiben. Bestehende Hardware, die auf LMCI aufbaut macht das dann am V3 Stack auch so. Welche Auswirkungen das auf eine Batterielebensdauer haben kann sollte klar sein. Man kann zwar in den Deviceeinstellungen das RX1 Delay auf 1s festlegen, trotzdem versucht der Stack ins 5s Raster zu wechseln. 3. Alle Gateways die nicht alle 8 Kanäle abdecken sind obsolet. Klar der Fortschritt geht weiter, aber die unendlich großen Lücken die das Netz hat werden sicher nicht kleiner wenn man die User gängelt. Auf alle Fälle ist diese Politik nicht mein Ding. Und jeden blöden Temperatursensor oder Türkontakt einen Rückkanal aufzuzwingen und damit das Spectrum zu verstopfen ist das aller Letzte. Da bleibt man besser bei Lora ohne Wan. Ich hab hier auf vielleicht 2000 km² das einzige 8 Kanal Gateway am laufen und werde das nicht länger als Zukunftstechnologie betrachten und wieder verkaufen.
temp schrieb: > Seit dem ersten Dezember gibt es bei TTN nur noch V3. Da sind jetzt > einige Fallstricke eingebaut, die für mich ein nogo sind. z.B. > > 1. TX-only Nodes werden ausgesperrt. Das sind z.B. alle die die tinyLora > lib verwenden. Als Begründung wird angegeben, dass TTN zwingend über den > Rückkanal die Parameter der Node (RX1 delay, Frequenzen u.s.w. ) > einstellen will. Werden diese MAC-Commandos nicht bearbeitet, nimmt TTN > die Packete der Node irgendwann nicht mehr an. Tolle Idee! Find ich gut! Ab jetzt können wir bei den Smartmetern einen kleinen Störsender am Stromzähler platzieren mit ganz wenig Sendeleistung um den Empgänger zu blockieren. Dieser sendet dann munter weiter, empfgängt aber kein GW mehr und wird irgendwann ausgesperrt.
LoRana von TTN die Dritte schrieb: > Tolle Idee! Find ich gut! > > Ab jetzt können wir bei den Smartmetern einen kleinen Störsender am > Stromzähler platzieren mit ganz wenig Sendeleistung um den Empgänger zu > blockieren. Dieser sendet dann munter weiter, empfängt aber kein GW > mehr und wird irgendwann ausgesperrt. Hab ich was verpasst oder wo gibt es Smartmeter die über TTN kommunizieren? Ich glaube kaum, dass sich da jemals einer mit solchen ernsthaften Anwendungen wie Smartmetern auf TTN einlässt. Da würde ja wieder die Gefahr bestehen, dass ein Teil der Nodes draußen bleiben, wenn sich die Version des TTN Stacks ändert.
temp schrieb: > Seit dem ersten Dezember gibt es bei TTN nur noch V3. Da sind jetzt > einige Fallstricke eingebaut, die für mich ein nogo sind. z.B. ... Bitte Quellen nennen! Ich konnte dazu nichts finden. Danke.
Kann man ggf im eigenen Gateway konvertieren, in dem man die RX funtkion dort simuliert?
Flip B. schrieb: > Kann man ggf im eigenen Gateway konvertieren, in dem man die RX funtkion > dort simuliert? zuerst soll er das bitte mal belegen.
doschi schrieb: > Bitte Quellen nennen! Ich konnte dazu nichts finden. > Danke. Zu faul zum Suchen? Dann begib dich mal ins TTN Forum und such da nach der Diskussion zu tinyLora vom März/April. https://www.thethingsnetwork.org/forum/t/is-v3-the-end-for-tinylora/43525 Oder die von mir angestoßene Diskussion: https://www.thethingsnetwork.org/forum/t/tx-only-nodes/53561/2 Oder: https://githubmemory.com/repo/things4u/ESP-1ch-Gateway/issues/94 Flip B. schrieb: > Kann man ggf im eigenen Gateway konvertieren, in dem man die RX funtkion > dort simuliert? Klar kann man machen, das heißt aber dass das Gateway auch jedes Device kennen muss, weil es selbst die MAC Commandos nicht entschlüsseln kann. Aber wenn man das macht, kann man gleich ganz auf TTN verzichten und nimmt nur Lora. Eine eigenes Lora to Mqtt Gateway ist ja nun auch kein Hexenwerk.
Gähn. TTN V3 ist gut. Es ist schade, daß sie den Migrationspfad von v2 nicht so gut supporten, aber eigentlich auch nicht deren Aufgabe. Das Problem ist nicht TTN V3, sondern TTN V2. Man hat ein Netzwerk zugelassen, das sich in weiten Teilen nicht an die LoRaWAN-Spezifikation gehalten hat, um Technologieentwicklung und Experimentieren zu unterstützen. Ich erinnere mich noch, wie ich vor Jahren damit angefangen habe, mit einem zusammengebastelten ESP8266-Single-Channel-"Gateway" mit Drahtantenne und Arduino-Knoten als Sensoren. Das war nötig, da die Gateways schlecht erhältlich und sauteuer waren. Doch mittlerweile: 1) Gibt es gute günstige Gateways, die Raspberry-Pi-und-Konzentrator-Board-Bastellösung für viel Geld ist nicht mehr attraktiv. Ein ordentliches LoRaWAN-Gateway für den Heimgebrauch kostet um die 140 Euro, wer noch weniger bezahlen will, kriegt Lösungen, die sich nur per WLAN verbinden, auch für etwas weniger Geld. 2) Gibt es günstige Microcontroller, die die notwendige Power für LoRaWAN haben. Sowas wie TinyLora war immer zum Scheitern verurteilt, weil einfach klar war, dass die Leistung der Geräte so gut wie nicht ausreicht. Ist natürlich blöd, wenn man damit alles implementiert hat, kann ich verstehen. Aber das war nie spezifikationstreu und daher darf man dann auch nicht beleidigt sein, wenn die Spezifikationen eben irgendwann mal durchgesetzt werden. 3) Gibt es günstige kommerziell erhältliche LoRaWAN-Sensoren und günstige Entwicklungsboards, mit denen man unkompliziert eigene Lösungen entwickeln kann. Das funktioniert gut. 4) Ist es nötig, das Netzwerk "ordentlich" zu betreiben, da die Anforderungen steigen. TTN ist vom Hobby-Netzwerk durchaus zum ernstzunehmenden Netz geworden, das auch teilweise öffentlich gefördert als Netzwerk zur kommunalen Sensorüberwachung und Steuerung (Füllstand von Müllbehältern, Beleuchtung, etc.) genutzt wird. Bastler profitieren ungemein davon, weil einfach die Netzwerkabdeckung dann da ist, ohne eigene Gateways aufstellen zu müssen. TTN hat eine sehr gute Fair-Use-Policy und lässt auch beliebige Geräte zu. In vielen kommerziellen Netzwerken kannst du nicht einfach irgendein Gerät anmelden, sondern die Geräte müssen vom Netzwerkbetreiber zugelassen sein. Aber gerade weil man nun gerne im TTN die Verfügbarkeit und Netzwerkqualität sicherstellen will, damit Leute auch richtige Lösungen damit betreiben können und nicht nur experimentelles Gebastel, ist es notwendig, bestimmte Spezifikationen durchzusetzen. Das nervt, wenn man mit TTNv2 zurechtgekommen ist und ausgenutzt hat, dass diese Spezifikationen dort nicht so eng gesehen werden, aber es bringt jetzt auch nicht mehr viel, sich darüber aufzuregen. Der Rückkanal ist notwendig, um Knoten zu konfigurieren und auch die join-Nachrichten zu verarbeiten. ABP ist möglich, aber eigentlich kaum sinnvoll. Wer will, kann übrigens trotzdem noch individuell Framecounter-Checks abschalten. ADR ist wichtig, damit das Netzwerk nicht überlastet wird. Dein Knoten soll einfach immer so kurz (mit niedrigem SF) senden wie möglich. Ich weiß nicht, ob man Rx-Only-Nodes mit dauerhaft SF7 betreiben kann (ich kenne die Spezifikation nicht so genau) und dann eben keine Nachrichten zur Anpassung der Datenrate kriegt und auch nicht aus dem Netz geschmissen wird. Müsste man mal ausprobieren. Um die Netzqualität sicherzustellen, müssen auch die 1-Kanal-Bastelgateways weg. Die sind leider ein echtes Problem, da wir ja einen Kanalplan haben. Die Knoten senden immer auf allen Kanälen, um den Frequenzbereich möglichst gut auszunutzen und möglichst wenige Kollisionen zu erzeugen. Wenn ein Gateway jetzt nur auf einem Kanal empfängt, kriegt man nur jede 8. Nachricht des Knoten zugestellt. Das merkt auch das Netzwerk und wird wahrscheinlich versuchen, dem Knoten mitzuteilen, doch bitte den SF hochzudrehen, weil man von Empfangsproblemen ausgehen muss, wenn nicht alle Nachrichten ankommen. Das bringt aber wenig, weil der Knoten ja so toll senden kann, wie er will, da dein Gateway nur einen Kanal empfängt. Zum Basteln war das okay, da hat man sich halt einen Kanal ausgesucht und dann die Knoten manuell so konfiguriert. Geht ja immer noch, aber dann kann man halt nicht Teil eines Netzwerks sein. TTN hat Bedingungen, wer das nutzen will, muss sich denen fügen. Die Bedingungen sind meines Erachtens nach extrem fair und gut, daher stelle ich gerne mehrere Gateways zur Verfügung. Single-Channel-Gateways machen deutlich mehr Probleme als sie nützen. Mit einem normalen Gateway und einer brauchbaren Antenne deckt man bequem auch innerstädtisch mehrere Kilometer ab, für einen Gesamtpreis unter 200 Euro. Die Einstiegskosten sind mittlerweile so gering, dass man sich nicht mit den unzuverlässigen Single-Channel-Gateways rumärgern muss. Wenn du das alles nicht magst und nur Sensoren in deiner eigenen Umgebung hast, kannst du natürlich auch dein eigenes privates Netz betreiben, z.B. auf Chirpstack-Grundlage. Ich finde aber gut, dass ich meine Sensoren auch irgendwo hinstellen kann, wo mein Gateway eben nicht hinkommt und dennoch ein Signal kriege, weil sie Teil eines Netzwerks sind.
temp schrieb: > Zu faul zum Suchen? Es geht doch. Warum nicht gleich? Und die Pöpelei ist überflüssig. Falls Du mal wieder einen Thread eröffnest, dann auf einen sinnvollen Titel achten. Da fehlt "TinyLora".
temp schrieb: > 2. Das RX1 Delay wurde auf 5s verlängert. Das heißt nach dem Senden muss > eine Node anstelle der bisherigen 1s + 1s jetzt 5s + 1s auf Empfang > bleiben. Bestehende Hardware, die auf LMCI aufbaut macht das dann am V3 > Stack auch so. > Welche Auswirkungen das auf eine Batterielebensdauer haben kann sollte > klar sein. Man kann zwar in den Deviceeinstellungen das RX1 Delay auf 1s > festlegen, trotzdem versucht der Stack ins 5s Raster zu wechseln. > Ich vermute LMCI sollte LMIC heissen? Für den Fall keine Auswirkungen auf die Batterielebensdauer. Ausser man verwendet das Arduino Gebastel was das Timing mittels Busywaits macht. Die LMIC enthält einen minimalistischen Job Scheduler (oslmic.[ch]) der, falls hal_sleep() implementiert ist, die CPU schlafen legen kann wenn nix zu tun ist. Damit lässt sich ein Stromverbrauch (STM32L) von weniger als 1µA während der Pausen erreichen. Die Arduino Integration tut das nicht. > Auf alle Fälle ist diese Politik nicht mein Ding. Und jeden blöden > Temperatursensor oder Türkontakt einen Rückkanal aufzuzwingen und damit > das Spectrum zu verstopfen ist das aller Letzte. Da bleibt man besser > bei Lora ohne Wan. Ich hab hier auf vielleicht 2000 km² das einzige 8 > Kanal Gateway am laufen und werde das nicht länger als > Zukunftstechnologie betrachten und wieder verkaufen. Ich hätte Interesse, was ist das für ein Gateway, was soll er kosten? Gerne per PM. Gruß, Frank
:
Bearbeitet durch User
someone schrieb: > Wenn du das alles nicht magst > und nur Sensoren in deiner eigenen Umgebung hast, kannst du natürlich > auch dein eigenes privates Netz betreiben, z.B. auf > Chirpstack-Grundlage. Ich finde aber gut, dass ich meine Sensoren auch > irgendwo hinstellen kann, wo mein Gateway eben nicht hinkommt und > dennoch ein Signal kriege, weil sie Teil eines Netzwerks sind. Ich will deinen langen Text nicht weiter kommentieren. Vom Grundsatz her stimmt das was du schreibst. Die Problematik mit den 1 und 2 Kanal Gateways kenne ich und das ist der Punkt, bei dem ich noch mitgehe. Zumal viele Bastler die Problematik nicht mal kennen und mit ihren Nodes in Standardkonfiguration viele Pakete in die Luft rotzen die niemals einer empfangen kann. Die Sache mit den TX-Only Nodes ist aber eine völlig andere. Wenn hier der Zwang besteht, das jeder dumme Türkontakt oder Temperatursensor einen Rückkanal braucht und jedes Paket ein Antwortpaket produziert, dann müllt das das ohnehin schon knappe Band noch mehr ein. Anders als bei WLAN, hat TTN das Band ja nicht exklusiv. Und wenn die Bastler wieder nur Lora machen, landen die Pakete auch im selben Frequenzbereich. Es wäre ein leichtes gewesen, einfach in der Device-Konfiguration einen Checkbox für "Tx-Only" einzubauen mit dem Vorteil, das Datenvolumen mindestens zu halbieren. Klar kann ich mein eigenes Netz betreiben, das muss sich das Spektrum aber mit TTN und anderen teilen. Und wenn genügend andere Netze existieren, kann der TTN-Stack MAC-Commandos geben wie es will, besser wird es für TTN dadurch auch nicht. Man stelle sich diesen Zustand mal bei WLAN vor. Da bremsen Geräte mit altem Standard auch das Netz aus. Was würde das für einen Aufschrei geben wenn die alten Geräte von heute auf morgen nicht mehr gehen würden. Hier liegt es in der Hand dessen, der den AP betreibt was geht und was nicht. Könnte man bei TTN so was optional im Gateway konfigurieren wäre es auch noch gut. So gibt es hier aber eine zentrale Stelle an der alles hängt. Der Wechsel von V2 zu V3 bei TTN hat bei mir jedenfalls dazu geführt, dass ich da nicht mehr mitspiele. Ich habe hier sowieso das einzige Gateway weit und breit und werde es nicht weiter betreiben. Das ganze Bundesland hat nicht mal 40. Mal sehen was in 10 Jahren ist.
temp schrieb: > Ich will deinen langen Text nicht weiter kommentieren. Schade! temp schrieb: > Die Sache mit den TX-Only Nodes ist aber eine völlig andere. Wenn hier > der Zwang besteht, das jeder dumme Türkontakt oder Temperatursensor > einen Rückkanal braucht und jedes Paket ein Antwortpaket produziert, > dann müllt das das ohnehin schon knappe Band noch mehr ein. Wenn das tatsächlich so wäre, wäre das natürlich desaströs. Zum Glück ist es nicht so: Der Rückkanal wird nicht dafür benötigt, damit jede Nachricht eine confirmed message ist, die Nachrichten schickst Du weiterhin als normale unconfirmed messages. Den Rückkanal braucht man lediglich, damit das Netzwerk die Knoten richtig steuern kann, also für Aktivierung und insbesondere auch Netzwerkkonfiguration (Kanalplan, Datenrate). Das ist letztendlich wichtig, um das Netzwerk möglichst effizient zu halten. Kommt ein neues Gateway hinzu, sollen die Knoten in der Umgebung ihren Spreading Factor natürlich so weit wie möglich reduzieren und damit kürzere Nachrichten schicken, damit das 868-MHz-Band nicht so stark belegt wird. Das geht aber eben nur, wenn der Knoten irgendwelche Informationen dazu kriegt, wie denn sein Paket empfangen wurde und die kriegt er eben ab und an vom Netzwerk. Ich verstehe, dass es nervig ist, wenn man jetzt irgendwo Sensoren gebaut hat, aber andererseits kriegt man halt kein ernstzunehmendes Netzwerkprotokoll in superwenig Speicher rein. Ich finde, das hätte man natürlich schon viel früher deutlich besser und direkter kommunizieren sollen, da jetzt die Frustration natürlich verständlich ist: Einige Knoten, die bisher funktionierten, werden nun Probleme machen. Dabei war es von Anfang an absehbar, dass das in Netzen, die sich an die LoRaWAN-Spezifikation halten, so sein wird. Man hätte da dann deutlich früher mitteilen sollen, dass diese Libraries eine Technologiedemonstration sind und nicht für den Produktivbetrieb gedacht, weil sie keine vollständig spezifikationsgetreuen Geräte implementieren. temp schrieb: > Anders als > bei WLAN, hat TTN das Band ja nicht exklusiv. Bei WLAN hat auch niemand das Band exklusiv, im 868-MHz-SRD-Band gibt's ja zumindest noch maximal erlaubte Sendezeiten. Damit WLAN überhaupt funktioniert, braucht man schon ganz spezielle Empfänger. temp schrieb: > Man stelle sich diesen Zustand mal bei WLAN vor. Da bremsen Geräte mit > altem Standard auch das Netz aus. Was würde das für einen Aufschrei > geben wenn die alten Geräte von heute auf morgen nicht mehr gehen > würden. Ich höre keinen Aufschrei. In meiner Fritzbox kann ich kein WEP mehr konfigurieren, das wird einfach nicht mehr unterstützt. Es gibt sicher einige WLAN-Geräte, die kein WPA beherrschen. Die werden halt ersetzt. TTNv2 war ein unüblich freundliches Netz, das alle möglichen Geräte reingelassen hat, mitsamt der Probleme, die das nach sich zog. Es ist verständlich, dass man das nicht mehr will.
temp schrieb: > Die Sache mit den TX-Only Nodes ist aber eine völlig andere. Wenn hier > der Zwang besteht, das jeder dumme Türkontakt oder Temperatursensor > einen Rückkanal braucht und jedes Paket ein Antwortpaket produziert, > dann müllt das das ohnehin schon knappe Band noch mehr ein. Anders als > bei WLAN, hat TTN das Band ja nicht exklusiv. Und wenn die Bastler > wieder nur Lora machen, landen die Pakete auch im selben > Frequenzbereich. Es wäre ein leichtes gewesen, einfach in der > Device-Konfiguration einen Checkbox für "Tx-Only" einzubauen mit dem > Vorteil, das Datenvolumen mindestens zu halbieren. Bei WLAN ist das Frequenzband auch nicht exclusiv, bei LTE/5G wäre das so. Deshalb kostest da ja auch extra was. Es wird bei LoraWAN nicht für jede Message eine Rückantwort gesendet. Normalerweise sind die eher selten. Dennoch dienen die MAC Kommandos dazu die Knoten im Netz zu steuern damit die mit dem Frequenzband möglichst sparsam umgehen. Ausnahmen bestätigen die Regel: Wenn der Node eine Bestätigung für seine Message anfordert, dann wird das Netz diese auch über den Rückkanal senden. Sollte aber vermieden werden wenn nicht unbedingt nötig. Das der Übergang von TTNv2 nach TTNv3 einige Einschränkungen für ABP Nodes und single/dual Channel Gateways mitbringt ist nicht neu. Im TTN Forum wurde immer wieder, auch zu TTNv2 Zeiten, wiederholt dass diese nicht Zukunftssicher sind und daher nur zu experimentellen Zwecken eingesetzt werden sollten. Genau so ist dort öfters zu lesen dass Messages mit Bestätigung nur in Ausnahmefällen benutzt werden sollen. Gruß, Frank
Frank K. schrieb: > Ich vermute LMCI sollte LMIC heissen? Für den Fall keine Auswirkungen > auf die Batterielebensdauer. Ausser man verwendet das Arduino Gebastel > was das Timing mittels Busywaits macht. Die LMIC enthält einen > minimalistischen Job Scheduler (oslmic.[ch]) der, falls hal_sleep() > implementiert ist, die CPU schlafen legen kann wenn nix zu tun ist. > Damit lässt sich ein Stromverbrauch (STM32L) von weniger als 1µA während > der Pausen erreichen. Die Arduino Integration tut das nicht. Keine Auswirkung ist nicht richtig. Man kann die Zeit bis zu RX1 oder 2 zwar mit Schlafen überbrücken, in den RX Modus muss die dümmste Node dann trotzdem und wenigstens 1s warten oder bis ein Paket rein kommt. Bei TX-Only wäre das nicht nötig. Es geht auch nicht darum was man machen kann, sondern was mit den alten Nodes passiert. Klar kann man die große Fresse haben und auf das "Arduino Gebastel" schimpfen. Es ist jedenfalls kein guter Zug das Netz mit Hilfe dieser Bastler aufgebaut und getestet zu haben, und dann die gleichen Leute vor den Kopf stoßen mit dem Tenor: "Haut ab mit euren Spielkram". Ich selbst habe keine Arduinos oder AVRs, mich betrifft das nicht mal ernsthaft. Bisher habe ich eigene PCBs mit RFM95/96 und STM32 Chips im 32 Pin TQFP Format und verwende nur Lora. LoraWan ist bisher nur zum probieren. Der LMIC-Stack wird ja aktuell auch nur im Arduino Umfeld gepflegt: https://github.com/mcci-catena/arduino-lmic Deswegen sollte man mit dem Arduino schimpfen auch vorsichtig sein. Mittlerweile ist es ja so, entweder man schreibst seine Libs gleich selber oder man portiert Arduino-Libs zurück weil die ganze Welt nichts anderes mehr zu machen scheint. Ich hab mir den LMIC für mich so portiert, dass ich weder Arduino noch STM-Hal oder so was brauche. Alle anderen Versionen von LMIC werden scheinbar nicht mehr gepflegt und sind inkompatibel zu TTN V3. Frank K. schrieb: > Ich hätte Interesse, was ist das für ein Gateway, was soll er kosten? > Gerne per PM. Das Gateway ist ein Raspi mit einem IMST iC880a Board. Als Packetforwarder habe ich sowohl den alten Semtech als auch "basicstation" laufen. (natürlich nicht gleichzeitig). Verkaufen will ich das Teil nicht. Wenn es halt nicht mit TTN spielt, kann man das immer noch gut zum einsammeln seiner eigenen Sensoren verwenden. Da reichen ein paar Zeilen Code und es geht gleich in den eigenen Mqtt-Server.
someone schrieb: > Ich höre keinen Aufschrei. In meiner Fritzbox kann ich kein WEP mehr > konfigurieren, das wird einfach nicht mehr unterstützt. Es gibt sicher > einige WLAN-Geräte, die kein WPA beherrschen. Du kannst aber eine AP einsetzen der das kann. Und wenn der das schon immer konnte geht's ja auch. Bei LoraWan hat aber das Gateway nicht die Macht etwas zu bestimmen. Mit dem Wechsel auf V3 war es das dann. someone schrieb: > Kommt ein neues Gateway hinzu, sollen die Knoten in > der Umgebung ihren Spreading Factor natürlich so weit wie möglich > reduzieren und damit kürzere Nachrichten schicken, damit das > 868-MHz-Band nicht so stark belegt wird. Das geht aber eben nur, wenn > der Knoten irgendwelche Informationen dazu kriegt, wie denn sein Paket > empfangen wurde und die kriegt er eben ab und an vom Netzwerk. Den Gedanken daran verstehe ich schon. Selbst wenn es funktionieren sollte, semmeln alle anderen 868MHz Anwendungen trotzdem dazwischen. Aber was soll's, dann verwerfe ich eben den Gedanken mit zu helfen das sich die Technologie verbreitet und sende weiter auf den gleichen Frequenzen mit einem SF wie es mir passt. Schließlich kann sowieso keiner dafür garantieren, daß TTN in 10 oder 20 Jahren noch existiert. Oder dass nicht in 3 Jahren die V5 zum Einsatz kommt die wieder Ich beobachte das ganze ca. 1 Jahr, wenn sich wenigstens der Zubau von Gateways an Corona ein Beispiel nehmen würde, könnte man ja die eine oder andere Kröte schlucken.
Ich glaube mittlerweile, dass du dich nur über irgendwas aufregen willst. Technologien entwickeln sich weiter, Geräte veralten. Das ist der Lauf der Dinge. Wenn du da irgendwo im Mecklenburgischen Nirgendwo kein TTN-Gateway mehr betreiben willst, weil dir die Nutzungsbedingungen des Netzwerks nicht passen, nun gut. Das darfst du ja gerne.
someone schrieb: > Wenn du da irgendwo im Mecklenburgischen Nirgendwo > kein TTN-Gateway mehr betreiben willst, weil dir die Nutzungsbedingungen > des Netzwerks nicht passen, nun gut. Das darfst du ja gerne. Es ist kein Mecklenburgisches Nirgendwo sondern fast genau die Mitte Deutschlands. > weil dir die Nutzungsbedingungen > des Netzwerks nicht passen, nun gut. Das darfst du ja gerne. Genau mache ich someone schrieb: > Ich glaube mittlerweile, dass du dich nur über irgendwas aufregen > willst. Technologien entwickeln sich weiter, Geräte veralten. Ja ich war war mal begeistert von TTN und habe viel Zeit investiert um mich da einzuarbeiten und hatte nie tinyLora oder andere TX-Only Geschichten gemacht. Aber das Netz ist voll davon. Und alle haben geholfen dazu beizutragen dass es weiter voran ging. Und jetzt ist man so arrogant zu sagen "Schert euch zum Teufel". Diese Politik kann ich weder verstehen noch unterstüten. Jedenfalls nicht zum jetzigen Zeitpunkt. In 5 Jahren vielleicht wenn TTN eventuell wirklich ein Netz ist und Engpässe und Verstopfungen drohen vielleicht. Aber nicht jetzt mitten in der Chipkrise.
> tinyLora oder andere TX-Only > Aber das Netz ist voll davon. Es ist in der Tat ärgerlich wenn jemand mehrere(viele) solche Sensoren verbaut hat. Aber es könnte doch einen "Konzentrator" geben der die Signale dieser Sensoren empfängt und dann gemäß der V3 Spezifikation an das TTN weiter meldet. So kann der Betreiber dieser Sensoren entscheiden ob seine Sensoren ersetzt, oder so einen Konzentrator aufstellen will.
asd schrieb: > Aber es könnte doch einen "Konzentrator" geben der die Signale dieser > Sensoren empfängt und dann gemäß der V3 Spezifikation an das TTN weiter > meldet. Diese alten Sensoren senden ja keine Packete die nicht der Spezifikation entsprechen sondern sie sind völlig konform. Sie antworten einfach nur nicht auf Anfragen/Befehle von TTN. Nachdem ein Packet von so einem (ABP)Sensor bei TTN einläuft wird im nächsten RX1 Fenster (jetzt noch 1s) von TTN ein MAC-Commando gegeben, dass er ab sofort mit 5s RX1 Delay arbeiten soll. Das muss der Sensor dann im nächsten Packet bestätigen. Da die einfachen Sensoren aber nicht empfangen, klappt dieser Mechanismus natürlich nicht. Und wenn das nicht mehr klappt, wird der Sensor dann halt ausgesperrt. Der Concentrator hat hier wenig Mittel. Er müsste wenn schon, die gegebenen MAC Commandos entschlüsseln und entsprechende Antworten senden. Da TTN aber Ende zu Ende verschlüsselt ist, geht das nur wenn der Concentrator die Keys der Sensoren kennen würde. Das wäre dann aber noch größerer Schwachsinn. Man könnte jetzt auf die Idee kommen, dass die einfachen Sensoren einfach alle Bestätigungsflags in jedem Befehl mit senden. Keine Ahnung ob der Stack diese Manipulation frisst. Und wenn er es sollte, ist es noch viel weiter von der Spezifikation weg als der jetzigen Zustand.
temp schrieb: > 1. TX-only Nodes werden ausgesperrt. Das sind z.B. alle die die tinyLora > lib verwenden. Als Begründung wird angegeben, dass TTN zwingend über den > Rückkanal die Parameter der Node (RX1 delay, Frequenzen u.s.w. ) > einstellen will. Werden diese MAC-Commandos nicht bearbeitet, nimmt TTN > die Packete der Node irgendwann nicht mehr an. Meine TX-only ATTNodes (v2) [1] funktionieren mit TTN v3 aktuell (noch?). Allerdings nur, wenn sie wie hier [2] beschrieben per CLI registriert werden. Dann versucht TTN keine Downlink-Pakete zu senden. Wenn ich den Node über die Web UI registriere hingegen schon. Keine Ahnung wo der Unterschied liegt und ob das Bug oder Feature ist. [1] https://www.attno.de/11-attnode_v2 [2] https://www.attno.de/blog/2021-09-02
Frieder S. schrieb: > Dann versucht TTN keine Downlink-Pakete zu senden. Klar, wenn die node mit der Konfiguration engerichtet wird, die ttn am Ende haben will, braucht nichts mehr umkonfiguriert werden. Sollte der Stack irgenwann aber der Meinung sein die Datenrate oder der SF sollten sich ändern kann das Spiel von vorn los gehen. Mal sehen wie sich das entwickelt.
demo schrieb: > Ja ich war war mal begeistert von TTN und habe viel Zeit investiert um > mich da einzuarbeiten und hatte nie tinyLora oder andere TX-Only > Geschichten gemacht. Und warum bist du jetzt nicht mehr begeistert? Weil die ihr Netz auf eine funktionierende Infrastruktur umstellen wollen, mit der man was machen kann? Beinahe jeden Tag gibt's wieder irgendwelchen neuen kommerziellen Mist mit ggf. eingeschränkter Nutzbarkeit für Hobbyisten--bei TTN kriegst du auch als Hobbyist eine einigermaßen professionelle Lösung und musst dich nicht irgendwelchem kommerzialisietem Quatsch unterwerfen. Andere Netzbetreiber fackeln nicht lange und werfen alle Geräte aus dem Netz, die sie nicht geprüft haben. Man kann damit rechnen, dass bei solchen Betreibern Geräte, die zu alt sind und irgendwelche neuen Spezifikationen nicht erfüllen, zumindest perspektivisch nicht mehr ins Netz aufgenommen werden. Bei TTN kannst du mit deinem Microcontroller-Gebastel genauso das Netz nutzen wie mit einem teuren kommerziellen Sensor. Und wenn du nie TX-Only-Sachen gemacht hast, wo ist denn da dein Problem? Aus Prinzip? Ich glaube, du willst dich nur über irgendwas aufregen und dir geht's gar nicht um die Sache, sondern nur darum, dass sich jetzt was ändert. > Aber das Netz ist voll davon. Und alle haben > geholfen dazu beizutragen dass es weiter voran ging. Nein. Das Netz wird durch Geräte, die sich nicht spezifikationskonform verhalten, allenfalls verschlimmbessert. TX-only nodes sind nicht vorgesehen. Kann man schlecht finden, ist vielleicht ein bisschen ungünstig, aber die sind nunmal nicht vorgesehen. > Und jetzt ist man > so arrogant zu sagen "Schert euch zum Teufel". Äh, nein? Genau das macht man nicht. Man hat schon lange darauf hingewiesen, dass die Dinge, die nicht spezifikationskonform sind, irgendwann einmal Probleme bereiten können. Der Zeitpunkt ist jetzt (bzw. noch nicht, aber bald). Es gibt Unterstützung, wie man tx-only-Nodes so konfiguriert, dass das Netz keine Notwendigkeit sieht, ihnen Nachrichten zu schicken. Ja, das ist absurd viel Aufwand, aber wer einen Netzteilnehmer betreibt, der sich nicht spezifikationsgemäß verhält, darf sich über Aufwand nicht beschweren. Die richtige Vorgehensweise hier wäre übrigens meiner Meinung nach, den Nutzern mit nicht richtig eingerichteten tx-only-Nodes und anderem Zeug, das sich nicht an die Spezifikationen halten will nach reichlich Vorwarnung die Zugänge zu ihren Daten (und zwar bitteschön allen) abzudrehen, bis das korrigiert ist. > Diese Politik kann ich > weder verstehen noch unterstüten. Jedenfalls nicht zum jetzigen > Zeitpunkt. Warum? Der Zeitpunkt ist genau richtig. Wir haben mit dem STM32WL55 einen benutzbaren Chip, der ein LoRa-Modul integriert hat. Das Ding kann viel und ist kostengünstig. Wir haben mit dem ASR6501, der aber etwas seltsam ist, sowas ja auch schon, aber der STM32WL55 ist einfach nochmal besser, weil er einfach viel mehr kann. Die Entwicklungsboards für LoRaWAN-Lösungen sind kostengünstig, die Gateways kommen mittlerweile auch in gute Preisbereiche und sind keine schrecklichen Bastellösungen mehr. Jetzt ist der Zeitpunkt, zu dem Lösungen entwickelt werden und die Leute Netze suchen, die sie nutzen und ggf. mit aufbauen. Wenn TTN das nicht leisten kann, weil sie zu vernarrt darauf sind, Leute zu befriedigen, die auf Teufel komm raus einen ATTiny84 benutzen wollen, weil man den in einen Sockel auf eine Lochrasterplatine stecken kann, dann hat das keine Zukunft. Die jetzige Richtung ist schon gut. > In 5 Jahren vielleicht wenn TTN eventuell wirklich ein Netz > ist und Engpässe und Verstopfungen drohen vielleicht. Aber nicht jetzt > mitten in der Chipkrise. Aha. Wie gesagt, nimm dein Gateway und deine Knoten aus dem Netzwerk, wenn du jetzt beleidigt bist, es wird ja sicher irgendwann jemand anderes kommen, der gerne Abdeckung haben will und sich dann einfach für 150 Euro ein Gateway mit ordentlicher Antenne hinstellen. Ich betreibe mehrere davon und kann das nur empfehlen. Gleichzeitig nutze ich auch vorhandene TTN-Infrastruktur für Sensoren, die nicht in Reichweite meiner Gateways sind. Ich finde es auch gut, dass TTN gleiches Recht für Alle umsetzt. Als Gateway-Betreiber habe ich keinerlei Vorteile und das ist auch gut so. Man stellt Infrastruktur bereit, die unbedingt zuverlässig laufen muss. Wenn man da nun im Gegenzug irgendwelche Möglichkeiten zulässt, das Netz bzw. das eigene Gateway stark zu belasten, dann ist das nur kontraproduktiv. TTN wird nur dann zum ordentlichen Netz, wenn es Nutzungsszenarien gibt, für die man die Leute begeistern kann. In einigen Gegenden haben Kommunen entdeckt, dass das ja ein tolles Netz ist, um Sensoren in der Kommune zu überwachen, mit geringsten Betriebskosten und dem zusätzlichen Bonus, das als tolles Innovationsprogramm für Bürger und kleine Unternehmen verkaufen zu können, die damit etwas entwickeln wollen. Andere Kommunen lassen sich von ihren Stadtwerken teuer kleine geschlossene LoRaWAN-Netze aufbauen, davon hat dann niemand was. Das wichtigste für die gute Nutzung ist aber, dass es ordentlich funktioniert und dafür ist nunmal der Stand der Dinge, dass ein Rückkanal zum Knoten benötigt wird, um diesem Kommunikationsparameter mitzuteilen.
someone schrieb: > Warum? Der Zeitpunkt ist genau richtig. Wir haben mit dem STM32WL55 > einen benutzbaren Chip, der ein LoRa-Modul integriert hat. Das Ding kann > viel und ist kostengünstig. Wir haben mit dem ASR6501, der aber etwas > seltsam ist, sowas ja auch schon, aber der STM32WL55 ist einfach nochmal > besser, weil er einfach viel mehr kann. Die Entwicklungsboards für > LoRaWAN-Lösungen sind kostengünstig, die Gateways kommen mittlerweile > auch in gute Preisbereiche und sind keine schrecklichen Bastellösungen > mehr. > Jetzt ist der Zeitpunkt, zu dem Lösungen entwickelt werden und die Leute > Netze suchen, die sie nutzen und ggf. mit aufbauen. Wenn TTN das nicht > leisten kann, weil sie zu vernarrt darauf sind, Leute zu befriedigen, > die auf Teufel komm raus einen ATTiny84 benutzen wollen, weil man den in > einen Sockel auf eine Lochrasterplatine stecken kann, dann hat das keine > Zukunft. Die jetzige Richtung ist schon gut. Fällt dir nicht mal auf was du für einen arroganten Schwachsinn schreibst? Es geht nicht darum ob die Leute heute ATTiny84 verbauen wollen, sondern es ist so verbaut worden und im Einsatz. Das ist schon ein gewaltiger Unterschied. Die bestehenden Installationen werden ausgeschlossen, nicht nur die neuen. Und wenn ich mir die Kommentare weiter oben ansehe, haben zwar die meisten mitbekommen, dass es nur noch den V3 Stack geben wird. Aber was das für Konsequenzen hat muss man sich aus den Foren zusammen klauben. Ne Freunde was ihr da macht ist das gleiche als wenn man den Oldtimer verbieten würde das Straßennetz zu benutzen, weil sie nicht mehr auf dem Stand der Technik sind. someone schrieb: > Bei TTN > kannst du mit deinem Microcontroller-Gebastel genauso das Netz nutzen > wie mit einem teuren kommerziellen Sensor. > Und wenn du nie TX-Only-Sachen gemacht hast, wo ist denn da dein > Problem? Aus Prinzip? Ich glaube, du willst dich nur über irgendwas > aufregen und dir geht's gar nicht um die Sache, sondern nur darum, dass > sich jetzt was ändert. Nein, und nun zum allerletzen mal, es geht nicht darum was ich jetzt und in Zukunft will, sondern darum dass bestehende Teilnehmer ausgegrenzt werden mit absolut schwachsinnigen Begründungen. Und ja, es geht mir hier nur ums Prinzip und um die Einschätzung ob so etwas wie jetzt in ein paar Jahren wieder passieren kann. Der Fortschritt ist ja nicht aufzuhalten und wenn eure Argumentation die gleiche bleibt ist es abzusehen, dass es wieder so kommt, weil man beschlossen hat dass alles was nicht mindestens dem Standard 1.0.4 genügt draußen bleiben muss. Lies dir deine Beiträge mal durch, das ist eine absolut herablassende Art und Weise wie du von Microcontroller-Gebastel und den AVR-Usern sprichst. someone schrieb: > Das > wichtigste für die gute Nutzung ist aber, dass es ordentlich > funktioniert und dafür ist nunmal der Stand der Dinge, dass ein > Rückkanal zum Knoten benötigt wird, um diesem Kommunikationsparameter > mitzuteilen. Ja genau, es ist absolut nötig einer TX-Only Node die RX Parameter mit zu teilen... Was bleibt denn sonst noch übrig? Die Sendeleistung? Da kann die Node ohnehin machen was sie will. Die Frequenzen? Wenn keiner mehr die Node hört stört sie auch keinen mehr (im TTN-Netz). Oder den SF Faktor? Da ist ein Thema wenn aus dem Lückenteppich wirklich mal ein Netz wird. In 5 Jahren vielleicht. Das beharren auf "dem Stand der Dinge" ist das Problem. Das kennzeichnet welche Politik gefahren wird. Und anders als in anderen Netzen wo eine Rückwärtsportabilität an oberster Stelle steht hat sich TTN für den "fortschrittlichen" Weg entschieden und damit jedenfalls das Vertrauen eines Teils der User verspielt. Und dabei ist es wie in der Politik, die oberste Priorität bei der Entscheidung ob man TTN benutzt hat die Frage ob man dem Netz jetzt und in Zukunft vertrauen kann. Und das beantworte ich für mich eindeutig mit nein. Und wenn wir von kommunalen Dingen sprechen wie du oben, dann sind das in der Regel feststehende Nodes. Der Kostenaufwand hierfür ein Mininetz aufzuspannen ist nicht größer als TTN zu nutzen wenn man die Gateways mangels Abdeckung selbst beisteuern muss. Ehr weniger. Aber man hat eine Investitionssicherheit die man bei TTN nicht hat. So damit beende ich die Diskussion mit someone da sowieso keine neuen Argumente mehr hinzukommen.
temp schrieb: > Fällt dir nicht mal auf was du für einen arroganten Schwachsinn > schreibst? Gehts's noch?
temp schrieb: > Fällt dir nicht mal auf was du für einen arroganten Schwachsinn > schreibst? Schön, dass du mich darauf hinweist. Nein, fällt mir nicht auf. Ich bleibe nur dabei, dass du dich nur künstlich aufregen willst und die TTN-Umstellung bietet sich gerade aus Aufhänger ganz gut an. Man kann das aber aus zwei Perspektiven sehen: Der Perspektive eines nutzbaren Netzes oder der Perspektive experimenteller Installationen. Für ein Netz ist das kein arroganter Schwachsinn, sondern Grundvoraussetzung dafür, dass es funktioniert. Wenn du halt der einzige bist, der in deiner Umgebung irgendwas betreibt, dann siehst du offensichtlich den Vorteil des Netzes nicht, für den man dann eben individuelle Einschränkungen inkaufnehmen muss. temp schrieb: > Es geht nicht darum ob die Leute heute ATTiny84 verbauen > wollen, sondern es ist so verbaut worden und im Einsatz. Das ist schon > ein gewaltiger Unterschied. Die bestehenden Installationen werden > ausgeschlossen, nicht nur die neuen. Ja, das ist auch in Ordnung so: Die bestehenden Installationen waren nämlich nie spezifikationsgemäß. Wenn bisher nichts passiert ist, ist das schön, aber das ist nicht in alle Ewigkeit garantiert. Natürlich werden sich viele early adopter zunächst mit Knoten ins Netzwerk gewagt haben, die einfach aufzubauen sind, aber eben die Spezifikation nicht vollständig umsetzen (damit sind sie nicht spezifikationsgemäß). Allerdings: Als early adopter weiß man, dass sich die Technik weiterentwickelt und man ggf. recht viel Aufwand haben wird. > Und wenn ich mir die Kommentare weiter oben ansehe, haben zwar die > meisten mitbekommen, dass es nur noch den V3 Stack geben wird. Aber was > das für Konsequenzen hat muss man sich aus den Foren zusammen klauben. Ja, und? Für spezifikationsgemäße Knoten: Nahezu keine Konsequenzen. Es ist absurd: Wir unterhalten uns hier echt darüber, inwiefern man Leute hofieren muss, die nicht-spezifikationsgemäße Netzwerkteilnehmer betreiben. Es ist ja nicht so, dass es irgendeine uralte LoRaWAN-Spezifikation gibt, nach der die Teilnehmer dann konform wären; das wäre dann etwas Anderes. TX-Only-Nodes waren aber einfach noch nie zulässig, bisher gab's eben keine Probleme damit. Du kannst deinen Backofen auch mit Klingeldraht ans Stromnetz anschließen, wenn du nur die Uhr haben willst. Das ist nicht zulässig und war nie zulässig, aber für eine sehr spezielle und eingeschränkte Anwendung funktioniert das. Gut, TX-Only-Nodes sind, im Gegensatz zu diesem Backofen, nicht gefährlich, aber sie stören trotzdem das Netzwerk, weil sie nicht reagieren und durch unbeantwortete Kommunikationsversuche Netzwerkkapazität binden. > Ne Freunde was ihr da macht ist das gleiche als wenn man den Oldtimer > verbieten würde das Straßennetz zu benutzen, weil sie nicht mehr auf dem > Stand der Technik sind. Ich weiß nicht, ob du schonmal mitgekriegt hast, dass wir genau das machen: Für Autos, die zu alt sind, sind manche Straßen nicht mehr benutzbar. Wir nennen das Umweltzonen und machen das, um die Bewohner von Städten vor Leuten zu schützen, die auf Teufel komm raus an irgendwelchem alten Zeug festhalten wollen, obwohl es schlecht ist. Oldtimer sind davon ausgenommen, die werden aber auch nicht produktiv eingesetzt (dann kriegst du kein H-Kennzeichen), sondern gewissermaßen im Demonstrations- oder Testbetrieb. Wenn du Schülern in einem Ferienkurs zeigen willst, wie man einen LoRaWAN-Stack implementiert, wird sich niemand darüber aufregen, wenn ihr nachher nur TX-Only-Nodes rauskriegt. TTN (auch v3!) erlaubt ja auch, die zu Demonstrationszwecken in Betrieb zu nehmen und kündigt dir nicht sofort den Vertrag, weil du irgendwelches halbgare Zeug ins Netz gebracht hast. temp schrieb: > Nein, und nun zum allerletzen mal, es geht nicht darum was ich jetzt und > in Zukunft will, sondern darum dass bestehende Teilnehmer ausgegrenzt > werden mit absolut schwachsinnigen Begründungen. Die Begründung ist nicht schwachsinnig: Es macht das Netz kaputt. LoRaWAN ist ein Netz, für das wenige Basisstationen benötigt werden, aber es ist nicht besonders resilient gegen schlechte Knoten und schlechte Basisstationen. > Und ja, es geht mir > hier nur ums Prinzip und um die Einschätzung ob so etwas wie jetzt in > ein paar Jahren wieder passieren kann. Kann schon sein, meine Kristallkugel ist gerade in der Werkstatt, die muss mal neu poliert werden. Regst du dich auf, dass dein UMTS-Handy nicht mehr funktioniert? Warum eigentlich nicht? Die haben das einfach abgeschaltet, nach nicht einmal 20 Jahren. > Der Fortschritt ist ja nicht > aufzuhalten und wenn eure Argumentation die gleiche bleibt ist es > abzusehen, dass es wieder so kommt, weil man beschlossen hat dass alles > was nicht mindestens dem Standard 1.0.4 genügt draußen bleiben muss. Wie gesagt, das kann passieren. Ich halte es aber für unwahrscheinlich. Spezifikationskonforme Knoten können ja durch den Rückkanal umkonfiguriert werden und es gibt eine Menge dieser Knoten in vielen verschiedenen Netzen. Selbst wenn man irgendwann mal auf die Idee käme, das ganze alte Zeug möglichst nicht mehr in den Bändern für neue tolle Knoten haben zu wollen, könnte man die ganzen alten Sachen durch eine Konfigurationsnachricht einfach auf weniger Kanäle einschränken und trotzdem weiter betreiben. Die Spezifikationen sind aber durchaus so entwickelt, dass lange Nutzungszeiten angedacht sind und funktionieren können, insofern mache ich mir da keine Sorgen. Du kannst ja auch die zu nutzende Version beim Anmelden deines Knoten einstellen. Nur muss er halt irgendwann mal die Spezifikation erfüllt haben. > Lies dir deine Beiträge mal durch, das ist eine absolut herablassende > Art und Weise wie du von Microcontroller-Gebastel und den AVR-Usern > sprichst. Nö, warum? Ich bastle ja selbst. An manchen Standorten, an denen ich gerne Sensoren hätte, gibt es keine TTN-Abdeckung, wohl aber Abdeckung durch kommerzielle LoRaWAN-Netze. Keine Chance, die lassen keine Eigenbauten rein. Im TTN geht das. Der ATTiny84 ist ein seltsamer Chip, der aus welchem Grund auch immer extrem beliebt ist. Zugegeben, die Handhabung ist leicht, aber das war's dann auch schon. Allerdings muss ich den ja auch nicht nutzen und jeder, der mag, darf meinetwegen alle Microcontroller nutzen, die es so gibt. Nur wenn man Teilnehmer eines Netzwerks sein will, dann muss man die Netzwerkspezifikationen erfüllen. temp schrieb: > Ja genau, es ist absolut nötig einer TX-Only Node die RX Parameter mit > zu teilen... Was bleibt denn sonst noch übrig? RX-Parameter? Nein, TX-Parameter werden dem mitgeteilt, z.B. der Kanalplan und die Modulationsrate. > Die Sendeleistung? Da > kann die Node ohnehin machen was sie will. Die Frequenzen? Wenn keiner > mehr die Node hört stört sie auch keinen mehr (im TTN-Netz). Oder den SF > Faktor? Da ist ein Thema wenn aus dem Lückenteppich wirklich mal ein > Netz wird. In 5 Jahren vielleicht. Diese Argumentation ergibt überhaupt keinen Sinn. Du sagst im Prinzip nur, dass du das alles nicht brauchst, weil die Knoten ja eh machen können, was sie wollen. Ja, können sie. Sobald sie das machen, müssen sie aber unbedingt aus dem Netzwerk fliegen. Du gehst ja einen Kontrakt ein, der beschreibt, wie sich die Netzwerkteilnehmer verhalten müssen. Wird der erfüllt, funktioniert das Netzwerk. Wenn du nicht Teil des Netzwerks sein willst, musst du dich auch nicht an die Netzwerkbedingungen halten, so einfach ist das. Ich verstehe ehrlich gesagt die Argumentation nicht. Damit das Netzwerk effizient funktioniert, muss es einen Rückkanal an die Knoten geben, damit diese für einen optimalen Betrieb des Netzwerks konfiguriert werden können. Das lehnst du aus irgendwelchen Gründen ab, weil du ja sowieso der einzige bist, der in deiner Gegend ein Gateway betreibt und dich jetzt ärgerst, dass TX-Only-Nodes nun genau spezifikationsgetreu nicht mehr ohne aufwendige Konfiguration funktionieren werden? Obwohl du keine betreibst und auch im Einzugsbereich deines Gateways keine betrieben werden? Du bist doch nur hier, um dich über Änderungen zu echauffieren. > Das beharren auf "dem Stand der Dinge" ist das Problem. Das kennzeichnet > welche Politik gefahren wird. Und anders als in anderen Netzen wo eine > Rückwärtsportabilität an oberster Stelle steht hat sich TTN für den > "fortschrittlichen" Weg entschieden und damit jedenfalls das Vertrauen > eines Teils der User verspielt. Da irrst du. TTN erlaubt sehr viel, deutlich mehr, als andere Netze. Sie haben beispielsweise immer noch das grausame ABP. Aber gut, vielleicht kenne ich mich nicht so gut aus wie du, daher eine Bitte: Magst du mir mal bitte andere (LoRaWAN)-Netze nennen, oder meinetwegen andere WANs, die nicht-spezifikationsgetreue Teilnehmer irgendwann erlaubten und danach sicherstellten, dass diese über viele Jahre und Infrastrukturänderungen hinweg noch funktionieren? Es würde mich wirklich interessieren, wie das gelöst werden kann, denn ich stelle mir das als undankbare und teure Aufgabe vor, dabei sicherzustellen, dass die moderneren, spezifikationsgetreuen Netzwerkteilnehmer nicht benachteiligt werden. > Und dabei ist es wie in der Politik, die > oberste Priorität bei der Entscheidung ob man TTN benutzt hat die Frage > ob man dem Netz jetzt und in Zukunft vertrauen kann. Und das beantworte > ich für mich eindeutig mit nein. Ich bin mir nicht so sicher, ob sich das finanzielle Modell lohnt und würde gerne einen kostenpflichtigen Unterstützer-tier ohne größere Vorteile (vielleicht ein paar mehr EUIs) sehen, der aber für Hobbyisten bezahlbar ist. Ansonsten sind die meines Erachtens nach deutlich vertrauenswürdiger als andere Anbieter, die keine sehr hohen Einstiegshürden haben. Für ein bisschen Hobby-Sensorik oder kleinere Anwendungen sowieso. > Und wenn wir von kommunalen Dingen sprechen wie du oben, dann sind das > in der Regel feststehende Nodes. Der Kostenaufwand hierfür ein Mininetz > aufzuspannen ist nicht größer als TTN zu nutzen wenn man die Gateways > mangels Abdeckung selbst beisteuern muss. Ehr weniger. Aber man hat eine > Investitionssicherheit die man bei TTN nicht hat. Die meisten LoRaWAN-Knoten werden wohl feststehend sein. Du denkst aber genau falschrum: Bei TTN hat man was für die Bürger und die lokale Industrie getan, außerdem wird der lästige Betrieb des Netzes einfach an einen Dienstleister ausgelagert, der das auch noch gratis macht. Damit werden Parkplätze überwacht, Straßenlaternen gesteuert und der Müllbehälterfüllstand übermittelt, was nichts ist, worauf man nicht auch mal ein paar Tage verzichten könnte, wenn's ganz hart kommt. Dafür spart man sich eigene Infrastruktur, die Geld kostet und auch gewartet werden muss, sondern stellt ein paar Gateways auf und das war's dann. > So damit beende ich die Diskussion mit someone da sowieso keine neuen > Argumente mehr hinzukommen. Von dir habe ich bisher wenig neue Argumente gehört, warum das jetzt so ein immenses Problem ist, mit dem man nicht leben kann.
someone schrieb: > Der ATTiny84 ist ein seltsamer Chip, der aus welchem Grund auch immer > extrem beliebt ist. Zugegeben, die Handhabung ist leicht, aber das war's > dann auch schon. In diesem Punkt gebe ich dir vollkommen Recht. Ich habe diese Chips aber weder verwendet noch hier ins Spiel gebracht. Bei allen anderen Punkten haben wir komplett gegensätzliche Meinungen. Aber das macht genau nichts. Du wirst mich nicht bekehren und ich dich sicher auch nicht. Und die Tatsache, dass sich sonst so gut wie niemand an der Diskussion beteiligt hat oder über den Sachverhalt was wusste, spricht Bände. Entweder es versteht kaum einer oder es interessiert keinen. Ist mir aber auch egal. Wenn das Netz mal in meine Reichweite (<10km) kommen sollte denke ich eventuell neu drüber nach. Bis dahin gibts halt Lora ohne WAN und ohne Verfallsdatum.
temp schrieb: > > Entweder es versteht kaum einer oder es interessiert keinen. Also mich interessiert es schon, nur mit dem Verstehen klappts nicht so recht. Die vielen Bezeichner sind mir meisst fremd und sagen mir nur am Rande etwas. Ich habe mir selber (nur "Lora") Anwendungen eingerichtet, da gibts halt "Senden nach (variabler) Zeit" und mitlesen. Funktioniert seit Jahren problemlos. Kurt
Kurt schrieb: > Ich habe mir selber (nur "Lora") Anwendungen eingerichtet, da gibts halt > "Senden nach (variabler) Zeit" und mitlesen. > Funktioniert seit Jahren problemlos. Dann hast du Glück gehabt, denn gewusst kannst du das ja nicht haben wie du sagts. Und wenn du Pech gehabt hättest, würdest du eventuell solche Klimmzüge machen müssen: https://www.iot-lab.org/blog/663/ Ob dem Netz damit wohl geholfen ist?
temp schrieb: > Aber wenn man das macht, kann man gleich ganz auf TTN verzichten und > nimmt nur Lora. Eine eigenes Lora to Mqtt Gateway ist ja nun auch kein > Hexenwerk. Genau das will ich machen. Ich will auch kein TTN mehr. Ich habe die Diskussion aufmerksam verfolgt und kann temp sehr gut verstehen. Ich selber habe durch ein Bastelprojekt der Zeitschrift Ct, ABP Nodes mit Attinys84 irgendwie hingekriegt (hat viel Zeit gekostet) und bei V2 lief alles gut, bis der Wechsel nach V3 kam. Ich will mit Attinys und RFM95 mein eigenes Lora machen und temp sagt ,es sei kein Hexenwerk. Daher bitte ich um Starthilfe. Welche Bibliothek im Empfänger Teil (Gateway) benutzt diese LoRa-chirp technik und sendet die emfangenen Pakete eben nicht an TTN, sondern schreibt die empfangene payload irgendwo auf den Raspi. Ich habe noch nichts gefunden wo Attiny84 und RFM95 ohne TTN zusammenspielen. Gibt es einen Link mit Beispielcode? Danke schonmal im Voraus.
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.