[Store] Radiateurs et interfaces Cozytouch

[Fafou69]

Bonjour,

je souhaite ajouter le script Cozytouch, je l'ai donc installé et lors du paramétrage des adresses de pièces ça ne fonctionne pas. je met nom d'utilisateur cozytouch (adresse mail) et MP, ça se connecte mais ça me met juste "liste des pièces"

J'ai loupé une étape ?
Merci pour vos retours.

[parabellum]

bonjour, il faut installer le script pour chaque radiateur.
lors de l'installation, il y a un lien "Cliquez ici pour lister vos pièces Cozytouch" qui permet de récuperer les adressses de vos radiateurs tels qu'il sont connu par la box cozytouch.

il suffit ensuite de reporter l'adresse d'un de vos radiateur dans le champ: "Adresse de la pièce"
puis de cliquer sur "creer" pour finaliser la création du premier radiateur.

[Fafou69]

Merci pour ton retour.
Il ne s'agit pas de radiateur mais d'une pompe à chaleur qui pour l'instant n'est donc pas sous eedomus.
quand je clic sur le lien , je me connecte mais je n'ai aucun lien qui s'affiche du coup.

[parabellum]

ah oui en effet, que les radiateurs...et encore, même pas les seches serviettes...que j'essaye d'ajouter mais pas si simple

[ARTNOW]

Bonjour , et si possible le chauffe eau thermodynamique

[P@t]

Salut à tous,

Alors, je débarque.. Je viens de passer 2h sur la modification du login, et je m'aperçois au moment de publier que ça a déjà été fait fait (et publié) par parabellum... Ben un grand merci à lui du coup
J'aurai du aller jeter un oeil sur le forum avant de m'y mettre!

[parabellum]

Salut à tous,

Alors, je débarque.. Je viens de passer 2h sur la modification du login, et je m'aperçois au moment de publier que ça a déjà été fait fait (et publié) par parabellum... Ben un grand merci à lui du coup
J'aurai du aller jeter un oeil sur le forum avant de m'y mettre!

De rien....et en même temps, je me dit que si tu as réglé le problème en seulement 2 heures, alors c'est que tu maitrises plus que moi.

[parabellum]

Plus sérieusement, je viens de mettre en ligne une nouvelle version 1.3.

Celle ci:
- corrige quelques bug
- permet d'avoir les mode, les etats et les consignes de températures qui s'actualise directement et non plus tard avec le polling.
- et surtout la gestion des sèches serviettes qui ne sont pas des radiateurs comme les autres au niveau des modes (manuel au lieu de basic, et mode été) , ainsi qu'avec des fonctionnalités supplémentaires comme le BOOST (soufflant) et le séchage.

évidement pour les seches serviettes, vous devrez réinstaller les radiateurs, par contre pour les autres une simple mise à jour suffira.
pour info, les nouveaux radiateurs installés auront un parametre de plus qui est le type de radiateur, mais je me suis justement débrouillé pour qu'en l'abscence de ce champ cela fonctionne aussi et ainsi vous éviter à tous de devoir tout réinstaller.

[P@t]

Ok super... de mon côté j'ai un soucis avec les actions simultanées (lors d'un changement de phase de journée par exemple avec plusieurs commandes envoyées en même temps à différents radiateurs).
J'avais mis en place le système de queue pour effectuer les actions les unes après les autres, mais parfois ça plante. Je vais donc changer le cache de l'identification car c'est ça qui a l'air de foirer. Désormais, à chaque appel du script, l'identification se fera (avec le jeton jwt en mémoire si possible).

EDIT: voilà, version 1.3.1 publiée

[parabellum]

ahhhhh....à mon tour de débarquer...you are THE "PATRICE", auteur d'origine du script ?

si c'est ça, c'est cool et tu pourras peut etre m'expliquer quelques lignes de code que je n'ai pas compris, comme les lignes 487/488 (pourquoi vider le cache ?)

Pour ton problème, je l'ai aussi constaté et j'ai passé un temps infini dessus pour en arriver à plusieurs constats problèmatiques:

- le premiere, c'est le même que toi, à savoir qu'un script qui s'arrete lorsqu'il détecte que d'autre ordres sont passé dans les 8 secondes qui suivent et ainsi de suite jusqu'au dernier ordre qui dépilera enfin la liste d'attente, risque de voir plusieurs ordres arriver à la même conclusion qu'il faut s'arreter en même temps alors qu'ils sont les derniers ordres et donc plus personne pour envoyer les ordres mis en file d'attente.

- le seconde est que le jeton d'authentification a une durée limitée, qui au depart est de une heure de memoire et si on interroge au bout de deux secondes , il reste deja moins de temps que prévu (je l'explique pas tres bien, ça serait plus simple de vive voix). bref, donc que se passe t il au bout d'une heure moins 1 minute si on demande de changer la température de plusieurs radiateurs...et bien il fait quelques action jusqu'au moment ou il se fait jeter car le jeton est périmé.

- le troisieme, et qui risque de te poser problème si tu enleve la file d'attente, est que le cloud cozytouch nous jete si on envoi 10 fois la meme demande dans la meme minute...et ça peut aussi arriver sur leur application...le fameux "quota exceeded"...resultat, on peut attendre une vie, obligé de se reconnecter pour pouvoir de nouveau acceder. je n'ai pas encore tester si avec 10 ordres différents, on se fait aussi jeté, mais ce qui est sur c'est que lorsque l'on demande de traiter un ordre, on recupere generalement les etats...avec la meme requete, quelque soit le radiateur sur lequel on souhaite recupèrer l'etat....parce qu'on recupere tout en fait....bref, l'enfer....il faudrait probablement repenser l'ensemble du script pour balancer les ordres (éventuellement sans depasser la cadence max ) et recuperer les etats une seule fois à la fin.

[P@t]

ahhhhh....à mon tour de débarquer...you are THE "PATRICE", auteur d'origine du script ?

Oui, c'est moi

si c'est ça, c'est cool et tu pourras peut etre m'expliquer quelques lignes de code que je n'ai pas compris, comme les lignes 487/488 (pourquoi vider le cache ?)

Aucune idée mais si je l'ai fait, c'est que je devais avoir une bonne raison! Ca fait longtemps que j'ai pas mis le nez dedans.

- le premiere, c'est le même que toi, à savoir qu'un script qui s'arrete lorsqu'il détecte que d'autre ordres sont passé dans les 8 secondes qui suivent et ainsi de suite jusqu'au dernier ordre qui dépilera enfin la liste d'attente, risque de voir plusieurs ordres arriver à la même conclusion qu'il faut s'arreter en même temps alors qu'ils sont les derniers ordres et donc plus personne pour envoyer les ordres mis en file d'attente.

Alors, non, ça en principe, ça ne peut pas arriver... Au bout de 8 secondes, il y a forcément un script qui sera en haut de la pile et qui s'exécutera. J'avoue que j'ai pas beaucoup commenté mon code, et que le fonctionnement est un peu tiré par les cheveux.

- le seconde est que le jeton d'authentification a une durée limitée, qui au depart est de une heure de memoire et si on interroge au bout de deux secondes , il reste deja moins de temps que prévu (je l'explique pas tres bien, ça serait plus simple de vive voix). bref, donc que se passe t il au bout d'une heure moins 1 minute si on demande de changer la température de plusieurs radiateurs...et bien il fait quelques action jusqu'au moment ou il se fait jeter car le jeton est périmé.

Je viens de modifier le script pour que le script refasse 3 essais de login en cas d'erreur (avec 3 secondes d'attente entre chaque essai).
J'ai aussi fait en sorte qu'une commande qui n'aboutit pas soit re-exécuter jusqu'à 3 fois (avec toujours 3 secondes d'attente entre chaque). Je publie ça ce soir.

- le troisieme, et qui risque de te poser problème si tu enleve la file d'attente, est que le cloud cozytouch nous jete si on envoi 10 fois la meme demande dans la meme minute...et ça peut aussi arriver sur leur application...le fameux "quota exceeded"...resultat, on peut attendre une vie, obligé de se reconnecter pour pouvoir de nouveau acceder. je n'ai pas encore tester si avec 10 ordres différents, on se fait aussi jeté, mais ce qui est sur c'est que lorsque l'on demande de traiter un ordre, on recupere generalement les etats...avec la meme requete, quelque soit le radiateur sur lequel on souhaite recupèrer l'etat....parce qu'on recupere tout en fait....bref, l'enfer....il faudrait probablement repenser l'ensemble du script pour balancer les ordres (éventuellement sans depasser la cadence max ) et recuperer les etats une seule fois à la fin.

Oui, ça malheureusement, c'est extrêmement compliqué à tester... Et c'est vrai qu'une refonte complète du plugin ne serait pas du luxe. Le problème, c'est qu'ils ne fournissent aucune doc, et c'est vraiment chiant à savoir ce qu'il faut faire ou ne pas faire. A l'époque, j'avais passé beaucoup de temps à décrypter les ordres envoyés par l'application cozytouch grâce à un "sniffer" de paquet. Malheureusement, le sniffer ne fonctionne plus sur mon téléphone.

[parabellum]

Merci P@t pour toutes ces explications.
par contre, je ne vois toujours pas la publication de ta nouvelle version....et ça m'interesse, car le script en l'état ne me donne toujours pas satisfaction, dans le sens où j'ai 13 radiateurs à la maison et si je demande un simple changement de température sur autant de radiateurs alors il y a forcement 2 ou 3 qui ne prennent pas l'ordre en compte. j'attends donc de voir si tu solution permet de corriger le problème. d'avance merci.

[P@t]

Désolé, j'avais complètement oublié!
Voilà, la version 1.3.2 est en ligne, dis-moi si c'est mieux...

[parabellum]

merci pour la mise en ligne.
alors après quelques tests rapides, je peux dire que c'est mieux clairement....mais, j'ai quand même réussi perdre quelques ordres.

bon déjà, analyser le retour de la demande de changement pour savoir si ça s'est bien passé est une tres bonne chose. faire d'autre tentative aussi, car même depuis leur appli, il arrive parfois (rarement , mais quand meme) que ça plante.

Par contre, qu'est ce que c'est lent...plusieurs minutes (7 min à 10 min) pour arriver à passer les derniers ordres... Sur ce coup là j'y suis peut etre pour quelque chose avec la volonté de vouloir récupérer l'etat final après l'envoi de la commande.
D'autant plus que je vois aussi des comportements chelou transitoire, du type: j'ai 20 degres, je demande 17....puis ça repasse à 20 dans l'appli eedomus avant de finir par etre de nouveau 17....et ça je pense savoir pourquoi....je cherche à récuperer l'etat apres l'envoi de la commande alors que coté cloud la commande est bien traité mais leurs données pas encore mises à jour....et ça colle avec ce que j'avais deja constaté en attaquant leur cloud avec un outil comme "postman"....en gros leur cloud met moins d'une demi seconde à repondre "ok, on a bien traité ton ordre", mais les valeurs des etats que l'on recupere avec le GET SETUP ne seront à jour que quelques secondes (parfois 10 sec) plus tard...donc je récupère les anciens état et pas les nouveaux.
Et parfois la mise à jour des valeurs des etats ne sont pas toutes en meme temps. exemple dans un changement de mode, l'etat du mode change puis plus tard la temperature se mettra à jour.

Bref, il faudrait peut etre abandonner cette idée de recuperer les nouveaux etats directement apres la commande et laisser simplement faire le pooling.

Pour valider cette théorie, je vais essayer de repasser un peu de temps pour attaquer leur cloud avec postman, histoire de bien définir au mieux leurs limitations....après on verra. et en attendant, cette version fera très bien l'affaire.

[Paga49]

Bonjour Parabellum, bonjour P@t,

Merci du travail que vous faites sur vos interfaces.
Personnellement, je n'utilise que le module Interface. Je rencontre aussi des problèmes de passage d'ordre depuis les dernières modifications. Il y a toujours 1 ou 2 radiateurs qui ne changent pas d'état . Les modifications que vous venez de faire sur le module Radiateur (ver 1.3.2) ne pourraient-elles pas être aussi appliquées sur l'interface (ver 1.1.2) ?

[parabellum]

Bonjour Paga49, désolé de ne pas avoir répondu avant.
pour répondre à ta question, oui il doit y avoir moyen de faire aussi quelque chose sur l'autre script par contre personnellement je n'ai pas du tout de temps pour ça en ce moment car je suis dans une periode de rush pro.
D'autre part, comme je le disais précédemment, la modif ralenti considérablement le script et n'est pas pour autant 100% efficace. j'ai donc commencé à voir pour reprendre completement le script, mais cela necessite beaucoup de temps...que je n'ai malheureusement pas en ce moment.
J'ai egalement dans l'idee de voir si c'est possible de fusionner les 2 scripts et ainsi de regler ton probleme.
pour résumer, je le laisse pas tomber ce sujet, mais j'ai aucune idee de quand j'aurai de la dispo pour ça. je vous tiendrai au courant ici de toute façon.

[Paga49]

Merci Parabellum pour ce retour.

[nvoron]

Bonjour @parabellum, je travaille côté Cloud chez Groupe Atlantic, j'ai également contacté Patrice, si tu veux nous pouvons nous caler un échange à propos du plugin. Je ne peux visiblement pas envoyer des MP, mais tu peux me contacter via ce biais

[P@t]

Je viens d'avoir Nicolas au téléphone, il m'a indiqué les problèmes à corriger sur le plugin.

@parabellum: je pense qu'il va falloir dans un premier temps supprimer les requêtes sdk_get_setup que tu avais rajoutées (qui récupèrent l'état et le mode de chaque périphérique) après chaque commande, car ça génère beaucoup trop de trafic de leur côté.

Concernant le jeton JWT d'authentification, je vais voir comment ne plus l'utiliser si celui-ci est périmé.

Enfin, concernant le polling, il va falloir le réduire à 10min.

[parabellum]

Bonsoir,
désolé de ne pas avoir pu être plus présent sur le forum...je suis débordé en ce moment.
J'avais commencé à voir pour refondre l'intégralité du script mais j'ai du mettre ça de coté.

j'ai cependant trouvé ce qui selon moi est l'un des problèmes principaux du script c'est à dire les temps de traitement de la fonction sdk_setup et plus précisément le temps necessaire à la convertion de la réponse json....en effet le fichier fourni en retour avec la liste de tous les parametres et les declaration et les valeurs possibles etc...est conséquent et la fonction sdk_json_decode met un temps important pour décoder tout ça...du coup on atteint souvent le timeout de la box eedomus qui kill automatiquement les scripts qui tournent encore apres 40 secondes.

donc oui, je suis en phase avec le fait qu'il faut mettre de coté (tout du moins pour le moment) l'idée de vouloir intérroger de nouveau apres un passage d'ordre.

j'avais dans lidée de voir si des appels API qui demanderaient les etats mais d'un seul périphérique serait mieux, car ça permettrait d'avoir des traitements beaucoup plus court.

sinon pour les jeton périmés j'avais aussi fait le constat que faire une première tentative de connexion avec un ancien jeton n'etait peut etre pas l'idée du siècle.
du coup j'ai commencé nouvelle fonction de connexion qui pour le moment s'authentifie à chaque fois et j'ai vu qu'il y avait un problème lorsque le jeton expire bientot. en effet dans ce cas , si on en demande un autre, alors il nous redonne le meme ...qui expirera toujours dans quelques secondes...il faut dans ce cas demander de le raffraichir....avec le refresh_token.

dans l'idée, ça donne ça

//Demande de token avec username/password
//---------------------------------------
$headers = array('Authorization: Basic czduc0RZZXdWbjVGbVV4UmlYN1pVSUM3ZFI4YTphSDEzOXZmbzA1ZGdqeDJkSFVSQkFTbmhCRW9h');
$data = array(
'grant_type' => 'password',
'username' => loadVariable('username'),
'password' => loadVariable('password')
);
$token = sdk_make_request($url_token, 'POST', $data, $headers);
//echo 'expires_in:'.$token['expires_in'].'<br/>';
//echo 'refresh_token:'.$token['refresh_token'].'<br/>';
//echo 'access_token:'.$token['access_token'].'<br/>';


//si le token expire bientôt (600 sec)
if (isset($token['expires_in']) and $token['expires_in'] < 600)
{
//demande de raffraichissement du token
//-------------------------------------
$headers = array('Authorization: Basic czduc0RZZXdWbjVGbVV4UmlYN1pVSUM3ZFI4YTphSDEzOXZmbzA1ZGdqeDJkSFVSQkFTbmhCRW9h');
$data = array(
'grant_type' => 'refresh_token',
'refresh_token' => $token['refresh_token']
);
$token = sdk_make_request($url_token, 'POST', $data, $headers);
}

//Demande de jeton avec le token
//------------------------------
$headers = array('Authorization: Bearer '.$token['access_token']);
$jeton = sdk_make_request($url_jeton, 'GET', null, $headers);
//echo 'jeton:'.$jeton.'<br/>';

saveVariable('jeton', $jeton);

//Demande de login avec le jeton
//------------------------------
$headers = array('Content-Type: application/x-www-form-urlencoded');
$data = array('jwt' => $jeton);
$login = sdk_make_request($url_login, 'POST', $data, $headers);
//echo 'login: '.$login['success'].'<br/>';