Aller au contenu

Messages recommandés

Posté(e)
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.

  • Thanks 1
Posté(e)

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.

Posté(e) (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é par Lazer
Posté(e)
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.

9t3m.png

Posté(e)
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 :)

 

Posté(e)

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

ou2c.png

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 ?

Posté(e)

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.

Posté(e) (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é par yves.guern
  • Like 2
Posté(e) (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é par jojo
add link
  • 2 semaines après...
Posté(e)

Bonjour à tous,

Un petit mot pour remercier Lazer pour le travail sur Domocharts : installation facile (à part mon synology qui a fait des siennes) et production rapide des courbes, ce qui me permet d'atteindre le premier objectif de voir l'évolution de l'humidité dans toutes les pièces de l'appartement sur la base des infos de quatre capteurs Sonoff (zigbee) et deux fibaro (et un zooz, que je trouve un finalement un peu cher et moche). Prochaine étape, comparer avec l'humidité extérieure avec l'installation d'un capteur (je pense à une station netatmo, sauf si je trouve plus simple) et pouvoir gérer l'aération en fonction. Puis voir un peu la base de données domocharts pour intégrer les données dans un tableau de bord.

En tous cas, super boulot, merci d'avoir mis cela à disposition de la communauté !

Merci !

 

  • Like 1
Posté(e)

Bon courage pour gérer l'aération en fonction de l'humidité extérieure.... car les capteurs donnent l'humidité relative, pas l'humidité absolue.
Et pour calculer cette dernière, il faut prendre en compte la température (intérieure et extérieure du coup, car tu souhaites faire la comparaison), mais aussi la pression atmosphérique, et peut-être d'autres paramètres que j'ai oublié.
Je ne sais plus où j'avais vu la formule de calcul, surement sur Wikipedia, mais elle fait peur à voir...

 

 

  • 2 semaines après...
Posté(e) (modifié)

Bonjour

cela fait longtemps que je n'avais pas eu de probleme avec domochart

j'ai ce message d'erreur

[13.02.2025] [00:27:33] [DEBUG] [QA_DOMOCHARTS_54]: Using tools library v2.20
[13.02.2025] [00:27:33] [DEBUG] [QA_DOMOCHARTS_54]: Using DomoCharts library v7.10
[13.02.2025] [00:27:33] [DEBUG] [QA_DOMOCHARTS_54]: DomoCharts library successfully initialized
[13.02.2025] [00:27:33] [DEBUG] [QA_DOMOCHARTS_54]: Refresh interval : 60 seconds
[13.02.2025] [00:27:33] [DEBUG] [QA_DOMOCHARTS_54]: NAS URL : http://192.168.1.8:80/domocharts 
[13.02.2025] [00:27:33] [DEBUG] [QA_DOMOCHARTS_54]: Maximum memory : 10000 measures
[13.02.2025] [00:27:33] [DEBUG] [QA_DOMOCHARTS_54]: Battery query time : 23:00
[13.02.2025] [00:27:33] [DEBUG] [QA_DOMOCHARTS_54]: Time is 00:27:33, first loop at 00:28:00 in 27 seconds...
[13.02.2025] [00:28:02] [ERROR] [QA_DOMOCHARTS_54]: http://192.168.1.8:80/domocharts/data.php => Error #HY000 => SQLSTATE[HY000]: General error: 130 Incorrect file format 'domocharts_temperature'
[13.02.2025] [00:28:02] [WARNING] [QA_DOMOCHARTS_54]: Memorize 192 sensors data

et j'ai cela dans mysql qui ne me semble pas correct

 

 

sql.png

Modifié par flacon030
Posté(e)

On dirait bien que tu as 3 tables qui ont crashé... :(

 

Tu peux essayer de les vider complètement, pour cela tu vas sur une table, puis tu cliques sur l'onglet Opérations, et ensuite "Vider la table (TRUNCATE)"

 

image.thumb.png.7f6dea0cfd5fb19c689eaf8eabdb081c.png

 

 

Généralement ça suffit.

Si jamais cela ne fonctionne pas, alors il faudra supprimer complètement les tables incriminées et les recréer manuellement.

 

 

 

  • Like 1
Posté(e)

Merci c'est se que j'ai fait, j'ai supprimé les tables en défauts et importé d'ancienne tables d'un précédent backup

 

A ce sujet quel solution utilisez vous pour faire un backup de vos tables mysql

car j'utilisais mysqldumper mais il ne fonctionnait que sous php7.4 et donc non fonctionnel a ce jour

Posté(e)

Je fais 2 sauvegardes par jour.


Une première, de la base SQL complète, avec les outils natifs proposés par Synology, à savoir l'application Hyper Backup.

 

image.thumb.png.e4cdd1a4619573be0f7070d00a58c7b1.png

 

C'est utile en cas de besoin de restauration complète, après un crash du NAS par exemple.

 

Et une seconde, avec un script Shell qui fait un dump de chaque base avec la commande mysqldump, script lancé par le Planificateur de tâches de DSM (équivalent d'une crontab d'un Linux classique)

 

image.thumb.png.92e8a860aab3fcf10a49641acf1a42ef.png

 

Utile pour une restauration granulaire, d'une seule base, voire d'une seule table si on l'extrait manuellement du fichier généré.

 

backup-mariadb.sh

 

  • Like 1
Posté(e)

Pas de chance.. je ne connais pas QNAP et je ne peux pas t'aider plus que ça, mais je suis persuadé qu'il y a tout un écosystème équivalent au DSM de Synology.... après tout c'est leur principal concurrent.

 

En ce qui concerne le script de sauvegarde, ça reste du Shell tout ce qu'il y a de plus universel, ça tournera sur n'importe quel environnement Linux, et même un Raspberry PI (j'ai utilisé ce script pendant des années dessus...), il faut juste adapter/supprimer toutes les lignes de notifications (push et email) car elles se basent sur les mécanismes propres à Syno.

Le cœur du script utilise mysqldump, qui est l'outil universel de sauvegarde des bases de données MySQL/MariaDB, toujours présent dès qu'une base SQL est installée.

×
×
  • Créer...