la SNOC sort une carte breakout (prototypage) de dimensions réduites. Basée sur un module Wisol SFM10R1 cette carte vous permet de disposer des fonctionnalités de SigFox sur tous vos montages. C’est l’IoT à portée de Raspberry Pi !
Après la carte RPISIGFOX destinée à munir le Raspberry Pi de l’accès à SigFox que je vous avais présentée fin 2015, voici une nouvelle carte équipée du tout récent module SFM10R1 de Wisol. SNOC m’a proposé de la tester sur le Raspberry Pi, ce que j’ai accepté avec plaisir et j’ai donc reçu à titre gracieux ce module (merci Pascal), ce qui vaut à cet article d’être classé comme sponsorisé.
Si vous voulez un rappel sur la technologie SigFox, reportez vous à l’article précédent. Rapidement, on peut dire que la portée d’un émetteur en numérique dépend de sa puissance, mais aussi du débit de données. Avec un faible débit de données, la portée peut être très importante. C’est le principe de SigFox.
============= Article sponsorisé =============
Breakout board – Carte de Prototypage SigFox pour Raspberry Pi et Arduino
La carte SNOC BRKSW01
La carte que propose SNOC est vraiment de dimension réduite puisqu’elle occupe moins de 5 cm2 !
Si on la compare à un timbre poste on voit que son encombrement est à peine supérieur.
Ceci permet d’envisager de l’embarquer dans des montages de taille réduite qui nécessiteraient une connexion à SigFox.
IoT nous voici !
Le matériel reçu
L’ensemble du matériel arrive dans un carton. Tout est bien protégé. L’antenne et son câble sont dans un sachet plastique zippé.
La carte SigFox est dans une pochette antistatique de bonne qualité. Vous éviterez de trop la manipuler, de mettre les doigts sur les pastilles etc. Ça craint l’électricité statique ces petites choses là !
Le matériel inclus dans le paquet reçu intègre le module lui même, ainsi que les connecteurs à souder (eh oui, il faudra sortir votre fer à souder ! ) pour monter le module à l’horizontale ou à la verticale.
Le montage de gauche permet d’assurer une bonne rigidité en cas de montage sur une breadboard (plaque d’expérimentation) ou sur une carte de circuit imprimé. La version de droite, pour montage vertical autorise un montage/démontage facile sur une breadboard. C’est cette configuration que j’ai choisie.
Le matériel comprend également une antenne adaptée à la fréquence de SigFox, ainsi qu’un adaptateur UFL <=> RP-SMA de 100 mm de longueur, assurant la liaison entre la prise coaxiale présente sur la carte et l’antenne.
Le module WISOL WSSFM10R1
Le module émetteur/récepteur SigFox qui équipe la carte pèse moins d’un gramme (0,85 g) et ne mesure quant à lui que 13 x 15 x 2,21 mm. Il confère à la carte ses caractéristiques, la contribution de SNOC est de faciliter son utilisation par les makers en proposant une carte facile à mettre en œuvre. Le module est en CMS et pas facile à souder avec des moyens amateurs.
Alimenté entre 1,8 et 3,3 volts, il consomme un peu plus de 50 mA en émission et 15 mA en réception (uniquement pendant le temps de ces opérations). En veille, la consommation chute à 2 μA !
Ses caractéristiques :
- Taille : 13.0×15.0x2.21mm
- Chipset : AX-SFEU-1-01/ ON Semiconductor
- Freq. Tx/ Data rate : 868.13MHz/ 100bps
- Freq. Rx/ Data rate : 869.525MHz/ 600bps
- Puissance sortie Tx : +14dBm (max)
- Sensibilité Rx : -127dBm@600bps
- Alimentation : @+3.3V
- Tx : 60mA(max), Rx: 15mA (max)
- Tensions acceptées : +1.8V~+3.6V
- Température d’utilisation : -30°C à +85°C
Le module utilise un TCXO 48 MHz pour rester dans la tolérance des fréquences SigFox durant toute la durée de vie du produit.
Ce module intègre un circuit ON Semiconductor AX-SFEU dont la documentation est disponible en ligne.
Le schéma du AX-SFEU
Ce schéma est extrait d’une note d’application du module AX-SFEU (page 16). S’il peut donner une idée du schéma réel du module Wisol dans lequel le AX-SFEU est utilisé, il n’y a aucune garantie qu’il soit exactement celui qui est mis en œuvre. Il n’est donné qu’à titre indicatif.
En résumé :
La carte BRKWS01 requiert au minimum les connexions +3,3v, masse et Tx Rx. Les transmissions de données peuvent être surveillées avec les LED LEDTX et LEDRX. La carte dispose également de deux sorties pour une LED CPU (activité du processeur) et RADIO LED pour l’émission. Il faut réfléchir à l’adjonction de ces LED qui peuvent se révéler utiles pour la mise au point mais seront par le suite consommatrices de courant…
Voilà le schéma de branchement que j’ai retenu.
La carte SNOC embarque un module Wisol SFM10R1… qui embarque un module AX-SFEU Avec la doc de ce dernier module on peut donc tirer pas mal d’informations sur le fonctionnement de tout cet ensemble et envisager des trucs rigolos… non ?
Par exemple, d’après SNOC les commandes AT$I=10 et AT$I=11 renvoient l’ID du module et le PAC… Ce qui correspond bien à la documentation du module AX-SFEU.
Si vous intervenez dans les registres de la carte, vous le faites à vos risques et périls, ni SNOC ni framboise314 ne pourront être tenus pour responsables en cas de dysfonctionnement.
Montage de la carte SNOC BRKWS01
Soudure du connecteur
J’ai sorti mon plus beau fer à souder pour souder le connecteur coudé. Utilisez un fer bien propre et évitez de chauffer trop fortement les pastilles. Éventuellement laissez un peu de temps entre deux soudures pour laisser redescendre la température.
Connexion de l’antenne
L’antenne se connecte sur cette prise, destinée à être montée sur un châssis ou un boîtier. Si vous faites un montage « en l’air » vissez d’abord la prise SMA sur l’antenne pour éviter de soumettre le câble à des torsions trop importantes.
Vissez bien la prise SMA sur l’antenne.
Connexion du câble sur la carte
La carte comporte une prise coaxiale miniature.
La prise présente à l’extrémité du câble d’antenne va venir se positionner sur la prise de la carte. Il faudra bien l’enfoncer pour assurer le contact et une solidité suffisante de la liaison.
Voilà, la prise est connectée à la carte. On est pratiquement prêt à passer aux essais. S’il se fait tard, reportez les essais à demain matin. Lorsqu’on commence à être fatigué il est plus facile de faire des conneries erreurs et vous risquez de mettre la vie de la carte SigFox en danger.
Mise en place de la carte prototype sur le Raspberry Pi
Bon, j’avoue ce n’était pas simple de connecter la carte SNOC BRKWS01 sur le GPIO du Raspberry Pi. Je ne voulais pas faire un montage volant avec des fils de liaison femelle/femelle. C’est un coup à laisser traîner (volontairement ou involontairement) la carte à un endroit dangereux. J’ai donc choisi d’utiliser une carte Explorer HAT Pro récemment arrivée.
Elle offre la possibilité d’accéder facilement à des ports GPIO intéressants dans ce cas : le 3,3 v et la masse, ainsi que les E/S de l’UART, TxD et RxD sur des connecteurs type Arduino.
L’Explorer HAT Pro est également équipée d’une mini breadboard bien pratique pour des essais rapide de petits montages électroniques, et bien adaptée dans le cas qui nous intéresse. Dans un premier temps j’avais positionné la carte « dans le fond » mais à l’usage il s’est avéré plus judicieux de la monter plus en avant et de connecter les fils derrière. Après… vous ferez bien comme vous voulez
Avant de relier les fils, si vous utilisez ce type de carte, pensez à faire un test de bon fonctionnement du Raspberry Pi. Un démarrage du système au minimum pour vérifier qu’il n’y a pas de souci avec la carte seule. Ensuite vous pourrez connecter les fils…
Pensez aussi à tester le bon fonctionnement du port série avant de vous lancer dans les tests ! Pas la peine d’aller plus loin si le port série ne répond pas
Pour ma part j’ai bouclé Tx et Rx et utilisé putty.
Comme d’habitude, si vous montez, connectez, reliez tout le bazar et que ça ne démarre pas ou que ça ne fonctionne pas… vous ne saurez pas où chercher Alors allez-y doucement, pas à pas, étape par étape… Vous augmenterez vos chances de réussite !
Connexion et tests
Bon, voilà… tout est connecté on peut passer aux essais. Pour tester la carte SigFox, j’ai choisi d’utiliser putty sur le Raspberry Pi (il n’est pas d’origine dans Raspbian, il faudra l’installer).
Configuration de putty
Configurez l’interface série comme ci-dessus.
Puis connectez vous sur le port série (cliquez sur le bouton Open). Avant de continuer on va faire une parenthèse, je vous explique ce qu’est l’écho. Si vous connaissez déjà… passez au chapitre suivant
L’écho, qu’est-ce ?
En informatique ça désigne le traitement qui est réservé à un caractère envoyé par un terminal (putty dans notre cas) à une unité centrale (la carte SigFox ici). Si une commande est composée de plusieurs caractères, chaque caractère est traité indépendamment.
Premier cas : pas d’écho
Le terminal envoie la commande AT (aussi appelée commande Hayes) à la carte SigFox. En l’absence d’écho, la carte SigFox reçoit la commande et répond OK si elle fonctionne… Le problème c’est que si rien ne s’affiche on ne sait pas si c’est parce que la carte ne fonctionne pas ou si la commande AT est réellement partie… (configuration, problème hard…)
Deuxième cas : écho distant
Lorsque l’écho distant est activé (dans ce cas ça se passe au niveau de l’UC distante, donc de la carte SigFox dans notre cas) le terminal envoie la commande AT à l’UC distante, qui la renvoie vers le terminal. Dans ce cas on est certain(e) que tout fonctionne, la liaison aller-retour ET la carte SigFox. Ensuite si l’UC distante (la carte SigFox) est prête, elle renvoie OK.
Le problème c’est que je n’ai pas trouvé dans les commandes de l’AX-SFEU de commande AT permettant d’activer l’écho On ne pourra donc pas utiliser l’écho distant. Par défaut on sera donc en mode sans écho comme ci-dessus dans le premier cas.
Troisième cas : écho local
Pour pallier à l’absence de l’écho distant il existe sur les terminaux un mode écho local qui envoie sur l’écran les commandes saisies, sans les faire transiter par l’UC distante. On voit donc s’afficher la commande et la réponse de l’UC distante. Bien évidemment, en cas de problème de liaison ou de non fonctionnement de la carte SigFox, on se retrouve avec juste AT affiché sur l’écran, sans savoir d’où vient le souci. C’est ce mode que nous utiliserons pour dialoguer avec la carte SigFox. Nous verrons comment activer le mode écho local sur putty.
Quatrième cas : écho local ET écho distant
Là c’est la totale. Lorsque vous tapez AT sur le clavier le terminal affiche AT sur l’écran (écho local) et envoie la commande simultanément via le port série jusqu’à l’UC distante. L’UC distante renvoie la commande AT vers l’écran. On se retrouve donc avec deux affichages successifs de chaque commande. Puis la carte SigFox répond OK. Sa réponse s’affiche sous les deux commandes AT.
Mode écho local sur putty
Dans putty ouvrez la catégorie Terminal et cochez Force on dans la rubrique Local echo. C’est bon nous sommes prêt(e)s pour tester la carte :
On commence par taper AT au clavier, puis Entrée
Yesssss la commande AT s’affiche et… ouf la carte répond OK ! On va pouvoir continuer à explorer les possibilités de la carte.
Inscription sur le site web SigFox
Avant de pouvoir accéder au réseau SigFox, il faut créer un compte sur le site de la société toulousaine. Cette inscription enregistre le numéro de série de votre carte SNOC et autorise le réseau à faire transiter vos données. Avec la carte SNOC, vous avez un an d’abonnement inclus, comprenant 140 messages (jusqu’à 12 octets) en UP par jour, et 4 messages en DOWN par jour.
Accéder à la page d’inscription
Rendez vous sur la page snoc.fr/sigfoxactivate. Cliquez sur le bouton ACTIVEZ.
Vous aboutissez sur le site SigFox. Sélectionnez le prestataire de votre pays. Pour la France… c’est SigFox
Saisissez les informations relatives à votre carte SNOC BRKWS01 (elles figurent sur les étiquettes du matériel que vous avez reçu).
Saisissez les informations nécessaires à la création de votre compte.
Votre inscription est terminée. Il reste à la valider en suivant le lien que vous avez reçu dans un mail à l’adresse que vous avez fournie.
Cliquez sur le lien dans le message pour terminer votre inscription.
Saisissez votre mot de passe (2 fois) en respectant les consignes : 8 caractères, comprenant au moins une minuscule, une majuscule, un chiffre et un caractère spécial !
Vous avez maintenant accès à la page de votre périphérique SigFox et allez pouvoir configurer certains paramètres, mais aussi voir les messages envoyés par votre carte.
Votre carte SigFox étant enregistrée sur le réseau, nous pouvons passer aux essais
Envoi de données via SigFox
Mode manuel
On va envoyer 12 octets de données à partir de putty :
Une commande AT pour voir si la carte répond… OK ! c’est bon ça fonctionne et on entre la commande d’envoi d’un message : AT$SF= suivie des 12 octets en hexadécimal.
Ensuite on appuie sur la touche Entrée et… on attend quelques secondes, le temps que les données soient envoyées par radio (n’oubliez pas qu’on a une grande portée, mais un faible débit). Quand le OK revient, c’est fait, votre message est envoyé !
On vérifie ?
Bon… Sur la page de mon module , sur le site de SigFox, on retrouve quoi ? La date et l’heure de mon message et le contenu que j’ai envoyé. Super !
En cliquant sur le symbole circulaire sous Location, on a l’affichage d’une carte qui indique la grande région dans laquelle le signal a été capté (carré coloré) et la zone de forte probabilité de la provenance (zones plus sombres). Ça correspond bien à ma position (Le Creusot – 71)
Programme Python
Si vous souhaitez envoyer des messages depuis une application domotique ou depuis une application que vous avez écrite, il est intéressant de le faire de façon automatique. Je vous propose ce programme traduit et adapté du github de SNOC.
#!/usr/bin/env python # -*- coding: utf-8 -*- ## @package rpisigfox # Ce script contrôle la carte BRKWS01 pour l'envoi d'un message SIGFOX. # # V1.0 Permet l'envoi d'un message normal sur le réseau SigFox. # syntaxe : # ./tx.py MESSAGE # où MESSAGE est une chaîne encodée en HEXA. La longueur peut être de 2 à 24 caractères représentant 1 à 12 octets. # Exemple : ./tx.py 00AA55BF envoie les 4 octets 0x00 0xAA 0x55 0xBF # import time import serial import sys from time import sleep class Sigfox(object): SOH = chr(0x01) STX = chr(0x02) EOT = chr(0x04) ACK = chr(0x06) NAK = chr(0x15) CAN = chr(0x18) CRC = chr(0x43) def __init__(self, port): # permet de choisir le port série – par défaut /dev/ttyAMA0 portName = port print 'Serial port : ' + portName self.ser = serial.Serial( port=portName, baudrate=9600, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, bytesize=serial.EIGHTBITS ) def getc(self, size, timeout=1): return ser.read(size) def putc(self, data, timeout=1): ser.write(data) sleep(0.001) # temporisation pour permettre au circuit de se préparer def WaitFor(self, success, failure, timeOut): return self.ReceiveUntil(success, failure, timeOut) != '' def ReceiveUntil(self, success, failure, timeOut): iterCount = timeOut / 0.1 self.ser.timeout = 0.1 currentMsg = '' while iterCount &amp;amp;amp;amp;gt;= 0 and success not in currentMsg and failure not in currentMsg : sleep(0.1) while self.ser.inWaiting() &amp;amp;amp;amp;gt; 0 : # bunch of data ready for reading c = self.ser.read() currentMsg += c iterCount -= 1 if success in currentMsg : return currentMsg elif failure in currentMsg : print 'Erreur (' + currentMsg.replace('\r\n', '') + ')' else : print 'Délai de réception dépassé (' + currentMsg.replace('\r\n', '') + ')' return '' def sendMessage(self, message): print 'Sending SigFox Message...' if(self.ser.isOpen() == True): # sur certaines plateformes il faut d'abord fermer le port série self.ser.close() try: self.ser.open() except serial.SerialException as e: sys.stderr.write("Ouverture du port série impossible {}: {}\n".format(ser.name, e)) sys.exit(1) self.ser.write('AT\r') if self.WaitFor('OK', 'ERROR', 3) : print('SigFox Modem OK') self.ser.write("AT$SF={0}\r".format(message)) print('Envoi des données ...') if self.WaitFor('OK', 'ERROR', 15) : print('OK Message envoyé') else: print 'Erreur Modem SigFox' self.ser.close() if __name__ == '__main__': if len(sys.argv) == 3: portName = sys.argv[2] sgfx = Sigfox(portName) else: sgfx = Sigfox('/dev/ttyAMA0') message = "1234CAFE" if len(sys.argv) &amp;amp;amp;amp;gt; 1: message = "{0}".format(sys.argv[1]) sgfx.sendMessage(message) #time.sleep(600) #mise en sommeil pendant 10 mn
Ce programme s’utilise en ajoutant en paramètre les 12 octets à envoyer. Comme parfois l’éditeur de WordPress fait des siennes avec les programmes, vous pouvez aussi le télécharger ici.
Essai du programme SigFox en Python
pi@raspberrypi:~ $ ./tx.py 012345678901AABBCCDDEEFF Serial port : /dev/ttyAMA0 Sending SigFox Message... Délai de réception dépassé () Erreur Modem SigFox
Quand ça ne fonctionne pas voilà ce qui se passe. En fait ici j’avais laissé putty connecté au port série. Le programme n’a pas pu accéder au port qui était déjà occupé et a retourné une erreur.
pi@raspberrypi:~ $ ./tx.py 012345678901AABBCCDDEEFF Serial port : /dev/ttyAMA0 Sending SigFox Message... SigFox Modem OK Envoi des données ... OK Message envoyé
Cette fois le message a bien été envoyé. Un tour sur le site SigFox pour confirmer :
Vous voyez que le précédent message est « descendu » d’un cran et que le nouveau message est bien affiché sur la première ligne.
Envoyer le message vers un site web
Principe
La première partie de l’aventure reste la même : le Raspberry Pi envoie un message à la carte SigFox. La carte transmet les 12 octets maxi) par radio au réseau SigFox. A réception du message le serveur SigFox va transférer les données vers un serveur désigné par l’utilisateur. C’est ce qu’on appelle un « callback ».
Paramétrage du callback
Dans l’onglet « Device Type » du site SigFox, en cliquant sur le nom de la carte, on fait apparaître dans la colonne de gauche un menu comportant l’option Callback. En cliquant sur cette option, on ouvre la fenêtre ci-dessus. Le lien encadré en rouge est appelé après réception du message. Le numéro de la carte SigFox {device} et les données {data} reçues sont passées en paramètres à la page sigfox.php, présente sur le serveur VPS hébergé chez web4all.
Vous pourrez aussi passer les infos en PUT et en json si ça vous fait plaisir RTFM
Le fichier sigfox.php
<?PHP // Création de la chaine contenant les données $data = ''; $data .= htmlspecialchars($_GET["id"]).PHP_EOL; $data .= htmlspecialchars($_GET["data"]).PHP_EOL; // Création du nom de fihier horodaté $name = 'data_'.date('Y-m-d H:i:s').'.txt'; $maj = fopen($name,"w+"); // On ouvre le fichier en ecriture fseek($maj,0); // On se place en debut de fichier fputs($maj, $data); // On ecrit dans le fichier la chaine $data fclose($maj); // On ferme le fichier ?>
Bon, j’avoue que je ne me suis pas foulé mais l’idée ici c’est de voir si ça fonctionne. Après, quand vous saurez récupérer vos données vous en ferez bien ce que vous voulez… Et puis ça vous fera un peu bosser aussi
Dans le dossier du site web (accès au VPS avec putty) sur le serveur VPS on retrouve le fichier PHP sigfox.php qui récupère les données et les enregistre dans un fichier (par sécurité je vais le renommer avant de publier cet article ). On voit aussi les fichiers horodatés créés lors des tests de la carte BRKWS01.
Les données enregistrées
root@prebeta1:/var/www/html# cat data_2017-02-14 20:46:52.txt 21xxxx 012345678901aabbccddeedd
Chaque fichier de données contient le numéro de la carte SigFox qui a envoyé le message et sur la ligne suivante le message lui-même.
Libre à vous de stocker ces infos dans une base de données, d’en extraire des moyennes, des statistiques et/ou de jolies courbes…
Dans 12 octets qu’est ce que tu veux mettre ?
Je viens d’un autre siècle. Non, je n’ai pas profité d’une faille spatio-temporelle ni effectué un voyage dans le temps. Mon premier ordinateur avait 1 Ko de mémoire. Pour les plus jeunes : il n’y a pas d’erreur ! Le ZX 81 possédait une mémoire de 1024 octets. Bon, j’ai vite ajouté une mémoire supplémentaire de 16 Ko sinon on ne faisait pas grand chose. Mais à cette époque, Monsieur, on coupait les Bytes en 4. Je m’explique : la place était tellement chère qu’on jonglait avec les données en mémoire pour occuper le moins de place possible. Décalages, rotations et autres masques à base de Et ou de OU logique étaient de rigueur. Aujourd’hui plus personne ne s’en préoccupe avec les Go de RAM disponible.
Sauf que…
Quand on n’a que 12 octets… Comment qu’on fait ?
Gestion des bits de données
Un exemple sera plus parlant. Ce n’est qu’un exemple, hein, on peut certainement faire mieux et on peut certainement faire pire ! C’est pour faire comprendre à ceux qui n’ont jamais pratiqué ce genre d’exercice…
Une station météo isolée
C’est une demande fréquente dans la région (bin oui, je suis en Bourgogne) de disposer d’une station météo autonome pour surveiller une vigne. Elle doit être alimentée par panneau solaire, et pouvoir renvoyer par SigFox la température sol, la température de l’air, la pression atmosphérique, la vitesse et la direction du vent, la pluviométrie, la tension de batterie, la tension en sortie du panneau solaire et le courant de charge… en 12 octets.
Le bon informaticien replie son ordinateur portable, range sa tablette et sort quelques feuilles de brouillon, un crayon et une gomme. Le mauvais informaticien saute sur son clavier et se met à taper (n’importe quoi en général) frénétiquement… Enfin ça, c’est juste mon avis de vieil informaticien.
Le tableau est juste la transcription de réflexions « papier ». Après, vous ferez bien comme vous voulez
Température
- Un bit est nécessaire pour le signe (+ ou -)
- Trois bits codent le premier chiffre (0 à 7)
- Quatre bits codent le deuxième chiffre (0 à 9)
- Quatre bits codent pour la décimale (0 à 9)
Avec 12 bits on code une température entre -79,9 °C et +79,9 °C. On peut réduire le nombre de bits utilisés, au détriment de la facilité de traitement. c’est vous qui verrez en fonction de vos besoins de transmission d’information… Si vous avez eu ce genre de réflexion, n’hésitez pas à en faire part dans les commentaires. Toutes les idées sont bonnes !
Pression
Les valeurs extrêmes enregistrées mondialement sont de 870 hPa et 1086 hPa. Plus modestement en France on peut tabler sur 940 à 1067 hPa. J’ai donc choisi de représenter la valeur (pression – 940) ce qui donne une valeur entre 0 et 127 qu’on peut coder sur 7 bits.
Pour les autres valeurs du tableau, je vous laisse regarder, critiquer…
En bonus quelques commandes supplémentaires
SNOC fournit dans sa documentation les commandes suivantes :
Le jeu de commandes disponibles est assez limité. Heureusement la documentation AX-SFEU vient au secours de l’utilisateur curieux :
Présentation vidéo de la SNOC
Conclusion
Toute petite mais pleine de possibilités, cette carte ne coûte que 23,88 € avec les connecteurs, le câble de raccordement et l’antenne, plus un an d’abonnement à SigFox. Rien à redire de ce côté là.
Le fonctionnement est conforme à ce qui est attendu et le traitement des données ne pose aucun problème.
De mon côté j’aurais apprécié d’avoir un câble d’antenne un peu plus long. Il sera peut-être possible d’en trouver dans les accessoires.
Selon le montage qu’on fera, la carte sera au plus près de l’antenne (c’est mieux pour les ondes radio) et reliée au Raspberry Pi via une liaison série. Ici on n’a pas de contrainte de distance aussi forte. Du coup, j’aurais bien aimé trouver un trou de fixation sur le module, pour le monter sur une colonnette à proximité de l’antenne.
Vu la longueur de cet article, j’ai choisi de l’arrêter ici mais il y aura un second épisode car on peut aussi recevoir 4 messages par jour via SigFox (download) et piloter à distance certains équipements (mettre une chaudière en route, régler une température…). Plus prosaïquement, je prévois d’allumer une LED à distance en réglant sa brillance en PWM
Sources
- https://yadom.fr/reseaux-iot/sigfox/carte-breakout-sfm10r1.html
- https://github.com/SNOC/rpisigfox
- https://yadom.fr/downloadable/download/sample/sample_id/162/
- http://www.onsemi.com/pub_link/Collateral/AX-SFEU-D.PDF
Cet article Carte de prototypage SIGFOX par SNOC a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....