Api Event/history

[henri-allauch]

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 

[Lazer]

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.

 

[henri-allauch]

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)

 

 

[Lazer]

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).

[henri-allauch]

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

 

[Lazer]

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.

[Krikroff]

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

[Lazer]

Oui tu as surement raison.

[henri-allauch]

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é 

[Lazer]

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.

 

[henri-allauch]

C'est un peu le principe de GEA Aussi pour capter les évènements ?

 

[Lazer]

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)

 

[henri-allauch]

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.

 

[Lazer]

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.

[henri-allauch]

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.

 

[Lazer]

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 :