MaxSmart – Prise multiple automatisable et RestAPI

J’ai récemment acheté plusieurs prises multiples MaxSmart de Max Hauri. Digitec a fait une offre exceptionnelle à CHF 75.00 pour la Power Station (multiprise six sockets).

C’est un produit intéressant à plus d’un titre. La multiprise elle-même comporte un port RJ45. Une fois branchée sur le routeur réseau, elle crée un réseau PowerLAN 500Mb/s. Il est dès lors possible de contrôler jusqu’à 15 périphériques MaxSmart dans la maison, à condition que l’on soit, bien entendu, derrière le même compteur électrique. Il s’agit ici d’une limitation PowerLAN, et non MaxSmart. Il est ensuite possible de contrôler et d’automatiser chaque prise depuis son téléphone mobile ou depuis internet.

MaxSmart, c’est quoi ?

La gamme MaxSmart offre plusieurs produits:

  • Power Station: La prise multiple
  • Power Plug: La prise unique
  • PowerLAN station: Un « modem » PowerLAN
  • AirSense: Un détecteur de température et d’humidité
  • Motion Sense: Un détecteur de mouvements
  • HD IP Camera: Une caméra IP

Je ne m’attarderai pas sur les derniers produits, et ne parlerai dans cet article que des deux premiers, à savoir la Power Station et la Power Plug.

Ce produits proposent les fonctionnalités suivantes:

  • Suivi de la consommation pour chaque prise, et pour l’ensemble de la prise (y.c. multiple)
  • Contrôle d’alimentation prise par prise, ou pour la multiprise complète
  • Programmation d’allumage et d’extinction des prises
    • Un générateur de programme aléatoire est disponible, afin de simuler la présence en cas d’absence
  • Extinction différée de la prise

Le contrôle est possible de deux façons:

  • Depuis une application Android ou iOS
  • Depuis le site de maxsmart.ch

Je relèverai, et c’est une excellente chose, que la connexion au cloud maxsmart n’est pas obligatoire. Le système peut fonctionner sans connexion internet, et sans connexion au Cloud. C’est un très très gros plus par rapport à des solutions comme NetAtmo qui ne fonctionnent pas sans accès internet. Il est possible de nommer chaque prise multiple, et chaque prise indépendante. Ainsi, on pourra très facilement noter quel appareil est sur quelle prise. C’est un excellent point pur l’organisation.

Pour les points positifs de la Power Station (multiprise), je retiens:

  • La qualité de fabrication: C’est très solide et très bien fini. Ca donne un sentiment de sécurité et de durabilité
  • Le codage des prises par couleur, la numérotation apparente, facilitent la mise en oeuvre et l’inventaire
  • L’application et le cloud sont relativement bien fait et très réactifs, malgré les points négatifs que je soulèverai plus bas
  • Le prix: Même hors offre spéciale, à CHF 125.00 pour la prise multiple 6 sockets, en T13 (prises suisse), je n’ai rien trouvé d’équivalent. C’est exceptionnel. A 125CHF, c’est moins cher que deux prises simples de la même gamme. Je suis franchement épaté.
  • La possibilité de créer un réseau PowerLAN sans appareil supplimentaire

Il est d’ailleurs à noter, concernant ce dernier point, que le réseau PowerLAN créé par la prise est standard. Il fonctionnera avec tous les appareils standards du marché exploitant le protocole PowerLAN. A ce sujet, malgré ce que le mode d’emploi indique, il n’est pas du tout nécessaire d’acquérir une PowerLAN station pour créer le réseau PowerLAN. Du moment que la première multiprise est proche du routeur, on peut la brancher directement par le port RJ45 au routeur, et elle créera alors le réseau PowerLAN pour l’ensemble des prises (15 au maximum).

Et alors où est le problème ?

Je détaille les points négatifs au fur et à mesure de mon article, puisque qu’ils sont la raison de celui-ci. On découvre par exemple que l’application et le cloud sont centrés sur l’appareil lui-même, c’est à dire que lorsque l’on souhaite éteindre un appareil, ou voir les statistiques, ou encore programmer des actions, on ne peut le faire qu’au sein d’une même prise (multiple ou simple) alors que ce ne serait pas nécessaire. Or, j’ai aujourd’hui chez moi 6 prises multiples et une simple. J’aimerais pouvoir travailler avec l’ensemble de mes prises sans tenir compte de quelle multiprise commande quel appareil. Il s’agit ici d’un changement mineur dans le développement de l’application. Et ça ferait une très grande différence. J’ai tenté de communiquer avec Max Hauri à travers leur email, seul contact possible, mais ils ne semblent absolument pas à l’écoute. J’espère qu’ils ne considèrent pas ce produit déjà mort. Ca serait vraiment dommage.

Comme tous les appareils connectés aujourd’hui, les produits MaxSmart sont commandés par restAPI. Qu’est-ce que c’est restAPI ? Il s’agit de commandes que l’on envoie par un lien URL (comme si on voulait ouvrir une page internet). Ce lien contient la destination et la commande de l’appareil que l’on souhaite commander. Je schématise ici afin de mieux vous faire comprendre: Imaginons que vous avez une caméra IP avec l’adresse IP 192.168.1.12. Vous souhaitez désactiver la détection de mouvement. Il suffirait, par exemple, d’ouvrir le lien suivant sur votre navigateur internet pour le faire, du genre:

http://192.168.1.12/?command=motiondetection&state=0

Dans cet exemple, on fait appel à la commande « motiondetection », et on lui ordonne le statut « 0 ». La réponse de la caméra sera http 200 si l’opération est correct. Si le chemin de l’API est faux, vous aurez une réponse http 404 (page non trouvée… vous connaissez n’est-ce pas ?). L’application MaxSmart utilise donc forcément des APIs pour envoyer les commandes aux prises.

Aujourd’hui, donc, la grande majorité des appareils connectés, sinon tous, fonctionnent sur ce principe. J’ai chez moi une caméra IP D-Link qui fonctionne sur ce principe. J’ai eu beaucoup de peine à trouver les API propre à la caméra, car bien sûr, elles dépendent de chaque constructeur, voire de chaque produit, et elles ne sont pas toujours publique. Pourtant, si elles étaient publiques, elles permettraient d’automatiser très facilement toutes les actions. Il serait ainsi facile de commander une prise MaxSmart lorsqu’il y a détection de mouvement avec la caméra D-Link grâce à une application d’automatisation comme MacroDroid qui permet d’envoyer des URL (donc utiliser des API) pour obtenir des informations ou pour enclencher des actions, ou, pourquoi pas, permettre à Logitech d’intégrer les produits MaxSmart dans son support de produit. Il serait alors possible, sur une pression d’une télécommande Harmony, d’allumer les prises électriques, avant d’allumer la TV, le tuner, l’ampli, etc…. et d’éteindre le courant à la fin de l’usage pour éviter l’utilisation en veille.

Là encore, on reconnaît l’ignorance de MaxSmart, puisque ses APIs ne sont pas diffusées. Lorsque l’on cherche dans leur FAQ, on y trouve une explication capillotractée prétendant qu’il s’agit d’une décision liée au support. Si vous lisez mon article, Max Hauri (je doute), prenez donc conscience de l’importante d’être à l’écoute de vos clients et du marcher. L’avenir est à l’automatisation. Ce n’est pas en fermant vos produits et en les limitants à votre écosystème que vous aurez du succès.

Bref ! C’était l’introduction. Vous êtes toujours là ? Alors on peut passer à la suite, car il y a une parade.

On arrive donc à l’objet de l’article: je n’aime donc pas l façon dont MaxSmart envisage le fonctionnement de son application, et j’aimerais m’en affranchir. Pour ça, il faut que je parte à la découverte des APIs par mes propres moyens, puisque Max Hauri ne veut pas les partager.

Et comment s’y prend-t-on ?

Il existe des applications permettant de capturer ce qui passe sur le réseau. Sur Windows ou sur Mac, il s’agit de WireShark entre autre. C’est le meilleur et le plus connu. En lançant cette application, on peut voir absolument tout ce qui se passe entre l’interface réseau de l’ordinateur, et le reste du réseau (et donc de l’internet). Attention, ça balance !

Il existe un pendant à Android que j’ai trouvé efficace et facile d’utilisation, il s’agit de Packet Capture. Cette application va vous demander d’identifier une application. Elle va ensuite ouvrir un VPN, et tout le trafic qui sera généré par l’application en question sera alors intercepté. Il est alors possible de voir les liens, leur contenu, leur destination, bref… il est possible de découvrir les API. C’est ce que j’ai fait pour trouver comment commander les prises MaxSmart sans passer par leur application ou leur Cloud.

Pour l’instant, je n’ai cherché que comment allumer et éteindre. En même temps, c’est le plus important. Je n’ai pas cherché comment récupérer les statistiques. Je ferai ça peut-être dans un deuxième temps, car j’aimerais bien les récupérer dans ma propre base de données et les consolider, pour ne pas avoir à dépendre de leur application, et surtout, pour pouvoir voir l’ensemble de la conso, et non la conso par multiprise.

J’ai donc lancé l’application Packet Capture, puis j’ai allumer la prise numéro 2 d’une de mes multiprise. Voici ce que ça donne:

L’application MaxSmart envoie l’URL suivant:

GET /?cmd=200&json=%7B%22sn%22:%22SWP6023002012345%22,%22port%22:2,%22state%22:1%7D HTTP/1.1
Host: 192.168.1.169
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Et reçoit la réponse suivante:

HTTP/1.1 200 OK
Content-Length: 27
Content-Type:text/plain

La prise répond avec HTTP 200 qui indique que la commande a bien été reçu et exécutée.

Je découvre donc ici plusieurs choses:

  • L’adresse IP de ma prise est 192.168.1.169
    • Voilà qui est utile. Je vais pouvoir aller dans mon routeur et fixer l’adresse IP pour éviter qu’elle change. Ca va me faciliter ensuite la vie pour l’automatisation. Cette opération n’est pas forcément nécessaire: les prises étant en permanence branchées sur le réseau, elles devraient toujours recevoir la même adresse IP. Reste que je préfère éviter les surprises
  • Nous sommes au format json. C’est un format très utilisé pour les RestAPI
  • C’est du JAVA. On est pas dans la merde. Bon en même temps, ça marche, on va pas se plaindre 🙂 C’est un petit clin d’oeil. Java est sur le déclin car c’est lourd, et fastidieux. Mais au final, tant que ça marche, ça n’a pas d’impact.

A noter que le retour ci-dessus est encodé en ASCII. JSON est un format qui utilise des accolades pour encapsuler les commandes. Pour pouvoir lire correctement l’URL, envoyée, on peut utiliser un site en ligne pour décoder. Pour cet article, j’ai utilisé https://www.url-encode-decode.com/.

Et voici ce que ça donne:

/?cmd=200&json={"sn":"SWP6023002012345","port":2,"state":1}

C’est tout de suite plus lisible, c’est-ce pas ?

On voit maintenant que l’URL contient quatre informations:

  • La commande (200)
    • Il s’agit ici en toute logique de la commande d’état électrique
  • Le numéro de série de la prise (sn)
  • Le port (le numéro de la prise sur la prise multiple en fait) (2)
  • L’état (1 pour allumer)

La prise a renvoyé une réponse également sous forme json

{"response":200,"code":200}

 Une application pour l’automatisation va donc recevoir response 200 et comprendre que l’action a été effectuée avec succès.

Pour vérifier que les commandes découvertes sont les bonnes, j’ai envoyé sur mon firefox les URLs suivantes, pour allumer:

http://192.168.1.169/?cmd=200&json={"sn":"SWP6023002012345","port":2,"state":1}

puis pour éteindre la prise

http://192.168.1.169/?cmd=200&json={"sn":"SWP6023002012345","port":2,"state":0}

Objectif atteint avec succès. Mais je dois admettre que mettre le numéro de série me dérange. C’est un long code, et probablement inutile puisque chaque appareil (prise simple ou prise multiple) a sa propre adresse IP. Le numéro de série est utile pour identifier la prise la première fois, et pourquoi pas, pour fixer l’adresse IP dans le serveur DHCP. Mais une fois que c’est fait, on n’en a plus rien à faire ! J’ai donc tenté la commande sans la donnée « sn », et … ça marche. Voici donc une excellente nouvelle. Toutes les commandes ci-dessous fonctionnent dès lors sans le numéro de série.

J’ai ensuite cherché comment vérifier l’état, pour définir si une prise était déjà allumée ou éteinte. Je ne reviendrai pas sur les éléments déjà expliqués plus haut. J’ai déterminé que la commande 511 permettait d’obtenir les informations de la prise multiple. En effet, en envoyer l’URL suivante:

http://192.168.1.169/?cmd=511&json={"sn":"SWP60230020012345"}

Et la réponse suivante:

{"response":511,"code":200,"data":{"watt":["0.00","0.34","62.02","17.07","2.09","0.00"],"amp":["0.3","0.4","34.5","14.2","2.8","0.2"],"switch":[1,1,1,1,1,0]}}

En comparant avec l’état de la multiprise, j’ai pu constater la chose suivante:

  • La donnée « watt » donne l’état actuel de la consommation pour chaque prise dans l’ordre (de 1 à 6)
  • La donnée « amp » donne, selon toute vraissemblance, la puisasnce actuelle requise pour chaque prise dans l’ordre également. C’est une donnée que l’on ne retrouve pas dans l’app.
  • La donnée « switch » indique l’état de chaque prise, toujours dans l’ordre de 1 à 6

Il est donc tout à fait possible d’exploiter ces données, toutefois on entre ici dans le développement et le scripting, et je ne vais pas continuer sur cette lancée dans cet article. Avec ce que j’ai découvert, il est déjà possible d’éteindre et d’allumer des appareils de toutes sortes de façon différentes. Pour ma part, je vais utiliser une application Android qui me permet de créer des boutons sous forme de Widget. Chaque bouton sera configuré pour envoyer une URL, et donc pour allumer ou éteindre un appareil. Sur Android, une application très pratique permet de faire des icônes qui envoient des URL. Elle s’appelle HTTP Shortcuts. On peut alors créer des boutons, et leur attribuer une commande d’allumage ou d’extinction.

Bien sûr, une fois que l’on a identifié les commandes principales, il est très facile d’automatiser de toutes les façons possibles. Sous linux avec Bash, Python, Perl, SOAP, etc… Sous Windows avec PowerShell, sous Android avec MacroDroid, ou d’autres outils de ce genre. Je reviendrai peut-être sur ce sujet dans un autre article.

Est-ce que je peux tout casser ?

Attention si vous partez vous-même à la recherche d’une API: Avec la mauvaise commande, on peut tout faire foirer. Pour la petite anecdote, pendant la rédaction de cet article, j’ai testé la commande 201 sous la forme suivante:

http://192.168.1.169/?cmd=201&json={"sn":"SWP6023002012345","port":2}

et je me suis retrouvé coincé avec l’application. Impossible de commander la prise deux. Et le nom que j’avais attribué avait été remplacé par un tas de caractères spéciaux. Fort à parier que ma commande 201 sert à changer le nom, et qu’en ne mettant pas de nom, le système est paumé. C’est signe d’un très mauvais développement … D’ailleurs, souvent, si les API ne sont pas publiés c’est parce que le développement est pourri, et qu’il serait trop facile de planter tout le système accidentellement à cause d’une routine de vérification mal implémentée, voire pas implémentée du tout. Ce genre de problème ne devrait pas être possible. Qu’importe, je suis reparti sur mon mobile, et utilisant Packet Capture, je suis allé voir quelle était la commande envoyée pour changer le nom d’une prise, et je renommé ma prise:

http://192.168.1.169/?cmd=201&json={"sn":"SWP6023002012345","port":2,"name":"Clavier"}

« Clavier » car il s’agit du chargeur de mon clavier Bluetooth pour les curieux. Ca a débloqué ma situation. Il est donc fortement recommandé de NE PAS tenté de découvrir les API en envoyant des commandes au hasard… Ca serait dommage de tout planter. Ca risque d’être plus compliquer à débloquer ensuite. Et il y a fort à parier que Max Hauri vous enverra péter si ils apprennent que vous avez jouer avec les APIs, vu leur politique de fermeture.

Et maintenant ?

J’arrête mon Mac (oui oui j’ai un Mac), et je regarde un moment la télé. Parce que si je me mets à aller plus loin, je vais y passer la nuit, et demain, je bosse ! ABE

Voilà. Des questions, des commentaires, n’hésitez pas… Je vais partir à la recherche de plus de commandes, donc si vous vous lancez dans l’acquisition de ce produit, j’échangerai avec vous avec plaisir.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *