Lazer
-
Compteur de contenus
25 874 -
Inscription
-
Dernière visite
-
Jours gagnés
1 256
Tout ce qui a été posté par Lazer
-
Un monosplit Zibro, marque vendue chez Leroy Merlin. En fait après quelques recherches, il semble que le concepteur soit Midea, un des leaders en Chine, avec un compresseur Toshiba. En tout cas, elle fonctionne bien avec l'un des codes Midea dans la doc du ZXT.
-
Oui voilàc'est parfait ça ! Et n'oublie pas les accolades autour
-
Je comprends bien tout ça. Mais je ne vois pas bien comment gérer les index simplement dans mon outil. Dans l'immédiat, tu peux changer le type de la colonne value afin d'accepter de grands nombres, mais il va calculer n'importe quoi dans le generate trends (car une somme de tous les index va donner un nombre non représentatif). Ceci dit, toutes ces comparaisons sont faisable à l'identique avec des valeur absolues de consommation, tu verras aussi bien l'eau versus le gaz et tu peux en déduire les mêmes conclusions. Mais pour cela, il faut juste que je travaille sur la suite de l'outil (pour rappel, la possibilité de mélanger des types de données différents). Et si l'Eco-Devices renvoie un index, c'est à mon avis parce que le hardware est hyper limité, donc le software aussi, donc c'est beaucoup plus facile de renvoyer l'index (l'eco-device n'est qu'un compteur d'impulsions après-tout), que de calculer la différence entre la valeur précédente et celle de maintenant.... ce qui impose de mémoriser des états supplémentaires. En fait, avec l'Eco-Devices, on a un outil qui est une bonne base de départ, mais c'est très "brut", et il faut traiter les données récoltées. OK merci, j'essaierai d'inclure ce module dans une prochaine version. Ce qui me gêne c'est que ce JSON n'est pas très cohérent avec les autres modules sur la HC2, mais on n'est plus à une incohérence près avec Fibaro.... Ca me semblait bien jusqu'à la dernière ligne, où tu mets 01:10 qui est un horaire chronologiquement avant l'horaire précédent... je suppose que c'est une faute de frappe ? Pour l'heure d'hiver, chez moi les horaires sont les mêmes, donc il n'y a pas de souci. Tant que la HC2 change d'heure en même temps que tout le monde (enfin, surtout EDF), il n'y a pas de problème.
-
Je ne sais pas si le calcul de la HC2 est faux.... au pire un relevé non pris sur une période donné sera remonté sur la période d'après. C'est n'est peut être pas aussi précis, mais il n'y a pas de perte d'information. De toutes façon, on fait plein d'approximations, à commencer par les horaires HP/HC (chez ERDF en France, ils varient en moyenne de 2 minutes d'un jour sur l'autre) Ce qui empêche de traiter les index, ce sont les graphiques et les requêtes de type "generate_trend". Sur un graphique, afficher une ligne montant perpétuellement, ,n'est pas très intéressant. Ce qui est intéressant avec les graphiques, c'est de voir les variations et de pouvoir comparer. Le but du jeu pour conserver des graphiques simples à générer, c'est de stocker des données déjà traitées dans la DB. J'ai le même souci pour mon Eco Devices, qui remonte l'index des compteurs électriques. Au moment de l'insertion dans la DB, je récupère le dernier index, calcule la différence, et stocke le delta, ce qui me donne bien la conso en kwh durant cet intervalle. Connaissant l'intervalle, et avec une division, j'obtiens la conso instantanée (lissée sur 60 secondes certes....donc un micro pic n'est pas visible). Donc avec ces données, je peux hyper-facilement tracer des graphiques. Mieux encore, avec des requêtes toutes simples, on peut avoir la conso totale kWh sur une période d'un an (SUM), ou la moyenne (AVG), etc.... Les index c'est vraiment la galère à traiter. Il faut au plus vite calculer la différence entre 2 index, et ne conserver que des valeurs afin de pouvoir travailler facilement sur ces données.
-
Oui l'énergie kWh est un index pour tous les modules (Wall plug, etc).... tant qu'on ne force pas le remise à zero. C'est bien normal, c'est comme pour un compteur électrique au tableau. Je n'ai pas lu ton code en détail, mais je vois que tu récupères les consos directement dans le JSON du device. Tu n'as pas essayé de passer par l'API du panneau d'énergie ? Moi j'utilise ça : payload = '/api/energy/'..timestamps[i][1]..'/'..timestamps[i][2]..'/compare/devices/power/'..device; Le 1er timestamp et le 2nd donnent les bornes de l'intervalle, et la HC2 se débrouille pour calculer la conso dans cet intervalle.
-
OK, mais mon outil DomoCharts n'est pas prévu pour prendre en compte les index (qui par définition, montent sans cesse). Dans ton VD, est-ce que tu aurais la possibilité quotidiennement de calculer la différence de consommation par rapport à la veille (une VG devra mémoriser l'index de la veille), tous les jours à minuit ? Comme ça, tu auras une conso du jour qu'il sera facile de placer dans la table domotique_water_day. Oui je ne prends que la liste des types officiellement supportés par Fibaro, ainsi que les 3 mesures de Yahoo Weather (Temp, hum, et vent). A cela, j'ai ajouté les mesures de la station Météo Netatmo (qui sont vus comme des multilevelSensor). Il faut que j'ajoute le thermostat Netatmo. Et donc il faut que j'ajoute tous les autres multilevelSensor, en basant la reconnaissance du "type virtuel" sur l'unité du module. Donc si tu as autre chose que mm et km/h, c'est le moment de le dire ! Est-ce que tu peux me fournir le JSON de ce module afin que je regarde pourquoi il n'est pas pris en compte ? Pour les mesures de puissance électrique, je ne regarde pas le type du module, mais ses propriétés, et notamment si il renvoie une puissance électrique déclarée. Etrange ces soucis de caractères accentués.... je n'ai aucun problème depuis que je code tout en UTF-8. Tu utilises quel navigateur ? Est-ce que ta base est hébergée sur un Linux (les Synology étant des Linux), ou un OS exotique comme Windows/MacOS/etc ? Pour l'onglet énergie, c'est quoi le message d'erreur ??? Tu as bien appliqué les étapes de configuration des horaires indiqués dans le tuto ? Quels sont les messages que tu vois dans la fenêtre Debug du bouton Energy du module virtuel ?
-
Construction Neuve ? Ce À Quoi Il Faut Penser
Lazer a répondu à un(e) sujet de thibaud dans Mon installation domotique
C'est dommage ça, le 10Gb sera la norme très vite (les entreprises sont déjàtoutes en train de le déployer, donc d'ici 5 ans ça sera abordable pour les particuliers, et d'ici 10/15 ans on trouvera déjàça trop lent) -
Construction Neuve ? Ce À Quoi Il Faut Penser
Lazer a répondu à un(e) sujet de thibaud dans Mon installation domotique
Yohan et moi (et peut-être d'autres) on a le MTVS Acohome et on n'a pas às'en plaindre. Ceci dit je n'ai testé ni le 10Gb (encore trop cher), ni le Satellite (pas l'utilité) !!- 111 réponses
-
- 1
-
-
- construction
- idées
- (et 4 en plus)
-
C'est simple, regarde les types existants : com.fibaro.temperatureSensor com.fibaro.humiditySensor com.fibaro.setPoint com.fibaro.lightSensor Donc il est assez facile d'extrapoler pour la pluie, le vent, etc. Sauf que Fibaro eux-mêmes ne l'ont pas fait pour le plugin Netatmo (le bruit, pression, co2, etc... sont tous en multilevelsensors). Donc si tu tu forces un type inexistant avec ton plugin, je ne suis pas certain que la box réagisse bien..... je vois d'ici le 503 error !
-
Ton index, il ne fait qu'augmenter sans cesse ? Comme calcule tu la consommation ? Par différence par rapport à la précédente valeur mesurée ? Je cherche à savoir comment tu gères exactement ta données, afin de déterminer la meilleur façon de la stocker en DB. HeidiSQL a l'air chouette, mais ça nécessite un accès direct au serveur SQL, ce qui n'est pas possible avec les sites hébergés (accès à MySQL uniquement depuis le site Web lui-même....donc phpMyAdmin)
-
Top merci aller je fais la mise àjour du 1er post.
-
@Nico : Argl, c'est ce que je craignais, les modules sont de type com.fibaro.multilevelSensor, donc générique. Le seul moyen de détecter le type de capteur, c'est de lire l'unité, et de supposer sur mm=pluie, et km/h=vent. C'est pas super propre, mais c'est le seul moyen tant que Fibaro ne créera pas de nouveaux types. Tu en as d'autre des comme ça ? @supermenteur, @BenjyNet : Comme déjàrépondu, il faut modifier le nom de tous les Main_Wave_Device, qui sont les modules parents de tous les modules enfants depuis la v4. C'est beaucoup plus propre ainsi. Perso je mets le nom du module (FGMS-001, ST814, FGSD-001, etc) @Sakkhho : Pour le bouton Delete, voir le lien donné par Sebcbien pour la version patchée permettant de deleter également dans les courbes d'historique journalière. Attention, sur les courbes minute par minute, il faut parfois zoomer assez fortement pour "attraper" le point, c'est le fonctionnement de Highcharts.
-
Bien vu, tu as raison, et je n'avais même pas fait attention ! Essaye de remplacer la ligne suivante : cat conso.xls.csv | sed -e 's/"//g' | sed '1d' | sed -n -e :a -e '1!{P;N;D;};N;ba' > conso-${DATE}.csv Par : cat conso.xls.csv | sed -e 's/"//g' | sed '1d' > conso-${DATE}.csv Si OK, je mettrai à jour le tuto.
-
Y'a un template pour le Qubino ou pas ? Parce que si c'est juste l'inclusion générique du module qui fonctionne, ça veut dire que cette v4 àenfin atteint le niveau de la v3... Quel exploit !!!
-
Je sais pas trop, si ton compteur c'est du journalier, alors il fait le mette dans la table water_day. Et là, mon VD n'est pas prévu pour injecter directement dans cette table. Je te partage demain soir un nouveau bouton justement pour ça Là, dodo
-
SI j'ai pensé aux charbons aussi, mais ils ne sont pas accessibles sans tout démonter, et je ne pense pas que ça soit accessible en pièce détachée pour ce genre de matos chinois. Je suis passé àLM aujourd'hui, ils ont le même modèle en plus beau, lol. Mais le mécanisme était tout sec, donc la graisse ça peut aider un peu.... àvoir si ça suffit pour sortir mon forêt demain.
-
Ah vi, la colonne value est un unsigned tinyint, donc ça fait 255 maxi. C'est bête ça :/ Tu peux changer la colonne en unsigned smallint avec phpmyadmin ? Ca fait 65535 maxi, ça laisse de la marge ! Euh, en fait, je suis en train de penser.... je sais pourquoi j'ai laissé un tinyint. La table domotique_water, c'est la table qui stocke les données minute par minute.... donc c'est pas possible de consommer plus de 255 L en 1 minute. Si ta valeur est un cumul journalier, alors c'est dans la table domotique_water_day qu'il faut la stocker..... comme on le fait pour notre compteur Veolia.
-
à mon avis, le plus simple, c'est une scène en autostart sur trigger de la VG, et tu update automatiquement une autre VG multipliée par 1000. C'est cette dernière VG que tu utilises avec DomoCharts. Parce que si tu modifies à l'arrache le code du bouton de mon VD, tu vas t'amuser pour le suivi des modifs ensuite. Sinon, je viens de poser la mise à jour de data_delete.php pour la suppression des données historiques journalières. Tu peux tester ? https://github.com/cdriget/DomoCharts/blob/master/graph/data_delete.php
-
pourquoi tu ne multiplie pas par 1000 directement au moment du stockage de la donnée dans la VG ? Sinon, faudrait modifier le code du VD pour appliquer une formule mathématique aux VG, mais je ne vois pas comment coder le truc proprement, là tout de suite....
-
Ah faut ajouter ça aussi dans /graph/js/config.js : {type:'water', title: "Consommation d'eau", yaxis: 'Eau (Litres)', tooltip: 'l', min: 0},
-
Déjà regarde dans la table si les données arrivent bien. Et dans index.php, ajoute : <option value="water">Eau [L]</option>
-
Bon Sakkhho, vu que tout semble fonctionner chez toi avec la nouvelle version de DomoCharts, il est temps de faire le ménage dans ce tuto. En effet, je n'utilise plus le script data_post_water_day.php donné en première page, qui est avantageusement remplacé par le script data_post.php livré avec DomoCharts v5.0. Pour que ça fonctionne, il faut juste que tu remplaces les dernières lignes du script veolia.sh par ceci : POST=`awk -F\, 'BEGIN {ORS="";print "[";OFS=",";sep=""} {print sep"{\"id\":3000","\"date\":\""$1"\"","\"type\":\"water\"","\"value\":"$3"}"; sep=","} END {print "]\n"}' conso-${DATE}.csv` /usr/bin/curl --request POST --data ${POST} http://XXXXX/graph/data_post.php echo Tu peux tester et me dire si c'est OK pour toi ? Ensuite tu pourras supprimer ton fichier data_post_water_day.php et je mettrai àjour la première page afin de simplifier et uniformiser tout ça.
-
Pour le type, il faut mettre water Ca me semble correct, essaye et dis moi si ça passe, je n'ai jamais essayé d'alimenter en direct la table minute par minute. En fait, Sakkhho et moi on n'injecte les données que 1 fois par jour à partir du relevé de Veolia, notre fournisseur d'eau local (tuto dans ma signature), donc du coup ça va directement dans la table d'historique domotique_water_day.
-
J'ai identifié toutes les commandes qu'on peut envoyer à 3 des 4 modules visibles dans l'interface pour ce ZXT-120 : Tableau de correspondance par rapport à l'image ci-dessus : Nom => ID 14.0 => 5 14.0.1 => 6 14.0.2 => 7 14.0.3 => 8 Seul le premier module avec la commande setThermostatSetpoint prend un second paramètre qui est la température désirée (21°C ci-dessous) : fibaro:call(5, "setThermostatSetpoint", "1", "21") -- Chauffage fibaro:call(5, "setThermostatSetpoint", "2", "21") -- Refroidissement fibaro:call(5, "setThermostatSetpoint", "8", "21") -- Air sec fibaro:call(5, "setThermostatSetpoint", "10", "21") -- Permutation automatique fibaro:call(7, "setMode", "0") -- OFF fibaro:call(7, "setMode", "1") -- Chaud fibaro:call(7, "setMode", "2") -- Froid fibaro:call(7, "setMode", "5") -- Reprendre fibaro:call(7, "setMode", "6") -- Ventilation seule fibaro:call(7, "setMode", "8") -- Air Sec fibaro:call(7, "setMode", "10") -- Basculement automatique fibaro:call(8, "setFanMode", "0") -- Vitesse basse automatique fibaro:call(8, "setFanMode", "1") -- Vitesse basse fibaro:call(8, "setFanMode", "2") -- Vitesse haute automatique fibaro:call(8, "setFanMode", "3") -- Vitesse haute fibaro:call(8, "setFanMode", "4") -- Vitesse moyenne automatique fibaro:call(8, "setFanMode", "5") -- Vitesse moyenne fibaro:call(8, "setFanMode", "128") -- OFF
-
non ne mélange pas, power c'est la puissance électrique en WATTS. pour eau, il y a les tables water water_day et water_month, mais je gère ça comme un cumul, donc l'unité c'est des LITRES. Si tu mesures un débit (des L/s ou L/min) il faut trouver une autre solution propre. Idem pour le gaz, sauf qu'il faut créer les tables. Pour le moment, je n'ai pas intégré les données de mon Eco Devices, qui sont toujours dans une table à part, qui n'est pas encore fusionnée avec DomoCharts..... ça fait partie du reste à faire !