Afficher nativement des graphiques

[vravolta 0]

Je suis en cours de remplacement de mes anémomètres et pluviomètres Netatmo par du Zwave, dans le but de ne plus devoir dépendre des serveurs capricieux de Netatmo. J'ai donc installé les capteurs, coché le fait d'enregistrer l'historique. Et là, je m'attendais à ce que nativement, ledit historique soit affiché, comme on peut le voir par exemple pour la température du QA Netatmo. Mais en fait, rien, nada. 

J'ai bien vu le sujet avec export d'une base de données (donc duplication de la data) puis intégration dans un server web qui lui même tourne sur un NAS. Mais je trouve bizarre qu'il faille déployer une telle énergie pour avoir quelque chose de basique et à mon avis indispensable à partir du moment où on dispose d'un historique. N'y a t il pas une option que je n'imagine pas pour que la HC3 affiche l'historique de n'importe quel capteur historisé voire permette de le voir sur Yubi?

[Lazer 8 497]

Non pas possible malheureusement, Fibaro n'a implémenté l'historique que pour certains types de capteurs (température, consommation, ...)

Et de surcroit, cet historique est limité dans le temps, afin de ne pas saturer la mémoire interne, il est purgé au bout d'un certain temps (variable selon la quantité de données stockée)

Du coup, perso je préfère tout conserver dans une base externe, sur mon NAS, que je maitrise, et qui survit au changement de box. Raison d'être du projet DomoCharts.

[vravolta 0]

Sauf que du coup, si ca résiste au changement de box, ca devient sensible aux MAJ d'OS du NAS, aux changement de version de la DB et à la capacité de tout ce petit monde à se parler. J'ai installé pas mal de choses sur mon NAS, mais force est de constater que ce n'est pas d'une stabilité mythique. Et par ailleurs, pour des raisons de sécurité, je n'aime pas trop exposer mon NAS à l'extérieur. Et là, on n'a pas encore parlé de Yubi qui par construction n'a pas de raison de bien intégrer un serveur web hébergé hors de la galaxie Fibaro.

Du coup, se pose une question: si je force le type de capteur à "température", est ce qu'il y a moyen de bidouiller quelque chose pour avoir les graphiques historiques de ce type de capteur? En essayant rapidement (et naïvement), ca ne semblait pas fonctionner, mais il y a peut être une bidouille à effectuer ou peut être qu'il faut passer par un QA qui lit les infos dans l'historique et simule un capteur de température pour les afficher.

[Lazer 8 497]

C'est vrai.... mais déformation professionnelle aidant, je ne fais jamais les dernières mises à jour logicielles, car par expérience ça casse souvent quelque chose qui marchait bien.

Idéalement il faut 2 environnements, 1 de test, et 1 de prod.
Bon chez moi c'est plus compliqué, puisque j'ai dissocié la DB (qui est hébergée sur le NAS) des pages Web (qui sont dans une VM).
Du coup je maitrise mieux les processus de mise à jour, et de retour arrière le cas échéant.
La DB sur le NAS c'est juste du MariaDB, donc aucun risque de casser quoi que ce soit, la seule difficulté ça a été lors de la migration vers MariaDB 10 il y a quelques années.... avec le changement de port sur le Syno, rien de si méchant que ça au final !

On est plus embêté avec le serveur Web ou la version de PHP... mais vu que je suis dans une VM dédiée à cet usage, je sais quel paquet je met à jour, et la version de PHP ne change jamais toute seule.

Mais surtout, je l'ai évoqué, l'essentiel c'est d'avoir des sauvegardes pour pouvoir faire un retour arrière.

 

Quant à l'exposition à l'extérieur, j'ai solutionné le problème avec un double reverse proxy filtrant.

De plus, la DB est sur le NAS en coeur de réseau, les pages Web sur la VM isolée dans une DMZ, avec filtrage firewall, du coup le NAS n'est jamais exposé sur Internet.

Un peu lourd à mettre en place, mais bien sécurisé.

Il y a longtemps, je n'avais pas encore mis en place toute cette infrastructure, et ma base DomoCharts était hébergée en ligne chez OVH. J'ai pu tout rapatrier sans perte de données et en conservant l'historique, c'est aussi ça la force de la solution maison comparée à un stockage dans la box.

 

Tu parles de Yubii, c'est pareil, je passe par le reverse proxy pour accéder à ma box sans passer par le cloud Fibaro tout en conservant un haut niveau de sécurité, la HC3 n'était pas accessible en direct depuis Internet.

 

Tu ne peux pas forcer un capteur lambda à être de type température... et de toute façon ça casserait la bonne intégration de ce capteur, donc quel intérêt ?

Tu peux le faire avec un QA puisque tu peux choisir le type, mais là encore à quoi bon, puisque ça casserait l'intégration.
La force des QA, c'est justement de pouvoir choisir le type de module qui va bien en fonction de sa finalité.
 

Il faut te faire une raison : la box Fibaro ne permet pas, en natif, d'historiser toutes les données (comparé à d'autres solutions domotiques)
Raison pour laquelle j'ai développé DomoCharts, afin d'historiser les données des capteurs sur une base de données externe.
D'autres ici sont même allés encore plus loin, par exemple pour historiser tous les événements, ou tous les logs, sur une plateforme externe.

 

Après quand je vois ce que proposent les autres concurrents, j'aime autant DomoCharts.

2 exemples :

- eedomus : sur le cloud, avec abonnement

- Home Assistant : dans InfluxDB, que je n'aime pas du tout, j'ai pas réussi à gérer correctement l'historisation comme je voulais

Une bonne base SQL, à l'ancienne, ça me parle mieux, je maitrise ce qui est stocké dedans, je peux faire toutes les requêtes qui m'intéressent pour exploiter les données

Si un jour je change de solution domotique (ce qui est déjà arrivé quand j'ai fait HC2 => HC3), je conserverai DomoCharts, c'est bien plus pérenne pour mon usage en tout cas.

[vravolta 0]

Le but étant uniquement de faire un affichage en plus, je ne perds pas la fonctionnalité du capteur d'origine avec ma méthode, c'est juste que je voudrais essayer de détourner le seul moyen d'origine qui affiche des graphes pour le faire pour n'importe quel capteur. Un truc du style QA qui scanne tous les capteurs ayant l'historique activé et qui crée un child de type température pour chacun de ces capteurs, child qui du coup aurait la fonctionnalité d'afficher un historique via un graphique. C'est ca mon idée, mais je ne sais pas si c'est techniquement faisable.

[Lazer 8 497]

Oui je pense que c'est techniquement faisable.

 

[vravolta 0]

Bon, ben je vais m'y mettre alors ;-) Les premiers steps seront de trouver comment obtenir une liste des ID des capteurs ayant un historique activé puis de créer un device child de type température. Jusque là, je ne vois pas de souci majeur si ce n'est de trouver la bonne syntaxe. Ce qui me fait un peu plus peur, c'est qu'à priori, le graphique historique des devices température va pointer sur l'historique officiel Fibaro en utilisant sans doute en dur l'ID du device. Il faut donc trouver un moyen de lui dire d'utiliser l'ID du device physique et le cas échéant de pouvoir appliquer une conversion si le range d'un capteur devait être très différent du range usuel des températures. Typiquement, une pression, c'est de l'ordre de 1000 et je ne suis pas certain que le graphe natif de Fibaro sache afficher des valeurs si élevées. Toute idée ou documentation du fonctionnement des graphiques natifs serait bienvenue ;-) .

[Lazer 8 497]

La liste des devices :

/api/devices

Qu'on peut récupérer en LUA avec api.get(), et qu'on peut également filtrer.

Quelques exemples (liste non exhaustive) :

/api/devices?visible=true                          returns devices with visible equal to 'true'
/api/devices?property=[batteryLevel,100]           returns devices with property batteryLevel equal to 100
/api/devices?property=[unit,%CE%BCg/m3]            returns devices with unit equal to µg/m3
/api/devices?interface=light                       returns devices with light interface
/api/devices?type=com.fibaro.netatmoWeatherStation returns Netatmo Weather Station
/api/devices?baseType=com.fibaro.weather           returns Weather plugins
/api/devices/?property=isLight
/api/devices?interface=zwave&parentId=1

 

Pour les child devices, voir la doc officielle : https://manuals.fibaro.com/knowledge-base-browse/hc3-quick-apps-managing-child-devices/

Et il y a un topic qui en parle sur le forum... la difficulté est de gérer la table de mapping des différents modules enfants.
 

 

Pour le reste, vu que c'est de la bidouille, il faudra être imaginatif !

Et expérimenter ce qui marche / ne marche pas...