air - User contributions [en]

File:M2M-Mengoli-Chartier Presentation.pdf

2016-04-12T11:23:49Z

CHARTIER.Aurelien: CHARTIER.Aurelien uploaded a new version of "File:M2M-Mengoli-Chartier Presentation.pdf"

PM2M-2016-Meteo433/Suivi

2016-04-12T11:21:11Z

CHARTIER.Aurelien:

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Chartier Aurelien et Mengoli Jean-Luc.

Dépôt Git : [https://github.com/PM2M2016-CHARTIER-MENGOLI/M2M_Projet '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:M2M-Mengoli-Chartier_Presentation.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteurs envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant se connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coûte moins de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de température et d'UV et de les envoyer sur le cloud où elles seront traitées. Il sera alors possible de les consulter selon le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulières tels que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoie des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/{event} avec event=(Temp, Humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoie d'email
- Persistence : Envoie donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoie de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Réception des données sur la machine du cloud.
- Création base de donnée MySql
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
'''Des capteurs aux beagleBone Black :'''
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le capteur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

'''Du beagleBone Black au cloud :'''
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fait un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyés dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

'''Du cloud aux graphiques :'''
Nous utilisons le sitemap d'OpenHab pour la visualisation des données sous forme de graphique (Tableau de bord).

'''Du cloud aux mails :'''
Nous utilisons les rules d'OpenHab pour le traitement et l'envoie des alertes par email.

'''Accès cloud à distance :'''
Nous avons créé un groupe de sécurité sur AWS pour rendre accessible les données uniquement sur les machines voulus.
Il est donc possible uniquement pour celles-ci d'accéder au tableau de bord (visualisation données).

[[File:M2M-Chartier-Mengoli_Architecture.png]]

===Dashboard===

Le dashboard permet de visualiser les données reçues pour la température, les UV et l'humidité.

La couleur du nombre de degrée de la température est affiché en :

- Bleu si température < 10

- Rouge si température > 30

- Orange sinon

La photo du réservoir pour l'humité se remplit d'eau tout les 20 points (de 0: vide à 100 : rempli)

La couleur du nombre d'humité est affiché en gris de 0 à 40, et en bleu au dessus.

Pour chaque données un graphique est disponible. Ce graphique peut affiché les données sur la journée, la semaine ou le mois.

Un graphique mélant les données des températures et de l'humidité est disponible.

===Envoie d'Email===
Si la température dépasse 30 degrée ou descend en dessous de 0 degrée un mail de notification est envoyé, de même si l'humidité dépasse 60 %.

[[File:M2M-Chartier-Mengoli_Envoi_de_Mail.png]]

=Expérimentations et Résultats=
'''Emetteur/Recepteur rf 433MHz :'''
Nous avons essayé de remplacer l'antenne RFXcom avec les composant rf 433MHz. Une des motivation fut la non réception des données du capteur UV avec l'antenne RFXcom. Si les UV n'était pas reçus avec cette antenne, peut être le serait ils avec les composants rf ? L'autre motivation concerne le prix de l'antenne à plus de 100 euros et des composants rf à moins de 5 euros. Si notre expérimentation était un succès, cela aurais pu faire économiser une centaines d'euros aux différents utilisateur souhaitant réaliser un système semblable au notre. Cependant si la réception des données était aussi simpliste avec l'antenne RFXcom c'est grâce à la librairie déjà existante de RFXcom. Malheureusement nous ne disposions pas d'assez de temps pour l'analyse et le développement du code nécessaire à la réception des données en 433MHz.

File:M2M-Mengoli-Chartier Presentation.pdf

2016-04-12T11:19:41Z

CHARTIER.Aurelien:

PM2M-2016-Meteo433/Suivi

2016-04-10T10:01:25Z

CHARTIER.Aurelien:

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Chartier Aurelien et Mengoli Jean-Luc.

Dépôt Git : [https://github.com/PM2M2016-CHARTIER-MENGOLI/M2M_Projet '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteurs envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant se connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coûte moins de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de température et d'UV et de les envoyer sur le cloud où elles seront traitées. Il sera alors possible de les consulter selon le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulières tels que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoie des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/{event} avec event=(Temp, Humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoie d'email
- Persistence : Envoie donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoie de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Réception des données sur la machine du cloud.
- Création base de donnée MySql
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
'''Des capteurs aux beagleBone Black :'''
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le capteur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

'''Du beagleBone Black au cloud :'''
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fait un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyés dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

'''Du cloud aux graphiques :'''
Nous utilisons le sitemap d'OpenHab pour la visualisation des données sous forme de graphique (Tableau de bord).

'''Du cloud aux mails :'''
Nous utilisons les rules d'OpenHab pour le traitement et l'envoie des alertes par email.

'''Accès cloud à distance :'''
Nous avons créé un groupe de sécurité sur AWS pour rendre accessible les données uniquement sur les machines voulus.
Il est donc possible uniquement pour celles-ci d'accéder au tableau de bord (visualisation données).

[[File:M2M-Chartier-Mengoli_Architecture.png]]

[[File:M2M-Chartier-Mengoli_Envoi_de_Mail.png]]

=Expérimentations et Résultats=
'''Emetteur/Recepteur rf 433MHz :'''
Nous avons essayé de remplacer l'antenne RFXcom avec les composant rf 433MHz. Une des motivation fut la non réception des données du capteur UV avec l'antenne RFXcom. Si les UV n'était pas reçus avec cette antenne, peut être le serait ils avec les composants rf ? L'autre motivation concerne le prix de l'antenne à plus de 100 euros et des composants rf à moins de 5 euros. Si notre expérimentation était un succès, cela aurais pu faire économiser une centaines d'euros aux différents utilisateur souhaitant réaliser un système semblable au notre. Cependant si la réception des données était aussi simpliste avec l'antenne RFXcom c'est grâce à la librairie déjà existante de RFXcom. Malheureusement nous ne disposions pas d'assez de temps pour l'analyse et le développement du code nécessaire à la réception des données en 433MHz.

File:M2M-Chartier-Mengoli Envoi de Mail.png

2016-04-10T09:58:11Z

CHARTIER.Aurelien: CHARTIER.Aurelien uploaded a new version of "File:M2M-Chartier-Mengoli Envoi de Mail.png"

File:M2M-Chartier-Mengoli Envoi de Mail.png

2016-04-10T09:52:59Z

CHARTIER.Aurelien: CHARTIER.Aurelien uploaded a new version of "File:M2M-Chartier-Mengoli Envoi de Mail.png"

File:M2M-Chartier-Mengoli Envoi de Mail.png

2016-04-10T09:49:10Z

CHARTIER.Aurelien:

PM2M-2016-Meteo433/Suivi

2016-04-10T09:48:44Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Chartier Aurelien et Mengoli Jean-Luc.

Dépôt Git : [https://github.com/PM2M2016-CHARTIER-MENGOLI/M2M_Projet '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteurs envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant se connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coûte moins de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de température et d'UV et de les envoyer sur le cloud où elles seront traitées. Il sera alors possible de les consulter selon le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulières tels que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoie des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/{event} avec event=(Temp, Humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoie d'email
- Persistence : Envoie donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoie de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Réception des données sur la machine du cloud.
- Création base de donnée MySql
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
'''Des capteurs aux beagleBone Black :'''
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le capteur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

'''Du beagleBone Black au cloud :'''
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fait un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyés dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

'''Du cloud aux graphiques :'''
Nous utilisons le sitemap d'OpenHab pour la visualisation des données sous forme de graphique (Tableau de bord).

'''Du cloud aux mails :'''
Nous utilisons les rules d'OpenHab pour le traitement et l'envoie des alertes par email.

'''Accès cloud à distance :'''
Nous avons créé un groupe de sécurité sur AWS pour rendre accessible les données uniquement sur les machines voulus.
Il est donc possible uniquement pour celles-ci d'accéder au tableau de bord (visualisation données).

[[File:M2M-Chartier-Mengoli_Architecture.png]]

[[File:M2M-Chartier-Mengoli_Envoi_de_Mail.png]]

=Expérimentations et Résultats=
'''Emetteur/Recepteur rf 433MHz :'''
Nous avons essayé de remplacer l'antenne RFXcom avec les composant rf 433MHz. Une des motivation fut la non réception des données du capteur UV avec l'antenne RFXcom. Si les UV n'était pas reçus avec cette antenne, peut être le serait ils avec les composants rf ? L'autre motivation concerne le prix de l'antenne à plus de 100 euros et des composants rf à moins de 5 euros. Si notre expérimentation était un succès, cela aurais pu faire économiser une centaines d'euros aux différents utilisateur souhaitant réaliser un système semblable au notre. Cependant si la réception des données était aussi simpliste avec l'antenne RFXcom c'est grâce à la librairie déjà existante de RFXcom. Malheureusement nous ne disposions pas d'assez de temps pour l'analyse et le développement du code nécessaire à la réception des données en 433MHz.

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-10T09:38:25Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Chartier Aurelien et Mengoli Jean-Luc.

Dépôt Git : [https://github.com/PM2M2016-CHARTIER-MENGOLI/M2M_Projet '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteurs envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant se connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coûte moins de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de température et d'UV et de les envoyer sur le cloud où elles seront traitées. Il sera alors possible de les consulter selon le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulières tels que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoie des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/{event} avec event=(Temp, Humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoie d'email
- Persistence : Envoie donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoie de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Réception des données sur la machine du cloud.
- Création base de donnée MySql
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
'''Des capteurs aux beagleBone Black :'''
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le capteur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

'''Du beagleBone Black au cloud :'''
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fait un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyés dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

'''Du cloud aux graphiques :'''
Nous utilisons le sitemap d'OpenHab pour la visualisation des données sous forme de graphique (Tableau de bord).

'''Du cloud aux mails :'''
Nous utilisons les rules d'OpenHab pour le traitement et l'envoie des alertes par email.

'''Accès cloud à distance :'''
Nous avons créé un groupe de sécurité sur AWS pour rendre accessible les données uniquement sur les machines voulus.
Il est donc possible uniquement pour celles-ci d'accéder au tableau de bord (visualisation données).

[[File:M2M-Chartier-Mengoli_Architecture.png]]

[[File:Example.jpg]]

=Expérimentations et Résultats=
'''Emetteur/Recepteur rf 433MHz :'''
Nous avons essayé de remplacer l'antenne RFXcom avec les composant rf 433MHz. Une des motivation fut la non réception des données du capteur UV avec l'antenne RFXcom. Si les UV n'était pas reçus avec cette antenne, peut être le serait ils avec les composants rf ? L'autre motivation concerne le prix de l'antenne à plus de 100 euros et des composants rf à moins de 5 euros. Si notre expérimentation était un succès, cela aurais pu faire économiser une centaines d'euros aux différents utilisateur souhaitant réaliser un système semblable au notre. Cependant si la réception des données était aussi simpliste avec l'antenne RFXcom c'est grâce à la librairie déjà existante de RFXcom. Malheureusement nous ne disposions pas d'assez de temps pour l'analyse et le développement du code nécessaire à la réception des données en 433MHz.

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-10T09:37:36Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Chartier Aurelien et Mengoli Jean-Luc.

Dépôt Git : [https://github.com/PM2M2016-CHARTIER-MENGOLI/M2M_Projet '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteurs envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant se connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coûte moins de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de température et d'UV et de les envoyer sur le cloud où elles seront traitées. Il sera alors possible de les consulter selon le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulières tels que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoie des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/{event} avec event=(Temp, Humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoie d'email
- Persistence : Envoie donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoie de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Réception des données sur la machine du cloud.
- Création base de donnée MySql
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
'''Des capteurs aux beagleBone Black :'''
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le capteur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

'''Du beagleBone Black au cloud :'''
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fait un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyés dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

'''Du cloud aux graphiques :'''
Nous utilisons le sitemap d'OpenHab pour la visualisation des données sous forme de graphique (Tableau de bord).

'''Du cloud aux mails :'''
Nous utilisons les rules d'OpenHab pour le traitement et l'envoie des alertes par email.

'''Accès cloud à distance :'''
Nous avons créé un groupe de sécurité sur AWS pour rendre accessible les données uniquement sur les machines voulus.
Il est donc possible uniquement pour celles-ci d'accéder au tableau de bord (visualisation données).

[[File:M2M-Chartier-Mengoli_Architecture.png]]

[[File:M2M-Chartier-Mengoli_Envoi_de_Mail.png]]

=Expérimentations et Résultats=
'''Emetteur/Recepteur rf 433MHz :'''
Nous avons essayé de remplacer l'antenne RFXcom avec les composant rf 433MHz. Une des motivation fut la non réception des données du capteur UV avec l'antenne RFXcom. Si les UV n'était pas reçus avec cette antenne, peut être le serait ils avec les composants rf ? L'autre motivation concerne le prix de l'antenne à plus de 100 euros et des composants rf à moins de 5 euros. Si notre expérimentation était un succès, cela aurais pu faire économiser une centaines d'euros aux différents utilisateur souhaitant réaliser un système semblable au notre. Cependant si la réception des données était aussi simpliste avec l'antenne RFXcom c'est grâce à la librairie déjà existante de RFXcom. Malheureusement nous ne disposions pas d'assez de temps pour l'analyse et le développement du code nécessaire à la réception des données en 433MHz.

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T09:26:15Z

CHARTIER.Aurelien: /* Expérimentations et Résultats */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
'''Des capteurs aux beagleBone Black :'''
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

'''Du beagleBone Black au cloud :'''
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyées dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

'''Du cloud aux graphiques :'''
Nous utilisons OpenHab pour la visualisation des données sous forme de graphique.

'''Du cloud aux mails :'''

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=
'''Emetteur/Recepteur rf 433MHz :'''
Nous avons essayé de remplacer l'antenne RFXcom avec les composant rf 433MHz. Une des motivation fut la non réception des données du capteur UV avec l'antenne RFXcom. Si les UV n'était pas reçus avec cette antenne, peut être le serait ils avec les composants rf ? L'autre motivation concerne le prix de l'antenne à plus de 100 euros et des composants rf à moins de 5 euros. Si notre expérimentation était un succès, cela aurais pu faire économiser une centaines d'euros aux différents utilisateur souhaitant réaliser un système semblable au notre. Cependant si la réception des données était aussi simpliste avec l'antenne RFXcom c'est grâce à la librairie déjà existante de RFXcom. Malheureusement nous ne disposions pas d'assez de temps pour l'analyse et le développement du code nécessaire à la réception des données en 433MHz.

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:55:38Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

PM2M-2016-Meteo433/Suivi

2016-04-09T08:53:39Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# Des capteurs aux beagleBone Black
# coucou
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

# Du beagleBone Black au cloud
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyées dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

# Du cloud aux graphiques
Nous utilisons OpenHab pour la visualisation des données sous forme de graphique.

# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:53:23Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# Des capteurs aux beagleBone Black
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

# Du beagleBone Black au cloud
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyées dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

# Du cloud aux graphiques
Nous utilisons OpenHab pour la visualisation des données sous forme de graphique.

# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:52:59Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# [[Des capteurs aux beagleBone Black]]
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

# [[Du beagleBone Black au cloud]]
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyées dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

# Du cloud aux graphiques
Nous utilisons OpenHab pour la visualisation des données sous forme de graphique.

# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:52:33Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# [[Des capteurs aux beagleBone Black]]
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

# [[Du beagleBone Black au cloud]]
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyées dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un subscribe sur le broker pour récupérer les données.

# Du cloud aux graphiques
Nous utilisons OpenHab pour la visualisation des données sous forme de graphique.

# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:51:53Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# [[Des capteurs aux beagleBone Black]]
Les capteurs envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de température et d'humitité et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée à l'antenne RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script utilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le récepteur RFXcom qui capte précisément en 433 n'arrive pas à récupérer les données du capteur UV.

# [[Du beagleBone Black au cloud]]
Pour l'envoie et la réception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish sur un broker MQTT public (hiveMQ). Selon leurs type(température, humidité...), ils sont envoyées dans le dossier /Captor/M2M du broker. Sur le cloud la machine est charger de faire un susbcribe sur le broker pour récupérer les données.

# Du cloud aux graphiques
Nous utilisons OpenHab pour la visualisation des données sous forme de graphique.

# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:37:50Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# [[Des capteurs aux beagleBone Black]]
Les capteur envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de temperature et d'humitidé et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée au RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script uitilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le recepteur RFXcom qui capte précisement en 433 n'arrive pas à récupérer les données du capteur UV.

# Du beagleBone Black au cloud
Pour l'envoie et la reception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish sur un broker MQTT public (hiveMQ). Selon leurs type(temperature, humidité...), ils sont envoyées dans le dossier /Captor/M2M du broker.

# Du cloud aux graphiques
# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:37:25Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# Des capteurs aux beagleBone Black
Les capteur envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de temperature et d'humitidé et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée au RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script uitilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le recepteur RFXcom qui capte précisement en 433 n'arrive pas à récupérer les données du capteur UV.

# Du beagleBone Black au cloud
Pour l'envoie et la reception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish sur un broker MQTT public (hiveMQ). Selon leurs type(temperature, humidité...), ils sont envoyées dans le dossier /Captor/M2M du broker.

# Du cloud aux graphiques
# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:35:40Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# Des capteurs aux beagleBone Black
Les capteur envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de temperature et d'humitidé et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée au RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script uitilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le recepteur RFXcom qui capte précisement en 433 n'arrive pas à récupérer les données du capteur UV.

# Du beagleBone Black au cloud
Pour l'envoie et la reception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish sur un broker MQTT public (hiveMQ). Selon leurs type(temperature, humidité...), ils sont envoyées dans le dossier /Captor/M2M du broker.

# Du cloud aux graphiques
# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:27:17Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# Des capteurs aux beagleBone Black
Les capteur envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de temperature et d'humitidé et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée au RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script uitilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le recepteur RFXcom qui capte précisement en 433 n'arrive pas à récupérer les données du capteur UV.

# Du beagleBone Black au cloud
Pour l'envoie et la reception des données sur le cloud nous avons utilisé l'API Mosquitto. A chaque fois que le script Python reçoit des données, il les décrypte et fais un publish

# Du cloud aux graphiques
# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:19:31Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# Des capteurs aux beagleBone Black
Les capteur envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de temperature et d'humitidé et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée au RFXcom. C'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script uitilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le recepteur RFXcom qui capte précisement en 433 n'arrive pas à récupérer les données du capteur UV.

# Du beagleBone Black au cloud
# Du cloud aux graphiques
# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-09T08:18:33Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

'''Station météo 433 MHz'''

Etudiants [[PM2M/2016/TP|M2PGI PM2M]]: Etudiants

Dépôt Git : [https://github.com/PM2M-2016-Meteo433/pm2m '''github''']

Documents : [[Media:PM2M-2016-Meteo433.pdf|Rapport]] - [[Media:PM2M-2016-Meteo433-slides.pdf|Transparents]] - [[Media:PM2M-2016-Meteo433-flyer.pdf|Flyer]] - Video

=Contexte=
RFXcom permet de recevoir les données de nombreux capteur envoyées en 433MHz et de les décrypter. Pour ce faire il existe une librairie rfxcom disponible pour plusieurs languages de programmation comme le "C" ou le "Python". Ce matériel coûte une centaine d'euros.
(RFXcom peut également servir d'émetteur).

Il existe un récepteur rf en 433MHz pouvant ce connecter à une carte BeagleBone. Bien qu'il n'existe aucune librairie, ce récepteur peut théoriquement "remplacer" RFXcom (il existe également un émetteur rf en 433MHZ). Ce composant coût moin de 5 euros.

=Objectif du projet=
Le but du project est de récupérer en temps-réel les données envoyées par les capteurs de temperature et d'UV et de les envoyer sur le cloud où ils seront traitées. Il sera alors possible de les consulter celons le jour,la semaine ou le mois. Notre système pourra envoyer un mail d'alerte pour prévenir de conditions particulière telle que le gel ou la sécheresse.

=Matériel utilisé=
* Carte BeagleBone Black
* Emetteur/récepteur 433MHz RFXCom
* Emetteur rf 433MHz
* Récepteur rf 433MHz
* Capteur UV Oregon Scientific
* Capteur de température Oregon Scientific
* Machine Amazon T2.micro (Ubuntu)

=Technologies utilisées=
* Script python :
- Récupère les données des capteurs avec l'antenne RFXCOM (433MHZ)
- Décode la tram et envoit des données sur un serveur MQTT (publish)
* Mosquitto :
- Broker : borker.hivemq.com
- Port : 1883
- PATH : /Captor/M2M/data avec data=(temp, humidity, UV)
* MySQL : Base de donnée Openhab
* OpenHab (subscribe sur /Captor/M2M/# :
- Item : Temperature, Humidité, UV
- Sitemap : Dashboard
- Rules : Envoit d'email
- Persistence : Envoit donnée vers MySQL
* AWS EC2 :
Installé sur la machine :
-Openhab sous /opt/openhab
-Mosquitto
-MySql

=Plan de développement=

Le travail à été effectué en parallèle et réparti de la manière suivante :
* Aurélien Chartier :
- Réception des données provenant des capteurs sur la beagleBone.
- Décryptage des données.
- Envoi de ces données de la beagleBone Black au cloud.
* Jean-Luc Mengoli :
- Reception des données sur la machine du cloud.
- Visualisation des données sur des graphiques.
- Envoie de mails d'alerte.

==Mise en place de l'infrastructure==
# Des capteurs aux beagleBone Black
Les capteur envoient, en 433MHz, des tableaux de bits toutes les 50 secondes pour le cateur de temperature et d'humitidé et toutes les 70 secondes pour le capteur d'UV. Pour les recevoir la carte BeagleBone Black est connectée au RFXcom, c'est un script Python qui est chargé de récupérer les données et de les décrypter, ce script uitilise la librairie de RFXcom. Ici nous avons rencontré un problème majeur, nous ne recevions pas les tableaux de bits provenant du capteur UV. Après de nombreux essais nous sommes allé à la FabLab pour savoir pourquoi nous ne recevions pas ces données. La seul explication que avons trouvé est due à la fréquence de 433MHz qui est assez instable, le capteur UV envoie sur un fréquence légèrement plus haute ou plus basse c'est pourquoi le recepteur RFXcom qui capte précisement en 433 n'arrive pas à récupérer les données du capteur UV.

# Du beagleBone Black au cloud
# Du cloud aux graphiques
# Du cloud aux mails

[[File:M2M-Chartier-Mengoli_Architecture.png]]

=Expérimentations et Résultats=

=Photos et Vidéo=

PM2M-2016-Meteo433/Suivi

2016-04-08T16:34:16Z

CHARTIER.Aurelien: /* Objectif du projet */

PM2M-2016-Meteo433/Suivi

2016-04-08T16:33:48Z

CHARTIER.Aurelien: /* Plan de développement */

PM2M-2016-Meteo433/Suivi

2016-04-08T16:33:25Z

CHARTIER.Aurelien: /* Mise en place de l'infrastructure */

PM2M-2016-Meteo433/Suivi

2016-04-08T16:24:23Z

CHARTIER.Aurelien: /* Plan de développement */

PM2M-2016-Meteo433/Suivi

2016-04-08T16:24:05Z

CHARTIER.Aurelien: /* Plan de développement */

PM2M-2016-Meteo433/Suivi

2016-04-08T16:19:08Z

CHARTIER.Aurelien: /* Plan de développement */

PM2M-2016-Meteo433/Suivi

2016-04-08T16:18:43Z

CHARTIER.Aurelien: /* Objectif du projet */

PM2M-2016-Meteo433/Suivi

2016-04-08T16:17:50Z

CHARTIER.Aurelien: /* Plan de développement */

PM2M-2016-Meteo433/Suivi

2016-04-08T16:11:16Z

CHARTIER.Aurelien: -

PM2M-2016-Meteo433/Suivi

2016-04-08T16:05:46Z

CHARTIER.Aurelien: Re

PM2M-2016-Meteo433/Suivi

2016-04-08T15:52:21Z

CHARTIER.Aurelien: /* Contexte */

PM2M-2016-Meteo433/Suivi

2016-04-08T15:51:25Z

CHARTIER.Aurelien: /* Contexte */

PM2M-2016-Meteo433/Suivi

2016-04-08T15:33:05Z

CHARTIER.Aurelien: /* Contexte */

PM2M-2016-Meteo433/Suivi

2016-04-08T15:15:12Z

CHARTIER.Aurelien: /* Matériel utilisé */

PM2M-2016-Meteo433/Suivi

2016-04-08T14:54:42Z

CHARTIER.Aurelien: /* Technologies utilisées */

PM2M-2016-Meteo433/Suivi

2016-04-08T14:53:11Z

CHARTIER.Aurelien: /* Matériel utilisé */

PM2M-2016-Meteo433/Suivi

2016-04-08T14:52:54Z

CHARTIER.Aurelien: /* Matériel utilisé */

PM2M-2016-Meteo433/Suivi

2016-04-08T14:52:09Z

CHARTIER.Aurelien: /* Objectif du projet */

Hypercat

2016-04-01T14:14:33Z

CHARTIER.Aurelien: /* Principe */

HyperCat is a consortium and standard driving secure and interoperable Internet of Things (IoT) for Industry.

It is designed for exposing information about IoT assets over the web. Specifically, it provides as standard way for any client to discover resources that it understands on any server - without a human having to write code (which is otherwise the bottleneck to growing an ecosystem of IoT clients and services).

* [http://www.hypercat.io Website]
* [http://fr.slideshare.net/1248_io/hypercat-introduction-15-mins Hypercat explained in 16 mins]

==Problématique==
Les applications d'aujourd'hui ont besoin de plus en plus de données non centralisées et provenant de différents services ou fournisseurs de données. Ces données peuvent également être utilisées par plusieurs applications.

En supposant qu'ils possèdent les mêmes standarts (ex : protocole http, JSON, ...), chaque service a sa propre arborescence et est organisé différemment. Ainsi chacun d'eux nécessite de lire la documentation et d'écrire un code spécifique au service.

Cette nécessité est moins problématique dans un écosystème avec une "intégration verticale" où chaque application utilise un seul service, mais dans le cadre d'un écosysteme à "intégration horizontale" toutes les applications fonctionnent avec tous les servives.

Dans un tel système, en prenant l'exemple de 10 applications fonctionnant avec une dizaine de services, il serait nécessaire d'écrire 100 codes différents pour la communication entre applications et services. De plus, une application ne connait pas automatiquement un nouveau service. Il faudrait donc ajouter du code pour chaque nouveau service entrant dans le système.

HyperCat a été créé pour résoudre ces problèmes.

==HyperCat==
HyperCat est un consortium composé de 40 partenaires basés au Royaume-Uni comprenant des sociétés comme ARM ou BT ainsi que des universités locales. Il est financé par "Innovate UK" 6,4 millions de £.

Bien que HyperCat possède le soutien de grandes organisations, il a besoin de soutien de leaders tels que Google et Apple pour s'imposer comme le grand standard de l'Iot, ce qui selon le Dr Ian Brown est loin d'être garanti : "If a company is leading in a market why on earth would they do anything that would make it easier for their competitors to enter?" "Sometimes there will be circumstances that will persuade them that if they open up in this way they can grow the overall market larger, " "But the hard economics is that they may be reluctant to do that.".

==Principe==

'''Formats :'''

* JSON.
* Flexible metadata model.
* URLs.
* HTTP/HTTPS.

'''Catalogue :'''

Les clients qui ont besoin de données vont les stocker dans un graphe de connaissances, auxquels ils pourront exécuter des requêtes pour récupérer les différentes ressources. Ce graphe est composé d'une accumulation d'un ou plusieurs catalogues de ressources.

Les catalogues sont fournis par des serveurs sous forme de tableaux d'URLs. Chaque ressource dans le catalogue est annotée avec des metadatas structurées en RDF(Resource Description Framework).

''Remarque : Utiliser les mêmes metadatas comme annotation dans différents catalogues crée des points d'interopérabilité.''

Un catalogue est un document JSON où chaque élément possède une URL plus les metadatas obligatoires et est annoté avec un type MIME.

==Sources==
https://fr.scribd.com/doc/272460411/Untitled?secret_password=pxDWVPpxl3fElVIiZVv6#fullscreen

http://www.alphr.com/news/389503/hypercat-a-british-way-to-connect-the-internet-of-things

Hypercat

2016-04-01T14:11:21Z

CHARTIER.Aurelien: /* HyperCat */

HyperCat is a consortium and standard driving secure and interoperable Internet of Things (IoT) for Industry.

It is designed for exposing information about IoT assets over the web. Specifically, it provides as standard way for any client to discover resources that it understands on any server - without a human having to write code (which is otherwise the bottleneck to growing an ecosystem of IoT clients and services).

* [http://www.hypercat.io Website]
* [http://fr.slideshare.net/1248_io/hypercat-introduction-15-mins Hypercat explained in 16 mins]

==Problématique==
Les applications d'aujourd'hui ont besoin de plus en plus de données non centralisées et provenant de différents services ou fournisseurs de données. Ces données peuvent également être utilisées par plusieurs applications.

En supposant qu'ils possèdent les mêmes standarts (ex : protocole http, JSON, ...), chaque service a sa propre arborescence et est organisé différemment. Ainsi chacun d'eux nécessite de lire la documentation et d'écrire un code spécifique au service.

Cette nécessité est moins problématique dans un écosystème avec une "intégration verticale" où chaque application utilise un seul service, mais dans le cadre d'un écosysteme à "intégration horizontale" toutes les applications fonctionnent avec tous les servives.

Dans un tel système, en prenant l'exemple de 10 applications fonctionnant avec une dizaine de services, il serait nécessaire d'écrire 100 codes différents pour la communication entre applications et services. De plus, une application ne connait pas automatiquement un nouveau service. Il faudrait donc ajouter du code pour chaque nouveau service entrant dans le système.

HyperCat a été créé pour résoudre ces problèmes.

==HyperCat==
HyperCat est un consortium composé de 40 partenaires basés au Royaume-Uni comprenant des sociétés comme ARM ou BT ainsi que des universités locales. Il est financé par "Innovate UK" 6,4 millions de £.

Bien que HyperCat possède le soutien de grandes organisations, il a besoin de soutien de leaders tels que Google et Apple pour s'imposer comme le grand standard de l'Iot, ce qui selon le Dr Ian Brown est loin d'être garanti : "If a company is leading in a market why on earth would they do anything that would make it easier for their competitors to enter?" "Sometimes there will be circumstances that will persuade them that if they open up in this way they can grow the overall market larger, " "But the hard economics is that they may be reluctant to do that.".

==Principe==

'''Formats :'''

* JSON.
* Flexible metadata model.
* URLs.
* HTTP/HTTPS.

'''Catalogue :'''

Les clients qui ont besoin de données vont les stocker dans un graphe de connaissance, auxquels ils pourront executer des requêtes pour récupérer les différentes ressources. Ce graphe est composé d'une accumulation d'un ou plusieurs catalogues de ressources.

Les catalogues sont fournis par des serveurs sous forme de tableaux d'URLs. Chaque ressource dans le catalogue est annotée avec des metadatas structurées en RDF(Resource Description Framework).

''Remarque : Utiliser les mêmes metadatas comme annotation dans différents catalogues crées des points d'interopérabilité.''

Un catalogue est un document JSON où chaque élément possède une URL, les metadatas obligatoires et est annoté avec un type MIME.

==Sources==
https://fr.scribd.com/doc/272460411/Untitled?secret_password=pxDWVPpxl3fElVIiZVv6#fullscreen

http://www.alphr.com/news/389503/hypercat-a-british-way-to-connect-the-internet-of-things

Hypercat

2016-04-01T14:10:12Z

CHARTIER.Aurelien: /* Problématique */

HyperCat is a consortium and standard driving secure and interoperable Internet of Things (IoT) for Industry.

It is designed for exposing information about IoT assets over the web. Specifically, it provides as standard way for any client to discover resources that it understands on any server - without a human having to write code (which is otherwise the bottleneck to growing an ecosystem of IoT clients and services).

* [http://www.hypercat.io Website]
* [http://fr.slideshare.net/1248_io/hypercat-introduction-15-mins Hypercat explained in 16 mins]

==Problématique==
Les applications d'aujourd'hui ont besoin de plus en plus de données non centralisées et provenant de différents services ou fournisseurs de données. Ces données peuvent également être utilisées par plusieurs applications.

En supposant qu'ils possèdent les mêmes standarts (ex : protocole http, JSON, ...), chaque service a sa propre arborescence et est organisé différemment. Ainsi chacun d'eux nécessite de lire la documentation et d'écrire un code spécifique au service.

Cette nécessité est moins problématique dans un écosystème avec une "intégration verticale" où chaque application utilise un seul service, mais dans le cadre d'un écosysteme à "intégration horizontale" toutes les applications fonctionnent avec tous les servives.

Dans un tel système, en prenant l'exemple de 10 applications fonctionnant avec une dizaine de services, il serait nécessaire d'écrire 100 codes différents pour la communication entre applications et services. De plus, une application ne connait pas automatiquement un nouveau service. Il faudrait donc ajouter du code pour chaque nouveau service entrant dans le système.

HyperCat a été créé pour résoudre ces problèmes.

==HyperCat==
HyperCat est un consortium composé de 40 partenaires basées au Royaume-Uni comprenant des sociétés comme ARM ou BT ainsi que des universités locales. Il est financé par "Innovate UK" 6,4 millions de £.

Bien que HyperCat possède le soutien de grandes organisations, il a besoin de soutien de leaders tel que Google et Apple pour s'imposer comme le grand standart de l'Iot. Ce qui selon le Dr Ian Brown est loin d'être garanti : "If a company is leading in a market why on earth would they do anything that would make it easier for their competitors to enter?" "Sometimes there will be circumstances that will persuade them that if they open up in this way they can grow the overall market larger, " "But the hard economics is that they may be reluctant to do that.".

==Principe==

'''Formats :'''

* JSON.
* Flexible metadata model.
* URLs.
* HTTP/HTTPS.

'''Catalogue :'''

Les clients qui ont besoin de données vont les stocker dans un graphe de connaissance, auxquels ils pourront executer des requêtes pour récupérer les différentes ressources. Ce graphe est composé d'une accumulation d'un ou plusieurs catalogues de ressources.

Les catalogues sont fournis par des serveurs sous forme de tableaux d'URLs. Chaque ressource dans le catalogue est annotée avec des metadatas structurées en RDF(Resource Description Framework).

''Remarque : Utiliser les mêmes metadatas comme annotation dans différents catalogues crées des points d'interopérabilité.''

Un catalogue est un document JSON où chaque élément possède une URL, les metadatas obligatoires et est annoté avec un type MIME.

==Sources==
https://fr.scribd.com/doc/272460411/Untitled?secret_password=pxDWVPpxl3fElVIiZVv6#fullscreen

http://www.alphr.com/news/389503/hypercat-a-british-way-to-connect-the-internet-of-things

Hypercat

2016-04-01T14:00:23Z

CHARTIER.Aurelien: /* Principe */

HyperCat is a consortium and standard driving secure and interoperable Internet of Things (IoT) for Industry.

It is designed for exposing information about IoT assets over the web. Specifically, it provides as standard way for any client to discover resources that it understands on any server - without a human having to write code (which is otherwise the bottleneck to growing an ecosystem of IoT clients and services).

* [http://www.hypercat.io Website]
* [http://fr.slideshare.net/1248_io/hypercat-introduction-15-mins Hypercat explained in 16 mins]

==Problématique==
Les applications d'aujourd'hui ont besoin de plus en plus de données non centralisées et provenant de différents services ou fournisseurs de données. Ces données peuvent également être utilisées par plusieurs applications.

En supposant qu'ils possèdent les mêmes standarts (ex : protocole http, JSON, ...), chaque service a sa propre arborescence et est organisé différemment. Ainsi chacun d'eux nécessite de lire la documentation et d'écrire un code spécifique au service.

Cette nécessité est moins problématique dans un écosystème avec une "intégration verticale" où chaque application utilise un seul service. Mais dans le cadre d'un écosysteme à "intégration horizontale" toutes les applications fonctionnent avec tous les servives.

Dans un tel système, en prennant l'exemple de 10 applications fonctionnant avec une dizaine services, il serait nécéssaire d'écrire 100 codes différents pour la communication entre applications et services. De plus, une application ne connait pas automatiquement un nouveau service. Il faudrait donc ajouter du code pour chaque nouveau service entrant dans le système.

HyperCat a été créé pour résoudre ces problèmes.

==HyperCat==
HyperCat est un consortium composé de 40 partenaires basées au Royaume-Uni comprenant des sociétés comme ARM ou BT ainsi que des universités locales. Il est financé par "Innovate UK" 6,4 millions de £.

Bien que HyperCat possède le soutien de grandes organisations, il a besoin de soutien de leaders tel que Google et Apple pour s'imposer comme le grand standart de l'Iot. Ce qui selon le Dr Ian Brown est loin d'être garanti : "If a company is leading in a market why on earth would they do anything that would make it easier for their competitors to enter?" "Sometimes there will be circumstances that will persuade them that if they open up in this way they can grow the overall market larger, " "But the hard economics is that they may be reluctant to do that.".

==Principe==

'''Formats :'''

* JSON.
* Flexible metadata model.
* URLs.
* HTTP/HTTPS.

'''Catalogue :'''

Les clients qui ont besoin de données vont les stocker dans un graphe de connaissance, auxquels ils pourront executer des requêtes pour récupérer les différentes ressources. Ce graphe est composé d'une accumulation d'un ou plusieurs catalogues de ressources.

Les catalogues sont fournis par des serveurs sous forme de tableaux d'URLs. Chaque ressource dans le catalogue est annotée avec des metadatas structurées en RDF(Resource Description Framework).

''Remarque : Utiliser les mêmes metadatas comme annotation dans différents catalogues crées des points d'interopérabilité.''

Un catalogue est un document JSON où chaque élément possède une URL, les metadatas obligatoires et est annoté avec un type MIME.

==Sources==
https://fr.scribd.com/doc/272460411/Untitled?secret_password=pxDWVPpxl3fElVIiZVv6#fullscreen

http://www.alphr.com/news/389503/hypercat-a-british-way-to-connect-the-internet-of-things

Hypercat

2016-04-01T13:55:43Z

CHARTIER.Aurelien: /* HyperCat */

HyperCat is a consortium and standard driving secure and interoperable Internet of Things (IoT) for Industry.

It is designed for exposing information about IoT assets over the web. Specifically, it provides as standard way for any client to discover resources that it understands on any server - without a human having to write code (which is otherwise the bottleneck to growing an ecosystem of IoT clients and services).

* [http://www.hypercat.io Website]
* [http://fr.slideshare.net/1248_io/hypercat-introduction-15-mins Hypercat explained in 16 mins]

==Problématique==
Les applications d'aujourd'hui ont besoin de plus en plus de données non centralisées et provenant de différents services ou fournisseurs de données. Ces données peuvent également être utilisées par plusieurs applications.

En supposant qu'ils possèdent les mêmes standarts (ex : protocole http, JSON, ...), chaque service a sa propre arborescence et est organisé différemment. Ainsi chacun d'eux nécessite de lire la documentation et d'écrire un code spécifique au service.

Cette nécessité est moins problématique dans un écosystème avec une "intégration verticale" où chaque application utilise un seul service. Mais dans le cadre d'un écosysteme à "intégration horizontale" toutes les applications fonctionnent avec tous les servives.

Dans un tel système, en prennant l'exemple de 10 applications fonctionnant avec une dizaine services, il serait nécéssaire d'écrire 100 codes différents pour la communication entre applications et services. De plus, une application ne connait pas automatiquement un nouveau service. Il faudrait donc ajouter du code pour chaque nouveau service entrant dans le système.

HyperCat a été créé pour résoudre ces problèmes.

==HyperCat==
HyperCat est un consortium composé de 40 partenaires basées au Royaume-Uni comprenant des sociétés comme ARM ou BT ainsi que des universités locales. Il est financé par "Innovate UK" 6,4 millions de £.

Bien que HyperCat possède le soutien de grandes organisations, il a besoin de soutien de leaders tel que Google et Apple pour s'imposer comme le grand standart de l'Iot. Ce qui selon le Dr Ian Brown est loin d'être garanti : "If a company is leading in a market why on earth would they do anything that would make it easier for their competitors to enter?" "Sometimes there will be circumstances that will persuade them that if they open up in this way they can grow the overall market larger, " "But the hard economics is that they may be reluctant to do that.".

==Principe==

'''Formats :'''

* JSON.
* Flexible metadata model.
* URLs.
* HTTP/HTTPS.

'''Catalogue :'''

Les clients qui ont besoins de données vont les stocker dans un graphe de connaissance, auquel il pourront executer des requêtes pour récupérer les différentes ressources. Ce graphe est composé d'une accumulation d'un ou plusieurs catalogues de ressources.

Les catalogues sont fournis par des serveurs sous forme de tableaux d'URLs. Chaque ressources dans le catalogue est annotée avec des metadatas structurés en RDF(Resource Description Framework).

''Remarque : Utiliser les mêmes metadatas comme annotation dans différents catalogue crée des points d'interopérabilité.''

Un catalogue est un document JSON où chaque elements possède une URL, les metadatas obligatoire et est annoté avec un type MIME.

==Sources==
https://fr.scribd.com/doc/272460411/Untitled?secret_password=pxDWVPpxl3fElVIiZVv6#fullscreen

http://www.alphr.com/news/389503/hypercat-a-british-way-to-connect-the-internet-of-things

Hypercat

2016-04-01T13:54:50Z

CHARTIER.Aurelien: /* Problématique */

HyperCat is a consortium and standard driving secure and interoperable Internet of Things (IoT) for Industry.

It is designed for exposing information about IoT assets over the web. Specifically, it provides as standard way for any client to discover resources that it understands on any server - without a human having to write code (which is otherwise the bottleneck to growing an ecosystem of IoT clients and services).

* [http://www.hypercat.io Website]
* [http://fr.slideshare.net/1248_io/hypercat-introduction-15-mins Hypercat explained in 16 mins]

==Problématique==
Les applications d'aujourd'hui ont besoin de plus en plus de données non centralisées et provenant de différents services ou fournisseurs de données. Ces données peuvent également être utilisées par plusieurs applications.

En supposant qu'ils possèdent les mêmes standarts (ex : protocole http, JSON, ...), chaque service a sa propre arborescence et est organisé différemment. Ainsi chacun d'eux nécessite de lire la documentation et d'écrire un code spécifique au service.

Cette nécessité est moins problématique dans un écosystème avec une "intégration verticale" où chaque application utilise un seul service. Mais dans le cadre d'un écosysteme à "intégration horizontale" toutes les applications fonctionnent avec tous les servives.

Dans un tel système, en prennant l'exemple de 10 applications fonctionnant avec une dizaine services, il serait nécéssaire d'écrire 100 codes différents pour la communication entre applications et services. De plus, une application ne connait pas automatiquement un nouveau service. Il faudrait donc ajouter du code pour chaque nouveau service entrant dans le système.

HyperCat a été créé pour résoudre ces problèmes.

==HyperCat==
HyperCat est un consortium composé de 40 partenaires basées au Royaume-Uni comprenant des sociétés comme ARM ou BT ainsi que des universités locales. Il est financé par "Innovate UK" 6,4 millions de £.

Bien que HyperCat possède le soutien de grandes organisations, il a besoin de soutien de leaders tel que Google et Apple pour s'imposer comme le grand standart de de l'Iot. Ce qui celon Dr Ian Brown est loin d'être garanti : "If a company is leading in a market why on earth would they do anything that would make it easier for their competitors to enter?" "Sometimes there will be circumstances that will persuade them that if they open up in this way they can grow the overall market larger, " "But the hard economics is that they may be reluctant to do that.".

==Principe==

'''Formats :'''

* JSON.
* Flexible metadata model.
* URLs.
* HTTP/HTTPS.

'''Catalogue :'''

Les clients qui ont besoins de données vont les stocker dans un graphe de connaissance, auquel il pourront executer des requêtes pour récupérer les différentes ressources. Ce graphe est composé d'une accumulation d'un ou plusieurs catalogues de ressources.

Les catalogues sont fournis par des serveurs sous forme de tableaux d'URLs. Chaque ressources dans le catalogue est annotée avec des metadatas structurés en RDF(Resource Description Framework).

''Remarque : Utiliser les mêmes metadatas comme annotation dans différents catalogue crée des points d'interopérabilité.''

Un catalogue est un document JSON où chaque elements possède une URL, les metadatas obligatoire et est annoté avec un type MIME.

==Sources==
https://fr.scribd.com/doc/272460411/Untitled?secret_password=pxDWVPpxl3fElVIiZVv6#fullscreen

http://www.alphr.com/news/389503/hypercat-a-british-way-to-connect-the-internet-of-things

Hypercat

2016-04-01T13:53:24Z

CHARTIER.Aurelien: /* HyperCat */

HyperCat is a consortium and standard driving secure and interoperable Internet of Things (IoT) for Industry.

It is designed for exposing information about IoT assets over the web. Specifically, it provides as standard way for any client to discover resources that it understands on any server - without a human having to write code (which is otherwise the bottleneck to growing an ecosystem of IoT clients and services).

* [http://www.hypercat.io Website]
* [http://fr.slideshare.net/1248_io/hypercat-introduction-15-mins Hypercat explained in 16 mins]

==Problématique==
Les applications d'aujourd'hui ont besoin de plus en plus de données non centralisées et provenant de différents services ou fournisseurs de données. Ces données peuvent également être utilisées par plusieurs applications.

En supposant qu'ils possèdent les mêmes standarts (ex : protocole http, JSON, ...), chaque service a sa propre arborescence et est organisé différemment. Ainsi chacun d'eux nécessite de lire la documentation et d'écrire un code spécifique au service.

Cette nécessité est moins problématique dans un écosystème avec une "intégration vertical" où chaque application utilise un seul service. Mais dans le cadre d'un écosysteme à "intégration horizontal" toutes les applications fonctionnent avec tous les servives.

Dans un tel système, en prennant l'exemple de 10 applications fonctionnant avec une dizaine services, il serait nécéssaire d'écrire 100 codes différents pour la communication entre applications et services. De plus, une application ne connait pas automatiquement un nouveau service. Il faudrait donc ajouter du code pour chaque nouveau service entrant dans le système.

HyperCat a été créé pour résoudre ces problèmes.

==HyperCat==
HyperCat est un consortium composé de 40 partenaires basées au Royaume-Uni comprenant des sociétés comme ARM ou BT ainsi que des universités locales. Il est financé par "Innovate UK" 6,4 millions de £.

Bien que HyperCat possède le soutien de grandes organisations, il a besoin de soutien de leaders tel que Google et Apple pour s'imposer comme le grand standart de de l'Iot. Ce qui celon Dr Ian Brown est loin d'être garanti : "If a company is leading in a market why on earth would they do anything that would make it easier for their competitors to enter?" "Sometimes there will be circumstances that will persuade them that if they open up in this way they can grow the overall market larger, " "But the hard economics is that they may be reluctant to do that.".

==Principe==

'''Formats :'''

* JSON.
* Flexible metadata model.
* URLs.
* HTTP/HTTPS.

'''Catalogue :'''

Les clients qui ont besoins de données vont les stocker dans un graphe de connaissance, auquel il pourront executer des requêtes pour récupérer les différentes ressources. Ce graphe est composé d'une accumulation d'un ou plusieurs catalogues de ressources.

Les catalogues sont fournis par des serveurs sous forme de tableaux d'URLs. Chaque ressources dans le catalogue est annotée avec des metadatas structurés en RDF(Resource Description Framework).

''Remarque : Utiliser les mêmes metadatas comme annotation dans différents catalogue crée des points d'interopérabilité.''

Un catalogue est un document JSON où chaque elements possède une URL, les metadatas obligatoire et est annoté avec un type MIME.

==Sources==
https://fr.scribd.com/doc/272460411/Untitled?secret_password=pxDWVPpxl3fElVIiZVv6#fullscreen

http://www.alphr.com/news/389503/hypercat-a-british-way-to-connect-the-internet-of-things

Hypercat

2016-04-01T13:52:10Z

CHARTIER.Aurelien: /* Problématique */

HyperCat is a consortium and standard driving secure and interoperable Internet of Things (IoT) for Industry.

It is designed for exposing information about IoT assets over the web. Specifically, it provides as standard way for any client to discover resources that it understands on any server - without a human having to write code (which is otherwise the bottleneck to growing an ecosystem of IoT clients and services).

* [http://www.hypercat.io Website]
* [http://fr.slideshare.net/1248_io/hypercat-introduction-15-mins Hypercat explained in 16 mins]

==Problématique==
Les applications d'aujourd'hui ont besoin de plus en plus de données non centralisées et provenant de différents services ou fournisseurs de données. Ces données peuvent également être utilisées par plusieurs applications.

En supposant qu'ils possèdent les mêmes standarts (ex : protocole http, JSON, ...), chaque service a sa propre arborescence et est organisé différemment. Ainsi chacun d'eux nécessite de lire la documentation et d'écrire un code spécifique au service.

Cette nécessité est moins problématique dans un écosystème avec une "intégration vertical" où chaque application utilise un seul service. Mais dans le cadre d'un écosysteme à "intégration horizontal" toutes les applications fonctionnent avec tous les servives.

Dans un tel système, en prennant l'exemple de 10 applications fonctionnant avec une dizaine services, il serait nécéssaire d'écrire 100 codes différents pour la communication entre applications et services. De plus, une application ne connait pas automatiquement un nouveau service. Il faudrait donc ajouter du code pour chaque nouveau service entrant dans le système.

HyperCat a été créé pour résoudre ces problèmes.

==HyperCat==
HyperCat est un consortium composé de 40 partenaires basées au Royaume-Uni comprenant des sociétés comme ARM ou BT ainsi que des universités locales. Il est financé par "Innovate UK" 6,4 millions de £.

Bien que HyperCat possède le soutien de grandes organisations, il a besoin de celui de leaders tel que Google et Apple pour s'imposer comme le grand standart de de l'Iot. Ce qui celon Dr Ian Brown est loin d'être garanti : "If a company is leading in a market why on earth would they do anything that would make it easier for their competitors to enter?" "Sometimes there will be circumstances that will persuade them that if they open up in this way they can grow the overall market larger, " "But the hard economics is that they may be reluctant to do that.".

==Principe==

'''Formats :'''

* JSON.
* Flexible metadata model.
* URLs.
* HTTP/HTTPS.

'''Catalogue :'''

Les clients qui ont besoins de données vont les stocker dans un graphe de connaissance, auquel il pourront executer des requêtes pour récupérer les différentes ressources. Ce graphe est composé d'une accumulation d'un ou plusieurs catalogues de ressources.

Les catalogues sont fournis par des serveurs sous forme de tableaux d'URLs. Chaque ressources dans le catalogue est annotée avec des metadatas structurés en RDF(Resource Description Framework).

''Remarque : Utiliser les mêmes metadatas comme annotation dans différents catalogue crée des points d'interopérabilité.''

Un catalogue est un document JSON où chaque elements possède une URL, les metadatas obligatoire et est annoté avec un type MIME.

==Sources==
https://fr.scribd.com/doc/272460411/Untitled?secret_password=pxDWVPpxl3fElVIiZVv6#fullscreen

http://www.alphr.com/news/389503/hypercat-a-british-way-to-connect-the-internet-of-things

Hypercat

2016-04-01T13:48:54Z

CHARTIER.Aurelien: /* HyperCat */

HyperCat is a consortium and standard driving secure and interoperable Internet of Things (IoT) for Industry.

It is designed for exposing information about IoT assets over the web. Specifically, it provides as standard way for any client to discover resources that it understands on any server - without a human having to write code (which is otherwise the bottleneck to growing an ecosystem of IoT clients and services).

* [http://www.hypercat.io Website]
* [http://fr.slideshare.net/1248_io/hypercat-introduction-15-mins Hypercat explained in 16 mins]

==Problématique==
Les applications d'aujourd'hui ont besoins de plus en plus de données non centralisées et provenant de différents services ou fournisseurs de données. Ces données pouvant également être utilisées par plusieurs applications.

En supposant qu'ils possèdent les mêmes standarts (ex : protocole http, JSON, ...), chaque service a sa propre arborescence et est organisé differement. Ainsi chaqu'un d'eux nécessite de lire la documentation et écrire un code spécifique au service.

Cette nécessité est moins problématique dans un écosystème avec une "intégration vertical" où chaque application utilise un seul service. Mais dans le cadre d'un écosysteme à "intégration horizontal" toutes les applications fonctionnent avec tous les servives.

Dans un tel système, en prennant l'exemple de 10 applications fonctionnant avec une dizaine services, il serait nécéssaire d'écrire 100 codes différents pour la communication entre applications et services. De plus, une application ne connait pas automatiquement un nouveau service. Il faudrait donc ajouter du code pour chaque nouveau service entrant dans le système.

HyperCat a été créé pour résoudre ces problèmes.

==HyperCat==
HyperCat est un consortium composé de 40 partenaires basées au Royaume-Uni comprenant des sociétés comme ARM ou BT ainsi que des universités locales. Il est financé par "Innovate UK" 6,4 millions de £.

Bien que HyperCat possède le soutien de grandes organisations, il a besoin de celui de leaders tel que Google et Apple pour s'imposer comme le grand standart de de l'Iot. Ce qui celon Dr Ian Brown est loin d'être garanti : "If a company is leading in a market why on earth would they do anything that would make it easier for their competitors to enter?" "Sometimes there will be circumstances that will persuade them that if they open up in this way they can grow the overall market larger, " "But the hard economics is that they may be reluctant to do that.".

==Principe==

'''Formats :'''

* JSON.
* Flexible metadata model.
* URLs.
* HTTP/HTTPS.

'''Catalogue :'''

Les clients qui ont besoins de données vont les stocker dans un graphe de connaissance, auquel il pourront executer des requêtes pour récupérer les différentes ressources. Ce graphe est composé d'une accumulation d'un ou plusieurs catalogues de ressources.

Les catalogues sont fournis par des serveurs sous forme de tableaux d'URLs. Chaque ressources dans le catalogue est annotée avec des metadatas structurés en RDF(Resource Description Framework).

''Remarque : Utiliser les mêmes metadatas comme annotation dans différents catalogue crée des points d'interopérabilité.''

Un catalogue est un document JSON où chaque elements possède une URL, les metadatas obligatoire et est annoté avec un type MIME.

==Sources==
https://fr.scribd.com/doc/272460411/Untitled?secret_password=pxDWVPpxl3fElVIiZVv6#fullscreen

http://www.alphr.com/news/389503/hypercat-a-british-way-to-connect-the-internet-of-things