Lazer Posté(e) le 12 janvier Auteur Signaler Posté(e) le 12 janvier il y a 28 minutes, jojo a dit : Du coup j'ai vu que la table domocharts_current_day ne se remplissait pas, alors que les autre tables domocharts_*_day et domocharts_*_month se remplissent bien (j'ai vérifié pour tels tables qui remontent des données) Suis-je seul ? Y a-t-il un fichier de config qui ne serait pas à jour chez moi ? Surement parce que la version partagée sur le forum ne calcule pas non plus les trends pour le courant.... Dans le fichier trend.php, tu peux ajouter ceci quelque part, par exemple juste après voltage : //*** Current array_push($response['data'], ExecuteQuery($bdd, " INSERT INTO domocharts_current_day (date, device_id, min_value, avg_value, max_value) SELECT DATE(time) AS date, device_id as device_id, MIN(value) AS min_value, AVG(value) AS avg_value, MAX(value) AS max_value FROM domocharts_current WHERE DATE(time) > ( SELECT COALESCE(MAX(`date`), '0001-01-01') FROM domocharts_current_day ) AND DATE(time) < CURDATE() GROUP BY date, device_id ")); array_push($response['data'], ExecuteQuery($bdd, 'DELETE FROM domocharts_current WHERE DATE(time) < SUBDATE(CURDATE(), '.$db_interval_current.')')); array_push($response['data'], ExecuteQuery($bdd, 'OPTIMIZE TABLE domocharts_current')); ça devrait fonctionner je pense. il y a 12 minutes, jojo a dit : Mais comment faire pour voir les données < 7 jours ? Alors là.... je n'ai jamais testé.... Je ne me souvenais même plus qu'il y avait le paramètre $display_interval dans le fichier config.inc.php ! Donc tu l'as augmenté et ça n'a aucun impact sur le graph ? Parce que quand je regarde la requête SQL qui est générée dans data.php, ça devrait théoriquement être pris en compte. 1
jojo Posté(e) le 12 janvier Signaler Posté(e) le 12 janvier j'ai implémenté ton code, j' regarderai la table demain. Pour les graphes, à la lecture de ta note, je n'ai pas osé toucher au paramètre de peur de tout fair planter. Je viens de le doubler, et aucun impact de performance, et en jouant avec les curseurs, je peut voir ce que je veux. Maintenant, je devrait voir avec Grafana, mais ça ne semble pas être du YAKFautCon à implémenter.
Lazer Posté(e) le 12 janvier Auteur Signaler Posté(e) le 12 janvier (modifié) Bah pourquoi ? On ne s'est pas compris j'ai l'impression.... Moi je te demande juste si la modification a eu un effet ou non sur l'affichage de tes graph ? Tu peux modifier la valeur sans risque, ce n'est que de la consultation. Je ne vois pas ce qui te fait peur dans mon message précédent, il n'y a aucune mise en garde. Pour le trend, tu peux appeler la page maintenant, ça va forcer un reclacul immédiat et tu verras tout de suite si les curent_day sont bien générés. Modifié le 12 janvier par Lazer
jojo Posté(e) le 12 janvier Signaler Posté(e) le 12 janvier il y a 28 minutes, Lazer a dit : Je ne vois pas ce qui te fait peur dans mon message précédent, RIEN, que du contraire ! En fait je disais juste que je n'avais pas osé changer le paramètre (à la lecture de la note au-dessus du paramètre) // Note : increasing this number may considerably slow down graph generation time j'aurais du être plus courageux ... il y a 41 minutes, Lazer a dit : Pour le trend, tu peux appeler la page maintenant, ça va forcer un reclacul immédiat et tu verras tout de suite si les curent_day sont bien générés.
Lazer Posté(e) le 12 janvier Auteur Signaler Posté(e) le 12 janvier il y a 13 minutes, jojo a dit : je disais juste que je n'avais pas osé changer le paramètre (à la lecture de la note au-dessus du paramètre) ah oui lol ! c'est sans risque après, tu verras vite si tu trouves ça lent à l'usage ou pas. Et encore une fois, tout est réversible. Cool pour les trends du courant
jojo Posté(e) samedi à 17:13 Signaler Posté(e) samedi à 17:13 Je "commance" à apprivoiser Grafana, et du coup je veux faire des graphes qui comparent mes consignes de température avec la température mesurée. Evidemment, la collecte des données avec Domochart est la base. Pour mes régulations, j'utilise ce développement : il crée des devices de type : com.fibaro.hvacSystemAuto Qui contient les DEUX propriétés suivantes : coolingThermostatSetpoint & heatingThermostatSetpoint En fonction que le QA est en mode AirCo ou chauffage, il va lire la valeur d'une des 2 propriétés. Et évidemment, c'est cette propriété qui est mise à jour. Dans le programme Domochart, j'ai adapté la table deviceSensors (en début de code), en y ajoutant ces entrées : { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto" , visible = "true", dead = "false", property = "heatingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID HeatingDevices setpoints { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto" , visible = "true", dead = "false", property = "coolingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID CoolingDevices setpoints les entrées sont bien créées dans les tables. Mais, les résultats ne sont pas cohérents En fait c'est logique, Domochart ne sait pas si le device est en mode Cooling ou Heating. Y a-t-il un moyen de le lui dire ?
Lazer Posté(e) samedi à 18:15 Auteur Signaler Posté(e) samedi à 18:15 Non.. ce n'est pas prévu... j'avais identifié cette limitation dès le portage de DomoCharts pour HC3. Et je ne sais pas trop comment on pourrait adapter le code sans entrer dans des trucs ultra compliqués... car le souci n'est pas tant du coté du code LUA du QuickApp, que de la base de données SQL qui n'est pas prévue pour reconnaitre plusieurs propriétés pour un même type de device.
yves.guern Posté(e) dimanche à 08:25 Signaler Posté(e) dimanche à 08:25 (modifié) Bonjour Jojo, Je ne garanti pas à 100% que ce qui suit va fonctionner pour toi, mon utilisation n'est pas 100% celle là... Il y a probablement une solution (au moins un début) en utilisant le champ "userDescription" qui est présent dans les properties de chaque device. C'est un champ libre ou chacun peut y écrire ce qu'il souhaite. Ce qui est intéressant c'est que domochart peut filtrer les devices qu'il cherche selon ce champ. Il y a 2 ou 3 chose à faire: dans domochart.lua modifier la définition des devices à récolter et installer ce filtre suplémentaire: -- là ou tu as ajouté tes définitions, ajouter un field 'userDescription' : { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto", userDescription="heat" , visible = "true", dead = "false", property = "heatingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID HeatingDevices setpoints { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto", userDescription="cool" , visible = "true", dead = "false", property = "coolingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID CoolingDevices setpoints --autour des lignes 597 il y a la définition des filtres: -- Get datas from API local typeFilter = sensor.fibaroType and ("&type=" .. tools:urlencode(sensor.fibaroType) ) or "" local visibleFilter = sensor.visible and ("&visible=" .. tools:urlencode(sensor.visible) ) or "" local interfaceFilter = sensor.interface and ("&interface=" .. tools:urlencode(sensor.interface) ) or "" local parentFilter = sensor.parentId and ("&parentId=" .. tools:urlencode(sensor.parentId) ) or "" local unitFilter = sensor.unit and ("&property=[unit," .. tools:urlencode(sensor.unit) .. "]") or "" local deadFilter = sensor.dead and ("&property=[dead," .. tools:urlencode(sensor.dead) .. "]") or "" local energyFilter = type(sensor.showEnergy) == "boolean" and ("&property=[showEnergy," .. tostring(sensor.showEnergy) .. "]") or "" -- il faut y ajouter la ligne: local usrDscFilter = sensor.userDescription and ("&property=[userDescription," .. tools:urlencode(sensor.userDescription) .. "]") or "" -- et modifier la ligne 610 (à peu près 610...) local url = "/devices?enabled=true" .. typeFilter .. visibleFilter .. interfaceFilter .. parentFilter .. unitFilter .. deadFilter .. energyFilter -- pour y intégrer ce nouveau filtre: local url = "/devices?enabled=true" .. typeFilter .. visibleFilter .. interfaceFilter .. parentFilter .. unitFilter .. deadFilter .. energyFilter .. usrDscFilter dans ton code de gestion/surveillance de la PAC Il ne reste plus qu'à lui faire écrire le mot cool ou heat dans le champ userDescription selon le mode de la PAC. Quelque chose du genre: if (CurModeHeatCool ~= LastModeHeatCool) then begin for CooltargetIds = ..... do begin fibaro.call(CooltargetIds, "setProperty", "userDescription",(CurModeHeatCool=="Cool") and "cool" or "heat") LastModeHeatCool = CurModeHeatCool end end En espérant que cela fonctionne pour toi Modifié dimanche à 08:27 par yves.guern 1
jojo Posté(e) dimanche à 11:23 Signaler Posté(e) dimanche à 11:23 (modifié) Merci a tous les 2 pour vos suggestions. Mais je ne suis pas du style à changer le standard. En fait, je vais demander une modif du code du QA PID pour écrire les set points dans les 2 propriétés et ainsi dans domochat.lua je ne rajoute que la ligne pour le heating, et basta, ça devrait être bon Modifié dimanche à 12:08 par jojo add link
Messages recommandés