Remontées d'informations sur Jeedom depuis un WiserLink 31800

Plugins Energie
1

Bonjour,

Je cherche à remonter des informations depuis mon compteurs Wiser Link. Malheureusement j’ai le nouveau 31800 (et non le 31600) et celui-ci n’est pas compatible avec le plugin officiel Wiserlink. Je ne dois pas être le seul :smile:

Je suis tombé sur un message d’une tentative sur l’ancien forum (ici), et semble avoir presque réussi,mais c’est du chinois pour moi.

Du coup ce petit post pour savoir si quelqu’un avait réussit ou des pistes, soit en local soit en se connectant au site web Schneider

1 « J'aime »
2

Bonjour,
Je suis dans le même cas que toi.
Pour suivre.

1 « J'aime »
3

Bonjour,

Je suis aussi dans la même situation. Au vu du post sur l’ancien forum, le module 31800 ne communique par directement via une api REST mais via un protocole SOAP spécifique, le DPWS.

J’arrive à découvrir le service en python (je ne connais pas le php), pas encore à l’interroger.
Je vous ferais par de mes avancée si j’arrive à quelque chose.

1 « J'aime »
4

Bon, j’avance un peu. Mais n’étant ni un expert en réseau, ni en java, c’est un peu laborieux.

En scannant les port du module (nmap) , j’ai 80 (http), 443 (https), 5357 (wsdapi) et 5000

  • wsdapi c’est du soap sur udp (par opposition à tcp qui utilise les adresse ip) pour faire de la découverte de device sur un réseau sans connaitre à l’avance son ip. (Comme udp permet de faire du broadcast ). L’étape de discovery, j’arrive à la répliquer avec ws-discovery en python. A ce stade, j’ai une ip, une url (xaddr) de type http:{ip}:5357/dpws/<uri_du_device>.
    En oscultant le trafic avec wireshark, je vois bien que je fais une requête au réseau 239.255.255.250 (broadcast) , et que c’est le module qui me répond directement à partir de {ip}

A ce stade là, je ne sais pas vraiment quoi en faire. Toutes mes tentatives de requête sur cette url coincent.

  • en get sur port 80 : erreur 404 (ressource non trouvé)
  • en get sur port 443 : erreur 401 (unauthorized)
  • en post sur 5357 avec une envelope soap xml : retour d’erreur dans une autre envelope soap : action not supported (ne m’en demandez par plus, le soap c’est vraiment pas mon truc)

J’ai justement essayé de faire du soap, mais impossible de trouvé le fichier wsdl qui est censé documenté le service. A ce stade, je suis à peu prêt sur que soap n’est utilisé que pour la découverte de device, pas pour les échanges de données (c’est vraiment barbare le soap).

De l’autre côté, je me suis inspiré de la démarche de didjee sur l’ancien forum : télécharger l’apk de esetup, le décompiler (sur decompiler.com) et parcourir les sources de l’application en java.

Je ne suis pas un expert en java, mais à force de regarder et de faire des grep dans tout les sens, tout en regardant le fonctionnement des applications esetup et energywiser (que j’arrive à faire marcher sans problème par ailleurs et qui me remonte bien mes conso), je commence à y voir un peu plus claire.

Dans esetup, il faut que l’on soit sur le même réseau que le module et que le bluetooth soit activé. pour faire l’appariement, il faut appairer manuellement en appuyant sur un bouton en façade du module.

Donc mon hypothèse ;

  • l’app détecte le module avec soap sur udp et trouve une ip, un uri avec l’adresse mac du module et le type du device. a ce stade, il s’agit peut être juste de savoir qu’il existe un module. l’url et l’ip ne sont peut être même pas utilisée.
  • l’app demande l’appairage via bluetooth avec validation manuelle (pas encore isolé cette partie dans le code)
  • l’app se connecte en utilisant le mot de passe par défaut de l’application (admin: admin)
  • La suite se passe bien via des requête REST classique (ouf).

Les url pour faire les remontées de données ont l’air d’être les mêmes que celles des modules php de jeedom (/vesta/UsageMeter). A ce stade je penche sur un problème liée à l’appairage ou au login.

Il est possible qu’un renforcement de sécurité ai cassé le fonctionnement qui marchait avec le module EER31600…

Je continue de creuser.

5

Je crois que j’avance.

Dans le fichier DetectedDevicesListActivity.java, voila la fonction qui s’occupe du login:

 private void requestLogin(SchneiderWLSLDevice schneiderWLSLDevice) {
        ScotDialogFragment instanceProgress = ScotDialogFragment.instanceProgress(true);
        this.dialog = instanceProgress;
        instanceProgress.show(getSupportFragmentManager(), (String) null);
        String replaceAll = schneiderWLSLDevice.getMacAddress().toUpperCase().replaceAll(":", "");
        if (schneiderWLSLDevice.getDeviceType().isSmartlinkB()) {
            doLoginSmartlink(schneiderWLSLDevice, replaceAll, true);
        } else if (schneiderWLSLDevice.getDeviceType().isWiserV1()) {
            doLoginWiserlink(schneiderWLSLDevice, new LoginReq("admin", "admin"));
        } else if (schneiderWLSLDevice.getDeviceType().isAramis()) {
            fetchAramisGatewayKey(schneiderWLSLDevice, replaceAll);
        }
    }

En cherchant la définition de isWiserV1 :

    public boolean isAramis() {
        return this == MIP_V2 || this == SL_EL_D || this == ELKO;
    }

    public boolean isWiserV1() {
        return this == MIP_V1;
    }

    public boolean isWiserV2() {
        return this == MIP_V2 || this == ELKO;
    }

Et en pistant les messages affichés par l’application, le modèle 31800 est référé en tant que aramis_wiserlink.

Je pense qu’Aramis est le petit nom du module bluetooth qui s’occupe de l’appariement. Dans ce cas de figure, on ne passe plus par login :admin et mdp: admin (peut êtte pas plus mal…).

A la place on passe par fetchAramisGatewayKeys.

ça ressemble à une méthode pour acquérir une clef d’api via le bouton d’association bt …

[edit ]
Bon en fait, le clef d’api est généré par un algorithme déterministe à partir de l’adresse mac du module.

J’essai de convertir le java en python et voir si j’arrive à forcer la serrure de mon module :slight_smile:

[edit 2]

Bon, j’arrive à générer un clef qui a l’air valide. j’arrive à récupérer les information du module en REST avec.

Sans la clef :

GET https://192.168.xxx.xxx/rsa1/ProductDetails

401 unauthorized (‹ WWW-Authenticate ›: ‹ Basic realm=«  » ›)

Avec la clef : (m2madmin : key )

GET https://192.168.xxx.xxx/rsa1/ProductDetails → 401 unauthorize

'{ "fw": "V1.7.5", "coS": true, "name": "myWiserEnergy-B2A1", "sn": "RN-2020-W17-1-0045", "pc": "EER31800", "cSsem": true }'

[Edit 3] Victory !

Avec la clef :

GET /rsa1/MeterInstantData

'{ "MeterInstantData": [ { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 0, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 205, "channel": 5 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 0, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 205, "channel": 0 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 0, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 205, "channel": 1 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 0, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 205, "channel": 2 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 0, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 205, "channel": 3 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 0, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 205, "channel": 4 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 0, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 201, "channel": 0 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 134, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 201, "channel": 1 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 0, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 201, "channel": 2 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 158, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 201, "channel": 3 }, { "currentA": 0, "currentB": 0, "currentC": 0, "voltageAB": 0, "voltageBC": 0, "voltageCA": 0, "voltageAN": 0, "voltageBN": 0, "voltageCN": 0, "powerA": 0, "powerB": 0, "powerC": 0, "powerTActive": 201, "powerTReactive": 0, "powerTApparent": 0, "powerFactorT": 0, "frequency": 0, "slaveId": 201, "channel": 4 } ] }'
6

Et bien tu parles chinois pour moi :joy:
Si tu as besoin que je teste quelque chose, n’hésites pas.
As-tu regardé comment fonctionne le plugin qui marche pour le 31600? ça te donneras peut-être des idées car schneider a du conserver le fonctionnement de l’ancien module dans les grandes lignes (ou peut-être pas :frowning: )

7

Bonjour,

Je viens de faire la facheuse découverte que les remontées d’info via la passerelle EER31800 étaient compliquées. Je suis tombé sur ce post qui semble encourageant mais plus de post depuis 2021, as-tu réussi à mettre en « prod » cette communication ?

Merci par avance

8

Bonjour,

Comme je l’ai évoqué sur ce fil Plugin wiser link pour EER31600 incompatible avec le nouveau module IP (EER31800) - #5 par verturin j’ai pu reproduire le comportement attendu en PHP mais en me confrontant à une erreur que je n’arrive pas à ignorer « URL error: error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal padding ».

Je n’ai pas mis à jour le firmware comme demandé pendant cette année. Je me demandais si

  1. le soucis était résolu avec cet update
  2. si cet update changeait la clé ou l’algo de génération du password

Est ce que quelqu’un qui aurait fait l’update pourrait me dire ? ou tester avec moi ?
Merci d’avance
Merci d’avance.

9

Bonjour,

Si vous avez un EER31800, vous êtes probablement piégés depuis le 2 septembre et l’arrêt des serveur wiser energy par Schneider. Mon système de suivi de consommation qui a 3 ans est donc devenu inutilisable, ils me proposent de racheter une nouvelle passerelle à 110 € ainsi que 5 nouveaux tores à 100 €/pièce pour avoir les mêmes fonctions qu’auparavant, ils ne doutent de rien. Bref, il y a-t-il une possibilité de travailler en local avec l’EER31800 (ou le 31600 si jamais j’arrive à en racheter un, mais j’ai cru comprendre qu’il y avait une mise à jour qui avait éventuellement supprimé son serveur local ?) ? Je suppose qu’on va être beaucoup à être coincés si les EER31600 et EER31800 sont inutilisables, à croire que ça semble normal pour Schneider d’abandonner les utilisateurs tous les 5 ans…
Je précise que toute ma domotique est sous Domoticz, mais je ne m’interdis pas d’utiliser Jeedom pour récupérer mes consommations…

Merci et bonne journée

10

Bonjour,

Je suis exactement dans la même situation.
Mon EER31800 n’a même pas 3 ans, je suis assez écœuré, surtout en ce moment quand on parle de réduire l’obsolescence des matos, on devrait jeter quelque chose en état de fonctionnement.

Bref, je suis en train de chercher une solution en local.
Peut-être une solution envisageable du côté du plugin MyModbus (Merci à @Michel_F pour l’info).

Je suis en train de regarder le post MyModbus et Powertag Schneider - #25 par ced2001. Mais j’avoue que je ne comprends pas grand chose :frowning:

A suivre.

11

Bonjour,

J’ai fait un fil dédié auquel vous pouvez vous référer :

Je vous conseille de faire chacun un fil dédié en cas de problème et de consulter le fil de l’autre en cas de pépin.

A+
Michel

12

Bonsoir désolé, je n’ai pas vu votre message, je n’ai jamais installé la WiserLink
J’ai l’ecostruxture (PAS600 et PAS800)

13

Bonjour, (je me demande quel est le topic le plus vivant pour les ERR31800 sur ce forum)
Je viens d’acheter ce matériel sur leboncoin, il y en a plein a vendre depuis que c’est arrêté.
Je vais commencer un gros travail de reverse engineering quand je les aurais reçu.
Quelqu’un a-t-il déjà sniffé les trames ? Tenter d’accéder au server web intégré ?
Communiquer directement en ZigBee avec les powerTag pour bypasser leur gateway ?
Du Modbus directement ce serait super !

De mon coté, C, Python, C#, Php ou autre pas de soucis j’espère pouvoir contribuer à rendre ces modules compatibles avec nos systèmes customs.

14

Bonjour R-A-F, tu as pu avancer ?
Pour info les EER31800 n’ont jamais eu de page web en http ou https contrairement au EER31600 qui eux en avait une