Discussion :

[ograweb]

bonjour,

Oui ce titre est vraiment très flou !

J'ai un système de domotique qui me permet d'enregistrer dans une base sql une masse d'information sur les HABITUDES de la maison :
Dates/heures, allumage et extinction de lumières, ouverture de portes, température des pièces et extérieur, mouvements...
Bref c'est mon big data personnel

J'aimerais coder un programme Afin de traiter et croiser ces données, dans un premier temps dans le but de logger les événements inhabituel (ex lumière á 4h du mat); puis dans un (lointain) second temps rendre le programme capable de prédire, d'anticiper des actions ( la luminosité baisse, la tv est allumé -> allume les lumières d'ambiance)

Mais aucune idée de la manière de programmer cet 'apprentissage' ni de stocker les données (une table sql indexé par date/heure est pour l'instant utilisé mais n'est pas exploitable tels quel.

Avez vous des pistes ?

Merci

Ps: le nombre de données pourra être très important ( années x 365 x 24 x 60 x nombre de capteur x changement d'une des valeurs d'un capteur par minutes (luminosité, temp, mouvement...))

[Trap D]

Tu peux t'orienter vers un système expert.

[ograweb]

Bonjour

Effectivement en lisant la définition d'un système expert, cela correspond assez au but final de l'application elle même. Mais cela reste très flou :-)

J'ai bien compris le concept de 'règles' (scenario en domotique), et l’exécution de ces règles.
J'ai en revanche un gros vide pour le stockage des données de façon optimale, leur traitement puis l'apprentissage des règles.

J'aimerais rester dans une programmation 'classique' (c, C++, js ou php !)

[ToTo13]

Tu peux sans doute simplifier un peu ton nombre de données en éliminant le x60, car je ne pense pas qu'il te faille être à la seconde près. Une précision d'une minute est largement suffisant pour l'emploi du temps de personnes. Ensuite, les maisons sont vides la journée car les gens travaillent et inactive la nuit car les gens dorment. Donc même si les données seront grandes, elles devrait être largement manipulable.

Je ne suis pas vraiment expert de la chose, mais je ferai des histogrammes pour savoir lorsque chaque type d'évènement se produit le plus durant la journée, mais il faudra différencier entre jour de la semaine et week-end.
Ensuite, tu peux corréler ces évènements entre eux, par exemple : est ce que l'heure d'allumage de la télé correspond avec celui de l'abaissement de la luminosité.

[Flodelarab]

Bonjour

Qui dit "habitudes" dit période. Et chaque évènement est une habitude de période infinie.

En clair, la quantité de données n'est pas si importante car tu vas garder les informations sur une simple, double ou triple période pré-supposée pour voir si l'évènement se reproduit, et jeter tes enregistrements anciens.

En reprenant ton calcul, ce n'est même pas effrayant.
pour 1 octet par évènement pour 100 capteurs pendant 5 ans, il faut 250Mo
pour 1 kilo-octet par évènement pour 100 capteurs pendant 5 ans, il faut 250Go.
La vérité se trouve probablement entre les deux et n'est pas effrayante.

[ograweb]

Bonjour,

Effectivement, la quantité de données en Mo/Go n'est pas si énorme. Ce ne sont que des valeurs numérique. Je cherche surtout le modèle de stockage facilement exploitable.

Un exemple de modèle facilement exploitable (Mais pas forcément le plus judicieux)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
|DATETIME|DURÉE|VAL1|VAL2|VAL3|VAL4|VAL5|VAL6|.....|VAL64|VAL65|
 
Je stock 1 ligne (avec les valeurs de tous les capteurs) à chaque changement d'une seule valeur. Je stock donc (nombres de capteur) fois plus de données. Un ajout d'un capteur m'oblige à modifier la structure de la table.
Mais l'exploitation des valeurs en SQL est très simple et très rapide. Un simple SELECT me permet de savoir si la lumière du salon (VAL3) n'est jamais allumé (!=1) lorsque la luminosité extérieur (VAL10) est supérieur à 30% (>0.3)

Un exemple de modèle plus classique, standard

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
|DATETIME|DURÉE|IDduCapteur|VALEUR|
 
Ici l'enregistrement est simple, léger. Mais les requêtes seront plus gourmande en jointure, sous requêtes (et plus prise de tête) etc...

Je peux aussi utiliser ce second modèle, puis générer des tables temporaires sur les capteurs qui m'interressent (VAL3, VAL10) en utilisant le premier modèle.
(Grosse consommation CPU pour recréer les tables mais peut être fait à 4H du mat...)


Je suis en train de faire des test sur de petits samples de données (à base de Mysql sur des anciens raspberry A ou B).
Je suis plus habitué modèles des sites internet classiques (Merise, etc..). Mais il doit bien y avoir une autre méthode plus performante pour stocker ce genre de données (big data, statistiques... etc)

[Nebulix]

Sauf ton respect, la principale difficulté me semble que tu ne sais pas vraiment ce que tu veux. Si tu prends le temps de l'expliciter, la programmation se fera tout simplement.

[ograweb]

J'ai :
Une masse croissante d'information issu de capteurs et d'actionneurs domotique (Datetime, capteurID, valeur (int, float))

Je veux :

Étape 1 : Stocker ces valeurs (afin de les exploiter,non pas pour les archiver)

Etape 2 : 'Combiner' ces valeurs et en déduire des règles d'états ; exemple de règles : Capteur10 est à 1 pour 95% des fois ou Capteur1 = 1 et Capteur2 < 50% et Datetime est un samedi

Etape 3 : Remonter des comportements anormaux (qui vont à l'encontre des règles déduites)

Etape 6 : Donner au programme la capacité d'action : Allumer l'actionneur10 car la règle indique que le capteur10 devrait être à 1.


Je poste sur le forum afin d'obtenir des pistes, des noms de procéder, de SGBD, etc.. Je suis autodidacte en informatique, et je n'ai que très peu d’expérience dans ce type de programmation. Je ne sais même pas si cela pourrai être qualifié de Big Data, d'IA, de système expert (bonne piste que je ne connaissais pas du tout)...

Merci

[tbc92]

En terme de stockage, je pencherais plutôt vers ta 2ème proposition (1 ligne par capteur).
Tu as mis une colonne durée ... peut-être. A voir si tu préfères stocker des durées, ou alors stocker tous les changements ( et donc une colonne de plus qui dit Allumage ou Extinction.

De toutes façons, si à un moment tu considères que pour certaines analyses, l'autre organisation est plus adaptée, tu peux lancer un traitement pour créer l'autre table.