ça ne marche plus pour moi depuis hier
Résultat de la commande : Message: Error during authentication process. Please review your username/password Code: 0 Message: response didn’t contains code to get token probably due to an error in authentication process. Response : Code: 0
je n’ai rien touché !
suis-je le seul?
Mulb
Toujours fonctionnel chez moi.
Dans le mail reçu, une proposition pour accéder à un nouveau portail pour les développeurs : Viessmann Developer Portal Early Access
ah ok bon j’ai rempli ton formulaire. Merci pour l’info. Ceci-dit je me demande comment ils feront la différence entre le ViCare et une application tierce non officielle. Comme tout le code de l’application est disponible par décompilation on pourra facilement retrouver le token et au pire sniffer le réseau.
Bon ils ont communiqué dessus. Apparemment, ils bloquent les appels trop fréquent. Il suffit d’espacer de 15 minutes minimum les appels.
Exemple de cron pour faire un appel toutes les 20 minutes:
*/20 * * * *
Source:
Merci pour l’info.
A la réception de leur email j’avais changé la fréquence d’interrogation de 1 à 5 minutes.
Les valeurs se sont arrêtées aujourd’hui à 12h20. soit après ~150 requêtes/jour ou la mise en place de leur limite. 
Avec une relève toutes les 20 minutes, l’API perd beaucoup d’intérêt.
On ne va même plus avoir les démarrages du bruleur.
Les réactions au communiqué de Viessmann avec la mise en place des seuils sont plutôt négatives.
Je viens de passer à 20min ce qui fera 72 req/jour au lieu des 1440 avant.
La meilleure solution serait ce que vous leur avez demandé: une API locale.
Bonjour @thetrueavatar
Voici la réponse du serveur Viessmann à mes requêtes:
limitReset est en millisecondes. Ça sera à 17h 16’ 36" pour moi. J’ai eu un blocage hier à partir de 12h20 puis à 17h15 une seule requête a abouti. Cette unique dernière requête me bloque 24 heures.
Ce qui est intéressant est le nombre de requêtes autorisées par jour : 1450
Ça autorise l’interrogation de leur serveur chaque minute.
Reste à avoir le message équivalent pour la limite par quart d’heure. Je m’y atèle dès que je sors du blocage. A moins qu’il y ait un volontaire pour être bloqué 15 minutes (normalement) ou plus.
Faut que je vérifie mon code pour savoir comment je suis arrivé à la limite en interrogeant leur serveur toutes les 5 minutes.
Je ne fais qu’une seule requête pour tout récupérer:
https://api.viessmann-platform.io/operational-data/installations/$installation/gateways/$gw/devices/0/features
Edit: Trouvé pour mon blocage. J’avais modifié la fréquence de MAJ du virtuel et pas celle du script qui récupére les données. Et le script faisait 2 requetes par exécution.
oui j’ai remarqué aussi et je les ai interpellé à ce sujet. Le ban est beaucoup trop long et pas logique. En général, il est plus courant de demander une période de pause de minium x temps(exemple 30 minutes) avant de débloquer les requêtes. J’imagine qu’ils doivent encore affiner leur policy.
Attention que c’est une limite totale. Je récupère mes infos toutes les 5 minutes ce qui fait 168 call par jour. Le problème c’est que chaque appelle est comptabilisé et donc si on demande 10 infos ça fait 1680 et boum. je pense qu’il faut essayer de récupérer toutes les infos en un seul appel. J’ai demandé des précision sur quand est-ce que le compteur global est remis à 0 ar c’est pas clair. J’avais déjà envisagé ce cas pour ne pas surcharger leur serveur mais pas encore implémenté. Une façon via mon api de contourner le problème est d’utiliser getFeatures() qui renvoie toutes les informations en un seul appel et puis d’extraire les informations du gros json renvoyé.
C’est ce que fait mon script. ( basé sur votre travail. Merci)
Dans les tests que j’avais fait à l’époque, il était plus rapide de demander tout en une seule requête que de demander 1 info par requête dès que plus de 2 infos.
Avec le limitReset qui est un timestamp en ms, c’est clair.
Vous n’avez pas essayé d’obtenir le message d’erreur de la limite par quart d’heure?
Ce qui n’est pas clair c’est ce qui est comptabilisé dans le total de requêtes par jour. J’ai l’impression que les requêtes qui échouent sont aussi comptabilisés alors que je penserais que le compteur retourne à 0 une fois le ban fini. Ce n’est qu’une hypothèse. Je verrai quand mon ban sera levé à 17h20.
Ce que je leur reproche aussi c’est que leur design HATEOAS qui est censé permettre de rajouter des fonctionnalités à la volée pousse en théorie à naviguer dans l’api pas à pas comme dans le parcours d’un arbre. Du coup, il est normal d’avoir un nombre important de requête. On peut certes imaginer d’avoir un parcours des features dispo 1fois/jour max afin de détecter de nouvelle fonctionnalités et ensuite de faire un seul appel pour récupérer les fonctionnalités déterminées par cet appel par la suite.
Concernant mon api, j’imagine que je devrais pour la lecture d’information faire un seul appel ou l’utilisateur spécifie les features qui l’intéresse et extraire ces features de la réponse globale. Ca pourrait être une solution à mettre en place
Le mien sera levé 3 minutes avant.
Cette concordance des horaires me fait plutôt penser à la mise en service du seuil chez eux.
Pour réduire le nombre d’appels, je crois qu’il n’ y a pas d’autre solution que de tout récupérer et d’en extraire ce que vous avez besoin. De plus au-dessus de 2 infos, c’est plus rapide.
Voici la réponse:
I’m happy to provide you and all other user more concrete information on how the current restriction works:
We have a rate limit with sliding window. Whenever the first request arrives, we open a time window and count all request in that window. If the number of requests reach the limitation, we block all incoming user request until the time window ends. Then, with the next user request, a new time window opens.
Currently, we have two limits active:
120 calls for a time window of 10 minutes
1450 calls for a time window of 24 hours
We see these limitations reasonable, also based on your great explanation concerning cloud based services. So thank you for that!
Also, we decided against HATEOAS as it is deprecated and will sooner or later be switched off.
C’est cool. Je devrais pouvoir repasser à une maj toutes les 2 minutes ( pour avoir un peu de marge )
Ou faire une relève différente entre jour (1min) et nuit (5min).
Attention de ne pas chatouiller la limite des 120 requêtes en 10 minutes.
La punition est la même: ban de 24 heures.
Le message d’erreur est d’ailleurs strictement identique à celui pour la limite de 1450/jour
Perso me suis refait ban rapidement alors que j’ai désactivé mon cron. J’ai juste fait quelques tests manuel… Donc Il y a un truc qui cloche dans leur count de 1450/jour ou y a quelqu’un qui utilise mon compte(même si je vois pas l’utilité 
)…
J’avais cherché la limite. Une boucle faisant 122 requêtes pour voir le message de ban.
J’espérais que ça ne serait pas un ban de 24h
Hélas perso si je suis reban jusqu’à demain 17h…
17h44 pour moi.
World record !
Précédent ban jusque Tuesday, March 17, 2020 5:20:10.106 PM
Nouveau ban jusque Wednesday, March 18, 2020 5:23:42.988 PM
En gros, il m’a fallu 4 minutes pour me faire ban… Etonnant car je n’ai pas testé à 17h20… Bref ça pue le caca leur treshold…
J’ai fait un refactoring pour tenter l’utilisation d’une cache. C’est dispo dans la dernière version SNAPSHOT sur mon github.
Je l’ai fait un peu à l’aveugle vu que j’ai plus accès à mes données. Le changement est censé être transparent. Il y a un seul appel fait à l’instanciation du client et ensuite on stock en cache les résultats pour les appels suivants.
Si vous voulez revenir à la version précédente(un appel à chaque fois), il suffit d’éditer le bootstrap.php en mettant
$viessmannApi = new ViessmannAPI($params,false);
Vraiment pas au point leur système de ban.
Je vous ai battu. Retour au ban en 11s.
Je testais mon script pour avoir des messages de ban et ne pas perturber leur serveur.
J’ai récupéré des données 9s après la sortie de ban.
Et retour au ban aussitôt aprés.
Sortie demain à 17:44:21
ViCare HS aussi !
Vitotrol Plus que je n’ai pas encore désinstallé fonctionne encore.