saut (dans le polling) d'acquisition de donnée ?

[thrymartin]

Hello, une demande d'info

est ce que, pour un plugin à acquisition web, quand on a un saut dans l'acquisition des données
par exemple, plugin à 30', et on remarque que la valeur ne s'est pas mise à jour pendant 1h
(on peut le remarquer dans l'historique; mode "toutes les données" bien entendu)

(j'ai d'ailleurs 2 suggestions à ce sujet :
Améliorer le polling (étaler les actions)
Améliorer le polling (pas d'acquisition)

est ce que donc le script n'est PAS DU TOUT exécuté ?

je pense que c'est le cas, mais je préfère demander, ça ne coûte rien

merci, de rien

[thrymartin]

je me répond : le script n'est pas du tout exécuté
l'eedomus ignore complètement le polling et fait comme s'il n'avait rien vu, il passe son tour

quand ça arrive à un périphérique dans le réseau z-wave, s'il est à pile, on se dit que c'est la faute du périphérique (ça peut évidemment arriver et ce cas n'est pas du ressort de l'eedomus) , et s'il est sur secteur, on se dit que c'est le z-wave qui est encombré (?)
nada! puisque l'eedomus fait pareil en capteur web, c'est l'eedomus le coupable : s'il le fait en web, pas de raison qu'il ne le fasse pas partout !

la raison j'en sais rien, peut être qu'il cause avec le cloud et que pendant ce temps la, il est sourd ? en tout cas, je reste persuadé qu'il doit y avoir un moyen, ne serait ce que
- une interruption (informatiquement parlant) : au moins pour une mise en :
- une file d'attente (et traitement quand il a le temps, et sequentiellement jusqu'à réussite)
- plus basiquement, quand monsieur Eedomus veut bien se calmer et qu'il n'a rien de mieux à faire: un scan des capteurs et tous ceux qui ont dépassé le temps de polling de plus de x minutes, en commençant par le plus ancien

j'ai suggéré ça ici

ma preuve;
des données de cache non mises à jour indiquent que l'appel web n'a pas eu lieu, parce que s'il avait eu lieu et échoué, j'aurai eu une notification, et s'il avait eu lieu et réussi, le cache aurait été à jour