Incapacité de Diagral à nous donner un service cloud digne de ce nom

Bonjour,

J’ai analysé un peu il y a quelques jours.
Il semble que Diagral ai mis des quotas de requêtes. J’ai reçu il y a quelques jours cette réponse :

Le problème c’est qu’ils bloquent tout le compte donc même l’application eOne devient inutilisable. Surtout que j’avais remonté les seuils à 10 minutes minimum en accord avec eux et j’était bien à 10mn de refresh.

De mon coté, je vois que finalement, ils envoient toujours les emails, donc j’ai remonté mon refresh à 60 minutes et les mails me permette toujours d’avoir du temps reel. Depuis que je l’ai fait il y a quelques jours, je n’ai plus eu de problème (une fois que le quota revient a un niveau acceptable pour eux - niveau que je ne connais pas).

Alors ca amène plusieurs questions.
Actuellement ca passe par un cron Diagral_eOne:pull. Il est possible de lancer une désactivation et une réactivation de cette cron. Après, il faut connaitre le bon déclencheur.
Si je reprend ton exemple @arcameca, tu voudrais désactiver le refresh quand l’alarme est désactivé, ok le déclencheur c’est alarme en état désactivé. Mais quand tu voudras réactiver le refresh, cela ne pourra pas être sur le fait que l’alarme est active car sans refresh, tu ne le sauras pas.

Voici le code bloc à utiliser pour désactiver le refresh :

$cron = cron::byClassAndFunction('Diagral_eOne', 'pull');
//$scenario->setLog("Statut avant modification :".$cron->getEnable());
if ( is_object($cron)) {
  if ( $cron->getEnable() == 1 ) {
    $cron->setEnable(0);
	$cron->save();
    //$scenario->setLog("Statut après modification :".$cron->getEnable());
  } else {
    $scenario->setLog("Cron Diagral_eOne:pull already disabled");
  }
} else {
	$scenario->setLog("Cron Diagral_eOne:pull don't exist");
}

Voici le code bloc à utiliser pour réactiver le refresh :

$cron = cron::byClassAndFunction('Diagral_eOne', 'pull');
//$scenario->setLog("Statut avant modification :".$cron->getEnable());
if ( is_object($cron)) {
  if ( $cron->getEnable() == 0 ) {
    $cron->setEnable(1);
	$cron->save();
    //$scenario->setLog("Statut après modification :".$cron->getEnable());
  } else {
    $scenario->setLog("Cron Diagral_eOne:pull already enable");
  }
} else {
	$scenario->setLog("Cron Diagral_eOne:pull don't exist");
}

A toute fin utile si ca peut vous aider

2 « J'aime »

Bonsoir
Ils bloquent même tous les comptes, je pense, car sur Jeedom, j’ai un compte secondaire, et j’ai plein de soucis sur le compte principal

Bien chanceux. Il y a longtemps que je n’ai plus de mails, et je ne peux même plus configurer l’envoi de mails pour arrêt et mise en marche de l’alarme. Je n’ai que des notifications (et pas sur tous les équipements)

Ben, si les mails fonctionnent, ou si comme moi je peux récupérer les notifications, on est quand même prévenus de la mise en marche. Pour ma part, pour être sûr, je m’envoie un sms que Jeedom récupère. Il y a un décalage d’une ou deux minutes car le système d’envoi est pitoyablement lent via la centrale, mais au moins on a l’info.

Par contre, je ne vois pas ce que ça va changer car si le cron reste à 10 minutes, et que je m’absente la journée, que je réactive quand l’alarme est mise, quand je vais rentrer ça va être bloqué par trop de connexions.
Peut être faut il faire l’impasse sur les mises à jour toutes les x minutes pour garder un système opérationnel à la demande, en cas de besoin ?
Qu’en pensez vous ?

En effet, les blocs code peuvent permettre de supprimer les refresh lorsque l’on sait que l’alarme n’est pas active mais après, on revient à un refresh et donc si il est trop récurent ça va bloquer.

J’avais demandé à Diagral la possibilité de recevoir un webhook en cas d’activation/désactivation pour éviter les refresh. Mais ils m’ont dit que ce n’était pas dans leur roadmap.

Donc le seul moyen vraiment viable qui reste c’est de recevoir l’information SMS ou mail pour forcer un refresh. Et positionner un refresh auto a un delai espacé. 60 minutes marche pour moi mais 30 marcherait peut être aussi. A tester

Merci pour ta réponse et pour ton code que je vais tester.
Pour la réactivation, on a tous des badges bluetooth donc ce peut-être l’absence de badge par exemple.

Une première question sur ce point, dans mon cas, avec un refresh à 60 minutes j’ai toujours des erreurs du coup j’au voulu (avant ta réponse avec le bloc code) « supprimer » les mises à jour en mettant un délai de 1440 minutes dans les paramètres du plugin (24 heures donc) mais dans les logs je continue à interroger toutes les heures, 60 min c’est le délai max ?

Une seconde question (j’y connais rien en programmation, désolé si c’est une question bête), le délai aléatoire que tu ajoutes semble être entre 0 et 60 secondes.
Serait-il possible de l’allonger un peu pour que nous n’interrogions pas tous le serveur dans la même minute ou est-ce que ça agit comme un « sleep » dans un scénario et que ça pourrai poser des problèmes de ressources sur certaine machines ?

Merci.

Non je verifier juste qu’elle soit supérieur ou égale à 10.
Si tu as bien sauvegardé, ca a changer la valeur dans la cron

Alors c’est pas 60secondes mais 10 secondes. Et oui c’est comme un sleep. Donc ca laisse attendre le processus raison pour laquelle je l’ai laissé court.
Après il n’y a que 250 utilisateurs du plugin (c’est d’ailleurs peu selon Diagral pour investir vraiment dans une API, mais suffisant pour faire tomber leurs serveurs), donc ca fait 25 connexions par secondes en simultané. J’ose esperer que leurs serveurs sont en mesure de recevoir plus de 25 utilisateurs en même temps

1 « J'aime »

Hello
Il n’y a rien de certain. Leurs serveurs, peut être, mais s’ils ont sous traité la partie connexion sécurisée à une appliance, comme c’est souvent le cas si on ne veut pas investir dans du développement, alors ils sont peut être limités par une licence ?

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.