Aller au contenu

Messages recommandés

Posté(e)
Le 11/04/2020 à 00:24, jjacques68 a dit :

plus de 20 000 enregistrements en 7 heures !!

 

hé bé... ça travaille sévère la dedans...

alors avec le status des device, je dépasse les 100 000 lignes en 24 heures !!!

c'est dingue comme ça travaille dans cette petite boite !

 

J'ai mis des filtres en place, sinon j'explose la base.

Surtout que certaines infos n'étaient absolument pas utiles...

 

Par contre en analysant les données, y a des trucs étranges... je sais pas si ça vient de ma programmation (sans doute), faut que je regarde de plus près.

 

Par exemple

des méthodes lancées sans raisons ???? en moyenne toutes les 30 minutes (j'ai aucun souvenir d'avoir programmé ça !!)

- lors de l'allumage/extinction d'une lumières (et que les lumières) j'ai une double saisie dans l'historique (mais ce n'est pas visible dans la page "History", que dans l'API).

   Et j'ai bien 2 ID différent dans l'API pour ce doublon d'informations (ça vient pas de mon système...)

 

Posté(e)
Il y a 5 heures, jjacques68 a dit :

100 000 lignes en 24 heures

Cela ne fait qu'environ 1 message par seconde.

Dis autrement, la box se tourne les pouces ;)

 

Ce qui serait plus judicieux, c'est de monitorer l'usage du Z-Wave. Car si tu as également 1 trame par seconde, c'est clairement trop (risque de congestion du réseau, avec perte de trames... donc réémission de trames, donc latences à l'exécution des ordres)

Je ne sais pas si la scène Z-Wave monitor qui avait été partagée sur le forum officiel fonctionne sur la HC3, mais ça serait très intéressant.

Posté(e)
il y a 30 minutes, Lazer a dit :

Z-Wave monitor

Je sais pas faudra que j'essaye...

 

il y a 29 minutes, Lazer a dit :

Car si tu as également 1 trame par seconde

après concernant les "Lignes", faut dire aussi, que je récupère par exemple toute les 3 secondes les infos d'un ECO-DEVICE et la nuit quand l'alarme tourne c'est une trame par seconde que je récupère...

Sans parlé de l'échange que j'ai entre l'IHM perso et la box....

Tout ça, sont des "lignes" qui ne sont pas de la communication Z-Wave...

 

Pour le moment je ne constate pas latence dans les device Z-Wave...

Au contraire, elle est plutôt réactive !

 

Mais justement, je fais tester en créant un "mode poursuite" avec les caméra.

j'avais essayé sur la HC2, ça marchait, mais alors le temps que tu passes d'un PIR à un autre, la camera avait pas encore bougée :) 

on verra...

 

 

  • Like 1
Posté(e)

Concernant la méthode, je serais curieux de savoir les ressources mobilisées pour mettre en musique tout cela , ce n’est pas raisonnable si tu veux mon avis de faire des appels sur ton QA mutualisé, l’idée n’est pas mauvaise mais dans ce cas de figure l’architecture retenue n’est selon moi pas la bonne et d’ailleurs l’impossibilité de nous appuyer sur des fonctionnalités natives du logger me semble rédhibitoire pour des questions de performances générales...

> ce point me semble éligible à une demande d’amélioration continue pour Fibaro

Au delà de ça.

Déformation professionnelle: Je ne vois toujours pas la nécessité de log l’intégralité des messages dans une base externe, à la limite oui pour les messages du type « error » et encore... Je reste persuadé que 90% de tes logs portent sur des éléments non critiques.

Il faut log à outrance en phase de conception ou lorsqu’un composant présente des comportements erratiques ou lorsqu’il y a des obligations: audits etc..

Ce n’est que mon point de vue et je ne cherche à convaincre personne ;)


Envoyé de mon iPhone en utilisant Tapatalk

  • Like 2
Posté(e)
Il y a 2 heures, jjacques68 a dit :

Mais justement, je fais tester en créant un "mode poursuite" avec les caméra.

j'avais essayé sur la HC2, ça marchait, mais alors le temps que tu passes d'un PIR à un autre, la camera avait pas encore bougée :) 

on verra...

et bien c'est nickel !!!

juste dommage que les caméras ne peuvent pas bouger plus vite... suis déjà au max avec la vitesse...

Mais niveau réactivité de la BOX (déclenchement d'une scène par les PIR, envoi de la requete HTTP pour faire bouger la caméra (à travers un QA) ...) , y a rien a dire !!

Posté(e)
Il y a 2 heures, Krikroff a dit :

ce n’est pas raisonnable si tu veux mon avis de faire des appels sur ton QA mutualisé

 

Comme tu dis, j'ai 1 QA qui envoi les données en base.

Et plusieurs autres (enfin 2) qui utilisent justement CE QA.

ça fonctionne bien ! (de ce que je constate)

Ensuite faut pas oublier que je passe par une variable de type tableau qui me sert de tampon...

Mes 2 QA ne font que remplir cette variable tableau.

LE QA de gestion de la socket s'occupe juste d'envoyer le contenu de ce tableau !

Je sais pas, y a rien qui me choque ! ça devrait ??

 

Maintenant côté performance, capabilité de la box, je m'y connais pas assez pour de dire si c'est bon ou pas...

A mon niveau, ça à l'air d'allé...

 

pour info :

j'ai franchi un autre cap avec les socket, où j'utilise maintenant le READ (toujours dans le même QA de gestion de la socket).

en effet depuis mon soft IHM, au lieu d'envoyer les ordres par requête HTTP à la HC3 pour actionner les device, je transmet l'ordre au QA via la socket.

Et c'est lui qui fait les actions sur les device. Je sais pas si je me suis fait comprendre...

Et bien je trouve que je gagne en réactivité par rapport aux requêtes HTTP.

Donc CE QA fait l'envoi et la lecture simultanément, comme des thread...

il a l'air d'encaisser :) 

 

Il y a 2 heures, Krikroff a dit :

Je ne vois toujours pas la nécessité de log l’intégralité des messages dans une base externe

Honnêtement c'était pour le fun... Et ça marche super c'est bien.

c'est nickel pour comprendre pourquoi tel ou tel truc c'est mal passé.

J'ai déjà plus que divisé par 2 les informations stockées en filtrant à la source (sur la HC3).

Posté(e)
il y a une heure, jjacques68 a dit :

Je sais pas, y a rien qui me choque ! ça devrait ??

:huh: désolé j'espère que je ne t'ai pas chatouillé avec mes propos, le problème c'est que j'ai tellement vu de systèmes instables quelques mois/années après en raison de choix motivés principalement par le "c'est bon y'en a sous le pied" encore une fois juste une déformation pro et je cherche à convaincre personne. Tu es un utilisateur expérimenté et indéniablement passionné et pugnace, je dis cela sans arrières pensées bien au contraire ;).

il y a une heure, jjacques68 a dit :

Et bien je trouve que je gagne en réactivité par rapport aux requêtes HTTP

Je n'en doute absolument pas.

Posté(e)
à l’instant, Krikroff a dit :

désolé j'espère que je ne t'ai pas chatouillé avec mes propos

non non pas du tout !! t'inquiète pas !!

ça m'intéresse de comprendre un peu plus en profondeur les choses !

 

Les avis, connaissances, conseils sont toujours bon à prendre...

 

:) 

  • 10 mois après...
Posté(e)

Mettre un focus sur le mot "XXX" fonctionne sur le theme écran mode clair mais pas sur un theme écran mode Noir pour les textes en blanc

Par contre pour les textes verts ( Domochart ) c'est OK

Pourtant dans l'exemple du début de @Krikroff on voit bien la mise en évidence ( noir sur fond blanc ) d'un mot d'un texte blanc sur fond noir

 

Suis je seul ? 

Posté(e)

je n'ai aucun souci, j'ai l'impression que tu es le seul non ?

Je suis en mode sombre et je peux surligner un texte, il apparait comme sur les screenshots de Krikroff

Posté(e) (modifié)

C'est curieux.

Je suis en version stable 5.050.13

Sur Firefox ça apparait comme ça, on voit clairement le mot surligné :

 

image.thumb.png.021b706968c37a5f3b24fdc4da0f9077.png

 

 

Tu n'aurais pas un plugin qui modifie l'apparence des pages ?
 

Modifié par Lazer
Posté(e)

Je viens de me rendre compte que l'image de la recherche de sensor sur le texte vert à perdu le fond blanc de mise en évidence lors de la capture de l'image.

Oui avec texte en vert ca marche comme toi, c'est seulement le texte en blanc ou il n'y a pas de de mise en évidence.

 

J'ai essayé d'enlever les images de ce post mais  je n'y arrive pas, elle prête à confusion.

Posté(e)

Je viens de me rendre compte que je ne parlais pas de la même chose que toi.

En fait habituellement je n'utilise que la recherche du navigateur (CTRL+F) ou bien la sélection à la souris.

 

Et toi tu parlais du champ de recherche en haut de la console, que je n'avais jamais utilisé.

Du coup je confirme que j'ai le même comportement que toi, les mots en couleurs sont bien écris en blanc, alors que les mots déjà en blancs.... ben ils restent en blanc, alors forcément la sélection ne se voit pas !

Posté(e)

OK  

alors que quand on est en mode "clair" le fond de la console est gris-bleu et la mise en évidence est fond blanc

je m'attendait donc à la même chose 

mais tu as raison la recherche par le navigateur est aussi pratique.

Le principal c'est de retrouver ce que l'on cherche 

Capture d’écran 2021-03-11 à 16.00.10.png

  • 3 mois après...
Posté(e)

Hello,

 

Je suis tombé un peu par hasard sur cet échange qui m'intéresse au plus haut point.

Est-il possible, dans la même logique, de transmettre tous ces log / évènement ... sur une base SQL server ?

Je m'étais posé la même question sur ma HC2 sans trouver de solution et il est clair que le gestionnaire d'évènement est juste hyper mal indexé (vois même pas du tout si nous somme sur du fichier plat) si bien qu'à chaque fois que je fais un filtre ... ça me plante ma HC2 :2:

 

Si oui, par quel type d'appel cela fonctionne ? (car je suppose que ce n'est pas de l'ODBC) :) ==> Je parle là sur une HC3 (mais si HC2 c'est pareil ça m'intéresse également de savoir)

Concernant la table à créer, quelle structure ? type de colonne ...

 

Dsl, questions peut être idiote, mais sincèrement intéressé.

 

Merci!

 

Posté(e)

je crois que @jjacques68 fait le transfert des log vers une base sql.

Moi dans un fichier car je ne transfère que les error et les messages d'init de mes QA pour surveiller d'un coup d'oeil rapide s'il y a eu des pb dans la journée. Puis je détruit le fichier quand il existe .

Pour les historiques ( évènements,  déclenchements ou valeurs de device Zwave ) c'est different:  ils sont nombreux et si l'historique de la hc3 ne convient pas c'est sûr que c'est vers une base sql que tu peux les transférer pour les exploiter à ta guise.

Pour l'insertion dans les tables SQL tu peux t'inspirer par exemple des travaux de @lazer ( domocharts ) qui appelle du php qui lui fait les requête SQL.

Ce qui est vrai pour la HC3 doit être aussi OK pour la HC2.

Mais rien n'existe de tout fait et il y a du boulot ...

Posté(e)

Voilà, c'est ça l'idée, créer des pages Web en PHP (ou autre langage) afin d'exposer une API, qui permet à un script LUA qui tourne sur la HC2/HC3 d'envoyer des données sur le serveur externe. Après les pages PHP peuvent écrire dans n'importe quelle base de données SQL/noSQL/fichiers à plat, il n'y a pas de limite.

×
×
  • Créer...