Version 6.2.0, données: 29 janvier 2020
Auteur: M. Westenberg ([email protected])
Copyright: M. Westenberg ([email protected])
Tous droits réservés. Ce programme et les documents qui l'accompagnent sont mis à disposition en vertu des termes de la licence du MIT qui accompagne cette distribution, et est disponible sur https://openseource.org/licenses/mit-license.php
Ce programme est distribué dans l'espoir qu'il sera utile, mais sans aucune garantie; Sans même la garantie implicite de qualité marchande ou d'adéquation à un usage particulier.
Entretenu par Maarten Westenberg ([email protected])
Tout d'abord: veuillez lire ce fichier et la documentation qu'il doit contenir la plupart des informations dont vous avez besoin pour commencer. Malheureusement, je n'ai pas le temps de suivre tous les e-mails, et comme la plupart des informations, y compris les épingles, etc. sont contenues sur ces pages, j'espère que vous avez le temps de les lire et de poster les questions restantes.
J'ai plus de 10 Mini Boards Wemos D1 en cours d'exécution, d'autres que j'ai construites moi-même, quelque 10+ sur Hallard, 3 sur Comresult et 4 planches ESP32. Ils fonctionnent tous sans problèmes sur ce code. J'ai cependant constaté que les bons joints de soudage et le câblage font toute la différence, donc si vous obtenez des réinitialisations / erreurs que vous ne pouvez pas expliquer, veuillez jeter un deuxième aperçu de votre câblage.
Ce référentiel contient une implémentation de preuve de concept d'une passerelle Lorawan à canal unique pour l'ESP8266. Le démarrage de la version 5.2 également l'ESP32 de TTGO (et d'autres) est pris en charge. Le logiciel implémente une passerelle LORA standard avec les exceptions et modifications suivantes:
Cette passerelle Lora n'est pas une passerelle complète, mais elle implémente juste une passerelle à un canal / une. La quantité minimale de fréquences soutenues par une passerelle complète est de 3, la plupart prennent en charge 9 fréquences ou plus. Ce logiciel a commencé comme une preuve de concept pour prouver qu'une seule puce RRFM95 à faible coût qui était présente dans presque tous les nœuds LORA en Europe pouvait être utilisée comme alternative bon marché aux passerelles complètes beaucoup plus coûteuses qui utilisaient la puce SX1301.
Comme le logiciel de cette passerelle sera souvent utilisé pendant la phase de développement d'un projet ou dans des situations de démonstration, le logiciel est flexible et peut être facilement configuré en fonction de l'environnement ou des exigences du client. Il existe deux façons d'interagir avec le logiciel:
Une documentation complète de la passerelle à canal unique est trouvée sur Things4u.github.io, veuillez consulter le guide matériel sous le chapitre de la passerelle.
La passerelle à canal unique a été testée sur une passerelle avec le WEMOS D1 Mini, en utilisant un émetteur-récepteur Hoperf RFM95W. Les tests ont été effectués sur la version 868 de LORA et quelques tests sur 433 MHz. Les nœuds lora testés à nouveau cette passerelle sont:
Le code a été testé sur au moins 8 cartes de passerelle distinctes à la fois sur la base des planches Hallard et Comresult. Je travaille toujours sur la broche et les fonctions ESP32 (attendu bientôt).
Il est recommandé de compiler et de démarrer la passerelle à canal unique avec le moins de modifications possible. Cela signifie que vous devez utiliser les paramètres par défaut dans les 2 fichiers de configuration autant que possible et ne modifier que le SSID / mot de passe pour votre configuration WiFi et les broches de votre ESP8266 que vous utilisez dans Loramodem.h. Cette section décrit le minimum de configuration nécessaire pour obtenir une passerelle de travail qui peut être configurée en utilisant la page Web.
Via le gestionnaire de bibliothèque:
Maintenant, votre passerelle devrait fonctionner. Utilisez la page Web pour définir "Debug" sur 1 et vous devriez pouvoir voir des packages arriver sur le moniteur en série.
Il existe deux façons de modifier la configuration de la passerelle à canal unique:
Lorsque vous avez le choix, l'option 2 est beaucoup plus conviviale et utile.
Le fichier Configgway.h contient les paramètres de passerelle configurable de l'utilisateur. Tous ont leurs définitions définies via les instructions #Define. En général, la définition d'un #Define sur 1 permettra la fonction et le définira sur 0 le désactivera.
De plus, certains paramètres peuvent être initialisés en définissant leur valeur avec un #Define mais peuvent être modifiés à l'exécution dans l'interface Web. Pour certains paramètres, la désactivation de la fonction avec un #Define supprimera également la fonction du serveur Web.
Remarque concernant l'utilisation de la mémoire: l'ESP8266 a une énorme quantité de mémoire disponible pour l'espace du programme et le système de fichiers SPIFFS. Cependant, la mémoire disponible pour le tas et les variables est limitée à environ 80k octets (pour l'ESP-32, c'est plus élevé). Il est conseillé à l'utilisateur de désactiver les fonctions non utilisées pour enregistrer sur l'utilisation de la mémoire. Si le tas tombe en dessous de 18 kilomètres, certaines fonctions peuvent ne pas se comporter comme prévu (dans un cas extrême, le programme peut s'écraser).
Le fichier Confignode.h est utilisé pour définir le point d'accès WiFi et la structure des capteurs connus sur la passerelle à 1 canal. La définition des points d'accès WiFi connues (SSID et mot de passe) doit être effectué au moment de la compilation.
Lorsque la passerelle n'est pas seulement utilisée comme passerelle, mais aussi à des fins de débogage, l'usage peut spécifier non seulement le nom du nœud du capteur, mais également décrypter pour certains nœuds le message.
L'utilisateur peut déterminer si la console USB est utilisée ou non pour les messages de sortie. Lors de la définition de _dUSB sur 0, toute la sortie par série est désactivée (en fait, les instructions série ne sont pas incluses dans le code).
#define _dusb 1
Définissez la classe d'opération qui est prise en charge par la passerelle. La classe A est prise en charge et contient l'opération de base pour les capteurs de batterie.
La classe B contient le mode de fonctionnement de la balise / batterie. La passerelle enverra une balise aux capteurs connectés qui leur permet de synchroniser les messages des liaisons descendante.
Le mode de fonctionnement de classe C (continu) contient la prise en charge des appareils qui ne sont probablement pas fonctionnels et écouteront le réseau à tout moment. En conséquence, la latence de ces appareils est également plus courte que pour les appareils de classe A. Les périphériques de classe C ne dépendent pas de l'alimentation de la batterie et prolongeront les fenêtres de réception jusqu'à la prochaine fenêtre de transmission. En fait, seules les transmissions feront abandonner l'appareil à écouter tant que cette transmission durera. Les périphériques de classe C ne peuvent pas effectuer l'opération de classe B.
#define _class "a"
Tous les appareils commenceront comme appareils de classe A et peuvent décider de «mettre à niveau» vers la classe B ou C. également la passerelle peut ou non prendre en charge la classe B, qui est un superset de la classe A. Remarque: seule la classe A est prise en charge
Nous prenons en charge deux configurations d'épinglage à l'extérieur: Hallard et Compresult. Si vous utilisez l'un de ces deux, définissez simplement le paramètre sur la bonne valeur. Si vos définitions de broches sont différentes, mettez à jour le fichier loramodem.h pour refléter ces paramètres. 1: Hallard 2: COMRESULT PIN OUT 3: ESP32 PIN OUT 4: Autre, définissez le vôtre dans Loramodem.h
#define _pin_out 1
Le paramètre suivant est défini sur 0 dans des circonstances normales. Il permet au système de formater le formatage du système de fichiers SPIFFS.
#define spiff_format 0
Définissez le facteur _Spreading sur la valeur SF7, SF8 - SF12 souhaitée. Veuillez noter que cette valeur est étroitement liée à la valeur utilisée pour _CAD. Si _CAD est activé, la valeur de _Spreading n'est pas utilisée par la passerelle car tous les facteurs de lecture sont activés.
#define _spreading sf9
Veuillez noter que la fréquence par défaut utilisée est de 868,1 MHz qui peut être modifiée dans le fichier loramodem.h. Il est conseillé à l'utilisateur de ne pas modifier cet etting et d'utiliser uniquement la fréquence par défaut 868,1 MHz.
La détection d'activité de canal (CAD) est fonction de la puce LORA RFM95 pour détecter les messages entrants (activité). Ces messages entrants peuvent arriver sur l'un des facteurs de propagation bien connus SF7-SF12. En permettant à la CAD, la passerelle peut recevoir des messages de l'un des facteurs de propagation.
En fait, il est utilisé en fonctionnement normal pour indiquer au récepteur qu'un autre signal utilise déjà le canal.
La fonctionnalité CAO a un (petit) prix: la puce ne pourra pas recevoir de signaux très faibles car la fonction CAO utilisera le réglage du registre RSSI de la puce pour déterminer s'il a reçu ou non un signal (ou simplement du bruit). En conséquence, les signaux très faibles ne sont pas reçus, ce qui signifie que la plage de la passerelle sera réduite en mode CAD.
#define _Cad 1
À partir de la version 4.0.6, la passerelle permet la mise à jour de l'air si le paramètre A_OTA est allumé. Le logiciel Over the Air nécessite une fois la définition de la version 4.0.6 sur USB vers la passerelle, après quoi le logiciel est (par défaut) activé pour une utilisation.
La première version ne prend en charge que la fonction OTA à l'aide de l'IDE qui, en pratique, signifie que l'IDE doit être sur le même segment de réseau que la passerelle.
Remarque: vous devez utiliser un logiciel Bonjour (Apple) sur votre réseau quelque part. Une version est disponible pour la plupart des plates-formes (expédiées avec iTunes pour Windows par exemple). Le logiciel Bonjour permet à la passerelle d'utiliser des MDN pour résoudre le jeu ID de passerelle par OTA, après quoi les ports de téléchargement apparaissent dans l'IDE.
TODO: Le logiciel OTA n'a pas (encore) été testé en conjonction avec le logiciel WifiManager.
#define a_ota 1
Ce paramètre permet le serveur Web. Bien que le serveur Web prenne lui-même beaucoup de mémoire, il aide grandement à configurer l'exécution de GatewayAt et inspecte son comportement. Il fournit également des statistiques des derniers messages reçus. Le paramètre A_Refresh définit si le serveur Web doit renouveler toutes les x secondes.
#define a_server 1 // définir le serveur Web local uniquement si cette définition est définie
#define a_refresh 1 // Le serveur Web est-il permis de rafraîchir oui / non? (oui c'est ok) #define a_serverport 80 // Port de serveur local local
#define a_maxbufSize 192 // doit être supérieur à 128, mais assez petit pour fonctionner
Le paramètre A_Refresh définit si nous pouvons ou non définir le paramètre de rafraîchissement oui / non dans le webbrowser. Le paramètre dans le WebBrowser est normalement mis sur "NON" par défaut, mais nous pouvons laisser la définition "1" pour activer ce paramètre dans le webbrowser.
Afin que la passerelle envoie des messages de liaison descendante sur le facteur de propagation prédéfini et sur la fréquence par défaut, vous devez définir le paramètre _strict_1ch sur 1. Notez que lorsqu'il n'est pas défini sur 1, la passerelle répondra aux demandes de liaison descendante avec la fréquence et le facteur de propagation défini par le serveur de backend. Et pour le moment, TTN répond aux messages de liaison descendants pour SF9-SF12 dans le délai de temps RX2 et avec la fréquence 869.525 MHz et sur SF12 (selon la norme LORA lors de l'envoi dans le délai RX2).
#define _strict_1ch 0
Il est conseillé de ne pas modifier le paramètre par défaut de ce paramètre.
En définissant l'OLED, vous configurez le système pour travailler avec des panneaux OLED sur I2C. Certains panneaux fonctionnent à la fois par SPI et I2C où I2C est Solwer. Cependant, puisque SPI est utilisé pour la communication de l'émetteur-récepteur RFM95, vous êtes très discouvré en utilisant l'un d'eux car ils ne fonctionneront pas avec ce logiciel. Choisissez plutôt une solution OLED qui fonctionne sur I2C.
#define oled 1
Les valeurs suivantes sont définies pour OLED:
Lorsque cela est défini (== 1), nous rassemblerons les statistiques de chaque message et la sortions au système de fichiers SPIFFS. Nous nous assurons que nous utilisons un certain nombre de fichiers avec chacun un nombre fixe d'enregistrements pour les statistiques. Le numéro REC nous indique combien d'enregistrements sont autorisés dans chaque fichier de statistiques. Dès que le numéro REC est supérieur au nombre d'enregistrements autorisés, nous ouvrons un nouveau fichier. Une fois que le nombre de fichiers dépasse la quantité de fichiers de statistiques, nous supprimons le fichier oldest et ouvrons un nouveau fichier. Lors de la sélection du bouton "Log" en haut de l'écran de GUI, tous les fichiers journaux sont OUPTU vers le périphérique série USB. De cette façon, nous pouvons examiner beaucoup plus d'enregistrements que d'ajuster l'écran de GUI ou la sortie en série.
#define stat_log 1
La définition des broches I2C SDA / SCL est effectuée dans le fichier Configgway.h juste après le #define de OLED. Standard L'ESP8266 utilise les broches D1 et D2 pour les lignes I2C BUS SCL et SDA, mais celles-ci peuvent être modifiées par l'utilisateur. Normalement, ce n'est pas nécessaire. Les fonctions OLED se trouvent dans le fichier _loramodem.ino et peuvent être adaptées pour afficher d'autres champs. Les fonctions sont appelées lorsqu'un message est reçu (!) Et par conséquent, cela ajoutera à l'instabilité de l'ESP car ces fonctions peuvent nécessiter plus de temps que prévu. Dans l'affirmative, SwithC hors de la fonction OLED ou construit dans une fonction dans la boucle principale () qui s'affiche en temps utilisateur (pas interrompre).
La passerelle permet de se connecter à 2 serveurs en même temps (comme la plupart des passerelles LORA le font BTW). Vous devez vous connecter à au moins un routeur LORA standard, au cas où vous utilisez le réseau (TTN) de choses que de vous assurer que vous définissez:
#define _ttnserver "router.eu.thethings.network"
#Define _ttnport 1700
Dans le cas où vous configurez votre propre serveur, vous pouvez spécifier comme suit en utilisant votre propre URL de routeur et votre propre port:
#define _Thingserver "votre_server.com" // URL du serveur du programme de serveur LORA UDP.js
#Define _thingport 1701 // Votre serveur UDP devrait écouter ce port
Définissez les paramètres d'identité pour votre passerelle:
#Define _Description "ESP-gateway"
#define _email "[email protected]"
#Define _Platform "ESP8266"
#define _lat 52.00
#define _lon 5.00
#define _alt 0
Il est possible d'utiliser la passerelle comme nœud. De cette façon, des valeurs de capteur locales / internes sont rapportées. Il s'agit d'une fonction CPU et à la mémoire car la fabrication d'un message de capteur implique des fonctions EAS et CMAC.
#define GatewayNode 0
Plus ci-dessous dans le fichier de configuration Confignode.h, il est possible de définir l'adresse et d'autres informations LORA du nœud de passerelle.
La façon la plus simple de configurer la passerelle sur le wifi est d'utiliser la fonction WiFimanager. Cette fonction fonctionne hors de la boîte. WiFimanager mettra la passerelle en mode AccessPoint afin que vous puissiez vous connecter en tant que point d'accès WiFi.
#define _wifimanager 0
Si WiFi Manager est activé, assurez-vous de définir le nom du point d'accès si la passerelle est en mode AccessPoint et le mot de passe.
#define ap_name "ESP8266-gway-things4u"
#define ap_passwd "ttnautopw"
Le nom du point d'accès standard utilisé par la passerelle est "ESP8266 Gway" et son mot de passe est "ttnautopw". Après avoir lié le point d'accès avec votre téléphone mobile ou votre ordinateur, accédez à HTP: //192.168.4.1 dans un navigateur et dites la passerelle au réseau WiFi que vous souhaitez qu'il se connecte et spécifiez le mot de passe.
La passerelle réinitialisera et se liera ensuite au réseau donné. Si tout se passe bien, vous êtes maintenant défini et l'ESP8266 se souviendra du réseau auquel il doit se connecter. Remarque: Tant que le point d'accès auquel la passerelle est liée est présente, la passerelle ne fonctionnera plus avec la liste WPA des points d'accès connus. Si nécessaire, vous pouvez supprimer le point d'accès actuel dans le serveur Web et le cycle d'alimentation de la passerelle pour le forcer à relire le tableau WPA.
#if GatewayNode == 1
#define _devaddr {0x26, 0x01, 0x15, 0x3d}
#define _appskey {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
#define _nwkskey {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
#define _sensor_interval 300
#endif
Le serveur Web intégré peut être utilisé pour afficher l'état et le débogage des informations. Le serveur Web permet également à l'utilisateur de modifier certains paramètres au moment de l'exécution tels que le niveau de débogage ou d'activer et de désactiver la fonction CAO. Il est accessible avec l'URL suivante: http: //: 80 où est l'IP donné par le routeur à l'ESP8266 au démarrage. C'est probablement quelque chose comme 192.168.1.xx Le serveur Web affiche divers paramètres de configuration ainsi que la fourniture de fonctions pour définir des paramètres.
Les paramètres suivants peuvent être définis à l'aide du serveur Web.
Le logiciel dépend de plusieurs logiciels, l'ide Arduino pour ESP8266 étant le plus important. Plusieurs autres bibliothèques sont également utilisées par ce programme, assurez-vous d'installer ces bibliothèques avec l'IDE:
Pour plus de commodité, les bibliothèques se trouvent également dans ce référentiel GitHub dans le répertoire des bibliothèques. Veuillez noter qu'ils ne font pas partie de la passerelle ESP 1Channel et peuvent avoir leur propre licence. Cependant, ces bibliothèques ne font pas partie du logiciel de passerelle unique.
Voir http://things4u.github.io dans la section matérielle pour les instructions de construction et de connexion.
Les dépendances suivantes sont valables pour la passerelle à canal unique:
Les choses suivantes sont toujours sur ma liste de souhaits à faire à la passerelle à canal unique:
Les fichiers source du croquis de passerelle dans ce référentiel sont mis à disposition sous la licence MIT. Les bibliothèques incluses dans ce référentiel sont incluses uniquement pour la commodité et toutes ont leur propre licence, et ne font pas partie du code de passerelle ESP 1CH.