IoT Appareils i CIoT - Solutions intelligentes

LoRaWAN & GSM - Ville intelligente





iSys - Systèmes intelligents







BROUILLON

Table des matières

1. Introduction. 3

1.1 Communication avec @City (IoT / CIoT) 4

1.2. Ressources matérielles des appareils IoT / CIoT 4

0..4 entrées binaires programmables 4

0..4 sorties binaires programmables 4

0..4 entrées de comptage (compteurs non volatils) 4

0..4 sorties variateurs (PWM ou 0..10V) 5

Entrée infrarouge + sortie 5

0..4 entrées de mesure (ADC) 5

interfaces série SPI / I2C / UART / CAN 5

1.3. Appareils GSM @City 6

1.4. Appareils @City LoRaWAN 9

Le module sans modem ni processeur LoRaWAN peut servir de module de capteur MEMs pour @City GSM, WiFi, Ethernet et autres architectures eHouse (alimentation CC 3v3..3v6) 10

2. Conditions générales d'utilisation des systèmes @City (LoRaWAN, GSM) 11

2.1. Conditions exclusives de @City GSM. 11

2.2. Conditions exclusives pour @City LoRaWAN. 12

3. Configuration du contrôleur @City (LoRaWAN, GSM) 13

3.1. @City Controller Configuration - Attribution de noms 13

3.2. Configuration générale des contrôleurs @City LoRaWAN et GSM 14

3.2.1 Configuration générale de l'appareil @City GSM 14

3.2.2. Configuration générale des contrôleurs @City LoRaWAN 17

3.3. Configuration des entrées binaires 18

3.4. Configuration des sorties binaires 19

3.5. Configuration des entrées de mesure ADC et des capteurs supplémentaires (XIN) 21

3.6. Configuration des gradateurs PWM / 0..10V 22

3.7. Configuration du calendrier-planificateur 24

4. Configuration de l'infrastructure réseau LoRaWAN 26

4.1. Configuration de la passerelle LoRaWAN. 26

4.1.1. Configuration de base de la passerelle LoRaWAN 26

4.1.2. Configuration de Semtech Packet Forwarder (SPF) 27

4.2. Configuration du serveur d'applications / réseau LoRaWAN 28

4.2.1. Configuration du serveur réseau LoRaWAN 29

5. Conditions de travail des appareils @City GSM / LoRaWAN 31


1. Introduction.

le @Ville système prend en charge un certain nombre d'appareils électroniques (contrôleurs) - appelés noeud, mote, appareil. De nombreux types de communication (filaire et sans fil) sont disponibles en fonction de l'infrastructure disponible, des exigences et des conditions.

Types d'appareils disponibles dans le système @City:

Tous les appareils sont intégrés les uns aux autres via le @Ville cloud et il existe une possibilité de coopération hybride en fonction de la disponibilité d'une infrastructure de communication donnée.

Pour les bâtiments et la disponibilité de LAN ou WiFi connectés à Internet, nous pouvons utiliser des solutions eHouse via un serveur eHouse.PRO (qui peut envoyer / recevoir des données à @Ville nuage):

Le document suivant décrit GSM et LoRaWAN dispositifs basés sur un microcontrôleur monopuce (microprocesseur) et un modem de communication externe. Cela permet au système d'être standardisé malgré la différence de modem de communication.

Pour d'autres variantes de communication, veuillez consulter eHouse Documentation.



Cela permet d'obtenir des fonctionnalités et des équipements similaires, ainsi qu'une migration facile vers d'autres variantes ou versions de communication.

1.1 Communication @City (IoT / CIoT)

Le système @City utilise actuellement l'un des modules de communication sélectionnés (modems):

1.2. Ressources matérielles des appareils IoT / CIoT

La totalité "intelligence" du système réside dans un microcontrôleur (microprocesseur) et ne dépend pas beaucoup du type de communication. Les ressources matérielles des appareils IoT / CIoT (microprocesseur) sont les suivantes:

1.3. Appareils GSM @City

@City GSM les appareils se connectent via le réseau cellulaire de l'opérateur mobile GSM via une ou plusieurs technologies et services. Ces services sont facturés et dépendent des opérateurs et des services individuellement. Le service est autorisé de la même manière que sur les téléphones mobiles via des cartes SIM actives:

La disponibilité des services sélectionnés dépend de l'opérateur de communication et du modem GSM intégré au stade de la production:

1) 2G (tous les opérateurs)

2) 2G / LTE CATM1 (orange) - il existe une possibilité de repli 2G lorsque CATM1 n'est pas disponible.

3) 2G / NBIoT (T-Mobile / Deutsche Telecom) - il existe une possibilité de repli 2G lorsque NBIoT n'est pas disponible et que l'opérateur le permet.

4) 2G / 3G (tous les opérateurs)

5) 4G / LTE (tous les opérateurs)

6) D'autres combinaisons de services peuvent également être disponibles en fonction du modem et des paramètres disponibles.

Les 3 premières solutions fonctionnent sur le même modem (NBIoT / CATM1 + fallback 2G). Dans le cas de l'utilisation "Plastique" Cartes Nano SIM, il est possible de remplacer la carte et de configurer à distance l'appareil pour qu'il fonctionne correctement dans un autre service. Dans le cas des MIM (SIM sous forme de puce (IC)), la décision est prise au stade de la production de l'appareil, et il n'est pas possible de changer d'opérateur ou de service. NBIoT est dédié à une très petite quantité de données transmises ~ 512 Ko par mois (veuillez négocier cette valeur à l'opérateur), ce qui est un obstacle important pour certaines solutions CIoT / IoT.

Les solutions 4, 5 nécessitent l'installation d'autres modems au stade de la production.

La consommation électrique de l'appareil dépend du service et est affichée du plus bas au plus élevé:

- NBIoT

- CATM1

- LTE

- 3G

- 2G / SMS / USSD / GPRS / EDGE

Taux de transfert de données du plus bas au plus élevé:

- NBIoT

- CATM1

- 2G / SMS / USSD / GPRS / EDGE

- 3G

- LTE



Tous les appareils GSM @City peuvent être équipés d'un récepteur GPS pour la géolocalisation et le positionnement automatique sur les cartes. Ils peuvent également travailler mobiles lorsqu'il y a un besoin de mesures ou travailler en mouvement.




1.4. Appareils @City LoRaWAN

LoRaWAN est une solution de communication longue portée (jusqu'à env. 15 km) travaillant dans des bandes ISM ouvertes (par ex. 433 MHz, 868 MHz, etc. ). Cependant, de très grandes plages nécessitent une réduction significative de la vitesse de transmission et de la longueur des paquets de données (par ex. pour la plage la plus élevée jusqu'à 250 bits par seconde et un maximum de 51 octets de données - charge utile). La transmission avec répétitions et confirmations peut prendre un temps très long, ce qui peut éliminer LoRaWAN dans certaines solutions. Le nombre de passerelles LoRaWAN est également important pour assurer une bonne gamme d'appareils, ce qui vous permet de travailler à des vitesses plus élevées, moins d'erreurs et moins de répétitions.

Les appareils LoRaWAN communiquent avec le @City cloud via les passerelles LoRaWAN, qui doivent fournir une couverture au niveau requis pour tous les appareils LoRaWAN disponibles. De plus, ces passerelles doivent être connectées au LAN ou à Internet via n'importe quel lien pour pouvoir envoyer des données au réseau / serveur d'applications LoRaWAN (NS / AS).

Le serveur Web est utilisé pour la communication bidirectionnelle avec les passerelles LoRaWAN et pour l'envoi d'informations vers / depuis les appareils LoRaWAN.

Le serveur de réseau / d'application peut être situé sur le LAN local ou dans le centre de données du fournisseur de services. Les données des appareils sont envoyées du réseau / serveur d'applications via des protocoles d'intégration vers le @City cloud (via webhook). Cela permet une intégration directe du @Ville LoRaWAN système avec Bases de données @City.



Le serveur d'application peut en outre implémenter une logique étendue et BIM (modélisation d'informations) pour le système, traiter les données à la réception et envoyer des commandes de contrôle (événements) à des appareils individuels en réponse.

Les appareils @City LoRaWAN contiennent des fonctionnalités supplémentaires telles que:


Le module sans modem et processeur LoRaWAN peut servir de module de capteur MEMs pour @City GSM, WiFi, Ethernet et autres architectures powered (alimentation CC 3v3..3v6)

2. Conditions générales d'utilisation des systèmes @City (LoRaWAN, GSM)

ATTENTION! Un réglage incorrect des principaux paramètres de l'interface de communication peut entraîner la destruction ou le blocage permanent de l'appareil (auquel nous n'avons pas d'accès physique).

Toute mise à jour par le contrôleur d'un firmware et configuration finale doivent être réalisés et testés (pour tous les appareils et pendant au moins une semaine pour plusieurs appareils) avant de les installer sur le lieu de destination.

Le fabricant n'est pas responsable de la mauvaise configuration / mise à jour logicielle effectuée par des personnes non autorisées, ainsi que de leur exécution dans les lieux d'installation des contrôleurs individuels.

Tous les frais de désinstallation, de services, de réparation, de remplacement, de réinstallation sont à la charge de l'utilisateur du système (et non du fabricant).

Afin de mettre à jour le micrologiciel et la configuration, il est nécessaire de garantir un niveau de signal suffisant et la disponibilité des services requis. Les activités ci-dessus peuvent être impossibles aux emplacements d'installation définitifs des contrôleurs et dans leurs boîtiers. Ils peuvent également dépendre de la saison, des conditions météorologiques et de la propagation des ondes radio.

Tous les frais de services liés à la configuration / changement de firmware sont à la charge de l'utilisateur (frais supplémentaires de transfert de données, éventuelle désinstallation, installation des appareils, déverrouillage, remplacement, etc. ).

La portée maximale est purement théorique, mesurée dans des conditions de propagation radio idéales et se réfère au fonctionnement d'appareils (avec des antennes externes et adaptées) dans le champ de vision (sans obstructions dans le trajet du faisceau du signal). En fonction de l'urbanisation de la zone, des arbres, des conditions météorologiques, de l'emplacement et de la méthode d'installation, la portée peut être pire de plusieurs centaines de fois que les données ci-dessus.

2.1. Conditions exclusives de @City GSM.

L'utilisateur supporte les coûts et est responsable du paiement en temps opportun de l'abonnement de l'opérateur GSM et de l'hébergement du serveur @City. Le manque de continuité de service peut entraîner des modifications irréversibles des paramètres de transmission critiques et bloquer l'ensemble du système (par ex. changement d'adresse IP statique, perte de domaine Internet, perte de données / configuration sur le serveur, perte de logiciels, de sauvegardes, etc. ).

Dans le cas où l'utilisateur paie les montants susmentionnés à un taux forfaitaire au producteur du système @City, le producteur n'est pas responsable des modifications des conditions de l'offre ou de la résiliation des services exécutés par des entités externes.

Le fabricant du système n'est pas responsable de la qualité des services fournis par des tiers, notamment l'opérateur GSM, l'hébergement externe @City. Le fabricant n'est pas responsable de la détérioration de la plage de propagation des ondes radio (par ex. en raison de la création de nouveaux bâtiments, des changements de localisation des stations de diffusion GSM (BTS), des arbres, etc. ).

Dans le cas de limites de transfert de données (en particulier pour NBIoT), la configuration et la mise à jour du logiciel doivent être effectuées au début de la période d'abonnement, avec la consommation de données la plus faible possible. Dans le cas contraire, il est possible de bloquer l'appareil jusqu'à la fin de la période de facturation, en raison de blocages liés au dépassement de la limite de transfert.

L'opérateur GSM est responsable de la qualité de la connexion GSM, et non le fabricant du système @City.

L'Utilisateur déclare accepter les informations suivantes et les accepter.

2.2. Conditions exclusives pour @City LoRaWAN.

L'utilisateur supporte les coûts et est responsable du paiement en temps opportun des frais de location et d'installation de la passerelle LoRaWAN, du serveur de réseau / d'application LoRaWAN et de l'hébergement du serveur @City. Le manque de continuité de service peut entraîner des modifications irréversibles des paramètres de transmission critiques et un blocage permanent du système (par ex. changement d'adresse IP statique, perte de domaine, perte de données / configuration sur le serveur, perte de logiciel, de sauvegardes, etc. ).

Dans le cas où l'utilisateur impose les obligations ci-dessus sur une base forfaitaire au producteur @City, le producteur n'est pas responsable de la modification des conditions ou de la résiliation des services fournis par des entités externes.

Le fabricant du système n'est pas responsable des services fournis par des entités externes, y compris tout opérateur LoRaWAN, de l'hébergement du réseau / serveur d'applications LoRaWAN, de l'hébergement du serveur externe @City. Le fabricant n'est pas responsable de la détérioration de la plage de propagation des ondes radio (par ex. en raison de la création de nouveaux bâtiments, des changements d'emplacement des passerelles LoRaWAN, des dommages aux passerelles LoRaWAN, des pannes de courant, des arbres, des interférences, des pertes de signal, etc. ).

Dans le cas de limites de transfert de données, la configuration et la mise à jour du logiciel doivent être effectuées au début de la période d'abonnement, avec la consommation de données la moins courante. Dans le cas contraire, il est possible de bloquer l'appareil jusqu'à la fin de la période de facturation en raison de blocages liés au dépassement de la limite de transfert. La mise à jour doit être effectuée un contrôleur du début à la fin et tester l'exactitude du travail. L'exécution de la mise à jour pour tous les contrôleurs peut entraîner le blocage complet de la bande radio pendant plusieurs jours.

LoRaWAN utilise des "bandes radio ouvertes" (433 ou 868 MHz pour l'UE), qui peuvent être perturbés ou occupés par d'autres appareils fonctionnant sur les mêmes fréquences. Le fabricant n'est pas responsable de la qualité de la communication dans le cas ci-dessus.

L'utilisateur est responsable de couvrir la zone avec le nombre approprié de portes LoRaWAN et leur emplacement pour obtenir le niveau de signaux approprié pour tous les appareils et l'ensemble du système @City LoRaWAN.

Les appareils GSM @City peuvent être utilisés dans des endroits très exposés aux interférences de signal.

L'Utilisateur déclare accepter les informations suivantes et les accepter.

3. Configuration du contrôleur @City (LoRaWAN, GSM)

La configuration du système est effectuée via l'interface Web. La configuration est très critique pour les contrôleurs @City et des paramètres incorrects peuvent entraîner un blocage complet du système. Il est recommandé que la configuration complète du modèle (paramètres par défaut) soit effectuée et testée par le fabricant du système @City.

3.1. @City Controller Configuration - Attribution de noms


Adresse du contrôleur 000000000000000 (15 zéros pour GSM / 16 pour LoRaWAN) est l'adresse par défaut qui s'applique à tous les contrôleurs de la famille (c.-à-d. pour le même Code de fournisseur et Code de fichier, et le même type de contrôleur LoRaWAN / GSM. Si le contrôleur n'a pas sa propre configuration individuelle définie, la configuration par défaut y est chargée.

Dans le cas des contrôleurs GSM, cette adresse correspond au numéro IMEI unique (15 caractères) attribué par le fabricant du modem GSM.

Dans le cas des contrôleurs LoRaWAN, cette adresse correspond à l'unique "Dev EUI" numéro donné par le fabricant du modem LoRaWAN (16 caractères en code hexadécimal).

Code de fournisseur - est un paramètre unique pour le client (utilisateur)

Code de fichier - est un paramètre indiquant le type de firmware (dépend de l'équipement et des algorithmes disponibles)

Dans la plupart des cas, il suffit de configurer ce périphérique (par défaut) pour l'ensemble du système ou comme modèle pour d'autres pilotes. Lors de la création d'une nouvelle configuration de contrôleur, ces paramètres sont copiés à partir du modèle.

Le micrologiciel et les configurations de toutes les installations (instances) sont situés sur les serveurs du fabricant du système @City disponibles via le WWW, auxquels l'utilisateur peut avoir un accès limité. Cependant, la configuration correcte est très critique, et il n'est pas recommandé d'apporter des modifications sans tester sur plusieurs appareils avec un accès physique complet (sur le bureau). Pour plus d'informations, veuillez consulter les conditions générales du système @City et les conditions spécifiques d'un mode de communication particulier.

3.2. Configuration générale des contrôleurs @City LoRaWAN et GSM

3.2.1 Configuration générale de l'appareil @City GSM

Avant de commencer la configuration, veuillez lire les conditions générales du système @City et les conditions spécifiques au système pour @City GSM.




Code de fournisseur - contient 8 caractères stockés en code hexadécimal dédié à un client (utilisateur). Il est accordé au stade de la production du contrôleur. Une tentative de modification peut causer des dommages permanents au contrôleur.

Code de fichier - contient 8 caractères stockés en code hexadécimal, dédiés à une version du firmware du contrôleur. Il est accordé au stade de la production du contrôleur et peut dépendre du type de communication (GSM / LoRaWAN) et des équipements supplémentaires, par ex. capteurs, le nombre d'entrées / sorties et les algorithmes individuels. Le changement peut entraîner des dommages permanents ou un blocage du contrôleur.

N ° PIN - Numéro PIN à 4 chiffres s'il est défini pour la carte SIM. Il n'est pas recommandé de définir des codes PIN. Pour les cartes SIM en plastique, vous pouvez les retirer de votre téléphone mobile. L'introduction d'une carte SIM incorrecte peut entraîner un blocage permanent de la carte dans l'appareil (auquel nous n'aurons finalement pas d'accès physique).

No de SMS - Numéro de SMS lors de l'envoi de l'état par SMS. Cette option est disponible en fonction du service et de l'opérateur (2G / CATM1 / NBIoT). Cela nécessite également d'activer le drapeau: SMS activé.

USSD Str - Commande USSD pour l'envoi d'états via USSD. Cette option n'est disponible que pour certains types de modems GSM (2G / 3G + GPS). L'option: Activation USSD est requis. L'opérateur doit fournir et activer le service USSD.

APN - Nom du point d'accès. Le nom du point d'accès Internet, par ex. l'Internet (pour les services spéciaux comme LTE-M1 ou NB-IoT, il peut être attribué individuellement par l'opérateur).

Adresse WWW - adresse Web (domaine ou IP) pour l'accès HTTP.

Page WWW - adresse de la page Web, où les statuts et les commandes des contrôleurs sont envoyés.

Activer HTTP - Active la transmission de données HTTP. Cette méthode génère beaucoup plus de transfert de données que toutes les autres méthodes de communication, ce qui peut entraîner une augmentation des coûts, un dépassement de la limite de transfert ou une incapacité à utiliser certains services, tels que NBIoT.

Adresse TCP / UDP - Adresse IP du serveur @City pour recevoir et transmettre des données entre le cloud et les appareils. Il est recommandé d'utiliser une adresse IP fixe et non une adresse de domaine Internet.

Port TCP - Port TCP / IP pour la communication

Activer TCP - Vous permet d'activer la transmission TCP / IP. Les trames de transmission et les confirmations TCP augmentent la quantité de données par rapport aux transmissions UDP, cependant, elles garantissent l'exactitude des données, les confirmations et garantissent leur livraison, si la communication est disponible.

Port UDP - Port pour recevoir l'état via UDP

Activer UDP - Activer la transmission UDP

Adresse Aux, Port Aux, Activation Aux - applications futures

Adresse Aux2, Port Aux2, Aux2 activé - applications futures

Activation du support des capteurs (ils doivent être physiquement montés sur le module @City). Sinon, l'appareil peut fonctionner beaucoup plus lentement et moins stable. Les capteurs sont installés au stade de la production pour toute la série de production.

Temp, pression, humidité, gaz - capteur intégré de température, pression, humidité et qualité de l'air

Temp + Presure - Capteur de température et de pression intégré

Gyroscope - Capteur gyroscope en 3 axes (X, Y, Z)

Magnétomètre - Capteur magnétique en 3 axes (X, Y, Z)

Accéléromètre - Capteur d'accélération / vibration sur 3 axes (X, Y, Z)

Couleur - Capteur de couleur (R, G, B, IR, G2)

Ambiant + proximètre - capteur de niveau de lumière intégré et (plage de 10 cm)

Commandes GSM - commandes supplémentaires d'initialisation du modem

Code de hachage - Un code de cryptage supplémentaire. Ne changez pas.

Transfert HTTP - Options de communication HTTP supplémentaires

Adresse globale - L'adresse globale du contrôleur pour la commande d'appareil à appareil.

Mode GSM - Mode de communication GSM (2G uniquement, LTE uniquement, CATM1, NBIoT, 2G + CAT M1, LTE 800, LTE 1800). Un réglage incorrect du mode de communication peut entraîner un blocage permanent de la communication de l'appareil.

3.2.2. Configuration générale des contrôleurs @City LoRaWAN

La plupart des options sont les mêmes que dans le contrôleur GSM. En principe, tous les champs liés à la communication GSM ne sont pas utilisés pendant le fonctionnement du contrôleur LoRaWAN. Les appareils LoRaWAN ont un micrologiciel différent qui prend en charge le module LoRaWAN à la place du GSM.

Sur le @Ville LoRaWAN côté appareil, la configuration est très simple:

EUID d'application - ID d'application pour le serveur LoRaWAN (16 caractères en code hexadécimal) - Application définie sur le serveur réseau / d'application LoRaWAN auquel nous envoyons des données.

Clé d'application - clé d'autorisation d'application pour le serveur LoRaWAN (comme ci-dessus)

Désactiver le débit de données adaptatif - Désactive la sélection de vitesse adaptative. Cela vous permet de forcer une vitesse constante de l'appareil. Dans certaines situations, cela peut entraîner de gros problèmes de communication. Il faut tenir compte du fait qu'à mesure que les paramètres RSSI et SNR s'améliorent en mode adaptatif, la vitesse augmente considérablement. Cela réduit considérablement le temps de transmission des données par radio "Sur le temps d'antenne" et bien plus souvent, des informations peuvent être transmises entre l'appareil et le serveur et vice versa.

Débit de données (DR) - Sélection de la vitesse de liaison LoRaWAN. Cette vitesse ne s'applique pas au Bootloader. Dans le cas où le contrôleur fonctionne en mode de réglage adaptatif de la vitesse, ce n'est que la valeur de départ, car le contrôleur après plusieurs tentatives de transmission, sélectionne de manière autonome la vitesse optimale pour limiter le temps de transmission des messages dans les airs.

Mettre à jour les paramètres - enregistre la configuration de démarrage du contrôleur - tous les paramètres



Le reste de la configuration @City LoRaWAN se trouve dans les éléments restants des écrans de configuration LoRaWAN du chapitre 4.

3.3. Configuration des entrées binaires




Les entrées binaires ont un certain nombre de fonctions et de paramètres qui permettent un fonctionnement autonome du contrôleur:

Inverser - négation d'entrée lorsque les capteurs "normalement connecté" (NC) sont connectés.

Alarme - activation de la fonction d'alarme.

Délai d'alarme - Temps de retard d'alarme. Si l'état d'entrée revient à son état d'origine avant l'expiration de ce délai, l'alarme ne sera pas activée.

Souvenez-vous de l'état - Il est temps de se souvenir du changement d'état d'entrée.

Désactiver l'exécution - Blocage des événements en cours liés à l'entrée.

Cours - Exécutez la commande de configuration d'entrée (Ad-Hoc)

Copie - Copier la commande de configuration d'entrée dans le presse-papiers

Événement activé - Description de la manière d'exécuter l'événement pour le niveau d'entrée haut (1)

Événement direct activé - Code d'événement à exécuter lorsque l'entrée est activée (0 => 1)

Événement désactivé - Description de l'activation d'événement pour un niveau d'entrée bas (0)

Événement direct désactivé - Code d'événement à exécuter lorsque l'entrée est désactivée (1 => 0)

Événement d'alarme - Description de l'événement d'alarme.

Événement d'alarme directe - Le code d'événement à déclencher lorsqu'une alarme se produit

Mettre à jour les paramètres - enregistre la configuration de démarrage pour tous les paramètres

3.4. Configuration des sorties binaires




Les sorties binaires intelligentes peuvent fonctionner en simple ou en double. Le formulaire vous permet de créer une configuration de démarrage pour le contrôleur (si vous la confirmez avec le bouton Mettre à jour).

Le formulaire sert également de créateur d'événements pour les sorties qui peuvent être démarrées en appuyant sur le bouton Exécuter ou copiées dans le presse-papiers pour une utilisation dans la configuration du contrôleur, par ex.



Configuration de sorties uniques:

Désactiver - Blocage de la sortie en mode simple (par ex. s'il est utilisé pour commander des entraînements afin de ne pas endommager accidentellement les volets roulants, portails, actionneurs)

Administrateur - Un drapeau administratif est requis lors de la modification des paramètres critiques

État - sélection de l'état (configuration initiale ou lancement de l'événement avec le "run" bouton)

Répète - Nombre de répétitions (changements d'état cycliques)

Il est temps - Heure d'activation de la sortie

Temps libre - Heure de désactivation de la sortie (c'est important lors de la répétition d'événements)

Cours - Exécutez l'événement pour quitter

Copie - Copiez l'événement dans le presse-papiers

Mettre à jour les paramètres - enregistre la configuration de démarrage pour tous les paramètres

Configuration à double sortie:

Désactiver - Verrouillez une paire de sorties en mode double (par ex. si utilisé comme entrées simples)

Administrateur - Un indicateur administratif est requis lors de la modification des paramètres critiques tels que le mode de lecteur

Somfy - mode variateur (coché => Somfy / décoché => Direct Servo)

État - sélection de l'état (pour la configuration initiale ou le déjeuner de l'événement avec le "run" bouton)

Répète - Nombre de répétitions (changement d'état cyclique)

Il est temps - Heure d'activation de l'état donné

Désactiver l'heure - Temps de blocage des sorties (temps minimum entre les changements de sorties) pour protéger les variateurs contre les dommages.

Temps libre - Heure de désactivation de la sortie (c'est important lors de la répétition d'événements)

Cours - Exécutez l'événement pour le lecteur

Copie - Copiez l'événement dans le presse-papiers

Mettre à jour les paramètres - enregistre la configuration de démarrage pour tous les paramètres

3.5. Configuration des entrées de mesure ADC et des capteurs supplémentaires (XIN)




Inverser - échelle inversée (100% -x) de l'entrée ADC

Alarme L - Activation de l'option pour générer une alarme lorsque la valeur descend en dessous du min. au seuil

Alarme H - Activation de l'option pour générer une alarme lorsque la valeur dépasse le max. au seuil

Délai d'alarme - Temps de retard d'alarme. Si l'état d'entrée revient à "d'accord" niveau avant la fin du temps, l'alarme ne sera pas activée.

Désactiver l'événement - Blocage de l'exécution des événements

Administrateur - flag admin permettant le changement de la configuration des entrées de mesure

Événement LOW - description de l'événement réalisé lors du dépassement du seuil bas

FAIBLE Direct - code d'événement à exécuter après avoir abaissé la valeur sous le seuil inférieur

Niveau faible - Niveau du seuil inférieur (min)

Événement OK - Description du "d'accord" un événement

OK Direct - code d'événement à exécuter après avoir saisi le "d'accord" intervalle

Événement HIGH - Description de l'événement pour le seuil supérieur

HAUT Direct - code d'événement à exécuter après dépassement de la valeur de seuil supérieure

Haut niveau - Niveau du seuil supérieur (max)

Cours - exécution de l'événement de configuration (changement de configuration ADC Ad-Hoc)

Mettre à jour les paramètres - enregistre la configuration initiale des entrées ADC

3.6. Configuration des gradateurs PWM / 0..10V




Inverser - Inversion de polarité du variateur (100% - x)

Administrateur - Un drapeau administratif qui vous permet de modifier les options critiques

Désactiver - Blocage de la sortie variateur

Une fois que - Modifiez les paramètres du gradateur une fois (puis arrêtez le gradateur)

Valeur Min - valeur minimale des réglages du gradateur

Valeur - valeur cible du variateur

Mode - Mode de réglage du gradateur (Stop / - / + / Set)

Marcher - Étape de modification de la valeur du niveau de gradateur

Valeur Max - la valeur maximale du réglage du gradateur

Cours - Exécute l'événement de gradateur

Copie - Copiez l'événement dans le presse-papiers



Le gradateur RGBW récupère les valeurs de réglage des couleurs individuelles.

De plus, il vous permet d'activer le mode de changement de couleur en continu à l'aide des préréglages de variateurs simples.

Mettre à jour les paramètres - enregistre la configuration de démarrage pour tous les paramètres





Boutons:

Mettre à jour les paramètres - sauvegarde de la configuration dans le système @City

Tous les contrôleurs - une liste de tous les contrôleurs

Paramètres - paramètres du contrôleur actuel

Changer les noms - changer le nom du contrôleur actuel

Planificateur - l'éditeur de calendrier-ordonnanceur du contrôleur actuel

Ecrire la configuration * - envoi d'une commande de téléchargement de la configuration par le contrôleur

Mise à jour du firmware * - envoi d'une commande pour télécharger le firmware par le contrôleur

Réinitialiser le contrôleur * - envoi de la commande de réinitialisation à télécharger par le contrôleur

Réinitialiser le contrôleur - Copier - copie de l'événement de réinitialisation du contrôleur dans le presse-papiers

Se déconnecter - déconnexion de l'utilisateur (pour des raisons de sécurité, vous devez également fermer toutes les instances ouvertes du navigateur Web qui peuvent stocker les paramètres de connexion dans le cache).

* - l'envoi de la commande signifie l'ajout à la file d'attente des événements. Lors de la connexion du contrôleur au système @City, le contrôleur télécharge ces événements.

3.7. Configuration du calendrier-planificateur


Le calendrier-ordonnanceur permet le déclenchement autonome d'événements (commandes) répétitifs ou programmés. Un exemple serait, par exemple, d'allumer le réverbère à 17 heures et de l'éteindre à 7 heures (en hiver).

Suppr (Supprimer) - supprime complètement l'élément de planification.

En. (Activer) - Activer l'élément de planification (seules les positions seront exécutées pour lesquelles le drapeau Activer est défini)

Nom - Nom de l'événement (vous pouvez décrire l'événement de manière reconnaissable)

Code d'événement - code d'événement en code hexadécimal (copié du presse-papiers lors de la création de commandes)

Champs du mois (Ja, Fe, .., No, De) - mois janvier ... Décembre au cours duquel l'événement débutera

Jour - Jour. Vous pouvez sélectionner n'importe quel jour du mois ou "*" pour tout (exécution de l'événement tous les jours).

Champs de la semaine (Lu, Ma, .. Su) - vous pouvez sélectionner les jours de la semaine où l'événement sera exécuté.

Heure - L'heure. Vous pouvez choisir n'importe quelle heure ou "*" pour tout le monde (animer l'événement toutes les heures).

Min - Minute. Vous pouvez sélectionner n'importe quelle minute ou "*" pour tout le monde (animer l'événement toutes les minutes).



Logique "et" l'algorithme est implémenté entre tous les champs (sauf Nom ), ils doivent donc tous être satisfaits pour que l'événement soit exécuté.



Par exemple. Allumer les lampadaires ( Novembre, décembre, janvier, février ) à 17.01 sans pour autant les dimanches.

Fr - sélectionné

Event code - 00002101010000000000 // exécution de la 1ère sortie binaire

Champs des mois - seul Non, De, Ja, Fe sont marqués

Jour - sélectionné "*" pour chaque jour du mois

Heure - l'heure sélectionnée est 17

Min - minute sélectionnée 01

Champs de la semaine - tout sauf Su choisi

4. Configuration de l'infrastructure réseau LoRaWAN

Ce chapitre s'applique uniquement à la communication LoRaWAN. Dans le cas de systèmes fonctionnant avec d'autres méthodes de transmission, il peut être omis.

Selon la spécification du réseau LoRaWAN, le contrôleur se connecte indirectement au cloud @City via:

4.1. Configuration de la passerelle LoRaWAN.

Il existe de nombreuses passerelles LoRaWAN sur le marché qui peuvent simultanément contenir un certain nombre d'options supplémentaires:

4.1.1. Configuration de base de la passerelle LoRaWAN

La passerelle LoraWAN doit être accessible depuis au moins une station de configuration.

Lors de l'installation via Ethernet / WiFi et de la configuration uniquement à partir d'un LAN / WLAN local, la sécurité de la passerelle n'est pas très critique (sauf si nous fournissons un accès à la passerelle de l'extérieur, c.-à-d. l'Internet).

Dans le cas où la passerelle LoRaWAN est connectée uniquement via GSM / LTE, il est nécessaire de sécuriser la passerelle contre les accès et divers types d'attaques.

- Si nous voulons pouvoir nous connecter à distance à la passerelle LoRaWAN, celle-ci doit disposer d'une adresse IP publique + statique et d'un service SSH disponible. Sinon, vous devrez vous connecter physiquement à la passerelle via une interface Ethernet ou WiFi.

- il est nécessaire de définir des mots de passe d'accès compliqués pour tous les utilisateurs de l'appareil.

- désactiver tous les services inutilisés tels que Telnet, FTP, POP, SMTP, IMAP, WWW, etc. qui peut être la cible d'attaques "occupant" la passerelle avec d'autres processus tels que les tentatives de connexion.

- vous pouvez limiter la possibilité de vous connecter, uniquement à partir de stations avec des adresses IP statiques sélectionnées, ce qui est une protection assez efficace contre le piratage. Cela s'applique également aux services apparemment insignifiants tels que ICMP (ping), HTTP, FTP, etc.

- après une configuration complète et de nombreuses semaines de tests système, nous pouvons bloquer tous les services externes et l'accès à distance, ce qui, cependant, entravera le service, recherchera et vérifiera les journaux de la passerelle.

4.1.2. Configuration de Semtech Packet Forwarder (SPF)

La tâche du SPF est d'envoyer des paquets LoRaWAN au serveur réseau LoRaWAN via le réseau IP (protocole UDP) à l'adresse requise du serveur réseau LoRaWAN.

La passerelle LoRaWAN avec SPF est transparente et transmet tous les paquets dans les deux sens.

Il ne traite ni n'autorise les paquets de données dans aucune direction.

La configuration du SPF est très simple et implique "direction" vers le serveur réseau LoRaWAN requis.

Connectez-vous via SSH à la passerelle LoRaWAN à l'aide du nom d'utilisateur et du mot de passe spécifiés par le fabricant de l'appareil.

Installez SPF conformément aux instructions du fabricant de la passerelle LoRaWAN.

Le répertoire de configuration SPF est "/ utilisateur / spf / etc /" cependant, selon le fabricant de la passerelle LoRaWAN, il peut être situé à d'autres emplacements.

La configuration principale de SPF est dans le fichier "/user/spf/etc/global_conf.json", qui doit être édité avec l'éditeur disponible (par ex. vi ou nano). Nous modifions la valeur du paramètre: "adresse du serveur" en entrant l'adresse IP fixe du serveur réseau ou le nom de domaine (nécessite un service client DNS supplémentaire correctement configuré).

Le port de communication de retour par défaut est 1700 (si vous prévoyez de les modifier, vous devez faire de même sur le serveur du réseau LoRaWAN) en saisissant des valeurs identiques.

Les journaux du package SPF se trouvent dans le "/ utilisateur / spf / var / logs /" répertoire dans le spf.log fichier et ses copies d'archive.

La configuration réseau de la passerelle LoRaWAN sous Linux OS se trouve normalement dans le répertoire "/etc/", où vous pouvez activer / désactiver les services réseau standard et sécuriser le serveur.

Vous devez également modifier les mots de passe de tous les utilisateurs disponibles sur le système avec le passwd commande pour se protéger contre tout accès non autorisé par des personnes non autorisées. Vous devez également modifier le mot de passe utilisateur pour l'assistance Web.

Il est également préférable de désactiver la communication WiFi, car des intrus peuvent essayer d'utiliser des attaques via ce support de transmission.

Une fois cette configuration terminée, réinitialisez la passerelle avec le redémarrer commander.



4.2. Configuration du réseau / serveur d'applications LoRaWAN

Il existe de nombreuses solutions pour les serveurs de réseau et d'applications (y compris les serveurs gratuits). Chacun d'eux a sa propre manière d'intégration avec des services et des systèmes externes (par ex. nuages ​​comme @Ville ). Pour cette raison, le @Ville le système doit avoir une interface pour l'intégration avec le serveur LoRaWAN NS / AS installé.

Dans le cas d'un système de production, nous pouvons utiliser le service gratuit "Le réseau des choses", tant que nous sommes dans des limites quotidiennes très importantes définies pour chaque appareil {en particulier "Sur le temps d'antenne" (30s **) et un petit nombre de commandes envoyées à l'appareil (10 **)}.

** Les limites quotidiennes indicatives des appareils peuvent changer.

Si vous devez charger un nouveau firmware et une nouvelle configuration, il est nécessaire d'utiliser votre propre serveur LoRaWAN (réseau + application).

Cela nous donne plusieurs options:

Sur certains systèmes, la configuration firmware + est fixe (pour tous les contrôleurs disponibles dans le système) et initiée au stade de la configuration initiale du système, ce qui simplifie la sélection.

(*) - dans ces cas, il est nécessaire d'avoir une deuxième passerelle LoRaWAN sur le deuxième serveur pour la configuration et la mise à jour du micrologiciel afin que l'environnement de production fonctionne en continu. Pour les applications peu critiques, vous pouvez modifier la configuration d'un serveur LoRaWAN dédié à la passerelle LoRaWAN, ce qui entraînera cependant une perte de communication avec l'environnement de production et un fonctionnement incorrect de ces périphériques.

Il faut se rendre compte que la mise à jour logicielle d'un seul contrôleur LoRaWAN prend environ une heure, avec une bonne portée (DR> = 4), il vaut donc la peine d'utiliser une passerelle supplémentaire pour mettre à niveau le firmware et la configuration. À faible couverture (DR <4), la configuration et la mise à jour du micrologiciel ne sont pas possibles et nécessitent une passerelle avec communication LTE à proximité des appareils mis à jour.

4.2.1. Configuration du serveur réseau LoRaWAN

Sur le serveur réseau LoRaWAN, ajoutez la passerelle de communication LoRaWAN (l'adresse se trouve sur son capot, ou dans le fichier "utilisateur / spf / etc / local_conf.json", ou affiché dans les journaux "/user/spf/var/log/spf.log". Vérifiez dans les journaux du serveur Web que la passerelle de communication se connecte au serveur.

Les étapes suivantes sont la configuration du serveur d'applications (il est généralement situé sur le même appareil que le serveur réseau).

Les prochaines étapes à effectuer dépendent de la solution de serveur d'applications utilisée et de la disponibilité de l'interface Back-End / Front-End. L'interface simplifie "premiers pas" et la configuration du système.

En règle générale, vous devez:

 







5. Conditions de travail des appareils @City GSM / LoRaWAN

Température - 40 ° C. + 65C

Humidité 0..80% r.H. pas de condensation (appareil)

GSM Alimentation 5VDC @ 2A ±0,15 V (pour capteur PPM et lors de la connexion de relais)

3,5VDC..4.2VDC @ 2A (dans les autres cas)


LoRaWAN power supply 5VDC @ 300mA ± 0,15 V (pour capteur PPM et lors de la connexion de relais)

3VDC..3.6VDC @ 300mA (dans les autres cas)


Appareils GSM + GPS:

Entrée d'antenne 50ohm

SIM nano-SIM ou MIM

(choix au stade de la production - MIM impose un opérateur de réseau)

Approbation du modem Orange (2G-CATM1), T-Mobile / DT (2G-NBIoT), 2G Autres opérateurs


BANDES (L'Europe ) Sensibilité de la puissance de sortie de classe

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 + 33dB ±2 <-107 dB

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

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

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

Lors de l'utilisation d'une antenne externe à bande étroite adaptée en fréquence pour une bande donnée.


* uniquement pour le modem Combo: 2G, CATM1, NB-IoT

Certificats:



GPS / GNSS:

fréquence de fonctionnement: 1559..1610 MHz

impédance d'antenne 50ohm

sensibilité maximale * -160dB stationnaire, -149dB navigation, -145 démarrage à froid

TTFF 1s (chaud), 21s (chaud), 32s (froid)

A-GPS oui

Dynamique 2g

taux de rafraîchissement minimal 1 Hz


* antenne à bande étroite externe assortie



Périphériques LoRaWAN 1.0.2 (8 canaux, puissance TX: + 14 dBm) Europe (863-870 MHz)

DR T modulation Tests de sensibilité Rx BR bit / s

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 50 s SF9 / 125 kHz 1760 à 128,5 dB

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

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

6 (*) 50 s SF7 / 250 kHz 11 000 à 119 dB

7 FSK 50kbs 50000 -130dB

(*) Paramètres requis pour mettre à jour le firmware du système via OTA

(DR) - Débit de données

(BR) - Débit binaire

T - La période minimale de mise à jour des données vers le cloud @City




Tests pratiques de couverture LoRaWAN:


Conditions d'essai:

LoRaWAN Kerlink ifemtocell Passerelle interne

antenne large bande passive extérieure placée à l'extérieur à une hauteur de ~ 9 m au-dessus du niveau du sol Wygoda gm. Karczew (~ 110 m d'altitude).

Dispositif LoRaWAN avec DR0 forcé avec une antenne magnétique large bande externe placée à 1,5 m au-dessus du sol sur le toit de la voiture.

Zones rurales (prairies, champs avec de petits arbres et bâtiments rares)


Le résultat le plus éloigné était Czersk ~ 10,5 km (~ 200 m au-dessus du niveau de la mer) avec RSSI égal à -136 dB (c.-à-d. avec la sensibilité maximale du modem LoRaWAN garantie par le constructeur)