Discussion :

[Tomtom31]

Bonjour a tous !
Dans le cadre de l'intégration d'un robot aspirateur dans Domoticz (Domotique inside! ), je cherche a récupérer les infos sur l'état du robot (en charge, working ou encore le niveau de batterie).
Pour savoir comment tout se bazar communique on a lancé un petit coup de Wireshark. De ce que j'en vois, on dirait que la robot communique en TCP avec un serveur au Canada... Et que le robot balance des trames TCP contenant toutes les infos (batterie, type de buse aspirante, etc...).
Donc j'aimerai pouvoir "simuler" le questionnement du robot pour intercepter les infos qui sont envoyées... Mais je n'ai aucune idée de comment faire (je suppose que le routing TCP est hardcodé dans le robot et que je ne pourrai pas utiliser une autre IP pour communiquer avec mon robot... Mais ce peut se tenter...)
Merci d'avance pour votre aide !

[boboss123]

Salut,

Pourquoi n'installes tu pas tous simplement domoticz sur un PC pour pouvoir piloter ton appareil ?
https://www.ladomotiquepourtous.fr/2.../domoticz.html

[Tomtom31]

Hello
ce n'est pas du tout comme ça que ça marche. Domoticz n'est qu'une application dans laquelle tu centralise des matériels qui peuvent correspondre à des contrôleurs z wave des contrôleurs infrarouge etc... ensuite en fonction du niveau d'intégration tu peux faire différentes choses comme récupérer l'état de la batterie lancer des ordres pour démarrer des chaînes hi-fi des clims des télévisions etc.
dans le cas du robot aspirateur le problème c'est que tu transit par une application proscenic à installer sur mobile. Et que du coup pour pouvoir récupérer ces informations sur l'état de batterie les activités de cetera tu es obligé d'utiliser l'application proscenic. Tu as aussi une télécommande infrarouge qui te permet de lancer les activités du robot mais en aucun cas tu ne récupérera le statut du robot. D'où ma question sur l'interception des protocoles tcp qui transitent entre le robot et le serveur applicatif proscenic (je pense) pour pouvoir récupérer dans domoticz les informations de batterie d'État du robot et cetera qui ne sont disponibles nulle part ailleurs.

[boboss123]

Si Proscenic ne fournit pas d'API, il va falloir faire du retro engineering pour comprendre le protocole (en espérant qu'il ne soit pas crypté) et ensuite développer l'API pour Domoticz... donc il faut du temps et des connaissances en prog.
=> moi je commencerai par contacter Proscenic (et/ou fouiller sur leur site) pour savoir s'il n’existe pas une API

L'aspi communique en Wifi ? tu connais son adresse IP ? tu as déjà essayé d'entrer son adresse IP (locale) dans ton navigateur Web pour voir s'il n'y aurait pas un serveur Web d'intégré dans l'aspi (si c'est la cas, on pourrait peut etre recup les infos par HTTP... ce qui serait plus simple) ?
Tu es certain que c'est le traffic émis par l'aspirateur que tu captures et non pas du serveur distant ?... si tu peux fournir les fichiers .pcap, ça pourrait être pas mal pour que je vois à quoi ça ressemble (ne met dans la capture que les paquets qui contiennent l'adresse IP de ton aspi)

[Tomtom31]

Hello!

Ben on est clairement dedans.... L'avantage de la domotique c'est que plusieurs solutions sont possibles (exemple: je prévois de déclencher mon robot avec un émetteur IR connecté à mon serveur domotique). Car le robot peut aussi être piloté sans aucune connexion internet via une télécommande.

Mais si on pouvait intégrer une app (en l'occurence un plugin) spécifique dans un serveur domotique, ce serait le top (car l'IR c'est pas super fiable en terme de portée...)

Pour le moment, nos contacts avec le support Proscenic n'a pas donné grand chose (comprendre qu'on s'est gentiment fait envoyer promener...). Donc on creuse nous mêmes les différentes possibilités. A savoir que la "seule" option qui est proposée par Proscenic actuellement, c'est d'utiliser un skill Proscenic Robotics avec Alexa (dispo sur Amazon) pour commander le robot. Mais idem, impossible de mettre la main sur ce script (et il ne gère que le démarrage du robot, pas ses différents statuts)

Dans le détail du fonctionnement du bazar: Il faut obligatoirement utiliser une app dédiée (Android ou IOS) pour pouvoir:
- Envoyer la configuration de connexion au réseau wifi au robot
- Connecter le robot à l'application (donc créer un compte sur l'appli)
- Piloter le robot à distance (LAN ou WAN) et récupérer, au travers de l'appli, les statuts du robot dont je parle.

Pour le moment, de mes analyses des paquets Wireshark (dispo ici, qui ne sot pas les miens mais qui y ressemblent très fortement), il n'y a hélas par d'appel http. J'ai l'impression que la communication se fait en TCP (d'où ma demande) entre un server 47.91.67.181 et le robot.

CE que j'ai fait, c'est que j'ai sniffer mon smartphone lorsque je déclenche le robot par l'application. Dans les trames que j'ai sniffé avec NetCapture, il y a 2 transactions TCP. Une de 47.91.67.181 vers mon robot, et une autre du robot vers 47.91.67.181. Le flux retour (robot vers 47.91.67.181) est récurrent et contient toujours le même type d'info (niveau de batterie - "battery":"100"; type de buse d'apirateur - "brush":"1"; etc...).

Donc mon idée serait d'envoyer un trame à mon robot sur la même base que la première qui est envoyée, à savoir:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{"cmd":0,"control":{"authCode":"Authcod de l'appli?","deviceIp":"ipdurobot","devicePort":"portdurobot","targetId":"IDdurobot","targetType":"1"},"seq":0,"value":{"transitCmd":"100"}}

En espérant que le système embarqué réponde au serveur qui lui a balancé la requête (on sait jamais... Ils ont peut être prévu un mode failover de serveur pour pouvoir rediriger les communications si l'ip du serveur Proscenic venait à changer...)

[boboss123]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{"cmd":0,"control":{"authCode":"Authcod de l'appli?","deviceIp":"ipdurobot","devicePort":"portdurobot","targetId":"IDdurobot","targetType":"1"},"seq":0,"value":{"transitCmd":"100"}}

La bonne nouvelle, c'est que ça ressemble à un format JSON : tu devrais donc trouver des library assez facilement pour faire la conversion... par contre dans les captures, on peut voir qu'il y a une entête non codées en ASCII : et la ça va être marrant pour découvrir à quoi ça sert...
Donc si je comprends bien si le serveur tombe, tu ne peux plus communiquer avec ton aspi ? XD... en plus ça veut donc aussi peut-etre dire que le protocole aspi vers serveur n'est pas le même que le protocole server vers appli android (il faudrait donc aussi mettre un sniffer wireshark entre ton aspi et ta box internet).

[boboss123]

Il y a aussi la solution de faire un bot qui interagit avec l'appli android (on peut faire tourner une application android sur windows via bluestacks)... c'est peut être la solution la plus simple...

Sinon sur l'aspi, il n'y a pas de connectique permettant de le piloter (port série, USB, ...) ? ... peut-être qu'il existe une API pour le piloter par ce systeme (il faudrait après utiliser un convertisseur USB/port série vers bluetooth ou wifi)

A voir aussi si le produit ne répondrait pas en au SNMP.

Je ne vais pas pouvoir t'aider plus que ça

[becket]

Bonjour a tous !
je suppose que le routing TCP est hardcodé dans le robot

La route qu'un paquet prend ne peut pas être hard codé, la décision est prise indépendamment à chaque "saut".
Rien ne t’empêche de simuler son ip chez toi à la maison en configurant par exemple une interface sur ton routeur pour que le réseau ( ip/masque) de cette l'interface "tombe" dans ce réseau
Rien ne t’empêche non plus d'envisager de le faire au niveau DNS si nécessaire.

[Tomtom31]

@boboss123: Nan la solution la plus simple c'est d'utiliser l'appli en rang 2 c'est d'utiliser un émetteur IR... Car faire un bot android avec les interfaces de l'appli domotique... Ca va être galère!!!

Et non, aucune prise usb, aucune connectique... c'est étanche!

@becket: c'est ce que je pensais faire quand je parlais (en n'utilisant certainement pas les bons termes) quand je disais que je voulais "intercepter" les paquets...

Mais le coup du JSON de boboss123 m'a fait tilt.... Effectivement si on regarde les commandes qui partent... On pourrait presque reconstruire un appel Json (en plus Domoticz embarque du json de base):

http://domoticz-ip<:port>/json.htm?type=command&param=control&authCode="xxx"&deviceIp="yyy"&devicePort="zzz"&targetId="qqq"&targetType="1"

PAr contre, je pense que le seq est important aussi, car des analyses qu'on fait sur cette trame wireshark, la valeur de la "serpillère" a été changée:

"seq":0,"value":{"transitCmd":"145","waterTank":"60" ==> Modification serpillère débit d'eau faible
"seq":0,"value":{"transitCmd":"145","waterTank":"40" ==> Modification serpillère débit d'eau moyen
"seq":0,"value":{"transitCmd":"145","waterTank":"20" ==> Modification serpillère débit d'eau fort

Alors que:
"seq":0,"value":{"transitCmd":"100"} ==> Démarrage du robot

Par contre je connais pas d tout json, ni comment lancer un seq (est ce qu'il faut l'encapsuler, le lancer à part, le prévoir dans une lib json quelconque...)

[boboss123]

JSON, c'est juste un format textuel pour décrire un objet. C'est comme du XML mais avec une notation plus compact (ça ressemble beaucoup à la définition d'un objet en javascript) :

Un tableau :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"tab1":[1,2,3,4]

Un object :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"obj1":{"property1":"salut", "property2":"hello"}

Un tableau d'objet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"tab1":[{"property1":"salut1", "property2":"hello1"},{"property1":"salut2", "property3":"hello2"}]

[boboss123]

Donc ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"seq":0,"value":{"transitCmd":"100"}

ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
variable seq = 0
objet value :
  - propriété transitCmd = 100

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
"seq":0,"value":{"transitCmd":"145","waterTank":"60"}

=> remarque : dans ton exemple, il manque l'accolade à la fin pour que le JSON soit valide

ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
variable seq = 0
objet value :
  - propriété transitCmd = 145
  - propriété waterTank= 60

[boboss123]

PAr contre, je pense que le seq est important aussi, car des analyses qu'on fait sur cette trame wireshark, la valeur de la "serpillère" a été changée:

"seq":0,"value":{"transitCmd":"145","waterTank":"60" ==> Modification serpillère débit d'eau faible
"seq":0,"value":{"transitCmd":"145","waterTank":"40" ==> Modification serpillère débit d'eau moyen
"seq":0,"value":{"transitCmd":"145","waterTank":"20" ==> Modification serpillère débit d'eau fort

Alors que:
"seq":0,"value":{"transitCmd":"100"} ==> Démarrage du robot

Donc a priori la propriété transitCmd défini le type d'action à réaliser et peut être suivit d'une (ou plusieurs ?) autre propriété dépendant de l'action désirée
seq doit surement permettre de définir le numéro de la séquence

[Tomtom31]

Hello

Merci pour les explications. Du coup je vais voir pour essayer de me faire un Json avec l'ensemble des informations que j'ai pu voir dans la trame Wireshark?

Grosso modo ca donnerai un truc du style (pour l'allumage du robot, dans e message #5):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
variable cmd = 0
  - propriété authCode = xxxx
  - propriété deviceIp = 192.168.1.X
  - propriété devicePort = 1234
  - propriété targetId = yyyyy
  - propriété targetType = 1
variable seq = 0
objet value :
  - propriété transitCmd = 100

Pour avoir:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{"cmd":0,"control":{"authCode":"xxxx","deviceIp":"192.168.1.X","devicePort":"1234","targetId":"yyyyy","targetType":"1"},"seq":0,"value":{"transitCmd":"100"}}

Avec quelques cases pour gérer les différentes commandes (genre le débit de la serpillère, gestion des zones, etc..).

EDIT: Euh, mais je me pose une question... Mettre ça dans un fichier json, c'est bien... Mais comment je balance ça en TCP à mon robot? Je peux le tester en unitaire avec mon PC et Packet Sender (pour vérifier que ca lui suffit). Si tel est le cas, juste avec un IO pour lui balancer le contenu du json?

[Tomtom31]

Hello,

Bon, test fait avec Packet Sender... Et il ne se passe rien...

Pourtant j'ai l'impression qu'il répond (je reçois une trame, mais qui ne contient rien).

[boboss123]

Je croyais que tu savais injecter un fichier JSON dans ton robot XD

Pour :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://domoticz-ip<:port>/json.htm?type=command&param=control&authCode="xxx"&deviceIp="yyy"&devicePort="zzz"&targetId="qqq"&targetType="1"

"domoticz-ip<:port>" fait référence à ton aspi ou au serveur ? ... si c'est ton aspi, tu peux peut-être envoyer tes infos via l'URL

ça ne marcherait pas un truc de ce style (exemple pour modifier le débit d'eau à 60) ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://domoticz-ip<:port>/json.htm?type=command&param=control&authCode="xxx"&deviceIp="192.168.1.X"&devicePort="1234"&targetId="yyyyy"&targetType="1"&transitCmd="145"&waterTank="60"

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://domoticz-ip<:port>/json.htm?type=command&param=control&authCode="xxx"&deviceIp="192.168.1.X"&devicePort="1234"&targetId="yyyyy"&targetType="1"&type=seq&param=value&transitCmd="145"&waterTank="60"

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://domoticz-ip<:port>/json.htm?type=seq&param=value&transitCmd="145"&waterTank="60"

=> si ça marche, après tu pourras faire des scripts via cURL (ou autre)


Par contre dans tes exemple il y a la variable "deviceIp" : elle sert à quoi exactement vu qu'il faut connaitre l'adresse ip de ton aspi pour pouvoir le contacter ?

[Tomtom31]

Hello,

L'adresse

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://domoticz-ip<:port>/json.htm?

c'est le serveur domotique. Je ne suis pas sur qu'il sache interpréter des commande Json maison (il sait envoyer/récupérer des informations sur ce qui est paramétré sur le serveur, mais de là à lui demander de balancer des requêtes Json n'importe où, j'ai un doute...)

D'où ma tentative de balancer directement la requête Json via packet sender à mon robot...

A la lecture de la page (pour d'autres projets sur mon serveur domotique), les api doivent être dispo que pour les fonctionnalité inhérentes au serveur:

https://www.domoticz.com/wiki/Domoti...L&#39;s#Format

Et concernant le deviceIP et devicePort, dans le wireshark (d'un autre modèle de la même marque), l'info n'est pas renseignée, mais sur le mien elle l'est (et correspond à l'ip de mon robot). LE retrocoding a parfois ses limites

[Tomtom31]

pas mal de tests faits, sans succès hélas...

[boboss123]

Là ça devient compliqué... surtout que si ça se trouve, c'est l'aspi qui interroge régulièrement le serveur Proscenic pour récupérer les commandes à exécuter (tu ne pourras donc pas initialiser une transaction si ton PC n'est pas vu comme étant le serveur Prosonic... pour que ton PC soit vu comme tel, il faudrait créer une entrée dans le serveur DNS pour que l'url du serveur Proscenic pointe sur l'adresse IP de ton PC... ensuite il faudra créer le prog sur ton PC ce qui devient beaucoup plus compliqué XD).

[Tomtom31]

Je lache pas le morceau!!

En fait, après pas mal d'échanges avec d'autres mecs qui se sont arrachés les cheveux aussi.... Lorsqu'on lance l'application sur le téléphone, il y a une "authent" qui est faite sur un serveur (celui de Proscenic EU (qui est au canada...). Dans ces échanges, en http, pleins (pour pas dire toutes) d'informations snt récupérées, allant même jusqu'au lien vers le shop, et des icones de l'appli!!

Parmi tout ce bazar, il y a notamment un cookie Json (durée de vie de 2 jours) qui permet de balancer les requêtes en TCP au robot.

Donc je travaille plus en "amont" pour valider la synthaxe, récupérer le cookie et ensuite balancer les requêtes json (je confirme que c'est bien du json qui est appelé). Donc en ce moment, je fais des synthaxes POST sur le serveur pour vérifier que tout fonctionne correctement et pour le moment c'est pas trop mal... Restera plus qu'à voir le lancement des requêtes TCP e fin de chaînes (qui devient presque anodin maintenant... :/)

[boboss123]

J'ai du mal à comprendre toute la transaction :
- Il contient quoi ce cookie JSON ?
- Pourquoi l'aspi se connecte au serveur Proscenic ? C'est le serveur qui initialise la transaction ou l'aspi ?
- Quand tu commandes ton aspi via le tel : le tel communique directement avec l'aspi ou il envoie les infos au serveur qui ensuite envoie les infos à l'aspi ?
- l'authent c'est juste pour que l'appli ait le droit de se connecter au serveur ?