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 1
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
×
×
  • Créer...