ws2-550 @ 2.0.290b : start period should be anterior...

Une question, un bug ?
Répondre
antooine
Nouveau membre
Messages : 3
Inscription : mar. déc. 29, 2009 12:49 am

ws2-550 @ 2.0.290b : start period should be anterior...

Message par antooine »

Bonjour,

Tout d'abord, merci pour le super travail fourni sur GraphWeather, cela fait plaisir de voir un logiciel actif comme cela et de cette qualité !

Pour en venir à mon problème, j'essaye de faire fonctionner GraphWeather avec une ws2-550.
J'ai pour cela suivi les instructions de de ce sujet, ce qui m'a bien aidé.
Au passage, j'ai légèrement modifié la vue postgreSQL comme ceci, pour (tenter de) la rendre compatible avec GraphWeather 2.0.290b. La vue retourne plusieurs lignes de données en la testant sur pgadmin.

Code : Tout sélectionner

CREATE OR REPLACE VIEW Meteo AS SELECT
EXTRACT(EPOCH FROM a.savetime)as Tstamp,
a.weatherdata AS temp_out, b.weatherdata AS rel_hum_out,
g.weatherdata AS temp_in, h.weatherdata AS rel_hum_in, c.raincounter as rain_total,
c.counteramount, d.weatherdata AS rel_pressure, e.degree as wind_angle,i.counteramount as SolarRad ,
e.fluctuation, f.weatherdata AS windspeed,
0 as dewpoint, 0 as wind_chill
FROM outside_temp a, outside_hum b,inside_temp g, inside_hum h, rainfall c,
airpressure d, winddirection e, windforce f,sunshine i
WHERE a.savetime = b.savetime AND a.savetime = c.savetime AND a.savetime = d.savetime
AND a.savetime = e.savetime AND a.savetime = f.savetime AND a.savetime = g.savetime AND a.savetime = h.savetime AND a.savetime = i.savetime ;
GraphWeather se lance correctement, par contre les graphes sont à zéro. Puis, lorsque je clique sur le bouton "voir les statistiques", j'obtiens le message "la base de données de statistiques est inexistante. Souhaitez-vous la créer maintenant ?". Je clique sur "oui", et après quelques secondes j'obtiens l'erreur suivante :
"Start period should be anterior to end period".

Auriez-vous une piste sur laquelle m'orienter ? Y a t-il un moyen de s'assurer que GraphWeather récupère les données correctement, autre que par la lecture des graphes générés ?
Merci d'avance
Avatar de l’utilisateur
jturlier
Membre
Messages : 3150
Inscription : mar. août 22, 2006 8:38 am
Localisation : 34410 Sérignan - Languedoc
Contact :

Re: ws2-550 @ 2.0.290b : start period should be anterior...

Message par jturlier »

bonjour Antoine,
Puisque ta vue semble correcte (tu as des lignes avec pgadmin), je te suggère de vérifier que le contenu du champ Tstamp que tu obtiens correspond bien à des dates valides. (Il existe de nombreux sites qui à partir d'un tstamp unix te donnent la date en réel). Cela semble la première chose à vérifier.
Le fait d'ajouter des colonnes pour une "compatibilité" était absolument inutile, il suffit de ne pas mapper ces champs avec les sondes de GW, tu n'as pas par exemple la base des nuages, la pression de vapeur, le heatindex... et pourtant GW fonctionne.
Si tes difficultés persistent, mets un extrait de ta vue et des fichiers de config (config.cfg, odbc_base.cfg) pour qu'on puisse y jeter un coup d'oeil.

Jean
Avatar de l’utilisateur
jturlier
Membre
Messages : 3150
Inscription : mar. août 22, 2006 8:38 am
Localisation : 34410 Sérignan - Languedoc
Contact :

Re: ws2-550 @ 2.0.290b : start period should be anterior...

Message par jturlier »

Pour info,

Voici une requête qui fonctionne.
Pour pallier le risque de rupture de séquence sur le TS (qui pourrait provoquer le type d'erreur que tu signales), j'ai rajouté un order by

CREATE OR REPLACE VIEW meteo AS
SELECT date_part('epoch'::text, a.savetime) AS tstamp, (((substr(a.savetime::text, 1, 4) || substr(a.savetime::text, 6, 2)) || substr(a.savetime::text, 9, 2)) || substr(a.savetime::text, 12, 2)) || substr(a.savetime::text, 15, 2) AS recdate, a.weatherdata AS outdoor_temp, b.weatherdata AS outdoor_hum, g.weatherdata AS indoor_temp, h.weatherdata AS indoor_hum, c.raincounter AS rainfall, c.counteramount, d.weatherdata AS barometer, e.degree AS winddirection, i.counteramount AS solarrad, e.fluctuation, f.weatherdata AS wind
FROM outside_temp a, outside_hum b, inside_temp g, inside_hum h, rainfall c, airpressure d, winddirection e, windforce f, sunshine i
WHERE a.savetime = b.savetime AND a.savetime = c.savetime AND a.savetime = d.savetime AND a.savetime = e.savetime AND a.savetime = f.savetime AND a.savetime = g.savetime AND a.savetime = h.savetime AND a.savetime = i.savetime
ORDER BY date_part('epoch'::text, a.savetime);



Si tu fais tourner cette requête, tu seras amené à faire un "drop" de ta vue avant de pouvoir la recréer.

Jean
antooine
Nouveau membre
Messages : 3
Inscription : mar. déc. 29, 2009 12:49 am

Re: ws2-550 @ 2.0.290b : start period should be anterior...

Message par antooine »

Bonjour Jean,

Merci pour tes pistes. J'ai recréé la vue avec le code que tu m'as suggéré, avec le "order by".
Voici pour info les 3 dernières lignes renvoyées par la vue :

Code : Tout sélectionner

1262113260;"200912292001";;;19.1;53;;0;971;;0;;
1262113560;"200912292006";;;19;53;;0;971;;0;;
1262113800;"200912292010";;;19.1;53;;0;971;;0;;
Actuellement, seules les valeurs {indoor_temp, indoor_hum et barometer} sont enregistrées car j'ai déconnecté le "capteur combi", le temps de le monter à son emplacement définitif dans le jardin :-)

Autrement, les timestamps semblent corrects, j'ai également revu le mapping des champs de la vue avec GW comme tu l'as suggéré !
J'ai cependant toujours le même problème au moment de la création de la BD des statistiques : start period should be anterior to end period.

Ci-joint mes fichiers de configuration...
Vous ne pouvez pas consulter les pièces jointes insérées à ce message.
Avatar de l’utilisateur
jturlier
Membre
Messages : 3150
Inscription : mar. août 22, 2006 8:38 am
Localisation : 34410 Sérignan - Languedoc
Contact :

Re: ws2-550 @ 2.0.290b : start period should be anterior...

Message par jturlier »

Bonsoir Antoine,
à première vue ton plugin odbc est mal configuré
tu devrais avoir "A partir d'un timstamp unix associé au champ --> tstamp" (c'est le nom du champ que tu utilises pour la date, le champ recdate donne une date -- normalement UTC-- en clair mais entre quotes, donc si tu préfères l'utiliser, il faudrait faire un cast pour le transformer en bigint) et ne rien avoir ds le format date.

+ et c'est secondaire, tu devrais avoir pression absolue -> barometer
ne rien avoir ds pression relative, puisqu'elle est calculée par GW en fonction de ton altitude

Je ne suis pas allé plus loin ds l'examen de ton config, il faut déjà régler ce pb.

Bonne soirée

Jean
antooine
Nouveau membre
Messages : 3
Inscription : mar. déc. 29, 2009 12:49 am

Re: ws2-550 @ 2.0.290b : start period should be anterior...

Message par antooine »

jturlier a écrit : tu devrais avoir "A partir d'un timstamp unix associé au champ --> tstamp" (c'est le nom du champ que tu utilises pour la date, le champ recdate donne une date -- normalement UTC-- en clair mais entre quotes, donc si tu préfères l'utiliser, il faudrait faire un cast pour le transformer en bigint) et ne rien avoir ds le format date.
J'avais effectivement indiqué "1" comme valeur pour la zone "A partir d'un timestamp unix associé au champ", car j'avais vu cela sur une capture d'écran dans ton fichier ws2-550gw.odt.
En indiquant "tstamp", j'obtiens l'erreur "Ce type de champ date n'est pas supporté".
Par contre, en choisissant l'option "a partir d'une date formatée" / "champ date (et heure)" avec "recdate" et "%Y%m%d%H%M", ça marche du tonnerre !!!
Super, un grand merci pour ton aide :D
jturlier a écrit : + et c'est secondaire, tu devrais avoir pression absolue -> barometer
ne rien avoir ds pression relative, puisqu'elle est calculée par GW en fonction de ton altitude
Merci, c'est corrigé :-)
Répondre