IoT i CIoT-Geräte - Intelligente Lösungen

LoRaWAN & GSM - Smart City





iSys - Intelligente Systeme







ENTWURF

Inhaltsverzeichnis

1. Einführung. 3

1.1 @ City (IoT / CIoT) -Kommunikation 4

1.2. Hardwareressourcen von IoT / CIoT-Geräten 4

0..4 programmierbare Binäreingänge 4

0..4 programmierbare Binärausgänge 4

0..4 Zähleingänge (nichtflüchtige Zähler) 4

0..4 Dimmerausgänge (PWM oder 0..10V) 5

Infrarot-Eingang + Ausgang 5

0..4 Messeingänge (ADC) 5

serielle Schnittstellen SPI / I2C / UART / CAN 5

1.3. @ City GSM-Geräte 6

1.4. @City LoRaWAN-Geräte 9

Das Modul ohne LoRaWAN-Modem und -Prozessor kann als MEMs-Sensormodul für @ City GSM-, WiFi-, Ethernet- und andere eHouse-Architekturen (3v3..3v6 DC) 10 fungieren

2. Allgemeine Nutzungsbedingungen @City (LoRaWAN, GSM) -Systeme 11

2.1. Exklusive Bedingungen von @City GSM. 11

2.2. Exklusive Bedingungen für @City LoRaWAN. 12

3. @ City (LoRaWAN, GSM) Controller-Konfiguration 13

3.1. @ City Controller-Konfiguration - Zuweisen von Namen 13

3.2. Allgemeine Konfiguration von @City LoRaWAN- und GSM-Controllern 14

3.2.1 Allgemeine Konfiguration des @ City GSM-Geräts 14

3.2.2. Allgemeine Konfiguration von @ City LoRaWAN-Controllern 17

3.3. Konfiguration der Binäreingänge 18

3.4. Konfiguration der Binärausgänge 19

3.5. Konfiguration von ADC-Messeingängen und zusätzlichen Sensoren (XIN) 21

3.6. Dimmerkonfiguration PWM / 0..10V 22

3.7. Kalender-Scheduler-Konfiguration 24

4. Konfiguration der LoRaWAN-Netzwerkinfrastruktur 26

4.1. LoRaWAN-Gateway-Konfiguration. 26

4.1.1. Grundkonfiguration des LoRaWAN-Gateways 26

4.1.2. Konfiguration des Semtech Packet Forwarder (SPF) 27

4.2. LoRaWAN-Netzwerk- / Anwendungsserverkonfiguration 28

4.2.1. LoRaWAN-Netzwerkserverkonfiguration 29

5. Arbeitszustand von @ City GSM / LoRaWAN-Geräten 31


1. Einführung.

Das @Stadt System unterstützt eine Reihe von elektronischen Geräten (Controllern), die als Node, Mote, Device bezeichnet werden. Abhängig von der verfügbaren Infrastruktur, den Anforderungen und den Bedingungen stehen viele Arten der Kommunikation (kabelgebunden und kabellos) zur Verfügung.

Im @ City-System verfügbare Gerätetypen:

Alle Geräte sind über die miteinander integriert @Stadt Cloud und es besteht die Möglichkeit einer hybriden Zusammenarbeit in Abhängigkeit von der Verfügbarkeit einer bestimmten Kommunikationsinfrastruktur.

Für Gebäude und die Verfügbarkeit von LAN oder WiFi, die mit dem Internet verbunden sind, können wir eHouse Lösungen über PRO.PRO Server verwenden (die Daten an senden / empfangen können @Stadt Wolke):

Das folgende Dokument beschreibt GSM und LoRaWAN Geräte, die auf einem Single-Chip-Mikrocontroller (Mikroprozessor) und einem externen Kommunikationsmodem basieren. Dadurch kann das System trotz des Unterschieds im Kommunikationsmodem standardisiert werden.

Weitere Kommunikationsvarianten finden Sie unter eHouse Dokumentation.



Dies ermöglicht das Erhalten ähnlicher Funktionen und Geräte sowie eine einfache Migration zu anderen Kommunikationsvarianten oder -versionen.

1.1 @ City (IoT / CIoT) -Kommunikation

Das @ City-System verwendet derzeit eines der ausgewählten Kommunikationsmodule (Modems):

1.2. Hardwareressourcen von IoT / CIoT-Geräten

Das Ganze "Intelligenz" des Systems befindet sich im Mikrocontroller (Mikroprozessor) und ist nicht sehr abhängig von der Art der Kommunikation. Die Hardwareressourcen von IoT / CIoT-Geräten (Mikroprozessor) sind wie folgt:

1.3. @ City GSM-Geräte

@ City GSM Geräte verbinden sich über das Mobilfunknetz des GSM-Mobilfunkbetreibers über eine oder mehrere Technologien und Dienste. Diese Dienste werden in Rechnung gestellt und hängen von den Betreibern und Diensten individuell ab. Der Dienst wird auf die gleiche Weise wie bei Mobiltelefonen über aktive SIM-Karten autorisiert:

Die Verfügbarkeit ausgewählter Dienste hängt vom Kommunikationsbetreiber und dem eingebauten GSM-Modem in der Produktionsphase ab:

1) 2G (alle Betreiber)

2) 2G / LTE CATM1 (orange) - Es besteht eine 2G-Fallback-Möglichkeit, wenn CATM1 nicht verfügbar ist.

3) 2G / NBIoT (T-Mobile / Deutsche Telecom) - Es gibt eine 2G-Fallback-Möglichkeit, wenn NBIoT nicht verfügbar ist und der Betreiber dies zulässt.

4) 2G / 3G (alle Betreiber)

5) 4G / LTE (alle Betreiber)

6) Abhängig vom verfügbaren Modem und den Einstellungen ist möglicherweise auch eine andere Dienstkombination verfügbar.

Die ersten drei Lösungen funktionieren auf demselben Modem (NBIoT / CATM1 + Fallback 2G). Im Falle der Verwendung "Plastik" Nano-SIM-Karten Es ist möglich, die Karte auszutauschen und das Gerät remote so zu konfigurieren, dass es in einem anderen Dienst ordnungsgemäß funktioniert. Bei MIM (SIMs in Form eines Chips (IC)) wird die Entscheidung in der Produktionsphase des Geräts getroffen, und es ist nicht möglich, den Betreiber oder die Dienstleistung zu ändern. NBIoT ist für eine sehr kleine Menge übertragener Daten ~ 512 KB pro Monat vorgesehen (bitte verhandeln Sie diesen Wert mit dem Betreiber), was für einige CIoT / IoT-Lösungen ein erhebliches Hindernis darstellt.

Die Lösungen 4, 5 erfordern die Installation anderer Modems in der Produktionsphase.

Der Stromverbrauch des Geräts hängt vom Dienst ab und wird vom niedrigsten zum höchsten Wert angezeigt:

- NBIoT

- CATM1

- LTE

- 3G

- 2G / SMS / USSD / GPRS / EDGE

Datenübertragungsrate vom niedrigsten zum höchsten:

- NBIoT

- CATM1

- 2G / SMS / USSD / GPRS / EDGE

- 3G

- LTE



Alle @ City GSM-Geräte können mit einem GPS-Empfänger für die Geolokalisierung und automatische Positionierung auf Karten ausgestattet werden. Sie können auch mobil arbeiten, wenn Messungen erforderlich sind oder in Bewegung arbeiten.




1.4. @ City LoRaWAN-Geräte

LoRaWAN ist eine Kommunikationslösung für große Entfernungen (bis zu ca. 15 km) Arbeiten in offenen ISM-Bändern (z. 433 MHz, 868 MHz usw. ). Sehr große Bereiche erfordern jedoch eine signifikante Verringerung der Übertragungsgeschwindigkeit und der Datenpaketlänge (z. für den höchsten Bereich bis zu 250 Bit pro Sekunde und maximal 51 Byte Daten (Nutzlast). Die Übertragung mit Wiederholungen und Bestätigungen kann sehr lange dauern, wodurch LoRaWAN in einigen Lösungen möglicherweise eliminiert wird. Die Anzahl der LoRaWAN-Gateways ist auch wichtig, um eine gute Auswahl an Geräten zu gewährleisten, mit denen Sie mit höheren Geschwindigkeiten, weniger Fehlern und weniger Wiederholungen arbeiten können.

LoRaWAN-Geräte kommunizieren mit dem @ City Cloud über LoRaWAN-Gateways, die für alle verfügbaren LoRaWAN-Geräte eine Abdeckung auf dem erforderlichen Niveau bieten müssen. Darüber hinaus müssen diese Gateways über eine beliebige Verbindung mit dem LAN oder dem Internet verbunden sein, um Daten an den LoRaWAN-Netzwerk- / Anwendungsserver (NS / AS) senden zu können.

Der Webserver wird für die bidirektionale Kommunikation mit LoRaWAN-Gateways und zum Senden von Informationen an / von LoRaWAN-Geräten verwendet.

Der Netzwerk- / Anwendungsserver kann sich auf dem lokalen LAN oder im Rechenzentrum des Dienstanbieters befinden. Daten von den Geräten werden vom Netzwerk- / Anwendungsserver über Integrationsprotokolle an die gesendet @ City Cloud (via Webhook). Dies ermöglicht die direkte Integration der @City LoRaWAN System mit @ City-Datenbanken.



Der Anwendungsserver kann zusätzlich erweiterte Logik und BIM (Informationsmodellierung) für das System implementieren, Daten beim Empfang verarbeiten und Steuerbefehle (Ereignisse) als Antwort an einzelne Geräte senden.

@ City LoRaWAN-Geräte enthalten zusätzliche Funktionen wie:


Das Modul ohne LoRaWAN-Modem und -Prozessor kann als MEMs-Sensormodul für @ City GSM-, WiFi-, Ethernet- und andere eHouse-Architekturen (3v3..3v6 DC) verwendet werden.

2. Allgemeine Nutzungsbedingungen @City (LoRaWAN, GSM) -Systeme

BEACHTUNG! Eine falsche Einstellung der Hauptparameter der Kommunikationsschnittstelle kann zur Zerstörung oder dauerhaften Blockierung des Geräts führen (auf das wir keinen physischen Zugriff haben).

Das Update eines Controllers von a Firmware und endgültige Konfiguration muss durchgeführt und getestet werden (für alle Geräte und mindestens eine Woche für mehrere Geräte), bevor sie am Zielort installiert werden.

Der Hersteller ist nicht verantwortlich für unsachgemäße Konfiguration / Software-Aktualisierung durch unbefugte Personen sowie für deren Ausführung an Installationsorten einzelner Steuerungen.

Alle Kosten für Deinstallation, Service, Reparatur, Austausch und Neuinstallation trägt der Systembenutzer (nicht der Hersteller).

Um die Firmware und Konfiguration zu aktualisieren, müssen ein ausreichender Signalpegel und die Verfügbarkeit der erforderlichen Dienste sichergestellt werden. Die oben genannten Aktivitäten sind möglicherweise an den endgültigen Installationsorten der Steuerungen und in ihren Gehäusen nicht möglich. Sie können auch von der Jahreszeit, dem Wetter und der Ausbreitung der Funkwellen abhängen.

Alle Kosten für Dienste im Zusammenhang mit der Konfiguration / Firmware-Änderung trägt der Benutzer (zusätzliche Gebühren für die Datenübertragung, mögliche Deinstallation, Installation von Geräten, Entsperren, Ersetzen usw.). ).

Die maximale Reichweite ist rein theoretisch, wird unter idealen Funkausbreitungsbedingungen gemessen und bezieht sich auf den Betrieb von Geräten (mit externen und angepassten Antennen) im Sichtfeld (ohne Hindernisse im Signalstrahlengang). Abhängig von der Verstädterung des Gebiets, den Bäumen, dem Wetter, dem Standort und der Installationsmethode kann die Reichweite um das Hundertfache schlechter sein als die oben genannten Daten.

2.1. Exklusive Bedingungen von @City GSM.

Der Benutzer trägt die Kosten und ist für die rechtzeitige Zahlung des GSM-Betreiberabonnements und des @ City Server-Hostings verantwortlich. Mangelnde Dienstkontinuität kann zu irreversiblen Änderungen kritischer Übertragungsparameter führen und das gesamte System blockieren (z. Änderung der statischen IP-Adresse, Verlust der Internetdomäne, Verlust von Daten / Konfiguration auf dem Server, Verlust von Software, Backups usw. ).

Für den Fall, dass der Benutzer die oben genannten Beträge pauschal an den Hersteller des @ City-Systems zahlt, ist der Hersteller nicht verantwortlich für die Änderungen der Bedingungen des Angebots oder die Beendigung von Dienstleistungen, die von externen Stellen erbracht werden.

Der Systemhersteller ist nicht verantwortlich für die Qualität der von Dritten bereitgestellten Dienste, einschließlich des GSM-Betreibers und des externen @ City-Hostings. Der Hersteller ist nicht verantwortlich für die Verschlechterung des Bereichs der Funkwellenausbreitung (z. aufgrund der Schaffung neuer Gebäude, Änderungen des Standorts von GSM-Rundfunkstationen (BTS), Bäumen usw. ).

Bei Datenübertragungsbeschränkungen (insbesondere für NBIoT) sollte die Softwarekonfiguration und -aktualisierung zu Beginn des Abonnementzeitraums mit möglichst geringem Datenverbrauch durchgeführt werden. Andernfalls ist es möglich, das Gerät bis zum Ende des Abrechnungszeitraums zu blockieren, da Blockierungen im Zusammenhang mit der Überschreitung des Übertragungslimits auftreten.

Der GSM-Betreiber ist für die Qualität der GSM-Verbindung verantwortlich, nicht der Hersteller des @ City-Systems.

Der Benutzer erklärt, dass er die folgenden Informationen akzeptiert und damit einverstanden ist.

2.2. Exklusive Bedingungen für @City LoRaWAN.

Der Benutzer trägt die Kosten und ist für die rechtzeitige Zahlung der Leasing- und Installationsgebühren für das LoRaWAN-Gateway, den LoRaWAN-Netzwerk- / Anwendungsserver und das Hosting des @ City-Servers verantwortlich. Mangelnde Dienstkontinuität kann zu irreversiblen Änderungen kritischer Übertragungsparameter und permanenter Systemblockierung führen (z. Änderung der statischen IP-Adresse, Verlust der Domäne, Verlust von Daten / Konfiguration auf dem Server, Verlust von Software, Backups usw. ).

Für den Fall, dass der Benutzer die oben genannten Verpflichtungen pauschal gegenüber dem @ City-Hersteller festlegt, ist der Hersteller nicht dafür verantwortlich, die Bedingungen zu ändern oder die von externen Stellen bereitgestellten Dienste zu beenden.

Der Systemhersteller ist nicht verantwortlich für Dienste, die von externen Stellen bereitgestellt werden, einschließlich eines LoRaWAN-Betreibers, die das Hosting für den LoRaWAN-Netzwerk- / Anwendungsserver und das Hosting von externen @ City-Servern durchführen. Der Hersteller ist nicht verantwortlich für die Verschlechterung des Bereichs der Funkwellenausbreitung (z. aufgrund der Schaffung neuer Gebäude, Änderungen des Standorts von LoRaWAN-Gateways, Schäden an LoRaWAN-Gateways, Stromausfälle, Bäume, Störungen, Signalverluste usw. ).

Bei Datenübertragungsbeschränkungen sollte die Softwarekonfiguration und -aktualisierung zu Beginn des Abonnementzeitraums mit dem geringsten aktuellen Datenverbrauch durchgeführt werden. Andernfalls ist es möglich, das Gerät bis zum Ende des Abrechnungszeitraums aufgrund von Blockierungen zu blockieren, die mit dem Überschreiten des Übertragungslimits verbunden sind. Das Update sollte von Anfang bis Ende auf einem Controller durchgeführt und die Richtigkeit der Arbeit überprüft werden. Das Ausführen des Updates für alle Controller kann dazu führen, dass das Funkband für viele Tage vollständig blockiert ist.

LoRaWAN verwendet öffentlich verfügbar "offene Radiobänder" (433 oder 868 MHz für die EU), die möglicherweise von anderen Geräten gestört oder belegt werden, die auf denselben Frequenzen arbeiten. Der Hersteller ist im oben genannten Fall nicht für die Qualität der Kommunikation verantwortlich.

Der Benutzer ist dafür verantwortlich, den Bereich mit der entsprechenden Anzahl von LoRaWAN-Gattern und deren Position abzudecken, um den geeigneten Signalpegel für alle Geräte und das gesamte @ City LoRaWAN-System zu erhalten.

@ City GSM-Geräte können an Orten eingesetzt werden, die stark Signalstörungen ausgesetzt sind.

Der Benutzer erklärt, dass er die folgenden Informationen akzeptiert und damit einverstanden ist.

3. @ City (LoRaWAN, GSM) Controller-Konfiguration

Die Systemkonfiguration erfolgt über die Webschnittstelle. Die Konfiguration ist für @ City-Controller sehr wichtig, und falsche Einstellungen können dazu führen, dass das System vollständig blockiert wird. Es wird empfohlen, die vollständige Vorlagenkonfiguration (Standardeinstellungen) vom @ City-Systemhersteller durchzuführen und zu testen.

3.1. @ City Controller-Konfiguration - Zuweisen von Namen


Controller-Adresse 000000000000000 (15 Nullen für GSM / 16 für LoRaWAN) ist die Standardadresse, für die gilt alle Controller in der Familie (d. h. für das Selbe Herstellerkürzel und Dateicodeund der gleiche Typ von LoRaWAN / GSM-Controller. Wenn für den Controller keine eigene Konfiguration konfiguriert ist, wird die Standardkonfiguration in den Controller geladen.

Bei GSM-Controllern entspricht diese Adresse der vom Hersteller des GSM-Modems zugewiesenen eindeutigen IMEI-Nummer (15 Zeichen).

Bei LoRaWAN-Controllern entspricht diese Adresse der eindeutigen "Dev EUI" vom Hersteller des LoRaWAN-Modems angegebene Nummer (16 Zeichen in hexadezimalem Code).

Herstellerkürzel - ist ein eindeutiger Parameter für den Kunden (Benutzer)

Dateicode - ist ein Parameter, der den Firmware-Typ angibt (abhängig von der Ausrüstung und den verfügbaren Algorithmen).

In den meisten Fällen reicht es aus, dieses eine Gerät (Standard) für das gesamte System oder als Vorlage für andere Treiber zu konfigurieren. Beim Erstellen einer neuen Controller-Konfiguration werden diese Einstellungen aus der Vorlage kopiert.

Sowohl die Firmware als auch die Konfigurationen für alle Installationen (Instanzen) befinden sich auf den Servern des @ City-Systemherstellers, die über das WWW verfügbar sind und auf die der Benutzer möglicherweise nur eingeschränkten Zugriff hat. Die richtige Konfiguration ist jedoch sehr wichtig, und es wird nicht empfohlen, Änderungen vorzunehmen, ohne auf mehreren Geräten mit vollem physischen Zugriff (auf dem Schreibtisch) zu testen. Weitere Informationen finden Sie in den allgemeinen Bedingungen des @ City-Systems und in den spezifischen Bedingungen für eine bestimmte Art der Kommunikation.

3.2. Allgemeine Konfiguration von @City LoRaWAN & GSM Controllern

3.2.1 Allgemeine Konfiguration des @ City GSM-Geräts

Bevor Sie mit der Konfiguration beginnen, lesen Sie bitte die allgemeinen Bedingungen des @ City-Systems und die systemspezifischen Bedingungen für @ City GSM.




Herstellerkürzel - enthält 8 Zeichen, die in hexadezimalem Code für einen Kunden (Benutzer) gespeichert sind. Es wird in der Produktionsphase des Controllers gewährt. Ein Änderungsversuch kann zu einer dauerhaften Beschädigung des Controllers führen.

Dateicode - enthält 8 im Hexadezimalcode gespeicherte Zeichen, die einer Controller-Firmware-Version zugeordnet sind. Es wird in der Produktionsphase des Controllers gewährt und kann von der Art der Kommunikation (GSM / LoRaWAN) und zusätzlichen Geräten abhängen, z. Sensoren, die Anzahl der Ein- / Ausgänge und einzelne Algorithmen. Die Änderung kann zu dauerhaften Schäden oder zum Blockieren des Controllers führen.

PIN-Nr. - 4-stellige PIN-Nummer, falls für die SIM-Karte eingestellt. Das Festlegen von PINs wird nicht empfohlen. Bei Plastik-SIM-Karten können Sie diese auf Ihrem Mobiltelefon entfernen. Die Einführung einer falschen SIM-Karte kann zu einer dauerhaften Blockierung der Karte im Gerät führen (auf die wir letztendlich keinen physischen Zugriff haben).

SMS Nr. - SMS-Nummer beim Senden des Status per SMS. Diese Option ist je nach Dienst und Betreiber verfügbar (2G / CATM1 / NBIoT). Außerdem muss die Flagge eingeschaltet werden: SMS aktivieren.

USSD Str - USSD-Befehl zum Senden von Status über USSD. Diese Option ist nur für ausgewählte Arten von GSM-Modems (2G / 3G + GPS) verfügbar. Die Option: USSD aktivieren erforderlich. Der Betreiber muss den USSD-Dienst bereitstellen und aktivieren.

APN - Zugangspunktname. Der Name des Internet-Zugangspunkts, z. Internet (Für spezielle Dienste wie LTE-M1 oder NB-IoT kann dies vom Betreiber individuell zugewiesen werden.)

WWW-Adresse - Webadresse (Domain oder IP) für den HTTP-Zugriff.

WWW Seite - Webseitenadresse, an die Controller-Status und -Befehle gesendet werden.

HTTP aktivieren - Aktiviert die HTTP-Datenübertragung. Diese Methode erzeugt ein Vielfaches an Datenübertragung als alle anderen Kommunikationsmethoden, was zu erhöhten Kosten führen kann, die das Übertragungslimit überschreiten oder die Unfähigkeit, einige Dienste wie NBIoT zu nutzen, beeinträchtigen können.

TCP / UDP-Adresse - IP-Adresse des @ City-Servers zum Empfangen und Übertragen von Daten zwischen der Cloud und Geräten. Es wird empfohlen, eine feste IP-Adresse und keine Internetdomänenadresse zu verwenden.

TCP-Port - TCP / IP-Port für die Kommunikation

TCP aktivieren - Ermöglicht die Aktivierung der TCP / IP-Übertragung. Übertragungsrahmen und TCP-Bestätigungen erhöhen die Datenmenge in Bezug auf UDP-Übertragungen. Sie stellen jedoch die Richtigkeit der Daten und Bestätigungen sicher und garantieren deren Zustellung, wenn Kommunikation verfügbar ist.

Udp-hafen - Port zum Empfangen des Status über UDP

UDP aktivieren - Schalten Sie die UDP-Übertragung ein

Aux-Adresse, Aux-Port, Aux-Aktivierung - zukünftige Anwendungen

Aux2-Adresse, Aux2-Port, Aux2 aktiviert - zukünftige Anwendungen

Aktivierung der Sensorunterstützung (Sie müssen physisch auf dem @ City-Modul montiert sein.) Andernfalls arbeitet das Gerät möglicherweise viel langsamer und weniger stabil. In der Produktionsphase werden Sensoren für die gesamte Produktionsserie installiert.

Temperatur, Druck, Luftfeuchtigkeit, Gas - Integrierter Temperatur-, Druck-, Feuchtigkeits- und Luftqualitätssensor

Temp + Presure - Integrierter Temperatur- und Drucksensor

Gyroskop - Gyroskopsensor in 3 Achsen (X, Y, Z)

Magnetometer - Magnetsensor in 3 Achsen (X, Y, Z)

Beschleunigungsmesser - Beschleunigungs- / Vibrationssensor in 3 Achsen (X, Y, Z)

Farbe - Farbsensor (R, G, B, IR, G2)

Umgebungs + Proximeter - Integrierter Lichtpegel- und (10 cm Reichweite) Proximeter-Sensor

GSM-Befehle - Zusätzliche Modeminitialisierungsbefehle

Hash-Code - Ein zusätzlicher Verschlüsselungscode. Ändere dich nicht.

HTTP-Übertragung - Zusätzliche HTTP-Kommunikationsoptionen

Globale Adresse - Die globale Adresse des Controllers für die Steuerung von Gerät zu Gerät.

GSM-Modus - GSM-Kommunikationsmodus (nur 2G, nur LTE, CATM1, NBIoT, 2G + CAT M1, LTE 800, LTE 1800). Eine falsche Einstellung des Kommunikationsmodus kann zu einer dauerhaften Blockierung der Gerätekommunikation führen.

3.2.2. Allgemeine Konfiguration von @ City LoRaWAN-Controllern

Die meisten Optionen sind die gleichen wie beim GSM-Controller. Grundsätzlich werden während des Betriebs der LoRaWAN-Steuerung nicht alle Felder im Zusammenhang mit der GSM-Kommunikation verwendet. LoRaWAN-Geräte verfügen über eine andere Firmware, die das LoRaWAN-Modul anstelle von GSM unterstützt.

Auf der @City LoRaWAN Geräteseite, Konfiguration ist sehr einfach:

Anwendung EUID - Anwendungs-ID für den LoRaWAN-Server (16 Zeichen im Hex-Code) - Anwendung, die auf dem LoRaWAN-Netzwerk / Anwendungsserver definiert ist, an den wir Daten senden.

Anwendungsschlüssel - Anwendungsautorisierungsschlüssel für LoRaWAN-Server (wie oben)

Deaktivieren Sie die adaptive Datenrate - Deaktiviert die adaptive Geschwindigkeitsauswahl. Auf diese Weise können Sie eine konstante Geschwindigkeit des Geräts erzwingen. In einigen Situationen kann dies zu großen Kommunikationsproblemen führen. Es sollte berücksichtigt werden, dass die Geschwindigkeit erheblich zunimmt, wenn sich die RSSI- und SNR-Parameter im adaptiven Modus verbessern. Dies reduziert die Zeit der Datenübertragung per Funk erheblich "On The Air Time" und viel häufiger können Informationen zwischen dem Gerät und dem Server übertragen werden und umgekehrt.

Datenrate (DR) - Auswahl der LoRaWAN-Verbindungsgeschwindigkeit. Diese Geschwindigkeit gilt nicht für Bootloader. Wenn die Steuerung im adaptiven Geschwindigkeitseinstellmodus arbeitet, ist dies nur der Startwert, da die Steuerung nach mehreren Übertragungsversuchen autonom die optimale Geschwindigkeit auswählt, um die Zeit der Nachrichtenübertragung in der Luft zu begrenzen.

Update Einstellungen - speichert die Startkonfiguration des Controllers - alle Einstellungen



Der Rest der @ City LoRaWAN-Konfiguration befindet sich in den verbleibenden Elementen der LoRaWAN-Konfigurationsbildschirme in Kapitel 4.

3.3. Konfiguration der Binäreingänge




Binäreingänge haben eine Reihe von Funktionen und Parametern, die einen autonomen Betrieb der Steuerung ermöglichen:

Umkehren - Negation eingeben bei Sensoren "normalerweise angeschlossen" (NC) sind angeschlossen.

Alarm - Aktivierung der Alarmfunktion.

Alarmverzögerung - Alarmverzögerungszeit. Wenn der Eingangszustand vor Ablauf dieser Zeit in seinen ursprünglichen Zustand zurückkehrt, wird der Alarm nicht aktiviert.

Erinnere dich an den Staat - Zeit, sich an die Änderung des Eingangsstatus zu erinnern.

Ausführung deaktivieren - Blockieren von laufenden Ereignissen im Zusammenhang mit der Eingabe.

Lauf - Führen Sie den Eingabekonfigurationsbefehl (Ad-Hoc) aus.

Kopieren - Kopieren Sie den Befehl zur Eingabekonfiguration in die Zwischenablage

Ereignis ein - Beschreibung, wie das Ereignis für den hohen Eingangspegel ausgeführt wird (1)

Direktes Ereignis ein - Ereigniscode, der ausgeführt werden soll, wenn der Eingang eingeschaltet ist (0 => 1)

Ereignis aus - Beschreibung der Ereignisaktivierung für niedrigen Eingangspegel (0)

Direktes Ereignis aus - Ereigniscode, der ausgeführt werden soll, wenn der Eingang ausgeschaltet ist (1 => 0)

Alarmereignis - Beschreibung des Alarmereignisses.

Direktes Alarmereignis - Der Ereigniscode, der ausgelöst werden soll, wenn ein Alarm auftritt

Update Einstellungen - speichert die Startkonfiguration für alle Einstellungen

3.4. Konfiguration der Binärausgänge




Intelligente Binärausgänge können einfach oder doppelt arbeiten. Mit dem Formular können Sie eine Startkonfiguration für den Controller erstellen (wenn Sie dies mit der Schaltfläche Aktualisieren bestätigen).

Das Formular dient auch als Ereignisersteller für Ausgaben, die durch Drücken der Schaltfläche Ausführen gestartet oder zur Verwendung in der Controller-Konfiguration in die Zwischenablage kopiert werden können, z.



Konfiguration einzelner Ausgänge:

Deaktivieren - Blockieren der Ausgabe im Einzelmodus (z. wenn es zur Steuerung von Antrieben verwendet wird, um Rollläden, Tore und Aktuatoren nicht versehentlich zu beschädigen)

Administrator - Beim Ändern kritischer Einstellungen ist ein Verwaltungsflag erforderlich

Zustand - Statusauswahl (Erstkonfiguration oder Starten des Ereignisses mit dem "run" Taste)

Wiederholungen - Anzahl der Wiederholungen (zyklische Zustandsänderungen)

Zeit läuft - Zeitpunkt der Ausgangsaktivierung

Auszeit - Zeitpunkt des Ausschaltens des Ausgangs (wichtig beim Wiederholen von Ereignissen)

Lauf - Führen Sie das Ereignis zum Beenden aus

Kopieren - Kopieren Sie das Ereignis in die Zwischenablage

Update Einstellungen - speichert die Startkonfiguration für alle Einstellungen

Konfiguration mit doppelter Ausgabe:

Deaktivieren - Sperren Sie zwei Ausgänge im Dual-Modus (z. bei Verwendung als einzelne Eingänge)

Administrator - Ein Administrator-Flag ist erforderlich, wenn kritische Einstellungen wie der Laufwerksmodus geändert werden

Somfy - Antriebsmodus (aktiviert => Somfy / nicht aktiviert => Direct Servo)

Zustand - Statusauswahl (für die Erstkonfiguration oder das Mittagessen mit dem "run" Taste)

Wiederholungen - Anzahl der Wiederholungen (zyklische Zustandsänderung)

Zeit läuft - Zeitpunkt des Einschaltens des angegebenen Zustands

Zeit deaktivieren - Zeit zum Blockieren der Ausgänge (Mindestzeit zwischen den Änderungen der Ausgänge), um die Laufwerke vor Beschädigung zu schützen.

Auszeit - Zeitpunkt des Ausschaltens des Ausgangs (wichtig beim Wiederholen von Ereignissen)

Lauf - Führen Sie das Ereignis für das Laufwerk aus

Kopieren - Kopieren Sie das Ereignis in die Zwischenablage

Update Einstellungen - speichert die Startkonfiguration für alle Einstellungen

3.5. Konfiguration von ADC-Messeingängen und zusätzlichen Sensoren (XIN)




Umkehren - invertierte Skala (100% -x) des ADC-Eingangs

Alarm L. - Aktivierung der Option zum Auslösen eines Alarms, wenn der Wert unter die min. Schwelle

Alarm H. - Aktivierung der Option zum Auslösen eines Alarms, wenn der Wert die max. Schwelle

Alarmverzögerung - Alarmverzögerungszeit. Wenn der Eingabestatus auf zurückkehrt "OK" vor Ablauf der Zeit wird der Alarm nicht aktiviert.

Ereignis deaktivieren - Blockieren der Ereignisausführung

Administrator - Admin-Flag, mit dem die Konfiguration der Messeingabe geändert werden kann

NIEDRIGES Ereignis - Beschreibung des Ereignisses, das ausgeführt wurde, als der untere Schwellenwert überschritten wurde

NIEDRIG Direkt - Ereigniscode, der ausgeführt werden soll, nachdem der Wert unter den unteren Schwellenwert gesenkt wurde

NIEDRIGES Niveau - Höhe der unteren Schwelle (min)

OK Ereignis - Beschreibung des "OK" Veranstaltung

OK Direkt - Ereigniscode, der nach Eingabe des ausgeführt werden soll "OK" Reichweite

HOHES Ereignis - Beschreibung des Ereignisses für den oberen Schwellenwert

HOCH Direkt - Ereigniscode, der ausgeführt werden soll, nachdem der obere Schwellenwert überschritten wurde

Hohes Level - Höhe der oberen Schwelle (max)

Lauf - Ausführen des Konfigurationsereignisses (Änderung der ADC Ad-Hoc-Konfiguration)

Update Einstellungen - speichert die Erstkonfiguration für die ADC-Eingänge

3.6. Dimmerkonfiguration PWM / 0..10V




Umkehren - Umkehrung der Dimmerpolarität (100% - x)

Administrator - Ein Verwaltungsflag, mit dem Sie wichtige Optionen ändern können

Deaktivieren - Blockieren des Dimmerausgangs

Einmal - Ändern Sie die Dimmereinstellungen einmal (und stoppen Sie dann den Dimmer).

Wert min - Mindestwert der Dimmereinstellungen

Wert - Dimmerzielwert

Modus - Dimmer-Einstellmodus (Stop / - / + / Set)

Schritt - Schritt zum Ändern des Dimmerpegelwerts

Wert max - der Maximalwert der Dimmereinstellung

Lauf - Führt das Dimmer-Ereignis aus

Kopieren - Kopieren Sie das Ereignis in die Zwischenablage



Der RGBW-Dimmer ruft die Einstellwerte aus einzelnen Farben ab.

Darüber hinaus können Sie den kontinuierlichen Farbwechselmodus mithilfe der Voreinstellungen einzelner Dimmer aktivieren.

Update Einstellungen - speichert die Startkonfiguration für alle Einstellungen





Tasten:

Update Einstellungen - Speichern der Konfiguration im @ City-System

Alle Controller - eine Liste aller Controller

die Einstellungen - Einstellungen des aktuellen Controllers

Namen ändern - Ändern Sie den Namen des aktuellen Controllers

Planer - der Scheduler-Kalender-Editor des aktuellen Controllers

Write Config * - Senden eines Befehls zum Herunterladen der Konfiguration durch die Steuerung

Firmware-Aktualisierung * - Senden eines Befehls zum Herunterladen der Firmware durch den Controller

Controller zurücksetzen * - Senden eines Rücksetzbefehls zum Herunterladen durch die Steuerung

Controller zurücksetzen - Kopieren - Kopie des Controller-Reset-Ereignisses in die Zwischenablage

Ausloggen - Abmelden des Benutzers (aus Sicherheitsgründen sollten Sie auch alle offenen Instanzen des Webbrowsers schließen, in denen die Anmeldeparameter im Cache gespeichert werden können).

* - Das Senden des Befehls bedeutet das Hinzufügen zur Ereigniswarteschlange. Beim Anschließen des Controllers an das @ City-System lädt der Controller diese Ereignisse herunter.

3.7. Kalender-Scheduler-Konfiguration


Der Kalenderplaner ermöglicht das autonome Auslösen sich wiederholender oder geplanter Ereignisse (Befehle). Ein Beispiel wäre beispielsweise das Einschalten der Straßenlaterne um 17 Uhr und das Ausschalten um 7 Uhr (im Winter).

Entf (Löschen) - löscht den Zeitplan vollständig.

En. (Aktivieren) - Zeitplanelement aktivieren (es werden nur die Positionen ausgeführt, für die das Aktivierungsflag gesetzt ist).

Name - Ereignisname (Sie können das Ereignis auf erkennbare Weise beschreiben)

Ereigniscode - Ereigniscode in hexadezimalem Code (beim Erstellen von Befehlen aus der Zwischenablage kopiert)

Monatsfelder (Ja, Fe, .., No, De) - Monate Januar ... Dezember, in dem die Veranstaltung gestartet wird

Tag - Tag. Sie können jeden Tag des Monats oder auswählen "*" für jeden (jeden Tag die Veranstaltung laufen lassen).

Wochentagsfelder (Mo, Tu, .. Su) - Sie können die Wochentage auswählen, an denen die Veranstaltung durchgeführt wird.

Stunde - Die Stunde. Sie können jede Stunde oder wählen "*" für alle (stündliche Durchführung der Veranstaltung).

Mindest - Minute. Sie können eine beliebige Minute oder auswählen "*" für alle (jede Minute die Veranstaltung laufen lassen).



Logisch "und" Algorithmus wird zwischen allen Feldern implementiert (außer Name ), daher müssen alle erfüllt sein, damit das Ereignis ausgeführt werden kann.



Z.B. Straßenlaternen einschalten ( November, Dezember, Januar, Februar ) beim 17.01 ohne Sonntags.

En - ausgewählt

Event code - 00002101010000000000 // Lauf des 1. Binärausgangs

Monatsfelder - nur Nein, De, Ja, Fe sind markiert

Tag - ausgewählt "*" für jeden Tag des Monats

Stunde - gewählte Zeit ist 17

Mindest - ausgewählte Minute 01

Wochentagsfelder - alles andere als Su ausgewählt

4. Konfiguration der LoRaWAN-Netzwerkinfrastruktur

Dieses Kapitel gilt nur für die LoRaWAN-Kommunikation. Bei Systemen, die mit anderen Übertragungsmethoden arbeiten, kann dies weggelassen werden.

Gemäß der LoRaWAN-Netzwerkspezifikation stellt der Controller indirekt eine Verbindung zur @ City-Cloud her über:

4.1. LoRaWAN-Gateway-Konfiguration.

Es gibt viele LoRaWAN-Gateways auf dem Markt, die gleichzeitig eine Reihe zusätzlicher Optionen enthalten können:

4.1.1. Grundkonfiguration des LoRaWAN-Gateways

Auf das LoraWAN-Gateway sollte von mindestens einer Konfigurationsstation aus zugegriffen werden können.

Bei der Installation über Ethernet / WiFi und der Konfiguration nur über ein lokales LAN / WLAN ist die Sicherheit des Gateways nicht sehr kritisch (es sei denn, wir bieten Zugriff auf das Gateway von außen, d. H. das Internet).

Wenn das LoRaWAN-Gateway nur über GSM / LTE verbunden ist, muss das Gateway vor Zugriff und verschiedenen Arten von Angriffen geschützt werden.

- Wenn wir eine Remote-Verbindung zum LoRaWAN-Gateway herstellen möchten, müssen eine öffentliche + statische IP-Adresse und ein SSH-Dienst verfügbar sein. Andernfalls müssen Sie eine physische Verbindung zum Gateway über eine Ethernet- oder WiFi-Schnittstelle herstellen.

- Es ist erforderlich, komplizierte Zugriffskennwörter für alle Benutzer auf dem Gerät festzulegen.

- Deaktivieren Sie alle nicht verwendeten Dienste wie Telnet, FTP, POP, SMTP, IMAP, WWW usw. das kann das Ziel von Angriffen sein "besetzen" das Gateway mit anderen Prozessen wie Anmeldeversuchen.

- Sie können die Möglichkeit der Anmeldung nur von Stationen mit ausgewählten statischen IP-Adressen einschränken, was einen sehr wirksamen Schutz gegen Hacking darstellt. Dies gilt auch für scheinbar unbedeutende Dienste wie ICMP (Ping), HTTP, FTP usw.

- Nach vollständiger Konfiguration und vielen Wochen Systemtests können wir alle externen Dienste und den Remotezugriff blockieren, was jedoch den Dienst behindert, die Gateway-Protokolle durchsucht und überprüft.

4.1.2. Konfiguration des Semtech Packet Forwarder (SPF)

Die Aufgabe des SPF besteht darin, LoRaWAN-Pakete über das IP-Netzwerk (UDP-Protokoll) an die erforderliche Adresse des LoRaWAN-Netzwerkservers an den LoRaWAN-Netzwerkserver zu senden.

LoRaWAN Gateway mit SPF ist transparent und leitet alle Pakete in beide Richtungen weiter.

Datenpakete werden in keiner Richtung verarbeitet oder autorisiert.

Die Konfiguration von SPF ist sehr einfach und beinhaltet "Regie" es an den erforderlichen LoRaWAN-Netzwerkserver.

Melden Sie sich über SSH mit dem vom Gerätehersteller angegebenen Benutzernamen und Kennwort beim LoRaWAN-Gateway an.

Installieren Sie SPF gemäß den Anweisungen des Herstellers des LoRaWAN-Gateways.

Das SPF-Konfigurationsverzeichnis ist "/ user / spf / etc /" Abhängig vom Hersteller des LoRaWAN-Gateways befindet es sich jedoch möglicherweise an einem anderen Ort.

Die Hauptkonfiguration von SPF befindet sich in der Datei "/user/spf/etc/global_conf.json", die mit dem verfügbaren Editor bearbeitet werden sollte (z. vi oder nano). Wir ändern den Wert des Parameters: "Serveradresse" durch Eingabe der festen IP-Adresse des Netzwerkservers oder des Domänennamens (erfordert einen zusätzlichen ordnungsgemäß konfigurierten DNS-Clientdienst).

Der Standard-Rückkommunikationsport ist 1700 (Wenn Sie sie ändern möchten, müssen Sie dies auch auf dem LoRaWAN-Netzwerkserver tun.) Geben Sie identische Werte ein.

Protokolle des SPF-Pakets befinden sich in der "/ user / spf / var / logs /" Verzeichnis in der spf.log Datei und ihre Archivkopien.

Die Netzwerkkonfiguration des LoRaWAN-Gateways unter Linux befindet sich normalerweise im Verzeichnis "/usw/"Hier können Sie Standardnetzwerkdienste aktivieren / deaktivieren und den Server sichern.

Sie sollten auch die Passwörter aller auf dem System verfügbaren Benutzer mit dem ändern passwd Befehl zum Schutz vor unbefugtem Zugriff durch unbefugte Personen. Sie müssen auch das Benutzerkennwort für den webbasierten Support ändern.

Es ist auch am besten, die WiFi-Kommunikation zu deaktivieren, da Eindringlinge möglicherweise versuchen, Angriffe über dieses Übertragungsmedium auszuführen.

Setzen Sie nach Abschluss dieser Konfiguration das Gateway mit dem zurück Neustart Befehl.



4.2. LoRaWAN-Netzwerk- / Anwendungsserverkonfiguration

Es gibt viele Lösungen für Netzwerk- und Anwendungsserver (einschließlich kostenloser). Jeder von ihnen hat seine eigene Art der Integration mit externen Diensten und Systemen (z. Wolken mögen @Stadt ). Aus diesem Grund ist die @Stadt Das System muss über eine Schnittstelle zur Integration mit dem installierten LoRaWAN NS / AS-Server verfügen.

Im Falle eines Produktionssystems können wir den kostenlosen Service nutzen "Das Netzwerk der Dinge", solange wir uns innerhalb sehr großer Tagesgrenzen befinden, die für jedes Gerät definiert sind {insbesondere "On The Air Time" (30s **) und eine kleine Anzahl von Befehlen, die an das Gerät gesendet wurden (10 **)}.

** Die aktuellen täglichen Gerätelimits können sich ändern.

Wenn Sie neue Firmware und Konfiguration laden müssen, müssen Sie Ihren eigenen LoRaWAN-Server (Netzwerk + Anwendung) verwenden.

Dies gibt uns mehrere Möglichkeiten:

Auf einigen Systemen ist die Firmware + -Konfiguration fest (für alle verfügbaren Controller im System) und wird in der Phase der anfänglichen Systemkonfiguration initiiert, was die Auswahl vereinfacht.

(*) - In diesen Fällen muss auf dem zweiten Server ein zweites LoRaWAN-Gateway für die Konfiguration und Firmware-Aktualisierung eingerichtet sein, damit die Produktionsumgebung kontinuierlich funktioniert. Bei Anwendungen mit geringen kritischen Werten können Sie die Konfiguration eines dedizierten LoRaWAN-Gateway-dedizierten LoRaWAN-Servers ändern. Dies führt jedoch zu einem Kommunikationsverlust mit der Produktionsumgebung und einem fehlerhaften Betrieb dieser Geräte.

Es sollte beachtet werden, dass das Software-Update eines einzelnen LoRaWAN-Controllers bei guter Reichweite (DR> = 4) etwa eine Stunde dauert. Es lohnt sich daher, ein zusätzliches Gateway zum Aktualisieren der Firmware und Konfiguration zu verwenden. Bei geringer Abdeckung (DR <4) ist eine Firmware-Konfiguration und -Update nicht möglich und erfordert ein Gateway mit LTE-Kommunikation in der Nähe der aktualisierten Geräte.

4.2.1. LoRaWAN-Netzwerkserverkonfiguration

Fügen Sie auf dem LoRaWAN-Netzwerkserver das LoRaWAN-Kommunikationsgateway hinzu (die Adresse befindet sich auf der Abdeckung oder in der Datei "Benutzer / spf / etc / local_conf.json"oder in den Protokollen angezeigt "/user/spf/var/log/spf.log". Überprüfen Sie in den Webserver-Protokollen, ob das Kommunikations-Gateway eine Verbindung zum Server herstellt.

Die nächsten Schritte sind die Konfiguration des Anwendungsservers (dieser befindet sich normalerweise auf demselben Gerät wie der Netzwerkserver).

Die nächsten auszuführenden Schritte hängen von der verwendeten Anwendungsserverlösung und der Verfügbarkeit der Back-End / Front-End-Schnittstelle ab. Die Schnittstelle vereinfacht sich "erste Schritte" und Systemkonfiguration.

Im Allgemeinen sollten Sie:

 







5. Arbeitszustand von @ City GSM / LoRaWAN-Geräten

Temperatur - 40C .. + 65C

Luftfeuchtigkeit 0..80% r.H. keine Kondensation (Gerät)

GSM Stromversorgung 5VDC @ 2A ±0,15 V (für PPM-Sensor und beim Anschließen von Relais)

3.5VDC..4.2VDC @ 2A (in anderen Fällen)


LoRaWAN power supply 5VDC @ 300mA ± 0,15 V (für PPM-Sensor und beim Anschließen von Relais)

3VDC..3.6VDC @ 300mA (in anderen Fällen)


GSM + GPS-Geräte:

Antenneneingang 50 Ohm

SIM Nano-SIM oder MIM

(Auswahl in der Produktionsphase - MIM legt einen Netzbetreiber fest)

Modemgenehmigung Orange (2G-CATM1), T-Mobile / DT (2G-NBIoT), 2G Andere Betreiber


BANDS (Europa) Empfindlichkeit der Ausgangsleistung der Klasse

B3, B8, B20 (CATM1 - 800 MHz) ** 3 + 23 dB ±2 < -107.3dB

B3, B8, B20 (NB-IoT - 800 MHz ) ** **. 3 +23dB ±2 < -113.5dB

GSM850, GSM900 (GPRS) * 4 + 33 dB ±2 <-107 dB

GSM850, GSM900 (EDGE) * E2 + 27 dB ±2 <-107 dB

DCS1800, PCS1900 (GPRS) * 4 + 30 dB ±2 < -109.4dB

DCS1800, PCS1900 (EDGE) * E2 +26dB ±2 < -109.4dB

Bei Verwendung einer externen Schmalbandantenne, die für ein bestimmtes Band frequenzangepasst ist.


* nur für Combo-Modem: 2G, CATM1, NB-IoT

Zertifikate:



GPS / GNSS:

Betriebsfrequenz: 1559..1610MHz

Antennenimpedanz 50 Ohm

maximale Empfindlichkeit * -160 dB stationär, -149 dB Navigation, -145 Kaltstart

TTFF 1s (heiß), 21s (warm), 32s (kalt)

A-GPS ja

Dynamik 2g

minimale Bildwiederholfrequenz 1 Hz


* passende externe Schmalbandantenne



LoRaWAN-Geräte 1.0.2 (8 Kanäle, Sendeleistung: + 14 dBm) Europa (863-870 MHz)

DR T. Modulation BR-Bit / s Rx-Empfindlichkeit Rx-Tests

0 3 min SF12 / 125 kHz 250 -136 dB -144 dB

1 2 min SF11 / 125 kHz 440-133,5 dB

2 1 min SF10 / 125 kHz 980-131 dB

3 50s SF9 / 125kHz 1760 -128,5dB

4 (*) 50s SF8 / 125kHz 3125 -125,5dB

5 (*) 50s SF7 / 125kHz 5470 -122,5dB

6 (*) 50s SF7 / 250kHz 11000 -119dB

7 FSK 50 kbs 50000 -130 dB

(*) Parameter, die zum Aktualisieren der Firmware des Systems über OTA erforderlich sind

(DR) - Datenrate

(BR) - Bitrate

T - Die Mindestdauer für die Datenaktualisierung in der @ City-Cloud




LoRaWAN praktische Abdeckungstests:


Test-Bedingungen:

LoRaWAN Kerlink ifemtocell Internes Gateway

passive Breitbandantenne für den Außenbereich in einer Höhe von ~ 9 m über dem Boden Wygoda gm. Karczew (~ 110 m über dem Meeresspiegel).

LoRaWAN-Gerät mit erzwungenem DR0 mit einer externen Breitband-Magnetantenne, die 1,5 m über dem Boden auf dem Autodach platziert ist.

Ländliche Gebiete (Wiesen, Felder mit kleinen Bäumen und seltene Gebäude)


Das am weitesten entfernte Ergebnis war Czersk ~ 10,5 km (~ 200 m über dem Meeresspiegel) mit einem RSSI von -136 dB (d. H. mit der vom Hersteller garantierten maximalen Empfindlichkeit des LoRaWAN-Modems)