Aller au contenu
henri-allauch

Api Event/history

Recommended Posts

On récupère les éléments antérieurs à lastId alors qu'on devrait les ignorer et retrouver les plus récents non ?
Exemple : 
http://192.168.1.53/api/events/history?eventType=DevicePropertyUpdatedEvent&lastId=1502913&numberOfRecords=5

[
{"data":{"id":136,"newValue":22.38,"oldValue":22.31,"property":"value"},"id":1502911,"objects":[{"id":136,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291395,"type":"DevicePropertyUpdatedEvent"},
{"data":{"id":135,"newValue":26.69,"oldValue":26.75,"property":"value"},"id":1502909,"objects":[{"id":135,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291394,"type":"DevicePropertyUpdatedEvent"},
{"data":{"id":130,"newValue":30.56,"oldValue":30.62,"property":"value"},"id":1502907,"objects":[{"id":130,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291393,"type":"DevicePropertyUpdatedEvent"},
{"data":{"id":129,"newValue":31.31,"oldValue":31.38,"property":"value"},"id":1502905,"objects":[{"id":129,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291392,"type":"DevicePropertyUpdatedEvent"},
{"data":{"id":127,"newValue":29.75,"oldValue":29.81,"property":"value"},"id":1502903,"objects":[{"id":127,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291391,"type":"DevicePropertyUpdatedEvent"}
]

Dans le swager c'est pareil 

Pourtant : 
requests with id<=lastId will be skipped (only more recent entries then lastId will be returned)

Quelques chose m'échappe 

Partager ce message


Lien à poster
Partager sur d’autres sites

Effectivement, la doc du swagger semble erronée, mais le comportement en revanche est logique.


Avec numberOfRecords tu récupères les N derniers événements par rapport au moment spécifié (avec lastId).

Si lastId n'est pas spécifié, alors c'est le tout dernier.

 

L'idée, est de coller au fonctionnement du panneau d'événement de la HC3.

D'abord, on affiche les N derniers événements (afin de remplir la page)

Si l'utilisateur scrolle la page, alors on cherche les N événements précédent le dernier ID connu.

Etc... cela permet de scroller indéfiniment, et de remonter dans l'historique.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

En fait je m'en suis rendu compte car je voulais journaliser en externe quelques éléments particuliers au fil du temps. 

Comme tu le dis le lastId c'est utile pour remonter dans le temps.

Donc pour réaliser cela, j'utilise le timestamp le plus élevé (récent)  du json récupéré pour l'ajouter à la requête suivante par ......&from=" .. tostring( timestamp + 1)

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui, je comprends, en fait tu cherchais une logique similaire à /api/redreshStates

 

Les 2 ont un comportement inversé :

  • /api/events/history permet de remonter dans le passé
  • /api/redreshStates permet de suivre les nouveaux événements au fil de l'eau

 

Du coup, n'est-ce pas refreshStates que tu aurais dû utiliser pour ton application ?

Même si tu as trouvé une solution de contournement avec les timestamps from, cela me parait moins précis, car tu peux avoir plusieurs événements au même timestamp (pendant une seconde, c'est long).

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui mais comme j'utilise déjà /api/redreshStates pour lancer des fonctions de QA. ( ça me remplace les trigger de scènes ) et je ne voulais pas alourdir ce code. 

 

Disons que J'ai voulu essayer avec autre chose .. de plus c'est un QA un peu marginal .

Les événements retournés sont limités par un filtre sur eventType lors de l'api.get. j'en demande numberOfRecords=100  et si #events > 100 - Warning Pour le moment j'en ai entre 2 et 30 par requête toute les minutes;

 

Mais dans le principe tu as raison chacune de ces deux api à une fonction logique spécifique

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Théoriquement tu pourrais avoir plusieurs QA qui exploitent l'api refreshStates.


Je ne sais pas quel serait l'impact sur la charge système, je manque encore de recul.

Partager ce message


Lien à poster
Partager sur d’autres sites

Je suis convaincu que le refreshState n’a pas était désigné pour ça, sans prendre en compte les contraintes de disponibilité ou de charge. L’idée à la base c’était la mise à jour de l’ interface web pour 2 ou 3 sessions simultanées lors de consultations et donc pas 24/24... Maintenant la machine en a sous le capot alors ça va passer mais bon.


Envoyé de mon iPhone en utilisant Tapatalk

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui tu as surement raison.

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 17 heures, Krikroff a dit :

Je suis convaincu que le refreshState n’a pas était désigné pour ça,

Ce message concerne le message de @Lazer

Citation

Théoriquement tu pourrais avoir plusieurs QA qui exploitent l'api refreshStates.

Ou le fait d'avoir un QA avec  un appel cyclique à /api/redreshStates pour lancer des fonctions de QA suivant l'évènement attendu et détecté 

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui tout à fait, c'était le principe lancé par @jang avec son Webhook QD

Probablement plus efficace.

Mias l'appel de fonction entre QA ce n'est pas neutre non plus, j'imagine que si un seul QA passe son temps à appeler en permanence des fonctions des autres QA, cela doit avoir un cout CPU non négligeable.

Mais là aussi il faudrait benchmarker le comportement en charge.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

J'osais pas te parler de GEA ;)

Mais la petite différence, c'est qu'il traite tous les événements en interne, sauf exception (puisqu'il peut aussi appeler d'autres QA)

 

Partager ce message


Lien à poster
Partager sur d’autres sites

OK je comprend la difference avec GEA, donc c'est le plusieurs QA avec refreshState qui fait réagir @Krikroff, et pour toi c'est l'appel d'un QA vers des fonctions d'autres QA  qui pourrait être gourmand en CPU

 

J'ai enregistré un petit diag : ce qui est sur c'est que /api/events/history  est gourmand.

 

2078355559_Capturedecran2021-05-07a18_41_30.thumb.png.09f64512bf887b158a90ad37fa0510c3.png

Partager ce message


Lien à poster
Partager sur d’autres sites

Je pense quand même que plusieurs QA qui utilisent refreshStates, c'est plus consommateur de ressource qu'un seul QA avec refreshStates qui ferait des appels vers les autres QA.

 

Je te confirme que /api/events/history est très gourmand (*), car j'ai justement mis à jour le QA Evénements la semaine dernière avec cette nouvelle API, et ma consommation CPU a fait un bond (d'environ 0.5%, ça peut paraitre peu, mais sur le graph hebdo, ça fait un palier clairement visible).

Hier soir j'ai optimisé autant que possible ce QA, et j'ai gratté entre 0.1 et 0.2% de CPU.

 

Mon graph est avec DomoCharts, donc la résolution est de 1 minute, on ne voit donc pas les pics comme sur ton graph en temps réel.

Cela dit je n'aime pas du tout ce graph temps réel, car il représente à lui tout seul la moitié de ce qu'il affiche.... du coup pas facile de savoir si on regarde la consommation CPU de ses propres modules, ou bien de la page qui génère le graph. Un comble !

 

(*) Ce qui est gourmand avec cette API, c'est qu'on récupère une grosse table avec plein d'événements, qu'on doit ensuite parcourir... donc ça utilise pas mal de RAM et des cycles CPU. Mon QA faisait parfois des pointes à plus de 5 Mo de RAM utilisée. Après l'optimisation d'hier, je reste limitée dans la zone des 4 Mo. Bien sûr en pointe, après le garbage collection il redescend à 500 ko environ. Néanmoins le QA Evénement est mon QA le plus consommateur de RAM.

  • Thanks 1

Partager ce message


Lien à poster
Partager sur d’autres sites

En plus moi j'ai collé un sort de la table ... 

 

Je vais regarder de près tes analyses de memoire comme dans tes QA Domocharts ou NetworkMonitor pour aider à optimiser mes codes.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Attention aux opérations sur les tables, c'est très gourmand en CPU et en RAM.

 

Je t'invite à aller discuter de ce sujet sur ce nouveau topic :

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

×