Update request : payloadType = 1 about node-red-contrib-eesmart-d2l HOT 19 CLOSED

Ok, d'un côté ça me rassure de pas être le seul ;)
Il faut espérer que le support d'eeSmart donne l'explication (mise à jour firmware ? initialisation pour valider le dongle la première fois ?).
Ca serait bien de pouvoir utiliser directement le serveur local sans être obligé de se connecter une première fois à leur serveur.

from node-red-contrib-eesmart-d2l.

Réponse du support, le payload 1 correspond à une demande de mise à jour FW.
A voir si on va pouvoir le traiter de notre coté ou si il faut continuer de le connecter au serveur D2L pour qu'il fasse sa maj

from node-red-contrib-eesmart-d2l.

Le 0x05 c'est qu'il demande l'heure et le 0x01, toujours pas de nouvelles du support eesmart.

J'ai suivis la même procédure que @0rsa (passage vers le serveur d'eeSmart), et j'ai bien des messages en 0x03 maintenant. Il semble qu'il lui faut absolument téléphoner à la maison avant de complètement fonctionner.

from node-red-contrib-eesmart-d2l.

Debugging headers l.329, I have this object:

{ protocolVersion: 3,
frameSize: 64,
idD2L: 'XXXXXXXXX',
encryptionMethod: 1,
randomNumber: <Buffer 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00>,
crc16: <Buffer fc 0d>,
payloadSize: 26,
payloadType: 1,
nextQuery: 0,
isRequest: true,
isResponse: false,
isSuccess: true,
isError: false }

payloadType never changes

from node-red-contrib-eesmart-d2l.

Ok it works!
How I solved this?
First I tried to reset D2L because I started it before my server was launched.
It has been a fail.

Next I connected my D2L to eeSmart server (it was the first time I tried) and I think D2L received an update.
I did a new reset to reconnect it to my local server and now it works.

from node-red-contrib-eesmart-d2l.

Each time you plug the D2L he try to get the clock (payloadType = 0x5) then after he got it he start to send push json (0x3) You should not get payloadType to 1. According the doc it's should be 0x3 or 0x5
You still have the base64 data ?
What you have in the json payload _DATE_FIRMWARE ?

from node-red-contrib-eesmart-d2l.

S'agissant d'un module français à destination des compteurs électriques français, je vais me permettre de passer en Français.
Alors du coup, comme ça ne fonctionnait pas au début, j'ai commencé à potasser la doc d'eeSmart et je suis arrivé à cette même conclusion : la valeur du payloadType que j'obtenais dans le header n'était pas cohérente avec les deux valeurs indiquées dans la documentation. J'ai aussi compris que le dongle D2L synchronise l'heure avec le serveur local et qu'il reçoit donc des données (je pensais initialement que l'échange se faisait à sens unique, à tort).

C'est ce qui m'a mis sur la piste de faire un reset du dongle car je l'avais démarré et configuré avant d'avoir un serveur local pleinement fonctionnel, sachant que le dongle interroge et attend une réponse du serveur, le fait de l'avoir démarré sans serveur fonctionnel pouvait peut-être l'avoir mis dans un état incohérent.
Ce reset n'a rien changé à mon problème de payloadType qui était toujours à 1.

J'ai ensuite eu cette deuxième idée de connecter le D2L au serveur d'eeSmart en me disant qu'il y aurait peut-être une mise à jour du firmware en passant par leur serveur car je venais de recevoir le D2L et que je ne l'avais jamais connecté une seule fois à leur serveur, je l'avais configuré directement pour attaquer mon serveur local.
Lorsque je l'ai connecté au serveur eeSmart, la LED est passée au vert, j'ai surveillé cette LED avec attention les premières minutes et j'ai vu cette même LED passer au rouge un bref instant avant de repasser au vert : c'est ce qui m'a fait penser qu'une mise à jour du module avait pu être effectuée.

Maintenant, effectivement, lorsque je regarde l'attribut _DATE_FIRMWARE, il n'y a pas dû avoir de mise à jour du module puisqu'il est plus qu'ancien : "_DATE_FIRMWARE":"Jul 7 2017"

Du coup, à cette heure-ci, je ne saurai pas expliquer pourquoi le fait de l'avoir connecté au serveur eeSmart a "débloqué" le dongle. A partir du moment où je l'ai connecté au serveur d'eeSmart, il s'est ensuite mis à envoyé un header cohérent avec la documentation avec un payloadType à 5 et tout a fonctionné via le serveur local sans que je ne change quoi que ce soit.

Il y a peut-être un mécanisme de première initialisation du D2L qui nous échappe et qui n'est pas documenté, je ne vois pas d'autre explication dans la mesure où je n'ai aucun doute pour mon cas que c'est la connexion au serveur d'eeSmart qui est à l'origine d'un bon fonctionnement par la suite.

from node-red-contrib-eesmart-d2l.

Lorsque j'ai développé le module j'ai initialisé le D2L et il as commencé à me demander l'heure toutes les minutes. A ce moment là je ne lui répondait pas et cela as duré des heures. Une fois que j'ai pu décoder sa demande et lui répondre il as commencé à m'envoyer des données donc ce n'est pas un problème si le D2L est configuré en premier.

Concernant le _DATE_FIRMWARE j'ai aussi Jul 7 2017 mais tu avait peut être une version encore plus ancienne.

Par rapport au payload = 1, j'ai posé la question au support pour savoir à quoi cela correspondait et j'attend leurs réponse. Il n'est pas étonnant qu'ils y ait d'autres payload inconnus. Puisqu'il y a au moins 1,2 et 4 et techniquement le type payload est compris entre 0 et 127.

Il existe aussi une valeur CommandeSuivante dans la documentation qui d'après la documentation "force le D2L à exécuter une fonction" mais on as aucune info sur les valeurs possibles et leurs actions. Cette valeur est aussi comprise entre 0 et 127.
Le problème aussi c'est que pour lui envoyer des commandes il faut attendre qu'il se connecte car le D2L ne se connecte au réseau wifi que pendant 3 à 4 secondes le temps qu'il envoi ses données.

Avec le payload = 1 il y avait un payloadSize ou il était à 0 comme quand il demande l'heure ?

from node-red-contrib-eesmart-d2l.

J'avais mis le header dans mon deuxième post :

{ protocolVersion: 3,
frameSize: 64,
idD2L: 'XXXXXXXXX',
encryptionMethod: 1,
randomNumber: <Buffer 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00>,
crc16: <Buffer fc 0d>,
payloadSize: 26,
payloadType: 1,
nextQuery: 0,
isRequest: true,
isResponse: false,
isSuccess: true,
isError: false }

Le payloadSize était à 26

from node-red-contrib-eesmart-d2l.

As tu encore les données du payload pour voir ce qu'il contenait ? Ou même la sortie de TCP in, on peut le décoder à la main.
Et le randomNumber, il contenait réellement cette valeur ? On ne dirait pas des nombres aléatoire

from node-red-contrib-eesmart-d2l.

J'avais mis un console.log(headers) ligne 328 juste avant le switch (headers.payloadType) et c'est ce que j'avais en sortie directement dans la console node red que j'ai recopié au dessus
Je n'ai malheureusement plus rien d'autre à ma disposition.

from node-red-contrib-eesmart-d2l.

Si par hasard quelqu'un passe ici avec un payload type = 1 merci de laisser un commentaire afin que l'on regarde ce que pouvais bien contenir ce payload.

from node-red-contrib-eesmart-d2l.

Un autre utilisateur as exactement le même problème, le numéro aléatoire est le même et on as pu récupérer un payload mais sans tableau de correspondance impossible de savoir ce qu'attend le D2L

from node-red-contrib-eesmart-d2l.

J'ai exactement le même soucis. Je suis en train de dev mon propre serveur, et je reçois des call réguliers avec le payload type à 0x05 et parfois à 0x01. Des nouvelles de ce que ce type inconnus pourrait être ?

from node-red-contrib-eesmart-d2l.

Le 0x05 c'est qu'il demande l'heure et le 0x01, toujours pas de nouvelles du support eesmart.

from node-red-contrib-eesmart-d2l.

J'ai relancé le support pour savoir si ils ont un peu progressé.

from node-red-contrib-eesmart-d2l.

Ma première hypothèse était la bonne ma foi. Merci pour le retour.

from node-red-contrib-eesmart-d2l.

@0rsa J'ai crée un salon de discutions sur Discord pour qu'on en discute. Fait moi signe dessus pour que je mette les accès

from node-red-contrib-eesmart-d2l.

Corrigé dans la version 1.0.0 d851a80

from node-red-contrib-eesmart-d2l.