ein sensor wird zb auf ttn bzw. auf anderen (lokalen) instanzen als device angelegt.
ein sensornahes gateway (zb das mikrotik) hat als zielserver auch alle diese instanzen eingetragen, der forwarder schickt also pakete an alle diese instanzen.
funktioniert sowas?
wie reagiert der sensor (bzw. wie ist das im standard definiert) wenn er einen join-request absetzt und zwei (oder mehr) server antworten dem ding?
voraussetzung natürlich: alle notwendigen keys vom sensor sind bekannt um das ding jeweils anzulegen, jetzt egal ob ABP oder OTAA
mein Verständnis: ein Sensor kann lt. LoRaWAN-Standard nur in einem Netz bzw. einer Plattform registriert sein. Für OTAA sehe ich das von der Funktion auch kritisch, genau aufgrund des von dir beschriebenen Verhaltens.
Bei ABP mit statischen Keys und ohne Frame Counter wäre es theoretisch vielleicht sogar möglich, weil sich die DevEUI und Keys nicht ändern und der Packet Forwarder immer an alle Network Server sendet. Aufgrund der Security-Verbesserungen der nächsten LoRaWAN-Standards wird das aber irgendwann nicht mehr gehen. Und vom Packet Forwarder geht man ja schön langsam auch weg…
Fazit: don’t do it - das ist so nicht vorgesehen.
Es bringt auch viele Probleme mit sich, zB. bzgl. Adaptive Data Rate, dem Handling der Duty Cycle, usw.
Mir fällt auch keine Anwendung ein, für die man das brauchen würde. Worum geht es dir?
um zumindest die signalinfos zu haben (also wie „mein“ gw das hört - und andere) wenn ich kein zugriff auf „das andere“ system hab.
holst du dir nicht auch „fremde“ pakete (von s***, um signalstärken zu haben) in dein netz oder hab ich da was falsch verstanden? der inhalt ist ja eh ned zugänglich, die metadaten warads …
ich meinte das eh so … quasi … ich dachte ich muss zumindest das device auf einer plattform anlegen, komme aber selber grad drauf, dass ich dann (auch) die payload lesen kann, die mich aber eh nicht interessiert. vll war mein trugschluss der dass ich den deduplizierer „meiner“ plattform nutzen will um diese infos zu erhalten (wie gut gehört werden)