Data Logger Générique (Vd)

[CaptainIgloo]

Bonjour àtous et bon dimanche,

Dites-moi les loulous, quelqu'un aurait-il développé un VD data log générique.

Je connais le VD Graph de Lazer mais celui-ci est orienté température...

Quelqu'un aurait-il fait un truc plus générique avec la possibilité enregistrer toutes données avec comme table un truc du genre,

TS, RefDonnee, unité puis valeur (correspondant aux champs) ?

Merci d'avance pour vos retours

[jojo]

tu proposes de refaire le event panel de Fibaro. Je suis preneur, car c'est une vrai crasse ce brol

[CaptainIgloo]

Non pas vraiment, j'aimerai collecter toutes mes données de mes VD quitte àafficher tout sur un seul graphique avec une abscisse de temps et toutes les valeurs sur l'ordonnée car cela permet d'analyser les relations entre données.

[Nico]

Bah je pense que la dernière version de Lazer (Encours de dev) devrait le faire sans trop de modification.

[CaptainIgloo]

Mon idée est de m'abstraire d'un MCD, simple une table queue avec Timestamp, nomdonnee, valeur, unité.

Ainsi on peut tout mettre dedans.

[Invité chris6783]

un stockage générique peut être pas mal en effet pour nos besoins mais il faut un minimum de meta modèle autour pour avoir aussi une interface générique qui ressemble àquelque chose. La nouvelle version de l'outil graph peut être un bon point de départ pour ajouter cette forme de stockage. Par exemple souvent on voudra voir des sommes ou moyennes sur une période et il faut du modèle pour pas tout coder en dur. De la même manière les périodes de rétention de la data devraient être génériques mais pilotée par un modèle . L'écueil principal du modele générique brut de décoffrage c'est que très rapidement il devient un fourre-tout sans cohérence ni contrôle. Le faible coût de création de la base peut au final revenir très cher sur le moyen terme... Pour palier àça le meta modèle est incontournable. Je ne rentre pas dans le débat sur les performances & co .... Nous parlons de Db assez petites.

Si Lazer est partant on doit pouvoir collaborer au dessus de son outil pour le rendre encore meilleur plutôt que de créer un alternative de zéro

[Lazer]

Ca me semble difficile d'intégrer ce besoin spécifique sans créer une grosse verrue dans mon code.

 

Par contre, tu peux facilement reprendre le code, et une légère modification (en fait il s'agit d'une simplification) permettra d'alimenter ta table unique.

[CaptainIgloo]

Merci de ton retour Lazer. Je peux réfléchir àun MCD le plus exhaustif possible en terme de perspectives, mais j'oublierai forcément des choses. Mon objectif étant avoir une DB très polyvalente.

Je reste néanmoins très orienté capteurs environnementaux.

[Lazer]

Si j'ai bien compris ton idée "simple une table queue avec Timestamp, nomdonnee, valeur, unité", je t'avoue que ça me semble plutôt limité en terme d'évolutivité.

Parce que tout mettre dans une table, c'est simple, mais par la suite, ta table va gonfler très vite (puisque tu vas stocker du texte identique à  de multiples reprises (nomdonnee, unité) inutilement. Au final, quand tu auras beaucoup de données et que tu voudras faire une requête, ça fera d'autant plus de données à  manipuler inutilement. Alors sur ton NAS puissant ça ne sera pas un problème, mais c'est pas très propre quand même.

 

Dans ma solution, j'ai bien séparé les notions de devices, types, et valeurs, sachant qu'on a une table par type de valeur (température, humidité, etc). Donc c'est ultra simple d'ajouter juste une nouvelle table pour gérer un nouveau type de données.

[CaptainIgloo]

Tu as complètement raison Lazer, je suis partagé entre ma capacité àfaire moi-même et la simplicité de mise en œuvre pour le commun des mortels.

Bien entendu, j'arriverai bien àmodifier ta DB, mais j'aimerais qu'un utilisateur sans compétence saches seul faire évoluer la base.

Demain j'aurai un SBS avec capteur UV, foudre ou autres... Comment modifier le schéma données pour accepter d'autres données ? Il faut bien penser aux Noobs.

[CaptainIgloo]

De plus, j'aurai aimé un backend contemporain avec autre chose que du php avec par exemple Python Redis en RestFul...

[Lazer]

Générer des pages Web avec du Python, je ne trouve pas ça très contemporain, c'est carrément un retour aux scripts CGI là . Ou alors j'ai pas compris ton idée ?

Tu peux faire des choses très propres en Ajax, avec un mix de fichiers Javascript et PHP.

Et le Python ne tournera pas sur les hébergements mutualisés. Tout le monde n'a pas un NAS à  dédier aux graphs.

Alors que du PHP/MySQL/Javascript, ça tourne absolument partout.

 

Concernant l'évolution de la DB pour le Noob, ce qui importe c'est qu'il n'aie pas besoin de taper des requêtes SQL dans phpMyAdmin.

Donc il faut lui faire un frontend, une bête page Web qui lui permette d'ajouter un nouveau type de capteur. Ce qui se traduira pas la création de la table correspondante.

 

L'inconvénient (encore que ça n'en soit pas vraiment un), c'est qu'on va vers une multiplication des tâbles dans la DB. Depuis que j'ai intégré Netatmo, j'ai des tables CO2/Pression/Bruit/etc avec seulement une sonde dedans. Si demain on ajoute tout types de mesures, ça va multiplier les tables, mais le SGBD le gère très bien.

 

Pour tout dire, avant d'isoler les types de sondes dans des tables différentes, tout était dans la même table.

Au bout de quelques semaines j'avais dépassé le million de lignes dans la DB.

Avec les bon index, je n'avais pas de problèmes de performances lors des requêtes, mais comme je supprime les données au bout de 3 semaines pour limiter l'accroissement de volumétrie, je lance des Optimisations de tables. Ces optimisations plantaient sur mon hébergement mutualisé, tout comme ça aurait aussi planté sur un petit NAS.

 

Si tu veux que le Noob, toujours lui, puisse utiliser la solution, il faut penser qu'il n'a pas à  sa disposition un hardware de folie, donc la solution doit être la plus interopérable possible. Ce qui implique :

- performances (petit NAS, hébergement mutualisé)

- ergonomie (interface Web qui permette d'administrer facilement la solution)

- interopérabilité (utiliser des outils standards dispos partout)

 

Pour info, dans la prochaine version de mon outil, il n'y aura plus besoin de passer par phpMyAdmin pour l'installation, je suis en train de créer un mini-installer.

[CaptainIgloo]

Bon àpriori tu as déjàdu recul sur le stockage donc je fais confiance àton analyse. Pour le php c'est un peu une allergie pour moi. Par contre pour l'infra le portage sur un hébergement mutualisé n'est pas dans mes tablettes (spof internet).

[Lazer]

Internet est un Spof je suis d'accord, mais mon NAS aussi  (vu que je n'arrête pas de jouer avec).

Enfin maintenant mon NAS est stabilisé et tourne bien, mais je garde quand même mes données chez OVH car je consulte souvent mes graphs de l'extérieur, et si les données étaient sur mon NAS je serai limité par l'upload pourri de ma ligne ADSL pour la vitesse de chargement des graphs.

Alors que chez OVH, c'est rapide tout le temps.

 

Le PHP c'est crade quand tu mélanges code PHP et code HTML dans la même page, comme aux débuts du langage.

Maintenant avec Ajax tu sépares bien les fonctions dans des fichiers différents, donc c'est beaucoup plus propre (Ajax, Propre, tout ça...  désolé)

[CaptainIgloo]

:-) l'important est effectivement d'avoir une alternative au local pour ceux pas équipé. Du coup du prévoir une capacité de rétention de données sur indispo du net ? Je veux dire Ue le VD doit pouvoir historiser quelques minutes idéalement pour rien perdre.

[Lazer]

Oui je suis d'accord, sauf que ce n'est toujours pas implémenté !

Au pire, 5 minutes de coupure Internet, ça me fait 5 minutes de pertes de données, ça ne change pas grand chose sur les graphs de moyenne quotidienne.

 

En cas de coupure plus longue d'Internet (ce qui ne m'est pas arrivé depuis 2 ans), je peux simplement rediriger les graphs vers mon NAS local, et je me débrouillerai plus tard pour merger les données. Bon c'est sà»r que c'est pas user-friendly tout ça !!

 

Pourtant cette histoire de rétention des données est quelque chose que j'ai en tête, et qui est implémenté sur mon Raspberry PI (tu sais, celui qui compte les impulsions).

Donc ça viendra probablement un jour sur mon VD Graphiques. En plus avec la nouvelle structure à  paraitre bientôt, ça sera plus simple à  mettre en place.

[CaptainIgloo]

Bonjour Lazer,

Je ne sais pas comment tu géreras les inserts SQL, mais il pourrait-être envisageable de créer une fonction de rétention sous forme d'un tableau dictionnaire explicite avec des noms de colonnes timestamp unix (tostring) et des lignes nommées correspondant aux noms des variables dans lesquelq on stocke les valeurs collectées. Tant qu'internet indisponible, on stocke en table.insert dans la variable tableau (dictionnaire). Si on retrouve internet, on effectue l'insert SQL et on vide le tableau.

Le problème est qui faut pas s'appuyer sur le TS serveur mais sur un champ propriétaire pour pouvoir intercaler (forcer la position temps) les inserts.

C'est une idée comme ça...

[Lazer]

C'est exactement ça Captain !

 

En réalité, j'ai une API très proche d'un RESFULL.

Les données sont échangées en JSON. Donc il est très facile de retenir le JSON dans une variable globale, et de ré-emmètre le tableau à  la prochaine tentative. Seule limitation : la longueur maximale d'une chaine de caractère dans une VG.

 

Voici un exemple de JSON valide :

[{"id":0,"timestamp":"NULL","type":"temperature","value":10},{"id":1,"timestamp":"1427749407","type":"humidity","value":8},{"id":2,"timestamp":"NULL","type":"test","value":27},{"id":4,"timestamp":"1427749407","type":"water","value":0},{"id":1,"timestamp":"NULL","type":"temperature","value":12}]

Comme tu peux le voir, on retrouve les champs suivants :

• ID du module (correspond à  un ID réel de la HC2 pour un module Z-Wave, ou un ID fictif dans le cas d'un périphérique externe (par exemple un compteur d'eau issu d'un Eco-Devices stocké dans une VG.... dans la pratique, j'ai choisi des ID 2000, 3000, 4000 etc pour ce genre de devices)
• timestamp : si NULL, alors on prend le timestamp du NAS/Serveur Web. Sinon, la HC2 peut fournir la valeur, ce qui suppose que la clock de la HC2 soit synchro... il y a toujours un bug qui traine à  ce sujet.
• type : le type de la donnée, afin de stocker la donnée dans la bonne table.
• value : la valeur

[jojo]

Lazer,

Il me semble qu'en v4 on n'est plus limité comme en v3

http://www.domotique-fibaro.fr/index.php/topic/5669-se-passer-des-id-dans-vos-scenes-et-vd/?p=85435

[CaptainIgloo]

Oh !

D'enfer alors.

On peut balancer du json bien lourd alors.

Il me semblait que quelqu'un avait fait une boucle de test ?

[Lazer]

40000 caractères, avec une trame JSON moyenne de 60 caractères par device, ça fait une mémoire de 666 devices, si on considère 20 devices par minutes, ça fait donc une mémoire de 30 minutes environ. C'est tout àfait correct pour laisser le temps àune coupure internet courante (reboot de la box, déconnexion adsl, etc) de se rétablir.

[CaptainIgloo]

Salut les loulous,

En jouant avec mon RPISIGFOX (SNOC), j'ai pu découvrir un SGBD dédié aux séries temporelles de télémétrie par le biais de RunAbove IOT OVH. OVH propose une API pour atteindre une BD optimisée pour cet usage (gros volume de données et performance d'accès et d'affichage). Ce système n'est autre qu'OpenTSDB.

En utilisant Grafana il est possible d'obtenir une représentation graphique adaptée et performante.

 

J'ai donc dans l'idée de faire converger les données (indicateurs) HC2 et SIGFOX dans une infra locale sur un de mes Synology.

OpenTSDB image Docker : Check (fonctionnel).

api/put : Check 

Code lua net.FHTTP en cours...

 

Il me faut mette en place grafana et configurer le connecteur JSON...

[CaptainIgloo]

 

Bon et bien c'est de la balle.

[CaptainIgloo]

C'est d'une simplicité déconcertante...

local VDSoleilRadiPon=fibaro:getGlobal("VDSoleilRadiPon")

HC2 = Net.FHttp("192.168.1.2",4242)
--HC2:setBasicAuthentication("LOGIN","PASSWORD")
json = '{"metric": "VDSoleilRadiPon","timestamp": '.. tonumber(os.time())..',"value": '.. VDSoleilRadiPon..',"tags": {"Origine": "HC2"}}'
response, status, errorCode = HC2:POST('/api/put', json)
if tonumber(status) == 204 then
  fibaro:debug("OK")
else
  fibaro:debug("NOK")
end

[BenjyNet]

Ah ouais Grafana, très beau, très puissant