Page 1 sur 1

bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 05 janv. 2015, 12:48
par Tudgur
%curminmaxhour[4,1,37]% donne l’ensoleillement de la dernière heure.

Sun time last hour %curminmaxhour[4,1,37]%

%valuechange[37]=9% donne l'ensoleillement de 10 dernières minutes (ce devrait être des 9 dernières d'après Werner).

Value change *%valuechange[x]=mm% x = -1 .. 46 V2.91.4
in the last mm = 1..60 -> if 'mm' is smaller then the recording interval, then
minutes (mm) for mm the recording interval is used.


Le premier tag peut retourner 60 min alors que, simultanément, le second va retourner 9 min, ce qui n'est pas possible !

Ces deux tags sont affichés sur ma console, sous la durée d'ensoleillement.
Mais, il faut
- qu'il y ait eu ou qu'il y ait du soleil
- qu'il y ait eu la possibilité de 10 min de soleil après le lever pour l'un
- qu"il y ait eu la possibilité d'une heure de soleil après le lever pour l'autre

Parmi les tags utilisés, il y a aussi : %valuechange[37]=60% pour la variation d'ensoleillement sur 60 min.
Mais %valuechange[37]=59% donne aussi 60 minutes !!!
De même que %valuechange[37]=9% donne 10 minutes...

J'ai créé un fichier pour "surveiller" ces 3 tags : http://meteo-serre-chevalier.fr/ensolei ... _10min.php

Un exemple ici :

Image

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 06 janv. 2015, 14:07
par webmaster
Bonjour,

Effectivement, quel est ton pas de relevé ?
Je pense qu'il serait judicieux de demande à Werner, car pour le coup je doute que nous trouvions une réponse.

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 06 janv. 2015, 15:54
par Tudgur
Le pas est de une minute.

Il me semble avoir déjà fait parvenir un mail à Werner, à ce sujet, mais sans réponse.
Il faudrait peut-être que je réitère ma demande.

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 13 janv. 2015, 11:03
par mm91
Tudgur a écrit :%curminmaxhour[4,1,37]% donne l’ensoleillement de la dernière heure.

Sun time last hour %curminmaxhour[4,1,37]%

%valuechange[37]=9% donne l'ensoleillement de 10 dernières minutes (ce devrait être des 9 dernières d'après Werner).

Value change *%valuechange[x]=mm% x = -1 .. 46 V2.91.4
in the last mm = 1..60 -> if 'mm' is smaller then the recording interval, then
minutes (mm) for mm the recording interval is used.


Le premier tag peut retourner 60 min alors que, simultanément, le second va retourner 9 min, ce qui n'est pas possible !
................................
J'ai bien relu ta question mais je ne la comprends pas !

1/
pourquoi dis-tu qu'il n'est pas possible qu'il y ait eu 60 mn de soleil pendant une heure et simultanément 9 mn de soleil pendant 9 mn ?

Pour moi c'est parfaitement possible !!


2/
le tag %valuechange[37]=9%
doit donner la variation de la valeur 37 sur 9 mn
Or si ton pas est de 1 mn (5 mn chez moi) la valeur 37 ne peut être que 0mn ou 1mn (0mn ou 5mn chez moi), et donc la variation (sur 9 mn, ou sur une durée quelconque d'ailleurs ! ) ne peut être que 0 ou 1 (0 ou 5 chez moi)


Pour essai provisoire j'ai mis ce tag ainsi que le tag %valuechange[2]=9% (variation température extérieure, pour surveiller le fonctionnement) tout en bas de ma page:
http://icare.cinq.free.fr/meteo/courrent.html

Dans cette page la durée d'ensoleillement / dernière heure est le tag:
%curminmaxhour[4,1,37]%


Rappel:
Définition du tag (traduction de Chriss)

*%tempchange[x]=mm% x = 0 .. 16, 43, 44 Variation de la température de la sonde choisit durant une période de 1 à 60 min.
mm= 1 à 60 (en min) => Temps choisit pour étudier la variation Si mm est inférieur au pas de réception alors la variation sera calculé sur ce pas. Si mm>60 ou si quelque chose d'autre est mis alors le signe"?" sera affiché par ce tag.

*%valuechange[x]=mm% x = -1 .. 46 Variation de la valeur de la sonde choisit. Même principe que précédemment. mm= 1 à 60 min.

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 07:43
par Tudgur
Tu n'as pas bien lu !
Le tag %valuechange[37]=10% doit donner la variation d'ensoleillement sur 10 minutes.
Alors comment se fait-il que le tag %valuechange[37]=9% donne aussi 10 minutes ? (quand il fait beau bien sûr)
Jette un œil au fichier que j'ai joint plus haut.

Pour avoir l'ensoleillement des 10 dernières minutes je suis donc obligé d'utiliser ce dernier tag...

De même, comme déjà dit, comment le tag %valuechange[37]=59% peut-il donner 60 ???
mm91 a écrit :le tag %valuechange[37]=9% doit donner la variation de la valeur 37 sur 9 mn
Or si ton pas est de 1 mn (5 mn chez moi) la valeur 37 ne peut être que 0mn ou 1mn (0mn ou 5mn chez moi), et donc la variation (sur 9 mn, ou sur une durée quelconque d'ailleurs ! ) ne peut être que 0 ou 1 (0 ou 5 chez moi)
?????? Là, c'est moi qui ne te comprends pas !!!!
Ce que tu appelles "valeur 37" c'est l'ensoleillement...
Comment sa variation sur 9 minutes ou une durée quelconque ne pourrait être égale qu'à 0 ou 1 ???????
Ce qui est d'ailleurs contredit par les tags :
%valuechange[37]=9% peut donner toutes valeurs entre 0 et 10... (et non pas 0 et 9)
et %valuechange[37]=59% toutes valeurs entre 0 et 60. (et non pas 0 et 59)

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 08:40
par mm91
Tudgur a écrit :Tu n'as pas bien lu !
Le tag %valuechange[37]=10% doit donner la variation d'ensoleillement sur 10 minutes.
Alors comment se fait-il que le tag %valuechange[37]=9% donne aussi 10 minutes ? (quand il fait beau bien sûr)
Jette un œil au fichier que j'ai joint plus haut.

Pour avoir l'ensoleillement des 10 dernières minutes je suis donc obligé d'utiliser ce dernier tag...
OK, j'ai compris !

Je fais l'essai avec 60, 59, 55, 10, 9 et 5 mn en bas de ma page:
http://icare.cinq.free.fr/meteo/courrent.html
(avec mon pas de 5 minutes)

et j'attends le soleil !....

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 08:52
par Tudgur
On s'est croisé !!!
J'ai édité mon message précédent pendant que tu postais...
Ton pas étant de 5 minutes, tu auras sans doute des résultats différents.

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 09:56
par mm91
OK, mon raisonnement était faux (je n'avais jamais utilisé ce tag "valuechange"), je pensai (par erreur) qu'il s'agissait de la variation d'un enregistrement à l'autre pendant "mm" minutes.
Mais il s'agit bien de la variation entre le premier enregistrement (il y a "mm" minutes) et le dernier (ou peut-être l'avant dernier et c'est peut-être justement là qu'est l'erreur ?!)


Pour résumer,
finalement, ce dont tu te plains c'est seulement que les deux tag:

%valuechange[37]=mm%
et
%valuechange[37]=(mm-1)%

donnent la même chose
(ce qui n'est pas normal j'en conviens, mais tu arrives quand même à faire le calcul que tu souhaitais)

C'est bien ça ?



Mes essais permettront de voir si c'est à une minute près (= 1 pas pour toi) ou à un pas près (= 5 mn pour moi)

Petit détail:
dans:
"Station météo / Sondes spéciales / #3",
tout en bas, as-tu bien mis 1 minute pour "durée max par enregistrement ?
(ici j'ai mis 5 minutes bien sûr !)

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 10:18
par Tudgur
mm91 a écrit :Petit détail:
dans:
"Station météo / Sondes spéciales / #3",
tout en bas, as-tu bien mis 1 minute pour "durée max par enregistrement ?
(ici j'ai mis 5 minutes bien sûr !)
Eh non ! Je suis à 5 minutes et le choix 1 minute n'existe pas !!!
Je ne sais plus à quoi cela correspond mais il me semble qu'il y a eu une discussion à ce sujet...
Mon pas de mesure est de 1 minute mais mes enregistrements se font toutes les 5 minutes.(par tâche planifiée)

Sous ce même onglet, il y a aussi :
Etalonnage - minutes avec les choix A, 10, 20, 30, 40, 60, 100, 120, 150, 200
Cela correspond à quoi ?
mm91 a écrit :Pour résumer,
finalement, ce dont tu te plains c'est seulement que les deux tag:

%valuechange[37]=mm%
et
%valuechange[37]=(mm-1)%

donnent la même chose
(ce qui n'est pas normal j'en conviens, mais tu arrives quand même à faire le calcul que tu souhaitais)

C'est bien ça ?
Le (petit) problème, c'est qu'il arrive que j'affiche sur ma console 60min /1h et simultanément 9 min /10min, ce qui est impossible !!!

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 10:51
par mm91
Tudgur a écrit :
Eh non ! Je suis à 5 minutes et le choix 1 minute n'existe pas !!!
Je ne sais plus à quoi cela correspond mais il me semble qu'il y a eu une discussion à ce sujet...
Mon pas de mesure est de 1 minute mais mes enregistrements se font toutes les 5 minutes.(par tâche planifiée)

Sous ce même onglet, il y a aussi :
Etalonnage - minutes avec les choix A, 10, 20, 30, 40, 60, 100, 120, 150, 200
Cela correspond à quoi ?
Quand on parle du pas d'enregistrement, il s'agit bien sûr de l'enregistrement dans Wswin32, donc c'est 5 mn chez toi ? (comme chez moi)

Donc la "durée max par enregistrement" doit être réglé sur 5 mn

Ce réglage sert uniquement lorsque le pas d'enregistrement est très long (par exemple 1 heure), dans ce cas on peut estimer (par exemple) que statistiquement, pendant cette heure il n'y a pas eu une heure de soleil mais 50 minutes (par exemple).
Idem pour durée de pluie.


La fonction "Etalonnage" sert à déterminer l'échelle sur les graphiques (pour l'échelle de temps des durées soleil et durées pluie)
J'utilise "A" = échelle automatique (ainsi elle s'adapte quand je change l'échelle: semaine, mois, etc.)

exemple:
l'échelle tout à droite sur un graphique jour (de 0 à 30 minutes):
Image


et sur un graphique semaine (de 0 à 10 heures):

Image


Le (petit) problème, c'est qu'il arrive que j'affiche sur ma console 60min /1h et simultanément 9 min /10min, ce qui est impossible !!!
OK, je comprends,
s'il y a eu 60mn/h c'est 100% de durée d'ensoleillement,
donc forcément 10mn / 10 mn

mais avec 9 mn /10 mn l'erreur n'est que de 1 mn !
Le plus important est que le total (par jour, semaine…année) soit bon.

Au fait, je me demande si ton problème ne vient pas du fait que ton pas de mesure est de 1 mn et ton pas d'enregistrement est de 5 mn ?????

A surveiller ce que ça donne chez moi.

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 11:34
par Tudgur
mm91 a écrit :Quand on parle du pas d'enregistrement, il s'agit bien sûr de l'enregistrement dans Wswin32, donc c'est 5 mn chez toi ? (comme chez moi)

Donc la "durée max par enregistrement" doit être réglé sur 5 mn
Mon pas d'enregistrement est de 1 minute, c'est à dire que j'ai une ligne de données par minute.
Mais je démarre WsWin toutes les 5 min : il va alors enregistrer 5 lignes de données.
mm91 a écrit :Ce réglage sert uniquement lorsque le pas d'enregistrement est très long (par exemple 1 heure), dans ce cas on peut estimer (par exemple) que statistiquement, pendant cette heure il n'y a pas eu une heure de soleil mais 50 minutes (par exemple).
Idem pour durée de pluie.
????
mm91 a écrit :La fonction "Etalonnage" sert à déterminer l'échelle sur les graphiques (pour l'échelle de temps des durées soleil et durées pluie)
J'utilise "A" = échelle automatique (ainsi elle s'adapte quand je change l'échelle: semaine, mois, etc.)
Chez moi c'est sur 20.
Le graphique jour a une échelle de 0 à 20 min
Le graphique semaine, de 0 à 10h
Et le graphique mois, de 0 à 100h

Donc, l'échelle est tout de même automatique !
Par le menu Fichier / Propriétés, on peut choisir l'amplitude des mesures, le "quadrillage" et l'échelle auto ou pas...

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 14:03
par mm91
Tudgur a écrit : ...........
????
..........
Chez moi c'est sur 20.
Le graphique jour a une échelle de 0 à 20 min
Le graphique semaine, de 0 à 10h
Et le graphique mois, de 0 à 100h

Donc, l'échelle est tout de même automatique !
Par le menu Fichier / Propriétés, on peut choisir l'amplitude des mesures, le "quadrillage" et l'échelle auto ou pas...
Dans Wswin32, une échelle fixe est toujours une échelle minimum.
Si l'échelle fixe est trop petite l'échelle devient automatique.
Ainsi aucune valeur ne peut dépasser l'échelle.

Ceci est vrai aussi bien pour les échelles verticales du graphique (dans Fichier / Prpriétés...) que pour les échelle verticales de durée pluie et durée ensoleillement.
(voir ci-dessous)


Dans "Fichier / Propriétés" on ne peut pas régler les échelles verticales de temps (durée ensoleillement et durée pluie), ni en fixe ni en auto, celles-ci sont grisées.

Ces deux échelles verticales se règlent (comme indiqué précédemment) dans "Station météo / Sondes spéciales / #3")


Concernant le réglage "durée max par enregistrement", c'est expliqué (sommairement) dans l'Aide.
Je peux t'expliquer mieux (ce n'est pas mystérieux et c' est tout à fait logique), mais on est peut-être hors sujet.
(éventuellement ouvrir un sujet spécial).


Concernant le défaut du tag "valuechange", j'ai une petite idée, mais j'attends les résultats de mes essais en bas de ma page http://icare.cinq.free.fr/meteo/courrent.html
(quand il y aura du soleil assez longtemps !…)

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 15:17
par Tudgur
mm91 a écrit :Dans Wswin32, une échelle fixe est toujours une échelle minimum.
Si l'échelle fixe est trop petite l'échelle devient automatique.
Ainsi aucune valeur ne peut dépasser l'échelle.

Ceci est vrai aussi bien pour les échelles verticales du graphique (dans Fichier / Prpriétés...) que pour les échelle verticales de durée pluie et durée ensoleillement.
(voir ci-dessous)

Dans "Fichier / Propriétés" on ne peut pas régler les échelles verticales de temps (durée ensoleillement et durée pluie), ni en fixe ni en auto, celles-ci sont grisées.

Ces deux échelles verticales se règlent (comme indiqué précédemment) dans "Station météo / Sondes spéciales / #3")
OK pour les échelles.
mm91 a écrit :Concernant le réglage "durée max par enregistrement", c'est expliqué (sommairement) dans l'Aide.
Je peux t'expliquer mieux (ce n'est pas mystérieux et c' est tout à fait logique), mais on est peut-être hors sujet.
(éventuellement ouvrir un sujet spécial).
Je vais essayer de trouver le fichier d'aide...
mm91 a écrit :Concernant le défaut du tag "valuechange", j'ai une petite idée, mais j'attends les résultats de mes essais en bas de ma page http://icare.cinq.free.fr/meteo/courrent.html
(quand il y aura du soleil assez longtemps !…)
En fait, en bas de ma console, j'utilise %curminmaxhour[4,1,37]% pour l'ensoleillement de la dernière heure et %valuechange[37]=9% pour l'ensoleillement des 10 dernières minutes.
Il me semble que le problème se pose quand il y a eu un trou dans l'ensoleillement...
Y aurait-il un décalage de la minute de départ de la mesure ?

Edit
Je ne comprends pas l'aide de Werner :
Minutes – maximally time per recording
The sun time always is determined from the time distance between current and the prior measurement.
If the "prior" measurement is very much the off far from the current measurement now, so one can restrict the at most to collected sun time for it with it.


La durée d'ensoleillement est toujours calculée à partir du temps qui sépare la mesure courante de la mesure précédente. (et alors ???)
Si la mesure précédente est très éloignée de la mesure courante, alors on peut restreindre...????

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 18:55
par mm91
Tudgur a écrit : ...............
Edit
Je ne comprends pas l'aide de Werner :
Minutes – maximally time per recording
The sun time always is determined from the time distance between current and the prior measurement.
If the "prior" measurement is very much the off far from the current measurement now, so one can restrict the at most to collected sun time for it with it.



La durée d'ensoleillement est toujours calculée à partir du temps qui sépare la mesure courante de la mesure précédente. (et alors ???)
Si la mesure précédente est très éloignée de la mesure courante, alors on peut restreindre...????
Oui, dans ce cas il faut restreindre !

Les enregistrements dans une station et dans wswin32 sont des valeurs instantanées.
(ou tout au moins moyennées seulement par l'inertie des capteurs)

Par exemple si à 19h10 il fait 6.2°C et à 19h 15 il fait 6.3°C, cela n'empêche pas qu'entre les deux il a pu faire 7°C
Pour la température c'est peu probable (mais c'est aussi pour cela qu'on choisi un pas d'enregistrement petit).

Maintenant prenons l'exemple de l'ensoleillement:
(le problème est exactement le même pour la durée de la pluie)

à chaque pas (5 mn pour moi), wswin32 mesure et calcule s'il fait soleil;
s'il trouve qu'il fait soleil 2 mesures de suite il comptabilisera 5 mn de soleil ce qui a toutes les chances d'être vrai.

Maintenant suppose que le pas de mesure et d'enregistrement soit de une heure; il peut très bien faire soleil au moment de la mesure, mais ne plus faire soleil entre deux mesures.
Mais ni la station ni wswin32 ne peuvent le savoir, donc la seule façon de corriger est de faire une estimation statistique:
par exemple on peut se rendre compte qu'en moyenne (sur au moins un mois par exemple), quand wswin32 mesure du soleil deux mesures de suite (donc pendant 1 heure) il n'y a fait soleil que seulement pendant 40 minutes (je dis bien en moyenne)

Alors, dans ce cas, on mettra 40 min dans "maximum par enregistrement"
(on peut entrer moins que le pas, mais pas plus; c'est normal ! il ne peut pas faire 1h15 de soleil entre deux mesures séparées de 1 heure !)

Et ainsi on pourra s'approcher au mieux des cumuls réels d'ensoleillement.

J'avais testé ce système, mais il a le gros inconvénient, quand dans une journée il n'y a que du soleil, de comptabiliser beaucoup moins.
(dans le cas ci-dessus, si 8 h de jour complètement ensoleillé, il sera comptabilisé 8*40 mn = 5 h 20)

De toute façon le problème ne se pose pas avec des pas de mesure (à mon avis) inférieurs à 20 minutes.
Mais ça dépend de l'inertie de la mesure; chez moi c'est une mesure de température (corps noir), en cinq minutes la mesure est moyennée donc tout a fait valable (s'il indique du soleil deux pas de suite c'est sûrement qu'il a fait soleil entre les deux, j'ai vérifié)
Chez toi, avec une mesure par pyranomètre (sans doute plus rapide ?) sur cinq ou dix minutes, peut-être faudrait-il faire la correction ?
Mais avec ton pas de 1 minute il n'y a sûrement aucun problème (pas de correction à faire).

Re: bug %curminmaxhour[4,1,37]% et %valuechange[37]=9%

Posté : 14 janv. 2015, 20:15
par Tudgur
Merci pour cette explication très claire.
Mais effectivement, avec un pas de 1 min, il n'y a pas de problème.
Avec ma deuxième console et mon deuxième PC, j'avais fait des test avec un pas de 5 min.
L'ensoleillement augmente de façon significative mais je ne me souviens pas des chiffres !