WordPress database error: [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

WordPress database error: [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

WordPress database error: [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

Erreur de la base de données WordPress : [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

Erreur de la base de données WordPress : [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

Erreur de la base de données WordPress : [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

Erreur de la base de données WordPress : [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

Erreur de la base de données WordPress : [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

Erreur de la base de données WordPress : [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

Erreur de la base de données WordPress : [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

Erreur de la base de données WordPress : [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`

Smart Mirror – Partie II : Créer un module personnalisé – Genesis-blog

Genesis-blog

L'équipe mobile de Genesis et le miroir connecté

Smart Mirror – Partie II : Créer un module personnalisé

Après avoir configuré la plateforme MagicMirror à la fois sur nos machines virtuelles et sur notre Raspberry Pi, il est temps d’apprendre à développer de nouveaux modules complémentaires pour MagicMirror.

Les objectifs

L’idée du miroir connecté est née alors que nous devions trouver un sujet de recherche et développement pour un laboratoire dermatologique. Ce dernier cherchait un moyen d’inciter ses clients à réaliser des diagnostiques de peau pour ensuite pouvoir leur proposer des produits et des “rituels beauté” ciblés.

Qu’est-ce qu’un rituel beauté ? Globalement, c’est une succession de soins à exécuter chaque jour avec plusieurs produits en vue d’améliorer la qualité de la peau.

Par exemple : Se démaquiller avec un premier produit, puis gommer avec le produit 2 pour enfin hydrater avec le produit 3. Après avoir utilisé le dernier produit, le rituel beauté est terminé.

Nous avons donc choisi de développer des modules autour de ce « rituel beauté » en utilisant la reconnaissance faciale pour identifier l’utilisateur et la reconnaissance vocale pour piloter le miroir. Les instructions permettant guider l’utilisateur sont quant à elles énoncées grâce à un module de text to speech.

Coté matériel, nous avons connecté une caméra (la piCam) ainsi qu’un microphone à notre Raspberry.

Les fonctionnalités attendues

Voici la liste des fonctionnalités attendues à la fin des développements :

  • Identifier une personne : lui souhaiter la bienvenue sur le miroir et démarrer une session pour cet utilisateur. Chaque utilisateur est lié à un type de peau.
  • Démarrer son rituel beauté par la voix : Lorsqu’une session est active, l’utilisateur a accès à son rituel beauté : pour chaque action, une vidéo se lancera et décrira comment utiliser le produit. Lorsque l’utilisateur a fini d’utiliser le produit correctement, il peut le signaler au miroir en lui disant « passer à la suite». Le miroir notifiera l’utilisateur lorsque son rituel beauté sera terminé.
  • Observer l’évolution de sa peau : Chaque jour le miroir lui demandera de prendre une nouvelle photo de sa peau. Ainsi l’utilisateur aura la possibilité de faire défiler les photos prises depuis le premier jour pour voir l’évolution.

Les modules dans MagicMirror

Dans MagicMirror, chaque composant du miroir est représenté par un module : l’heure, la météo, les actualités, ou même quelque chose qui n’est pas forcément visible sur le miroir, tel que la reconnaissance faciale, ou la reconnaissance vocale en arrière plan.

A savoir : chaque module dispose d’une configuration globale dans le fichier de configuration de MagicMirror que nous avons évoqué dans la partie 1 de cette suite d’articles. Ce fichier permet de référencer les modules que l’on souhaite afficher sur notre miroir.

A travers ce fichier on peut configurer entre autre des paramètres généraux concernant le miroir, comme le langage, le format de l’heure, ou encore le niveau de zoom d’affichage des composant sur le miroir.

Mais nous pouvons également établir la configuration générale de chaque module avec différents paramètres : la position du module sur le miroir, le texte qui doit s’afficher au-dessus du module etc.

Plus d’informations sur les paramètres disponibles : https://github.com/MichMich/MagicMirror#configuration

Exemple d’un fichier de configuration simple qui affiche l’heure en haut à gauche du miroir :

var config = {
       port: 8080,
       ipWhitelist: ["127.0.0.1", "::ffff:127.0.0.1", "::1"],
       language: 'en',
       timeFormat: 24,
       units: 'metric',
       modules: [
              {
                     module: 'clock',
                     position: ‘top_left’
              },
       ]
};

Chaque module est défini par son nom à l’intérieur d’un tableau de modules dans le nœud « modules ». Chaque module est représenté par un dictionnaire clé-valeur qui permet d’affecter différents paramètres au module.

Créer son propre module

Emplacement du module

Un module doit être présent à la racine du dossier « /modules » de MagicMirror.

Un module peut être également placé dans un sous-dossier à la racine de « /modules ». Si tel est le cas, il faudra dans le fichier de configuration de MagicMirror « config.js »  indiquer ce sous-dossier devant le nom du module.

Exemple :  Reprenons l’exemple du fichier de configuration simple avec l’heure. Si notre module a pour nom « custom_clock », et qu’il est placé dans :

/modules/my_custom_modules/custom_clock

Alors le fichier de configuration devra ressembler à ceci :

//...
modules: [
       {
              module: 'my_custom_modules/custom_clock',
              position: ‘top_left’
       },
]
//...

Architecture d’un module

Module_name.js

Un module contient un fichier JavaScript principal qui représente le contenu principal du module : c’est le fichier qui permet d’initialiser le module, et qui va définir ce qu’il va se passer sur le miroir quand le module sera lancé.

Attention : Ce fichier doit avoir pour nom le nom du dossier dans lequel il se trouve (donc le nom du module).

Par exemple, dans notre exemple précédent, notre fichier JavaScript se nommerait « custom_clock.js ».

Voici une forme simple de ce fichier :

//custom_clock.js:

Module.register("custom_clock", {
       // Default module config.
       defaults: {
              //...
       },

       // Override dom generator.
       getDom: function() {
              // ...
       }
});

Le nœud defaults, permet de définir une configuration par défaut pour notre module : si par exemple l’utilisateur ne renseigne pas de nœud « config » dans le fichier config.js pour le module « custom_clock », alors ce sera la configuration par défaut qui sera chargée au chargement du module.

La fonction getDom est appelée au démarrage du module. C’est elle qui se charge d’afficher les éléments HTML du module sur le miroir. Cette méthode doit retourner un objet DOM, cet objet peut être créé avec les méthodes classiques de Node.JS.

Couplé avec la méthode suivante :

this.updateDom()

Nous pouvons rafraichir l’interface du miroir et ainsi mettre à jour les informations qu’affichent les modules.

Il existe des méthodes pouvant être surchargées après l’initialisation du module, la liste de ces méthodes ici : https://github.com/MichMich/MagicMirror/tree/master/modules#subclassable-module-methods

Après l’initialisation du module (Module.register), des propriétés sur le module sont disponibles tel que le nom du module, la configuration du module, etc.

La liste complète des propriétés :

https://github.com/MichMich/MagicMirror/tree/master/modules#available-module-instance-properties

Notifications entre les modules

Ce fichier permet également d’envoyer des notifications à d’autres modules, et également d’en recevoir.

Par exemple lorsqu’un événement X se produit dans notre module, nous aimerions peut-être qu’un autre module exécute une action en fonction de ce qu’il vient de se passer.

Un exemple :

Nous avons un module de reconnaissance vocale qui, lorsque nous émettons une instruction vocale, va exécuter une action, par exemple afficher une vidéo sur l’écran.

D’un autre côté nous avons un module « Text to Speech », qui lorsque nous lui passons une chaîne de caractère, va transformer cette chaîne de caractère en fichier audio, puis le lire.

Notre but :  lorsqu’une instruction est lancée, nous voulons effectivement lancer l’action qui correspond à cette instruction, mais aussi émettre un son à partir du miroir pour guider l’utilisateur :

Lancement d’une instruction : « Commencer le rituel »

Exécution de l’action correspondante à « Commencer le rituel » par le module 1 : Affichage de la vidéo pour le premier produit du rituel par exemple

Le module 1 envoie une notification au module 2 pour lui dire que le rituel a commencer

Le module 2 reçoit la notification et émet un son avec Text to Speech : « D’abord, utiliser le produit numéro 1 »

Exemple de code simple montrant la réception des notifications :

- notificationReceived: function(notification, payload, sender) {    
       if (sender) {        
              Log.log(this.name + " received a module notification: " + notification + " from sender: " + sender.name);    
       } 
       else {
              Log.log(this.name + " received a system notification: " + notification);    
       }
}

Le paramètre notification est un identifiant unique sur la notification qui est reçue. Grâce à cet identifiant nous pouvons voir si telle ou telle notification vient d’un module spécifique, et effectuer des traitements en fonction.

Le paramètre payload est un objet qui contient des données utiles, il est lié au module qui envoie la notification.

Le paramètre sender est le module émetteur de la notification. Si le paramètre n’est pas défini, cela signifie que la notification a été envoyée par le système et non par un module (un exemple de notification système est la notification qui indique que les modules ont tous bien démarrés : ALL_MODULES_STARTED).

Envoyer une notification depuis un module :

this.sendNotification(notification, payload)

Exemple :

this.sendNotification(‘NOTIFICATION_NAME’ , {objet1 : value, objet2 : value} )

Ici, nous envoyons une notification avec un identifiant unique et nous lui passons en paramètre deux objets.

Node_helper.js

C’est le fichier qui gère la partie logique « back-end » du module. Ce fichier peut communiquer avec le fichier principal du module via le système de socket.

Le dossier public

Toute ressource placée à l’intérieur de ce dossier sera accessible depuis :

/module_name/ressource_name

Informations pratiques

Ouvrir la console pour afficher les erreurs

Ctrl + MAJ + i

Les modules développés par la communauté externe à MagicMirror :

https://github.com/MichMich/MagicMirror/wiki/MagicMirror%C2%B2-Modules#3rd-party-modules

Installer un module développé par la communauté externe :

https://github.com/MichMich/MagicMirror/wiki/MagicMirror%C2%B2-Modules#installing

Sources

https://github.com/MichMich/MagicMirror

https://github.com/MichMich/MagicMirror/tree/master/modules

https://github.com/MichMich/MagicMirror/wiki/MagicMirror%C2%B2-Modules

4
4

 Developer : Swift and Objective-C

http://www.anthonyroani.com

Laissez un commentaire

Erreur de la base de données WordPress : [Got error 28 from storage engine]
SHOW FULL COLUMNS FROM `wp_options`