Récupérer id et localkey pour Tuya Smartlife

Bonjour à tous,

l’un de vous aurait-il réussi à effectuer cette manip avec du matériel d’Apple. (je n’ai pas d’android, ni de PC).
j’ai essayé plusieurs options trouvées sur le net mais sans succès jusqu’à présent…

merci d’avance.

Bonjour à tous
Je suis en train regarder le fonctionnement de l’api tuya … mais je suis pas certains de consommer les bons web services … savez-vous le endpoint consommé par l’app smartlife.
Moi je me suis basé sur ce endpoint : https://px1.tuyaeu.com
Pour la génération du token : https://px1.tuyaeu.com/homeassistant/auth.do ==> j’ai bien le token
Et pour lister mes équipements : https://px1.tuyaeu.com/homeassistant/skill
J’ai bien la liste de mes equipements, ex résultat pour un équipement :
‹ devices ›: [ { ‹ data ›: { ‹ max_temper ›: 90,
‹ min_temper ›: 55,
‹ online ›: True,
‹ state ›: ‹ false ›,
‹ temp_unit ›: ‹ FAHRENHEIT ›,
‹ temperature ›: 72},
‹ dev_type ›: ‹ climate ›,
‹ ha_type ›: ‹ climate ›,
‹ icon ›: ‹ https://images.tuyaeu.com/smart/icon/1493368574_0.png ›,
‹ id ›: ‹ 01106740cc50e350ad0c ›,
‹ name ›: ‹ Clim chambre Clement ›},
==> toutes les infos ne sont pas présentes et ne sont pas à jour par contre grâce à l’id je peux allumer/eteindre, modifier la température de l’équipement
Mais quand je fais votre procédure pour avoir les infos de l’app smartlife j’ai le résultat suivant pour l’équipement cité plus haut :
{
« devId »: « 01106740cc50e350ad0c »,
« dps »: {
« 1 »: false,
« 4 »: 0,
« 5 »: « 3 »,
« 6 »: 22,
« 8 »: « 0 »,
« 10 »: false,
« 13 »: 0,
« 14 »: 0,
« 15 »: 0,
« 16 »: true,
« 17 »: false,
« 18 »: 72,
« 19 »: false
}
}
Lui par contre à l’air de contenir toutes les infos…
D’ailleurs quel est la différence entre le devId et la localKey ?
Si y en a aucune y a un moyen plus simple de récupérer ces équipements et ID (sans téléphone) via un émulateur online de code python ==> added instruction how to check your device listed · PaulAnnekov/tuyaha@f2aac70 · GitHub
Emulateur : https://repl.it/ ==> creer un instance de code Python
Copier/coller le script de connexion tuya : https://github.com/PaulAnnekov/tuyaha/blob/master/tools/debug_discovery.py
Modifier les crédentials : username et password puis executer le code
Exemple de réponse :

Bonjour,
j’ai une petite question concernant le plugin.
J’ai vu dans le doc que les détecteurs de mouvements Tuya qui ne fonctionnent plus avec le Cloud ne sont pas compatibles, mais les autres alors c’est bon?
J’ai 2 détecteurs PIR immunisés contre les animaux qui fonctionnent dans SmartLife via le Cloud et l’application me donne un ID Virtuel. Est-ce que vous pensez que je pourrai les intégrer dans le plugin WifilightV2?

merci pour vos réponses

1 « J'aime »

Merci!

J’ai essayé et récupéré via ce script Python les id de mes devices, mais en fait je pouvais déjà les récupérer depuis l’application SmartLife en allant pour caque équipement dans Informations appareil…

Par contre ce script ne retourne pas les localkey dont a besoin le plugin j’en ai peur… :frowning: ??

Pour ma part Packetcapture et HTTP Canary ne me permettent plus de faire du Man in the middle pour récupérer les trames HTTP entre mon application SmartLife et le Cloud Tuya du probablment au passage en HTTPS de ces trames.

Une idée de comment procéder? Merci d’avance.
Je suis en version 3.20.1 de Smartlife…

1 « J'aime »

Perso avec la procédure ici, ça s’est fait super facilement : https://www.smarthomeblog.net/openhab-tuya/ :slight_smile:

1 « J'aime »

j’utilise cette méthode elle fonctionne parfaitement sans ce casser la tête avec un raspberry pi ou une machine linux sur le réseau ou une machine virtuelle . par contre il faut utiliser l’application smart life 3.11 trouvable sur apkmirror

2 « J'aime »

Merci beaucoup je vais regarder.
Mais as tu joué la procédure récemment ?
Après la sécurisation des flux par Smartlife notamment…?

Merci beaucoup.
Je vais aussi retenter via cette méthode.
In fine il vaut mieux récupérer une version 3.11 ou 3.12 de Smartlife sur apkmirror?
Merci

Edit: Hello, j’ai réussi la technique du Man In the Middle avec le proxy et le certificat en installant une version 3.11 de SmartLife sur un de mes anciens Smartphone!
J’ai pu récupéré d’une traite toutes les access key de mes devices Smartlife!

Merci encore pour votre aide!
Je vais pouvoir continuer la procédure avec Wifilightv2…

j’arrive un peut tard désolé mais puisque tu à réussi tant mieux :wink:

juste un précision quand à cette question :

A mon avis la sécurisation est simplement dans l’app android , c’est pour ça que ça marche avec là 3.11 je ne pense pas que ce soit une question firmware . Je ne sais même pas si c’est possible de protéger d’un man in the middle depuis le firmware , d’ailleurs j’en profite pour poser la question si des connaisseurs passe par là :wink: y à t-il un risque de ce coté ? si oui cela voudrait dire qu’ont ne pourrait plus être garantis de pouvoir utiliser les équipement tuya qu’ont achètera dans le futur … ? !..

ils peuvent d’une part changer les nouveaux firmware et coder le protocole différemment, c’est pour cela qu’il ne faut pas le changer et que de nouveaux appareils tuya peuvent devenir incompatibles avec le plugin. Et d’autre part changer l’appli (et c’est déjà fait car sur les dernières versions le localkey ne passe plus en clair).

Comme écrit dans la doc, il arrivera un jour où ce ne sera plus possible d’utiliser le plugin.

Par exemple la nouvelle box milight miboxer qui utilise le protocole tuya, il n’est pas possible de récupérer son protocole car il a changé et utilise un double cryptage (le protocole tuya et un protocole milight). L’appli miboxer ne permet pas de récupérer la clé et quand bien même je pense que la trame est encore cryptée. Pour milight il y a quelques années ils diffusaient leur protocole maintenant il est solidement protégé.

Il y a 2 raisons : le cloud pour savoir ce que vous faites, recouper avec d’autres de vos agissements et vous connaitre. L’autre est qu’il y a eu des articles sur les protocoles passoires permettant à un tiers de modifier l’état de vos appareils ou de récupérer des données des capteurs. Et les gens protestent donc les protocoles sont de plus en plus difficiles à cracker.

merci pour toute ces explications démoralisante … plus qu’a chercher du matériel open sources mais perso j’ai beau chercher je trouve rien de bien sympa , ya bien shelly qui permet pas mal de truc mais rien d’aussi vaste que les périphe tuya

@bernardfr.caron merci pour ce retour.
EDIT: je me réponds à moi-même en fonction de ce que j’ai compris après mise en pratique, au cas où cela intéresserait d’autres personnes…

Je me permet quelques questions pour être sûr de bien comprendre le mode de fonctionnement du plug-in au sein de l’écosystème Smartlife :

  1. le plug-in, une fois qu’un des équipements est connecté à celui-ci fonctionne-t-il en mode coupure par rapport au monde extérieur (le Cloud Tuya), i.e. l’équipement continue-t-il malgré tout de communiquer avec le Cloud Tuya?
    Réponse : le pilotage semble pouvoir se faire en parallèle via l’application SmartLife qui communique avec les équipements via le Cloud Tuya/SmartLife
  2. les communications de font-elles dans les 2 sens, i.e à l’initiative soit de l’équipement (pour pousser un changement d’état ou un évènement de type action, soit du Cloud Tuya (dans le cas où l’application Smartlife le pilote)?
    Réponse: j’ai l’impression que oui la communication se fait dans les 2 sens
  3. dans le cas où le périphérique ne connaît plus le Cloud Tuya, la mise à jour de son firmware est-il encore possible?
    Réponse: a priori le périphérique connait toujours le Cloud Tuya
  4. tant qu’il n’est pas supprimé de l’appli Smartlife et rajouté, l’équipement garde toujours le même token, c’est bien cela?
    Réponse : a priori oui comme indiqué dans la doc
  5. existe-t-il un état intermédiaire où l’équipement peut être à la fois piloté par l’application et par le plug-in ? Ou cela reste strictement exclusif? Dans ce cas à quel moment de fait cette passation de témoin pour piloter l’équipement?
    Réponse: pilotage en // pas exclusif
  6. l’application mobile doit- elle être forcément arrêtée pour que le plug-in puisse piloter les équipements ?
    Réponse : Non elle peut continuer de fonctionner pour pilotage via le Cloud
  7. j’ai une vingtaine d’équipements à migrer dois-je les migrer tous d’un coup dans ce cas?
    Réponse : non, cela peut et doit se faire les uns après les autres afin de détecter les commandes spécifiques à chaque type de matériel
    Merci d’avance pour ces éclaircissements ! De rien! :wink:
    N.B.: peut être profiter de ces réponses pour enrichir la documentation?
    Soit un chapitre d’introduction permettant d’appréhender les concepts, notions et principes de fonctionnement du plug-in, soit dans une FAQ.
    Cela permettra à ceux qui veulent s’y mettre de bien comprendre les tenants et aboutissants et donc les impacts suite à l’utilisation du plug-in.
    Je me permet cette remarque car j’ai vu dans l’un des post du forum que tu sollicitais les utilisateurs du plug-in à te faire part d’idées d’améliorations.

La doc du plugin est la plus lourde de tous les plugin et j’ai déjà eu la remarque qu’elle l’est trop.

La plupart des réponses aux questions sont dans la doc et pour les autres je ne sais pas.

Oui c’est vrai qu’elle est très riche (effectivement une des plus riche que j’ai pu parcourir parmi tous les plugin Jeedom, et c’est tout à ton honneur, et je comprend donc que tu renvoies systématiquement à la documentation lorsque tu as des questions) et que l’on peut parfois s’y perdre, c’est pour cela qu’il me semblait intéressant d’avoir quelques guidelines au début pour s’y retrouver plus facilement.
Mais je comprend que c’est déjà beaucoup de boulot de fait et que tu ne souhaites pas forcément réinvestir dessus maintenant.
En relisant certaines sections, je commence maintenant à mieux m’y retrouver, mais il est parfois nécessaire de relire plusieurs fois la documentation pour bien l’appréhender (en tout cas c’est le cas pour ma part) d’où mes nombreuses questions.
J’en profitais juste pour te donner mon retour d’expérience sur ce sujet si tu souhaitais améliorer un peu la doc.
En attendant, je continue à creuser la doc et je vous dis si je suis vraiment bloqué.

Bonjour @bernardfr.caron

je sollicite ton aide car je n’arrive pas à accrocher un de mes interrupteur Wifi.
J’ai désactivé tous les autres, redémarré le démon et j’ai ces traces:

>>>>Daemon Started
[2020-11-01 19:24:51][DEBUG] :    Memory used :2229 ko 280 o
[2020-11-01 19:24:51][DEBUG] : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Search for devices <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2020-11-01 19:24:51][DEBUG] : ****** Device listenable PC lumière salle à manger - Class:TuyaCustom_V2 @192.168.0.78Chanel:1 *****
[2020-11-01 19:24:51][DEBUG] :    Key not set
[2020-11-01 19:24:51][DEBUG] :    Socket created  @192.168.0.78
[2020-11-01 19:24:51][DEBUG] :    Connection impossible. Err=115 : Operation now in progress
[2020-11-01 19:24:51][DEBUG] :    ADD New device @192.168.0.78 channel:1
[2020-11-01 19:24:51][DEBUG] : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> End <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2020-11-01 19:24:51][DEBUG] :   Memory used :2337 ko 176 o
[2020-11-01 19:25:52][DEBUG] : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Search for devices <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2020-11-01 19:25:52][DEBUG] : ****** Device listenable PC lumière salle à manger - Class:TuyaCustom_V2 @192.168.0.78Chanel:1 *****
[2020-11-01 19:25:52][DEBUG] :    Key:0  time diff:61
[2020-11-01 19:25:52][DEBUG] :    Wait to update
[2020-11-01 19:25:52][DEBUG] : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> End <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2020-11-01 19:25:52][DEBUG] :   Memory used :2338 ko 640 o

La conf me semble bonne, tout est renseigné, je viens de récupérer le jeton via la technique Man In the Middle avec la commande tuya-cli list-app.

Et les traces avec le second switch identique qui lui passe à la connexion:

[2020-11-01 19:31:17][DEBUG] : ****** Device listenable Switch lumière garage - Class:TuyaCustom_V2 @192.168.0.71Chanel:1 *****
[2020-11-01 19:31:17][DEBUG] :    Key not set
[2020-11-01 19:31:17][DEBUG] :    Socket created  @192.168.0.71
[2020-11-01 19:31:17][DEBUG] :    ADD New device @192.168.0.71 channel:1
[2020-11-01 19:31:17][DEBUG] :    Device and socket exist : key:0 @192.168.0.71 channel:1 diff:0
[2020-11-01 19:31:17][DEBUG] : ****** Device listenable PC lumière salle à manger - Class:TuyaCustom_V2 @192.168.0.78Chanel:1 *****
[2020-11-01 19:31:17][DEBUG] :    Key not set
[2020-11-01 19:31:17][DEBUG] :    Socket created  @192.168.0.78
[2020-11-01 19:31:17][DEBUG] :    Connection impossible. Err=115 : Operation now in progress
[2020-11-01 19:31:17][DEBUG] :    ADD New device @192.168.0.78 channel:1
[2020-11-01 19:31:17][DEBUG] : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> End <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2020-11-01 19:31:17][DEBUG] :   Memory used :2353 ko 656 o
[2020-11-01 19:31:17][DEBUG] :    Update state @192.168.0.71
[2020-11-01 19:31:17][DEBUG] :     Cmd to 192.168.0.71 - Try:192.168.0.71  6668 - Connect OK!
[2020-11-01 19:31:17][DEBUG] :     Update state
[2020-11-01 19:31:17][DEBUG] :     Receive after decode :=

N.B. : je viens de reconnecter le second switch ce jour, j’ai du le réappairer avec SmartLife et donc mettre à jour le token.
Par contre SmartLife m’a demandé si je souhaitais mettre à jour le micro logiciel, mais je n’ai pour le moment pas accepté, je devrai peut-être finalement?

Une idée?
Merci d’avance

normalement ne fait pas de mise à jour.
Regarde ta version de firmware 1. ou 2. mais normalement maintenant tout est en 2. depuis longtemps.
la aussi l’err 115 : pas la bonne clé ou pas le bon id

1 « J'aime »

Merci @bernardfr.caron
Les micrologiciels de mes appareils semblent plutôt être en v1.0.6 par exemple sur l’interrupteur dont il est question ci-dessus.
Je n’arrive pas à obtenir la version du micrologiel de l’interrupteur qu’il me demande de mettre à jour, il me propose juste la version cible à mettre à jour. Comme c"est celle du second qui fonctionne, je pense que je vais la mettre à jour non?
Screenshot_20201105-191354_Smart Life|180x400
Screenshot_20201105-191329_Smart Life|180x400
Screenshot_20201105-191256_Smart Life|180x400

Pour la clef et le jeton, j’ai vérifié déjà 2 fois mais je ne! dois pas avoir les yeux en face des trous…
Je retente…! !

Bonjour à tous,
J’espere que vous allez bien
J’essaye de trouver la localkey d’un smart plug sur SmartLife, via iOS en utilisant l’application HTTP Catcher.
Autant le deviceID est assez facile a repérer, autant la localkey, c’est un peu plus tricky, vous connaissez le nom de la variable json qui donne cette fameuse key ??

Pour t’aider il faut nous donner des billes.
Je ne suis pas sûr que cette technique permette de récupérer les infos nécessaires.

Merci de ton retour rapide,
Le but est de pouvoir connaitre la consommation électrique d’une prise. Dans l’application SmartLife, j’ai bien la remonté d’info de consommation de la prise donc surement récupérable je pense (en tout cas j’espère).
De ce que j’ai pu lire du plugin WifilightV2 il est nécessaire d’avoir deux éléments :

  • Le DeviceID, ca easy a trouver :slight_smile:
  • La localkey, ou le token qui va bien
    C’est là que ca se complique un peu. Donc j’ai installé un proxy via l’applicaiton HTTP Catcher, installer le certificat pour récupérer les infos qui transites. Jusque là tout va bien, j’active le sniff du reseau et j’effectue les actions sur l’appli SmartLife lié à mon plug pour récupérer quelques trames.
    Je récupère bien des données en JSON, mais impossible de mettre la main sur ce jeton.
    Les infos remontées sont :
  • time
  • lang
  • deviceId (fastoche)
  • et
  • osSystem
  • BundleID
  • Ion
  • channel
  • appVersion
  • (je passe les trucs qui servent a pas grand chose …)
  • sid
  • sign
  • PostData
  • requestID
  • clientID (mais a priori non)

Du coup si qqun a une idée j’avoue que je suis bien preneur.

J’espere qu’avec ces infos il y aura un peu plus de matière