donc ce que j’ai découvert : tous ce passe en udp
la première requête est immuable, elle sert a avoir les infos de l’ibox 1/2 :
20 00 00 00 16 02 62 3A D5 ED A3 01 AE 08 2D 46 61 41 A7 F6 DC AF D3 E6 00 00 1E
a cette requête on a une réponse de l’ibox du style :
28 00 00 00 11 00 02 FF FF FF FF FF FF XX XX XX XX XX XX ID ID 00
les 7 premiers bits ne bougent pas, les 6 bits FF sont la mac adresse de l’ibox, les bits XX ne bougent pas non plus (je ne sais pas ce que c’est ), les bits ID sont les identifiants de la session et les 00 a la fin ne bouge pas non plus.
pour envoyer une action il faut une requête comme ça :
80 00 00 00 11 ID ID IC IC XX 31 00 00 08 04 02 00 00 00 ZZ CS CS
les 5 premiers bits sont immuable, les 2 ID sont a reprendre de la reponse a la première requête, IC sont un incrément avec un +1, le XX je ne sais pas ce que c’est, à partir de 31, c’est la commande : ça commence toujours par 31 00 00 08 (pour action de lumière) et aprés l’action :
-04 01 00 00 00 on
-04 02 00 00 00 off
-05 00 00 00 00 active blanc froid
-etc
ensuite Z pour la zone (1,2,3,4 ou 0 pour toute zone) et pour finir CZ pour le checksum (addition de la commande et la zone : 31+00+00+08+04+01+00+00+00+01(zone) = 00 40 en hexa
si la commande est exacte on a un retour de l’ibox qui commence par 88 00 00 03, aprés c’est les 2 bits IC et pour finir 00
pour le reste je suppose car je n’ai pas le soft pour vérifier plusieurs commandes d’affilées :
pour un blanc a 50% par exemple :
allumer lampe
envois : 20 00 00 00 16 02 62 3A D5 ED A3 01 AE 08 2D 46 61 41 A7 F6 DC AF D3 E6 00 00 1E
retour : 28 00 00 00 11 00 02 FF FF FF FF FF FF XX XX XX XX XX XX ID ID 00
recup des id et créer IC (=00 01), on précise la zone et on calcul le checksum
envois : 80 00 00 00 11 ID ID IC IC 00 31 00 00 08 04 01 00 00 00 ZZ CS CS
Retour : 88 00 00 00 03 IC IC 00
la lampe est allumée
passe en blanc
envois : 20 00 00 00 16 02 62 3A D5 ED A3 01 AE 08 2D 46 61 41 A7 F6 DC AF D3 E6 00 00 1E
retour : 28 00 00 00 11 00 02 FF FF FF FF FF FF XX XX XX XX XX XX ID ID 00
recup des id et incrémente IC (ic+1), on précise la zone et on calcul le checksum
envois : 80 00 00 00 11 ID ID IC IC 00 31 00 00 08 05 64 00 00 00 ZZ CS CS
retour : 88 00 00 00 03 IC IC 00
La lampe est en blanc
Dimmer a 50%
envois : 20 00 00 00 16 02 62 3A D5 ED A3 01 AE 08 2D 46 61 41 A7 F6 DC AF D3 E6 00 00 1E
retour : 28 00 00 00 11 00 02 FF FF FF FF FF FF XX XX XX XX XX XX ID ID 00
recup des id et incrémente IC (ic+1), on précise la zone et on calcul le checksum
envois : 80 00 00 00 11 id id ic ic 00 31 00 00 08 03 32 00 00 00 zz cs cs
retour : 88 00 00 00 03 IC IC 00
La lampe est à 50%
il faut une courte pause entre les envois sinon l’id saute de temps en temps
la lampe garde les derniers paramètres a l’extinction donc avant d’eteindre la lampe un dimmer a 0 permet de palier la transition violente a l’allumage a 50% (0%->50% au lieu de 100%->50%)
et je pense qu’il faut prioriser les commandes :
je pense que le code de l’ipx pour le milight est assez approchant de l’api v6 mais en priorisant les commandes comme citées plus haut, en mettant le dimmer à 0 avant la commande d’extinction et en faisant une courte pause entre les commandes je pense que ça peut être parfait