Wiki

Vous affichez une ancienne révision du document ! Si vous l'enregistrez, vous créerez une nouvelle version avec ce contenu.

====== Sd cc données energie très grandes ======

Lorsqu'il y a des données d'énergie qui sont gigantesques dans les rapports Solaire Direct Conext Control, ces valeurs faussent de fait les PRRef.

L'origine de ses valeurs gigantesques peut être due à une erreur de communication qui fausse la valeur de l'énergie accumulée minute. Si l'énergie accumulée minute M est inférieure à l'énergie acc mn de la minute M-1, clearscada pense que le compteur a été RAZ. Il prend donc la valeur de l'énergie accumulée minute qui fait le cumul de l'énergie produite sur parfois plusieurs semaines, reçue à la minute M, pour la valeur de l'énergie produite en une minute sur la centrale. D'où des bonds d'énergie produite.

Il faut donc aller voir la valeur de l'énergie minute, voir à quelle minute s'est opéré ce saut. Ces valeurs se trouvent la table** dbo.MEA_GBEMDel**. Il faut noter la minute où l'énergie minute fait un saut pour aller voir si la valeur de l'énergie accumulée minute a subi une "décroissance" (comme expliqué plus haut). Si la valeur de l'énergie accumulée minute est effectivement inférieure à la valeur de la minute précédente, il faut changer la valeur de la minute par la même valeur que l'énergie accumulée minute de la minute précédente. **De sorte de ne pas avoir de décroissances.** Ensuite, on rejoue les fichiers et le tour est joué.

Voir le cas résolu que l'on a eu sur le site de LaVerdière dans le détail du mail en PJ ci-dessous (à télécharger et à ouvrir en .msg au lieu du .pdf).

<WRAP center round download 60>
{{:tma:pv:rex_ai:rapports:re_conext_control_solution_of_solar_bu_-_solaire_direct_reports_nok_after_dailyjob_well_done_ref_00da0absm_50012bqctn_ref_.pdf|}}
</WRAP>

\\ Nouveau cas apparu sur Cestas fin août 2024 :

Problème : données gigantesques sur la journée du 19/08/2024. Nombreuses relances de calculs (update counters + daily job) effectuées mais elles n'ont pas solutionnées le problème de données

\\ Comme indiqué ci-dessus : il faut vérifier la table  **dbo.MEA_GBEMDel**, il doit y avoir l'énergie accumulée minute M qui est inférieure à l'énergie accumulée minute M-1. \\ Pour trouver la minute où la décroissance s'effectue, il faut regarder lorsque la valeur énergie minute (pas l'accumulée) est très importante (ci-dessous le cas qu'on a eu sur Cestas) : {{:tma:pv:rex_ai:rapports:donnees_trop_grandes_cestas_exemple.png?1600|}}

\\ Résolution : Dans notre cas, l'énergie accumulée minute est repartie de la valeur diminuée, je n'ai pas donc pu suivre la procédure ci-dessus en modifiant la valeur accumulée sur la période mauvaise. La procédure effectuée à été un recalcul des données à la main pour un bon affichage dans les rapports Cestas. 
\\ Pour cela, il faut : supprimer la valeur minute M trop grande en la remplaçant par sa valeur M-1. Essayer de faire une relance du daily job seulement (**pas d'update counters sinon les valeur minutes sont recalculées**)
\\ Si cette manipulation ne permet pas de résoudre le problème, il faut remplacer les données dans les tables **Site_Days** et **Site_Hours** (il s'agit des tables qui permettent l'affichage des rapports sur ConextControl). Les bonnes données à remplacer peuvent être recalculées en effectuant des sommes avec la table **dbo.MEA_GBEMDel** dont les données trop grandes ont été supprimées.
\\
<WRAP center round important 80%>
\\ Attention, si l'on doit retravailler les tables **Site_Days** et **Site_Hours**, il ne faut plus relance d'update counters ni de daily job sur la période concernée par les modifications sinon celles-ci seront écrasées.
</WRAP>

{{tag>rapport solaire direct sd cc end compteur accumulée minute energie}}

Résumé

Wiki

Outils pour utilisateurs

Outils du site

Outils de la page