bttn

Je vous avais présenté Smiirl, un compteur connecté dans un précédent article, voici Bt.tn un autre objet connecté très simple d'usage lui aussi.

Il suffit parfois d'exceller dans une idée simple pour faire du commerce, voici le bouton Bttn, un bouton connecté qui permet de déclencher des appels à un service sur Internet configurable à chaque fois qu'un appuie est réalisé sur le bouton.

Le concept est très simple et peut répondre à de nombreux cas d'usages :

  • Appel à un service de Taxi.
  • Livraison Deliveroo
  • Envoi d'un SMS
  • Appel d'urgence
  • Aide à domicile
  • ....

À vrai dire, tout ce qui est automatisable sur Internet peut être déclenché par un simple appui sur ce bouton.

Ce bouton connecté est disponible en plusieurs variantes :

  • Fabrication avec ou sans logo.
  • WiFi, GSM ou Sigfox pour les entreprises.
  • Taille normale ou mini
  • Couleur : Noir, bleu, rose, vert, jaune, rouge, blanc

Ce bouton coûte de 69€ jusqu'à 99€ pour le modèle imprimé avec le logo de votre choix. Il vous faudra ensuite payer un abonnement de 1.99 € par mois pour chaque bouton après 2 ans d'utilisation, autant dire qu'un usage personnel n'est pas envisageable à ce prix.

bttn price

La bonne nouvelle est que le Bttn possède de nombreux connecteurs lui permettant d’interagir rapidement avec différents systèmes tels que : IFTT, Twitter, Zapier, Facebook, RSS, email ... Pour vous permettre de configurer facilement votre Bttn, un portail en ligne est mis à disposition des utilisateurs du service : https://my.bt.tn

Voici une vidéo pour découvrir ce bouton connecté dans le détail :

En conclusion, la déclinaison GSM / Sigfox de ce bouton connecté est pratique pour des cas d'usage spécifiques où le WiFi n'est pas présent. Son prix reste abordable à l'achat (pour un objet connecté). Cependant, l'abonnement de 1,99€/mois, autant dire 2€/mois requis après deux années d"utilisation du bouton, va très vite rentre l'objet excessivement cher dans la durée, d'autant plus si vous utilisez la version Wifi qui ne nécessite pas de connectivité particulière pour fonctionner.

smiirl

Connaissez-vous les compteurs connectés Smiirl ? Ce sont des compteurs connectés avec un affichage à palette commercialisés par une startup française.

Deux modèles de compteur sont disponibles en standard, le premier permet de suivre le nombre de followers sur Instagram, le second permet de suivre le nombre de likes sur Facebook, vous avez aussi la possibilité d'utiliser un compteur Smiirl pour afficher vos propres données et de personnaliser le compteur avec votre logo lors de l'achat du produit en ligne. Il faudra pour cela exposer une API REST/JSON (exemple : http://api.smiirl.com/number).

Le prix du compteur varie de 299€ pour le compteur standard à 5 chiffres jusqu'à 349€ pour le compteur personnalisé, soit 50 euros de plus. Comptez un délai de livraison de 3 jours sur des compteurs standards et 15 jours sur les compteurs personnalisés. Si vous avez de gros nombres à afficher, un modèle de compteur à 7 chiffres est actuellement en précommande.

En terme d'installation, la procédure est assez simple, elle est décrite dans la vidéo ci-dessous. Pour la connectivité à Internet, Wifi ou câble Ethernet, c'est vous qui choisissez !

Le compteur réagit au quart de tour, enfin presque, il se met à jour tellement rapidement qu'un petit temps d'attente de 3 secondes a été mis en place par les concepteurs de l'objet pour permettre aux personnes qui ajoutent des likes de voir le compteur tourner.

Smiirl 990x607

Si vous souhaitez utiliser ce type de compteur pour un événement particulier, vous avez aussi la possibilité de louer le compteur auprès d'un distributeur.

En bref, ce compteur IoT est très esthétique, c'est un produit français, c'est un peu cher ... mais sympa ! Pour les bricoleurs, il ne manque plus qu'un connecteur Smiirl sur la plateforme IFTTT ;-)

MySQL

Vous rencontrez de temps à autre cette fameuse erreur fâcheuse "MySQL server has gone away" ? Voici quelques astuces pour résoudre cette erreur ...

Cette erreur a généralement lieu dès lors que vous avez ouvert une connexion MySQL et que la base n'y détecte aucune activité.

Soit votre traitement est trop long, dans ce cas pensez à maintenir des échanges avec la base de données régulièrement via des mysql_ping()

Sinon augmentez la valeur du "wait_timeout" (etc/mysql/my.cnf) de votre base de données à une durée suffisamment haute pour permettre d'éviter à votre base de donnée de fermer trop tôt ses connexions. Mais attention, le changement de ce paramètre peut avoir des conséquences très négatives sur le nombre de connexions ouvertes d'autant plus si celles-ci sont parfois mal fermées par votre applicatif.

# Au bout de 5 minutes d'inactivité la base fermera sa connexion automatiquement
wait_timeout=300

Si cette modification n'est toujours pas suffisante après un redémarrage de votre base données, pensez à augmenter la taille maximale des données pouvant être remontées par MySQL :

max_allowed_packet=64m

La connexion a été perdue probablement parce que la taille des données remontée est supérieure à la taille autorisée par défaut.

docker logo

Vous n'avez pas encore dompté les containers, vous ne savez pas par où commencer ?

Voici une vidéo très simple qui détaille le fonctionnement de Docker et qui explique comment créer son premier container en 12 minutes ...

Une très bonne introduction avant d'aller plus loin dans la construction de containers plus complexes et la découverte de Docker Compose et de Docker Swarm.

tensorflow

Tensorflow est un moteur d'intelligence artificielle Opensource développé par Google. Depuis le mois de février, Tensorflow a fait un grand pas en avant annonçant la première version complètement stable de son produit.

Tensorflow est aujourd'hui utilisé pour de nombreux cas d'usages: détection du cancer de la peau, prévention de la perte de vue chez les diabétiques ... Sur GitHub, vous trouverez pas moins de 8800 repository utilisant Tensorflow.

Tensorflow est développé en C++ et dispose d'une API Python. Des API Java et Go sont aussi à disposition en version expérimentale.

Si vous avez la chance d'avoir une carte graphique récente supportant CUDA 3.0 et supérieur, alors tournez-vous vers l'installation de Tensorflow en mode GPU, la compatibilité des cartes graphiques à Cuda peut être obtenue sur le site de NVidia. N'oubliez pas d'installer CUDA préalablement si votre carte est compatible.

$ pip install tensorflow-gpu  # Python 2.7;  GPU support
$ pip3 install tensorflow-gpu # Python 3.n; GPU support

Si vous n'avez pas de carte graphique compatible, tournez-vous vers une implémentation CPU de Tensorflow qui vous permettra de faire tourner les tutoriaux, mais celle-ci ne vous permettra pas de réaliser de l'apprentissage de manière efficace.

$ pip install tensorflow      # Python 2.7; CPU support (no GPU support)
$ pip3 install tensorflow     # Python 3.n; CPU support (no GPU support)

Une fois Tensorflow installé sur votre ordinateur, clonez le repository Git des models Tensorflow :

$ git clone https://github.com/tensorflow/models.git

Testez la reconnaissance d'image grâce à l'algorithme de classification des images :

$ cd models/tutorials/image/imagenet
$ python classify_image.py

La première analyse déclenche le téléchargement d'un référentiel de connaissance imagenet : L'image analysée est celle d'un panda :

giant panda, panda, panda bear, coon bear, Ailuropoda melanoleuca (score = 0.89632) indri, indris, Indri indri, Indri brevicaudatus (score = 0.00766) lesser panda, red panda, panda, bear cat, cat bear, Ailurus fulgens (score = 0.00266) custard apple (score = 0.00138) earthstar (score = 0.00104)

Vous pouvez maintenant essayer de catégoriser vos propres images, pour cela ajoutez la commande suivante au script de classification :

$ python classify_image.py --image_file monfichier.jpg

Le script vous retournera 5 propositions de classification avec des points de pondération allant de 0 à 1.

Enfin, si vous souhaitez garder précieusement la base de connaissance Imagenet dans un endroit particulier de votre système de fichier, l'argument "--model_dir" vous permet de préciser à l'emplacement des fichiers. Par défaut, la base de connaissance est téléchargée et installée dans le répertoire temporaire de votre ordinateur.

$ python classify_image.py --image_file monfichier.jpg --model_dir ./imagenet

Maintenant que vous arrivez à analyser des images grâce à inception, vous pouvez maintenant passer à l'étape suivante : l'apprentissage des images par Tensortflow. Rendez-vous dans un prochain article !

mugpointnet.jpeg

Vous habitez notre magnifique région nantaise et vous souhaitez découvrir le nouveau Visual Studio Microsoft et le C# 7 ?

Nicolas Mariot propose un Meetup ouvert à tous le 6 avril prochain à l'Epitech Nantes sur ces deux thématiques.

N'hésitez pas à vous inscrire à cet événement, 2 sessions d'une durée de 20 à 30 minutes chacune sont planifiées :

  • Une première assez généraliste présentant les nouveautés de Visual Studio 2017 et de C# 7.
  • Une seconde plus technique présentant les techniques avancées de débogage sous Visual Studio 2017.

Un apéro sera ensuite offert pour permettre de continuer la discussion entre passionnés.

opcache status

Le module PHP OPCache est aujourd'hui utilisé dans la majorité des déploiements de serveurs Web pour permettre d'optimiser l'exécution de scripts PHP. OPCache permet en effet de garder en mémoire le code compilé des scripts PHP évitant ainsi au serveur des compilations inutiles de code source inchangé.

Je vous l'avais détaillé dans un précédent article, OPCache permet de faire des miracles en terme d'optimisation d'IO sur un serveur Web, il permet notamment de cacher tous les fichiers PHP en mémoire et de ne plus demander aucun accès disque pour la vérification de la mise à jour du script PHP. Cette fonctionnalité est indispensable pour des sites de production à fort trafic.

Cependant, savez-vous correctement paramétrer la taille du cache OPCache ? Pas si simple ....

Au-delà de la commande suivante qui permet de configurer le paramètre "opcache.max_accelerated_files", il est compliqué de connaitre avec exactitude la consommation RAM du module.

$ find /path/to/root/of/project -name “*.php” -type f | wc -l

Pour remédier à cette problématique, il existe un script Opensource écrit en PHP qui vous permet de surveiller facilement la consommation mémoire de notre module, ce qui vous permet rapidement d'adapter vos paramètres du module en fonction de vos besoins.

Ce script Opensource s'appelle "opcache-status", il est disponible sur GitHub. Pour obtenir le code source de cette application, il vous suffit de réaliser un "git clone" du repository GIT du projet pour récupérer le code source :

$ git clone https://github.com/rlerdorf/opcache-status.git

Une fois les sources déposées dans votre serveur Web, il vous suffira d'ouvrir votre navigateur à l'URL sur laquelle vous avez déposé le code source de "opcache-status" pour permettre de connaitre l'état de fonctionnement de votre module OPCache et d'adapter ses paramètres en conséquence.

domogeeek

Vous avez toujours eu envie de vous lancer dans un projet de domotique Opensource, voici les 5 ingrédients utiles pour réussir votre projet domotique si vous avez un peu l'esprit bricoleur.

1. Le kit Raspberry Pi

kit raspberry pi

Ce kit centralisera les informations de votre maison, sa faible consommation d'énergie et son faible encombrement font de lui une solution parfaite. Comptez 71€ pour un kit complet incluant Raspberry Pi 3, boitier et carte SD..

NB: Vous pouvez aussi partir sur un Raspberry Pi moins puissant, comme le 2 ou le zéro en fonction de votre budget.

2. Le dongle ZWave USB

dongle zwave aeotec

Ce dongle USB z-stick GEN5 supporte les dernières normes ZWave plus, il vous permettra d'interconnecter vos objets ZWave à votre Raspberry Pi. Comptez 54€ pour le modèle ZWave Plus et 30€ pour l'ancien modèle.

3. Le dongle 3G et une carte SIM Free à 0€

dongle 3G usb

Ce dongle 3G USB vous permettra d'envoyer et recevoir des SMS gratuitement grâce à une SIM Free à 0€ si vous êtes client Free. Il vous permettra d'être alerté par SMS en cas de fuite d'eau à votre domicile. Comptez un prix de 31€ pour ce Dongle 3G.

4. Des objets connectés ZWave

aeon labs compteur de consommation electrique

En fonction de votre projet, le catalogue des objets ZWave vous offre une large gamme de produits allant de 10 à 60€ en fonction de l'objet. Les marques les plus connues sont Fibaro et Aeotec.

Les objets ZWave les plus rependus sont les suivants :

5. Une stack logicielle opensource : Node-Red / MQTT / ZWave2MQTT

node red screenshot

Enfin, le dernier ingrédient concerne la partie logicielle. Pour cela je vous conseille :

  • Node-Red pour la programmation de vos scénarios. Il s'agit d'un excellent logiciel Opensource réalisé en Node par IBM.
  • Un bus MQTT mosquitto pour la centralisation des événements sur un bus de données.
  • ZWave2MQTT, mon bridge permettant d'interconnecter un bus MQTT à un réseau ZWave.

Voici un assemblage disponible sur GitHub que je maintiens : https://github.com/ltoinel/domogeeek

En synthèse, le coût du projet est de 150€ pour la box domotique Opensource et de 10€ à 500€ en fonction de la quantité d'objets que vous souhaitez déployer. A vous de jouer !

MySQL

Je vous avais parlé du script MySQL Tuning Primer il y a déjà quelques années. Celui-ci n'est malheureusement plus mis à jour depuis quelque temps déjà ...

Voici désormais Mysqltuner.pl, un nouvel outil Opensource écrit en PERL qui vous permettra d'analyser des problèmes de performance sur une base MySQL / Mariadb.

Pour l'utiliser, il vous suffit de réaliser un WGET pour obtenir le script :

$ wget http://mysqltuner.pl/ -O mysqltuner.pl

Et de l'exécuter avec un interpréteur PERL :

$ perl mysqltuner.pl  --user admin_user --pass admin_password

L'outil analysera l'ensemble des paramètres de votre base de données et vous générera un rapport complet des possibilités d'optimisation trouvées :

mysqltuner

C'est simple comme ... bonjour !

Tous les paramètres recommandés par l'outil ne sont pas forcement à appliquer, comme notamment le "query_cache" qui peut avoir des impacts négatifs sur votre site. Mais cela offre une bonne base de travail pour identifier l'origine des contentions de votre base de données.

Des options plus avancées sont disponibles pour aller plus loin dans l'analyse de votre base, pour les consulter, rendez-vous directement sur la page GitHub du projet Mysqltuner.pl.

nginx

Vous développez une application PHP à fort trafic ? Vous ne souhaitez pas que vos workers PHP soient sollicités à chaque requête entrante pour permettre une sollicitation HTTP plus importante ? Il y a pour cela plusieurs solutions :

  • Soit vous prévoyez d'utiliser un CDN si vous prévoyez un trafic très important provenant de plusieurs pays dans le monde.
  • Soit vous prévoyez d'utiliser un frontal Varnish / Squid qui se chargera du cache ce qui rajoute une cache réseau supplémentaire dans la chaîne d'appel des pages hors cache. Il faudra cependant de prévoir lui aussi de le redonder ...
  • Soit vous utilisez le module Fascgi_cache de NGINX si vous utilisez NGINX comme serveur Web.

Dans cet article je vais vous montrer comment mettre en place le cache NGINX Fastcgi pour mettre en cache les ressources retournées par PHP FPM afin de limiter les sollicitations inutiles et consommatrices de CPU au pool PHP-FPM.

Dans un premier temps vous devez définir une zone de stockage de votre cache dans le fichier nginx.conf, celui-ci aura comme rôle de stocker l'ensemble des éléments mis en cache. La taille du cache est à adapter en fonction de la taille de votre site Web et de la quantité de pages à mettre en cache.

fastcgi_cache_path /var/nginx/cache/ levels=1:2 keys_zone=microcache:10m max_size=1024m inactive=1h;

Une fois cette étape réalisée, vous devrez préciser l'utilisation de cache à l'endroit où vous sollicitez PHP FPM dans votre vhost :

location ~ \.php$ {
fastcgi_cache  microcache;
fastcgi_cache_key $scheme$host$request_uri$request_method;
fastcgi_cache_valid 200 301 302 5m;
fastcgi_cache_use_stale updating error timeout invalid_header http_500;

fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;

add_header X-Cache $upstream_cache_status;

.... etc
}

Vous devez maintenant jouer avec la variable no_cache pour définir une priorité de cache à NGINX en fonction des contraintes de votre site Web :

#Cache everything by default
set $no_cache 0;

#Don't cache if the URL contains a query string
if ($query_string != ""){
    set $no_cache 1;
}

#Don't cache if there is a cookie called PHPSESSID
if ($http_cookie ~* "PHPSESSID"){
    set $no_cache 1;
}

Une fois ces modifications réalisées vous n'aurez plus qu'à redémarrer la configuration de NGINX et faire un test :

$ sudo /etc/init.d/nginx reload
$ curl -X GET -I http://localhost

Si le header HTTP "X-Cache: HIT" est retourné après plusieurs appels, c'est gagné ! La durée du cache peut être ensuite adaptée via le paramètre : fastcgi_cache_valid

Pour plus de performances et limiter les I/O sur votre disque, vous pouvez créer un disque en mémoire afin qu'aucune lecture / écriture au cache sur votre disque ne soit réalisée par NGINX .

Pour cela, arrêtez le processus Nginx :

$ sudo /etc/init.d/nginx stop

Montez le répertoire de cache sur une partition TMPFS en mémoire :

mount -t tmpfs -o size=1G tmpfs /var/nginx/cache/

Redémarrez le processus NGINX :

$ sudo /etc/init.d/nginx start

Pour permettre à ce montage d'être réalisé automatiquement à chaque démarrage de votre serveur, la modification de votre fichier fstab s'impose :

$ nano -w /etc/fstab
/

Ajoutez la ligne suivante à votre fichier en faisant attention à ce que la taille du disque corresponde à la taille du cache défini dans NGINX :

tmpfs /var/nginx/cache/ tmpfs defaults,size=1G 0 0

Vous voilà avec un serveur NGINX équipé d'un cache capable de restituer des pages HTML au lieu du pool PHP qui lui est très consommateur en CPU et en ressources.

Pour allez plus loin dans votre tuning, vous pouvez ajoutez les "proxy pass" en cache si votre serveur agit en reverse proxy :

proxy_cache            STATIC;
proxy_cache_valid      200  1d;
proxy_cache_use_stale  error timeout invalid_header updating
                                   http_500 http_502 http_503 http_504;

Mais aussi en ajoutant les fichiers statiques en cache :

open_file_cache          max=10000 inactive=5m;
open_file_cache_valid    2m;
open_file_cache_min_uses 1;
open_file_cache_errors   on;

Enfin, pour terminer et pour vous débarrasser des IO inutiles sur votre serveur qui sont souvent le goulot d'étranglement de votre système, vous pouvez faire en sorte qu'OPCache garde tous vos fichiers PHP en cache mémoire. Pour cela, assurez-vous que votre module OPCache est fonctionnel et positionnez les paramètres suivants dans le fichier .ini dédié au module OPCache. Après un redémarrage de PHP FPM, les fichiers PHP seront gardés en mémoire et plus aucune vérification de mise à jour de ces fichiers ne sera réalisée par PHP. Cela signifie que vous devrez redémarrer PHP-FPM à chaque modification de code PHP pour que celle-ci soit prise en compte.

opcache.memory_consumption=128 # MB, adjust to your needs
opcache.max_accelerated_files=10000 # Adjust to your needs
opcache.max_wasted_percentage=10 # Adjust to your needs
opcache.validate_timestamps=0

De plus en plus de projets utilisent la conteneurisation comme outil d’accélération du déploiement de systèmes informatiques. Malheureusement ces nouvelles technologies autour de la conteneurisationsont pas sans impacts sur l'architecture de la solution mise en place et quand aux choix à réaliser avant de démarrer un projet.

Voici un ensemble de questions que je juge pertinents de se poser avant de démarrer un projet avec des containers Docker. Les containers apportent de nouveaux paradigmes auxquels nous n'avons pas encore suffisamment de reculs pour adopter des réflexes naturels.

1. Qui va déployer les patchs de sécurité sur les containers livrés ?

Si l'équipe de développement a en charge la livraison des images, il est donc nécessaire donc mettre en place une gouvernance commune avec les OPS quant aux mises à jour des patchs de sécurité des containers. Cela peut signifier une charge plus importante pour l'équipe de développement lors de la phase de maintenance applicative.

2. Combien de ressources physiques mes images vont consommer en production ?

Créer des containers et les déployer de manière magique sur un cluster c'est super, faut-il encore se poser la bonne question : de combien de ressources physiques ont besoin mes containers pour fonctionner ? Il faut se poser cette question dès le démarrage du projet pour anticiper les coûts d'infrastructure et anticiper les besoins en CPU / IO / RAM de chacun des containers.

L'erreur est de surcharger des machines physiques avec trop de containers et voir les performances de son application s'écrouler à cause du nombre de threads sur chaque container et la consommation mémoire des processus démarrés. L'autre erreur commune est de surestimer les I/O d'un NAS, trop de containers sur un même NAS peut créer des performances désastreuses en écriture.

3. Quelle stratégie de sauvegarde dois-je envisager ?

Comment mes données sont sauvegardées / mutualisées entre les containers ? Quelle solution NAS de haute performance dois-je retenir pour permettre à tous mes containers de mutualiser des données ? Dois-je plutôt mettre en place du Rsync ? Dois-je sauvegarder l'état de mes containers régulièrement ? Ou alors créer des volumes persistants sur mon hôte Docker ?

4. Quelle stratégie de déploiement dois-je prévoir pour atteindre les engagements de SLA pris ?

Dois-je favoriser une stratégie de déploiement de type Blue/Green pour permettre de l'AB testing ? Ou alors, dois-je réaliser un déploiement en mode "big-bang" sur mon cluster ?

5. Est-ce que l'architecture réseau mise en oeuvre respecte les principes de sécurité ?

Est-ce que l'architecture réseau entre les containers est bien multicouche ? Est-ce que les ports ouverts entre les containers sont correctement maîtrisés pour assurer une sécurité suffisante ?

6. Comment vais-je livrer et versionner mes containers pour les OPS ?

Qui met en place un registry docker ? Est-ce une fourniture des OPS ou de l'équipe de DEV ? Quelle stratégie de versionning mettre en oeuvre sur mes containers ? Dois-je versionner mes images depuis mon intégration continue à chaque build ou depuis ma plateforme de recette dès lors que mon container a atteint un niveau de qualité correcte pour partir en préproduction ?

7. Comment seront supervisées les ressources consommées par chacun de mes containers ?

Quels outils doivent être déployés pour superviser chacun des containers et permettre d'identifier les containers plus consommateurs en ressources que d'autres ? Comment mettre en place une stratégie de supervision sur les ressources consommées par mes containers ?

8. Quelle stratégie ai-je prévue pour assurer une redondance applicative de mes composants ?

Comment est assurée la haute disponibilité des mes containers ? Quelle stratégie de réplication active/active ou redondance, ai-je mis en place pour assurer la haute disponibilité de l'ensemble de ma solution ?

9. Quelle solution d'Auto-scalling ai-je prévue pour permettre de bénéficier de l'élasticité du cluster hébergeant mes containers ?

Comment sera gérée les montées en charge et baisse de charge sur la solution ? Comment j'utilise au maximum les fonctions de containérisation pour réduire les coûts d'infrastructure de la solution ? Quelle solution d'orchestration de mes containers dois-je déployer en production ?

10. Quelle solution de distribution de charge dois-je mettre en place au-dessus de mon cluster ?

Comment distribuer la charge réseau sur l'ensemble de mon cluster de manière uniforme ? Comme s'assurer que la distribution du trafic réseau dépend du bon fonctionnement de l'application adressée ? En cas de "failover", est-ce que la session de l'utilisateur sera correctement accessible au travers de l'autre nœud qui reprendra la session de l'utilisateur ?


Bref, voici une liste de questions clefs, malheureusement les réponses à ces questions dépendront beaucoup du contexte de votre projet et des enjeux métiers. Les choix pris pour répondre à chacune de ces questions peuvent avoir des impacts financiers importants sur votre projet, il est important de se les poser dès le démarrage de votre projet pour éviter des dépassement non maîtrisés sur le budget de votre projet.

karotz back

Votre Karotz a perdu la parole depuis un mois suite à un blocage de l'utilisation des API d'Acapela ? Voici une solution alternative aux API de Google Translate pour redonner une belle voix féminine à votre Karotz.

La solution est d'utiliser les API Watson d'IBM qui fournissent une API de Text To Speech de bonne qualité. Malheureusement, cette API ne fournit pas de flux audio MP3, il est nécessaire de réaliser une petite conversion du fichier pour permettre au lapin de le lire grâce à son lecteur madplay.

Pour cela j'ai réalisé un petit bridge simple en PHP qui permet de rendre l'API d'IBM utilisable sur le lapin qui est malheureusement allergique à l'HTTPS ...

Voici le code source du bridge : https://github.com/ltoinel/openkarotz-tts-ibm-watson

Il vous suffit de le déployer sur un serveur Web PHP ayant accès au Web et d'adapter les fichiers tts et tts.inc présents dans les répertoires /www/cgi-bin du lapin. Pour cela, faites un telnet sur le port 23 de votre lapin, authentifiez-vous avec le login "karotz" et modifiez les fichiers grâce à la commande "vi" en suivant les instructions décrites sur le repository Github en n'oubliant pas de réaliser une sauvegarde préalable de ces fichiers.

openkarotz ibm watson

Une fois la modification effectuée, n'hésitez pas à réaliser une purge du cache TTS du lapin via l'interface Web de l'Openkarotz pour vous assurer d'utiliser la nouvelle voix d'IBM Watson et pas les fichiers en cache sur votre Karotz.

Votre lapin parlera désormais grâce à la voix de Renée de l'API TTS d'IBM Watson, il ne vous restera qu'à implémenter le Speech to text et à utiliser les API de conversation d'IBM Watson pour rendre votre lapin aussi intelligent que Jarvis de Mark Zukerberg.