Développement module pour prises DLink DSP-W215


#1

Bonjour,

Je suis en train de développer un module pour contrôler les prises DLink DSP-W215.

Le module est fonctionnel mais je butte sur la partie installation des prises.

En effet, je n’ai trouvé aucun module qui permet de détecter les prises présentes sur le réseau. Aussi, je prévoie de simplifier l’installation manuelle en proposant d’ajouter, dans les paramètres de Gladys, autant d’entrée qu’il y a de prises :

  • Nom du paramètre : W215_PRISE_n où n est le n° de la prise dans Gladys (W215_PRISE_1, W215_PRISE_2…)
  • Valeur : adresse_IP:PIN_Code (le code PIN est inscrit derrière la prise)

Le module setup.js parcourrait toutes les entrées W215_PRISE_n et créerait les devices correspondant (actuellement, ça ne fonctionne que pour une prise…).

J’ai écrit un code dans le fichier setup.js, mais il semble qu’on ne puisse pas faire de boucle. Cela est lié à ma méconnaissance du développement JS… Peut-être qu’il y a une meilleure solution. A l’aide s’il vous plaît :smile:

Dépôt Git : https://github.com/PhilippeMA/gladys-DSPW215


#2

salut,
et en faisant un scan des adresses IP sur ton routeur cela serait pas possible ?
je pense que chaque prise à un début de nom identique, non ?

en faisant des recherches je suis tombé sur une fonction qui te permettrait de faire ta recherche.
si tu tape http://IP_PRISE/mplist.txt est ce que tu as quelque chose ??


#3

Je crois que le soucis de ta boucle while est liée à l’async des “param.getValue”.
Tu sors du while avant le retour de l’appel en DB.
Check la doc, mais je crois que tu dois pouvoir remédier a cela avec “await” afin de passer en synchrone.

Autre possibilité, récupérer d’abord toutes les entrées en DB puis boucler ds le tableau de résultats.
J’espère que ca pourra t’aider, ou que qu’un corrigera si je dis DB tises ^^


#4

Merci @Jap93, malheureusement le scan du réseau ne donne rien parce que le nom de la prise est modifiable. J’ai essayé le lien fourni mais il ne fonctionne pas : erreur 404. Je vais regarder cette piste.

Merci @Boimb, je vais tester avec await. Le fonctionnement asynchrone me perturbe :stuck_out_tongue:


#5

Arf surtout pas ! Demande tout simplement à l’utilisateur de créer les prises dans les devices, c’est plus simple non ?

Et le meilleur des cas ça serait d’arriver à scanner automatiquement le réseau

Await n’est disponible qu’à partir de Node 8, nous sommes actuellement en Node 6 dans Gladys ça ne sera pas possible pour l’instant.


#6

Arf. My bad. Merci pour ta vigilance @pierre-gilles


#7

D’accord, je laisse quand même la possibilité de le faire prise par prise (ça me semble plus rapide que la saisie manuelle) avec un paramètre unique dans Gladys. Si cela ne te convient pas, je supprime.

Pour la détection automatique, il apparaît qu’aucune solution n’existe et je n’ai clairement pas la capacité pour le faire. Pour info, la solution utilisée pour le module est plus basée sur un hack qu’une solution basée sur une API officielle.


#8

Pour l’instant je ne vois pas de meilleur alternative, mais c’est vraiment pas terrible parce que clairement les Gladys param ne sont pas fait pour ça ! Il faut qu’on réfléchisse à une autre façon de faire :wink:

Par exemple ça serait pas mal d’avoir une vue HTML pour chaque module où justement ce genre d’infos pourraient être effectué.

Je viens d’accepter ton module sur le store :

https://developer.gladysproject.com/fr/modules/d-link-dsp-w215

Avant que je l’accepte dans Gladys, j’ai quelques changements en tête :slight_smile:

Plutôt que de faire un return Promise.resolve(); à la fin de ton fichier setup ( ce qui n’est pas génial, si quelque chose se passe mal lors du setup on aimerait que l’utilisateur récupère une erreur côté interface )

Il faudrait changer =>

Et ajouter un “return” devant “gladys.param.getValue”. Tu pourras ensuite enlever le return Promise.resolve() qui devient inutile derrière. Pareil, pourquoi vouloir toujours resolve en cas d’erreur ici =>

?

Je sais que c’est plus jolie d’afficher toujours du vert dans l’interface, mais si ça n’a pas marché autant que ça resolve pas et que dans l’interface il y ait un message d’erreur… Essayons de faire en sorte que l’utilisateur ait le minimum à aller dans les logs ^^


#9

Hey @PhilippeMA je viens de voir ton GitHub il y en a du module Gladys :open_mouth:

Hésite pas si tu veux de l’aide pour mettre en ligne tout ça sur le site dev Gladys :slight_smile:


#10

Bonjour @pierre-gilles, j’ai corrigé selon tes recommandations. Peux-tu vérifier que cela convient ?


#11

Bonjour,

Je reviens vers vous après plusieurs mois d’utilisation… Le module fonctionne toujours aussi bien pour contrôler mes prises mais j’ai l’impression que depuis les récentes mises à jour de Gladys, j’ai perdu l’accès aux courbes de ces devices… Je sélectionne le device mais aucune courbe ne se charge.

Peut-être que ça vient de mon code ? Merci pour votre aide :slight_smile:


#12

Bizarre, ça fonctionne toujours chez moi !

Tu peux regarder dans la base de donnée si tes valeurs de deviceState s’enregistre toujours ?


#13

Rien dans la table devicestate pour ces devices. Mince, ça doit venir de mon code mais je ne vois pas. Je vais fouiller davantage.

Pour information, les prises sont activées / désactivées par des scénarios liés à ma présence ou non dans mon appartement.


#14

Ah mince, tu as des erreurs dans les logs ?


#15

Je ne vois que cette erreur :

Error (E_VALIDATION) :: 1 attribute is invalid
    at WLValidationError.WLError (/home/pi/gladys/node_modules/gladys/node_modules/waterline/lib/waterline/error/WLError.js:25:15)
    at new WLValidationError (/home/pi/gladys/node_modules/gladys/node_modules/waterline/lib/waterline/error/WLValidationError.js:19:28)
    at _afterValidating (/home/pi/gladys/node_modules/gladys/node_modules/waterline/lib/waterline/query/validate.js:53:23)
    at allValidationsChecked (/home/pi/gladys/node_modules/gladys/node_modules/waterline/lib/waterline/core/validations.js:265:12)
    at /home/pi/gladys/node_modules/gladys/node_modules/waterline/node_modules/async/lib/async.js:52:16
    at Object.async.forEachOf.async.eachOf (/home/pi/gladys/node_modules/gladys/node_modules/waterline/node_modules/async/lib/async.js:236:30)
    at Object.async.forEach.async.each (/home/pi/gladys/node_modules/gladys/node_modules/waterline/node_modules/async/lib/async.js:209:22)
    at Validator.validate (/home/pi/gladys/node_modules/gladys/node_modules/waterline/lib/waterline/core/validations.js:144:9)
    at /home/pi/gladys/node_modules/gladys/node_modules/waterline/lib/waterline/query/validate.js:42:25
    at /home/pi/gladys/node_modules/gladys/node_modules/waterline/node_modules/async/lib/async.js:718:13
    at Immediate.iterate (/home/pi/gladys/node_modules/gladys/node_modules/waterline/node_modules/async/lib/async.js:262:13)
    at runCallback (timers.js:649:20)
    at tryOnImmediate (timers.js:622:5)
    at processImmediate [as _immediateCallback] (timers.js:594:5)

Invalid attributes sent to Notification:
 • priority
   • "max" validation rule failed for input: 3
Specifically, it threw an error.  Details:
 undefined

#16

Là c’est un problème d’insertion d’une notification, le champs “priority” est à undefined


#17

ok, rien à voir avec mon problème. Ce n’était qu’une coïncidence.

Je viens de refaire le test, il n’y a eu aucune erreur dans les logs :

0|gladys   | Access with token to user Philippe
0|gladys   | Event : create : new Event with code : back-at-home
0|gladys   | Scenario : Trigger : New event : back-at-home
0|gladys   | Scenario : Trigger : Found 4 launchers with code back-at-home.
0|gladys   | Scenario : Trigger : Launcher condition verified.
0|gladys   | Scenario : Trigger : Launcher condition verified.
0|gladys   | gladys.location.create : Create location for user 1
0|gladys   | Scenario : Trigger : Condition not verified.
0|gladys   | Scenario : Trigger : Condition not verified.
0|gladys   | Verifying condition "Maison non vide" with template ()
0|gladys   | Verifying condition "Nuit" with template ()
0|gladys   | Verifying condition "Maison non vide" with template ()
0|gladys   | Scenario : Trigger : Condition not verified.
0|gladys   | Scenario : Trigger : Conditions verified, starting all actions.
0|gladys   | User 1 detected in area Home
0|gladys   | Scenario : exec : Found 2 actions to execute.
0|gladys   | Executing action "DeviceType exec"
0|gladys   | Executing action "DeviceType exec"
0|gladys   | Demarrage du device : OK du 1er coup

#18

J’ai remarqué qu’à chaque mise à jour de Gladys, j’ai des erreurs lors des MAJ de la BDD (exécution de node init.js). Je ne m’en suis jamais inquiété car au démarrage de Gladys, le contrôle de la BDD semble valide.

Est-il possible que ma BDD soit altérée ? Pour ma compréhension, qui va écrire dans la table devicestate ? (mon module ou le déclencheur du module, le scénario dans ce cas)


#19

aaah oui effectivement ! C’est même surement ça le problème, car à la dernière mise à jour j’ai fais une modification de base de donnée dans la table deviceType qui affecte l’enregistrement des devicestate

Alors après le node init.js n’est plus requis normalement ( typiquement sur l’image Gladys de base j’ai arrêté de le faire faire )

Il y a désormais des migrations automatique de base de donnée au démarrage de Gladys après une maj

Pour vérifier ou tu en es, tu pourrais aller voir le schéma de ta table devicetype, voir si il correspond au model ?


#20

Bonjour,

la description de la table semble juste :

MariaDB [gladys]> describe devicestate;
+------------+------------------+------+-----+---------+----------------+
| Field      | Type             | Null | Key | Default | Extra          |
+------------+------------------+------+-----+---------+----------------+
| value      | float            | YES  |     | NULL    |                |
| datetime   | datetime         | YES  |     | NULL    |                |
| devicetype | int(11)          | YES  |     | NULL    |                |
| id         | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| createdAt  | datetime         | YES  |     | NULL    |                |
| updatedAt  | datetime         | YES  |     | NULL    |                |
+------------+------------------+------+-----+---------+----------------+
6 rows in set (0.04 sec)

Je pense que ça vient de mon module. En effet, dans l’utilisation quotidienne c’est à dire via les scénarios les prises démarrent et s’arrêtent comme prévu. En revanche, quand je passe par l’interface “Contrôle mes devices”, en cliquant sur l’interrupteur de la prise j’ai un message d’erreur dans les logs code retour 500 et rien ne se passe.

J’en perds mon latin… Il doit bien y avoir quelque chose qui explique cette différence de fonctionnement ?