Archives mensuelles : septembre 2014

Présentation de « Mother »

Dans un précédent post je vous ai parlé de Rafi Haladjian, le Monsieur objets connectés français.

Je vous propose aujourd’hui une vidéo de 01net TV présentant « Mother », sa dernière création.

Vous allez voir qu’il y a pas mal de bonnes idées et que ce système est ouvert et permet à des sociétés tierces de développer des applications utilisant le système « Mother ».

 

Stéphane Sibué

Rafi Haladjian, un grand monsieur des objets connectés (et pas que)

Si le sujet des objets connectés vous intéresse, Rafi Haladjian est un personnage incontournable !

Il est le père du très célèbre lapin Nabaztag et présente en ce moment sa nouvelle création « Mother ».

Ce nouvel objet mi-culbuto, mi- poupée russe vous permet de mesurer intelligemment votre vie. Accompagnée de « cookies », ces petits capteurs que vous pouvez disposer partout, vous pourrez enfin «choisir le scénario de votre vie connectée« en mesurant la température, votre sommeil, surveillez votre prise de médicaments ou encore les présences chez vous.

Je vous laisse découvrir ce grand monsieur via un reportage vidéo proposé par FABERNOVEL :

Il y a d’ailleurs quelques temps (mars 2013), Rafi était l’invité de Jérôme Colombain et François Sorel dans leur émission « L’appart », dans laquelle il expliquait son parcours et sa vision :

Il a été aussi l’invité de Microsoft lors des TechDays 2014 (pendant lesquels j’ai animé une session sur les objets connectés justement) et s’est exprimé pendant la plénière du dernier jour qui avait pour titre « Objets connectés avez-vous une âme ? ». L’intervention de Rafi commence dans cette vidéo à 1h05 :

Stéphane Sibué

Apple Watch, la montre connectée d’Apple

Apple vient de nous présenter ses dernières nouveautés. iPhone 6, iOS 8 et surtout un nouveau produit, une montre connectée (connectée à votre iPhone obligatoirement bien sûr), l’Apple Watch (et non la iWatch, comme si Apple voulait qu’on oublie le grand Steve en arrêtant d’appeler les produits comme lui, étrange).

Je vous laisse découvrir ce bel appareil, qui, il faut bien l’avouer semble très sérieux (comme son prix d’ailleurs).

 Stéphane Sibué

Un thermostat connecté, bonne idée !

En direct de l’IFA 2014, un thermostat connecté proposé par NEST, une société rachetée par Google récemment.

Ce thermostat se veut particulièrement intelligent car il apprend les préférences de ses utilisateurs, sait gérer au mieux la température de votre foyer quand vous êtes présents et absents, et permet au final de faire des économies d’énergie.

Il est aussi pilotable à distance, depuis les smartphones et les tablettes, et permet de connaître la quantité d’énergie consommée, quand et pourquoi.

Un must dans son genre, et en plus il est magnifique.

Stéphane Sibué

Nouvelles montres connectées de Motorola et LG, magnifiques !!!

Nos amis Jérôme Colombain et François Sorel de 01netTV nous présentent depuis l’IFA 2014 deux nouvelles montres connectées qui pour une fois ressemblent à de vraies montres.

Ces montres sont la Motorola Moto 360 et la LG G Watch R.

Ecran rond, grande fluidité, bracelet amovible à choisir parmi plusieurs modèles, ces montres sont donc belles, puissantes et pratiques.

Je vous laisse découvrir ces petites merveilles au travers de 2 vidéos de présentation :

Stéphane Sibué

Pourquoi apprendre la programmation aux enfants ?

Cet article a été publié dans le magazine Programmez! n°177  de septembre 2014

Je suis développeur de métier depuis plus de 20 ans et cela fait plus de 30 ans que je programme. J’ai commencé à 12 ans, en 1980. A cette époque les choses n’ont pas été simples.

Tout a commencé quand mon père m’offrit pour Noël une console de jeux Philips Videopac. Au contact de cette machine très limitée je me suis mis à rêver de pouvoir programmer des jeux. Quelques mois plus tard, Philips mis en vente une cartouche qui permettait de réaliser des programmes en assembleur. Pas super simple d’accès pour un débutant, d’ailleurs le manuel expliquant comment faire était en anglais ! Ce ne fut pas simple de comprendre ce qu’était un accumulateur, un registre, un flag, et tous ces termes propres au développement en langage machine. J’ai fait preuve à l’époque d’une sacré dose de persévérance pour arriver à sortir quelque chose des tripes de ma console.

              Videopac_9

Cartouche programmation Vidéopac

J’ai voulu aller plus loin. Au CDI de mon collège j’ai trouvé quelques livres qui parlaient du Basic, et du monde des ordinateurs. Apprendre le Basic dans des livres c’est bien, mais très vite le manque de matériel permettant de mettre en pratique s’est fait sentir. Mon père voyant que cette nouvelle lubie de programmer était sérieuse m’a alors acheté un Casio PB 100 programmable en Basic et là j’ai pu avancer. Je crois d’ailleurs que ma passion pour la mobilité est née de la programmation de ces petites machines qui tenaient dans la poche et qui permettaient, pour l’époque, de faire beaucoup de choses. Les choses se sont ensuite emballées avec l’arrivée de l’Amstrad CPC 464, puis un PC, ce qui m’a permis de découvrir d’autres langages tels que le Pascal, le C, le Logo. J’ai fait de ma passion mon métier et c’est toujours avec autant de joie que je code. J’ai une grande préférence pour le développement mobile et je dois bien avouer que je me régale à coder des applications pour iOS, Android ou Windows Phone.

 casio_pb-200

Casio PB-100 et son livre sur le Basic

J’ai fait tout ce chemin seul, personne dans mon entourage était capable de m’aider. J’étais une sorte d’extraterrestre aux yeux de mes copains qui ne comprenaient pas comment je pouvais préférer rester tout l’après-midi à coder plutôt que d’aller avec eux à la piscine courir après les filles !

Je regrette que la programmation ne soit pas étudiée à l’école, et ce dès le plus jeune âge car elle m’a permis d’avoir un bon esprit d’analyse et une logique dans la résolution de problèmes. J’ai toujours été nul en maths et pourtant je suis un bon développeur (du moins c’est ce qu’en disent tous mes clients). A l’école on apprend la logique par les maths, alors que ce n’est pas forcément la meilleure manière de faire, la programmation étant une très bonne alternative.

Je vois beaucoup de personnes qui sont esclaves de leur ordinateur. Elles ne savent pas comment il fonctionne, alors elles utilisent les quelques petites choses qu’elles ont apprises çà et là sans jamais comprendre comment éviter certains problèmes. Si on apprenait aux enfants comment fonctionne un ordinateur, on créerait une génération maitresse et non esclave de ces machines, et pas mal de vocations naîtraient plus tôt pour l’informatique et la programmation.

Mon fils a suivi le même parcours que moi et programme depuis ses 12 ans. La différence c’est que j’étais là. Il a toujours voulu se débrouiller tout seul le plus possible, mais quand il était vraiment coincé j’étais là pour l’aider, le guider, et lui éviter de s’épuiser à  trouver des réponses à des problèmes trop ardus.

Actuellement il prépare un BTS SIO (programmation), et comme à mon époque (même BTS passé en 1988) il s’est retrouvé avec une majorité d’élèves qui n’avait jamais vu une ligne de code et ne savait pas comment fonctionne un ordinateur. Ils se sont lancés dans une carrière de développeur sans aucune notion scolaire. Je peux vous dire que mon fils n’a pas trouvé cette 1ère année super intéressante, il a passé son temps à revoir ce qu’il sait déjà depuis bien longtemps.

A bien y réfléchir, l’enseignement de la programmation dès l’école primaire pourrait être d’une très grande utilité et permettre aux enfants d’éveiller leur esprit très tôt et faire naître de belles vocations, et à notre pays d’être finalement plus fort face aux enjeux qui se dessinent pour les 30 prochaines années et qui sont indéniablement liés à l’informatique sous toutes ses formes.

Stéphane Sibué

 

Communiquer avec un GPS Bluetooth, quelques améliorations

Dans un précédent article j’ai abordé la communication avec un périphérique Bluetooth en utilisant comme exemple la communication avec un GPS.

Comme j’étais en train de découvrir la nouvelle manière de lire des données en provenance d’un socket (StreamSocket) je n’avais pas utilisé la manière la plus simple ni la plus efficace.

Dans ce nouvel article, je vais apporter quelques améliorations à la méthode utilisée.

En creusant encore un peu le sujet, je me suis rendu compte que ma méthode était loin d’être la meilleure. Et tant mieux car perso je n’en étais pas super satisfait.

En 1er lieu, il faut passer par un DataReader pour lire les données en provenance du StreamSocket. On donne au DataReader l’InputStream utilisé par le StreamSocket pour collecter les données entrantes et on paramètre de DataReader pour qu’il effectue une lecture partielle des données.

DataReader wReader = new DataReader(_StreamSocket.InputStream);
wReader.InputStreamOptions = InputStreamOptions.Partial;

En d’autres termes, si on demande de lire 100 octets et qu’il n’y en a que 50 dans le buffer d’entrée, le DataReader va lire les 50 octets et rendre la main au lieu d’attendre la vie des rats que les 100 octets soient effectivement disponibles. Ca arrange bien nos affaires cette histoire.

La lecture en elle-même est très simplifiée. Il suffit de dire combien on veut lire d’octets maximum et on reprend la main quand on a lu au maximum ce nombre d’octets. Simple et rapide.

La fonction de lecture est asynchrone, donc pour l’attendre on n’oublie pas de placer le petit await qui va bien devant. La fonction retourne le nombre d’octets effectivement lus.

Si elle retourne zéro c’est que rien n’était disponible dans le buffer d’entrée. Suivant les matériels connectés ça peut vouloir dire qu’il ne cause plus pour le moment (il boude par exemple) ou alors qu’il n’est plus connecté. Dans le cas d’un GPS, qui est je vous le rappelle un appareil très bavard, le fait de ne plus recevoir de données signifie souvent qu’il n’est plus là pour le faire.

// Lecture de 300 octets
uint r = await wReader.LoadAsync(300);

Une fois qu’on a des données disponibles dans le buffer d’entrée, il suffit d’aller les récupérer de la manière qui convient le mieux en utilisant le DataReader et ses fonctions de récupération (ReadByte, ReadBytes, ReadDouble, etc…). C’est lui qui s’occupe d’aller puiser le bon nombre d’octets dans le buffer d’entrée pour récupérer les informations dans le format que vous souhaitez (sympa le mec).

Dans le cas du GPS nous devons récupérer les données sous la format de caractères ASCII. Malheureusement la méthode ReadString ne convient pas car elle lit la chaîne en UTF8 ou en Unicode, mais ne sais pas le faire en ASCII. En fait le format ASCII a été retiré des formats proposés dans System.Text.Encoding. Quelle idée ???

Donc nous allons récupérer les octets comme si c’était de simples caractères ASCII et construire une chaîne ASCII, à la mano, comme le faisait mon grand père.

// On prépare le buffer de réception
// La variable r contient le nombre d'octets lus du StreamSocket

byte[] wBuffer = new byte[r];

// On récupère les données 

wReader.ReadBytes(wBuffer);

// On transforme ces données en string ASCII

string wString = "";

for (int i = 0; i < r; i++)
{ 
    wString += (char)wBuffer[i];
}

// Dans wString on a maintenant les données lues sous forme d'une chaîne de caractères

Ensuite il suffit de traiter ces informations comme dans l’article précédent pour afficher les trames NMEA envoyées par le GPS.

Il suffit alors de reboucler pour lire le flot suivant de caractères et le tour est joué. Plus besoin de timer pour effectuer la lecture à intervalles réguliers. On est toujours en mode pooling car nous ne sommes pas notifié de la disponibilité de nouveaux octets dans le buffer d’entrée, mais ce pooling-ci est plus « souple » que celui que je vous avais précédemment proposé.

Idéalement, il faudrait gérer un timeout. En effet, comme expliqué un peu plus haut, quand le périphérique est déconnecté, il cesse d’envoyer des données, mais aucune erreur n’est levée au moment où l’on essaye de notre coté de lire de nouvelles données, on n’a seulement comme indice le fait que la fonction de lecture du DataReader retourne zéro.

Au bout d’un certain temps, il sera donc nécessaire d’en conclure que la liaison est rompue. La durée de ce timeout dépendra du comportement « normal » du périphérique auquel vous êtes connectés. Par exemple, pour le GPS Hollux que j’ai utilisé, une absence de données pendant plus d’une seconde n’est pas normale, le timeout sera donc compris en 1000 et 1500 millisecondes.

Si j’en ai le courage, j’ajouterai ce timeout dans un prochain article. En tous cas, si cela vous intéresse, n’hésitez pas à me le demander, ce sera pour moi la meilleure des motivations.

Stéphane Sibué

Communiquer avec un GPS Bluetooth sous Windows Phone

A l’époque de Windows Mobile, communiquer avec un périphérique en utilisant une liaison série était quelques chose de très simple à mettre en œuvre. Le système d’exploitation intégrait tout ce qu’il fallait pour ouvrir un port série et permettre l’envoi et la réception de données par ce canal. Simple, ouvert, pratique.

Dans les 1ères versions de l’OS mobile de Microsoft, du temps de Pocket PC 2000 sous Windows CE 3 par exemple, la liaison série était physiquement réelle. On branchait un câble qui reliait le PDA avec le périphérique, comme on peut le voir dans cet exemple de borne interactive animée par un Pocket PC que j’ai mis en ligne en 2001. Le programme était réalisé en eVB (ça ne me rajeunit pas cette histoire).

Ensuite, avec la démocratisation du Bluetooth, les machines ont été en mesure de créer des liaisons séries virtuelles, le câble ayant été remplacé par les ondes radio. Classiquement, à cette époque, on se connectait avec des GPS Bluetooth car les machines sous Windows Mobile n’intégraient pas encore de puce GPS, il fallait donc passer par des appareils externes pour être en mesure de proposer une géolocalisation et de la carto.

A l’époque j’avais d’ailleurs écrit un article sur la manière de se connecter à un GPS et être en mesure de décoder les trames NMEA qu’il crachait périodiquement et pour le TechDays 2008 j’avais présenté une application permettant de prendre des photos géolocalisées avec la possibilité de les afficher sur une carte. Et oui à l’époque ça en a impressionné plus d’un, maintenant c’est d’une grande banalité je vous l’accorde.

Pour moi la sortie de Windows Phone fût un grand choc. Belle plateforme, belles et puissantes machines, fluidité, design moderne, en gros que du bonheur par rapport à la plateforme Windows Mobile. Mais en creusant un peu, quel retour en arrière sur certains points ! Certes les machines intégraient nativement une puce GPS et le SDK permettait d’en tirer partie, mais impossible par exemple d’ouvrir une liaison série (réelle ou virtuelle), impossible de créer un socket serveur, impossible de faire plein de choses qui étaient devenues si naturelles avec l’ancienne plateforme… Allez expliquer ça à vos clients qui vous demandent de porter leurs anciennes applications Windows Mobile vers Windows Phone. Dans certains cas impossible de le faire, et on passe donc à Android où là il n’y a rien qui s’y oppose.

Avec le recul je comprends très bien pourquoi les choses ont été faites comme ça, mais je dois bien avouer qu’à l’époque MS a pourri une partie de mon business avec ces choix !

Dans certains cas il est indispensable d’avoir plusieurs GPS en même temps. Par exemple, si vous faites du GPS différentiel, vous ne pouvez vous contenter d’utiliser celui inclus dans le device, vous devez collecter les données de plusieurs GPS et effectuer des traitements en temps réel pour arriver à une précision de positionnement de l’ordre du cm par exemple. De plus vous ne pouvez vous contenter de récupérer simplement la position (latitude, longitude), vous devez aussi récupérer des données très importantes sur le niveau de précision, le nombre de satellites en vue et j’en passe. Je ne vais pas entrer dans le détail du GPS différentiel ce n’est pas le but de cet article.

Donc avec Windows Phone, si vous voulez faire du GPS différentiel vous êtes cuit. Sauf depuis la sortie de Windows Phone 8 qui a ouvert encore un peu plus le périmètre des libertés anciennes (Windows Mobile) retrouvées.

Avec Windows Phone 8 vous avez la possibilité de créer un socket entre votre application et un périphérique Bluetooth. Donc pour faire simple, on peut communiquer très facilement en Bluetooth avec par exemple… un GPS, et même plusieurs GPS en même temps ! Ca y est, 3 ans après la sortie de la plateforme Windows Phone, je peux dire à mes clients qu’il peuvent abandonner Android et revenir dans le droit chemin sous Windows Phone ! Sauf que pour eux maintenant c’est trop tard, ils sont passés à Android et ne reviendront pas en arrière. En effet il n’ont pas la capacité financière de faire redévelopper toutes les 5 minutes leurs applications mobiles.

Je vais donc dans cet article vous montrer comment dialoguer avec un GPS en Bluetooth et vous allez voir que c’est assez simple à faire.

Le petit programme GpsBT que j’ai réalisé pour l’occasion permet de faire 3 choses :

  1. Lister les appareils liés en Bluetooth
  2. Sélectionner un appareil et s’y connecter
  3. Afficher les trames NMEA envoyées par le GPS

Les sources de GpsBT sont disponibles ici.

1/ Les droits

La 1ère chose à faire, c’est de donner à votre application les droits pour utiliser les fonctions Bluetooth :

ID_CAP_PROXIMITY

ID_CAP_NETWORKING

2/ Lister les appareils liés

Il faut partir à la découverte des appareils liées. Ces appareils sont ceux qui sont listés dans l’écran des settings du Bluetooth et qui ont été liés à votre téléphone par une opération d’appairage. On ne peut se connecter qu’avec un appareil qui a été au préalable lié et impossible dans l’état actuel du SDK de provoquer par programme ce lien.

        private async void BouPeerDiscovery_Click(object sender, RoutedEventArgs e)
        {
            BouPeerDiscovery.IsEnabled = false;

            PeerFinder.AlternateIdentities["Bluetooth:Paired"] = "";

            try
            {
                var wPairedDevices = await PeerFinder.FindAllPeersAsync();
                this.ViewModel = new MainPageViewModel(wPairedDevices.ToList());
                BouPeerDiscovery.Visibility = System.Windows.Visibility.Collapsed;
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message, "Peer Discovery", MessageBoxButton.OK);
                BouPeerDiscovery.IsEnabled = true;
            }
        }

La liste des appareils liés est retournée par la fonction PeerFinder.FindAllPeerAsync. Dans mon exemple, la liste est fournie au ViewModel de la page pour un affichage dans une liste comme dans l’écran suivant :

Le GPS que j’utilise est le Holux GR-230, c’est donc à lui que je vais essayer de me connecter. Il ne faut pas oublier au préalable de le mettre en route, bien sûr.

3/ Connexion à un appareil

La fonction permettant de lister les appareils disponibles retourne pour chacun d’entre eux un objet de type PeerInformation. Parmi les informations disponibles, on a le DisplayName qui est le nom en clair (celui que j’utilise dans la liste), et le HostName qui sera utilisé pour effectuer la connexion.

La connexion est réalisée via un objet de type « StreamSocket » en utilisant sa méthode asynchrone « ConnectAsync » avec en premier paramètres le HostName provenant du PeerInformation de l’appareil auquel on veut se connecter et la chaîne 1 en second paramètre (je ne sais pas vraiment à quoi correspond ce second paramètre, dans tous les exemples de la documentation la valeur utilisée est la chaine 1 alors va pour ça).

        public async Task ConnectAsync(PeerInformation wPeer)
        {
            // Si un précédent device était déjà connecté, on débranche

            if (_StreamSocket != null)
            {
                _ScanGpsTimer.Stop();

                _StreamSocket.Dispose();
                _StreamSocket = null;
            }

            // On essaye de se connecter au device

            _StreamSocket = new StreamSocket();

            try
            {
                await _StreamSocket.ConnectAsync(wPeer.HostName, "1");

                // Pas d'erreur ?
                // Alors c'est qu'on est connecté
                // On peut mettre en place le scan des données qui arrivent du device

                _CurrentGpsInput = "";
                this.DeviceName = wPeer.DisplayName;
                _ScanGpsTimer.Start();
            }
            catch (Exception ex)
            {
                // Erreur pendant la connexion

                _StreamSocket = null;
                return ex;
            }

            return null;
        }

Ma petite fonction de connexion, placée dans le ViewModel de la page, retourne l’erreur rencontrée en cas de problème ou null si tout c’est bien passé.
Si la connexion se passe bien, on passe en mode pooling dans lequel on va lire à intervalle régulier le contenu du buffer d’entrée du StreamSocket. Si des données sont disponibles, elles sont lues et partant du principe que ce sont des trames NMEA, elles sont « découpées » pour être affichées dans une liste.

C’est un DispatcherTimer qui s’occupe d’effectuer les lectures à intervalles régulier :

        private async void OnScanGpsTimerTick(object sender, EventArgs e)
        {
            if (_StreamSocket != null)
            {
                _ScanGpsTimer.Stop();

                // Lecture des données

                var wBuffer = new Windows.Storage.Streams.Buffer(100);
                await _StreamSocket.InputStream.ReadAsync(wBuffer, 100, Windows.Storage.Streams.InputStreamOptions.None);

                if (wBuffer.Length > 0)
                {
                    // On a bien des données

                    using (var wReader = DataReader.FromBuffer(wBuffer))
                    {
                        // On prépare le buffer de réception 

                        byte[] wBuffer2 = new byte[wBuffer.Length];

                        // On récupère les données 
                        wReader.ReadBytes(wBuffer2);

                        // On transforme ces données en string

                        string wString = System.Text.Encoding.UTF8.GetString(wBuffer2, 0, wBuffer2.Length);

                        // On ajoute ces données aux trames générales reçues du GPS

                        _CurrentGpsInput += wString;

                        // On essaye de découper la trame générale en lignes NMEA

                        int p;

                        do
                        {
                            // On recherche les caractères CRLF

                            p = _CurrentGpsInput.IndexOf("\r\n");

                            if (p > -1)
                            {
                                // On récupère le début (avant les caratères CRLF)

                                string wDebut = _CurrentGpsInput.Substring(0, p);

                                // On enlève cette partie de la trame générale

                                _CurrentGpsInput = _CurrentGpsInput.Substring(p + 2);

                                // Généralement une trame NMEA valide commence par $GP

                                if (wDebut.StartsWith("$GP"))
                                {
                                    // On ajoute la partie à la liste des trames NMEA

                                    this.GpsNmea.Add(wDebut);

                                    // On ne garde que les 25 dernières trames NMEA dans la liste

                                    while (GpsNmea.Count > 25) { GpsNmea.RemoveAt(0); }
                                }
                            }

                        } while (p > -1);
                    }
                }
                else
                {
                    // Aucune donnée n'a été lue, si ça dure trop longtemps cela voudra dire
                    // Que le device ne communique plus ou qu'il n'est plus connecté
                    // Dans la vraie vie, c'est un cas qu'il faut traiter
                }

                _ScanGpsTimer.Start();
            }
        }

Voilà, la boucle est bouclée, nous avons réalisé toutes les opérations pour se connecter à un GPS Bluetooth depuis un device Windows Phone 8.

Comme vous pouvez le constater, c’est très simple à mettre en œuvre. Mon seul regret étant de devoir effectuer du pooling pour récupérer les données.

Il y a peut-être le moyen de se « brancher » sur un événement du StreamSocket ou du InputStream sous-jacent, mais je dois vous avouer que je n’ai pas encore pris le temps de creuser cette piste pour le moment.

Stéphane Sibué

Ouverture du blog Guyzmo

Bonjour à tous,

Le bog de Guyzmo est maintenant ouvert.

Nous y parlerons de ce qui fait notre quotidien, c’est à dire, de développement sur les plateformes mobiles Android, iOS et Windows Phone, mais pas que…

ordinateurNous parlerons aussi d’objets connectés, de Cloud, et de tout les ingrédients dont il faut « saupoudrer »  nos applications pour qu’elles soient au final fluides, attrayantes, rapides, puissantes, innovantes et optimisés.

N’hésitez pas à nous suivre, nous essayerons de publier des articles le plus souvent possible.

Empreinte Guyzmo 360