Je rencontre un probleme bloquant avec le plugin odbc.dll et la base postgreSQL de ma station WS550 (WS2-550).
Le parametrage à la base postegreSQL est OK via ODBC et au moment où je souhaite ajouter une table, GW m'indique que le format du champ date n'est pas supporté.
J'ai essayé plusieurs modif mais sans succés
Avez-vous une idée pour resoudre ce point de blocage ?
Bonsoir,
Tu n'aurais pas dû définir ton champ pgsql en timestamp mais en character.
GW veut traiter un champ formaté et tu lui donnes un timestamp SQL qui a une structure très particulière ( 8 byte integer ou floating point ... l'un ou l'autre) .
GW sait aussi traiter la date/heure en entier long. J'utilise personnellement un bigint de la forme YYYYMMJJHHmm.
Jean
Station : VP2 Pro Console Vue + anémomètre à Ultra-sons
Logiciels : Cumulus 1.9.4 + Cumulus2SQL
Serveur local : Apache + MySQL +PHP
PC : W10
Support Audio : FR
Bonsoir Dolphinfr,
Les timestamps unix et sql sont totalement différents, les unix sont des integers longs et les SQL sont soit des flottants soit des entiers sur 4 bytes.
Je te contacte en MP.
Jean
je me rend compte que la base contient 1 table par sonde et donc dans GW il faudrait pouvoir lier au moins 5 tables se qui ne semble pas être faisable ?
une piste : creer une nouvelle table reprenant toutes les autres mais comment scripter ça pour le faire automatiquement pour les mises à jour
CREATE OR REPLACE VIEW meteo AS SELECT to_text(a.savetime,"YYYYMMDDHH24MI") AS savetime ,a.weatherdata AS outdoor_temp,b.weatherdata AS outdoor_hum, c.weatherdata AS rainfall,....
FROM outdoor_temp a,outdoor_hum b, rainfall c, ....
WHERE a.savetime=b.savetime AND a a.savetime=c.savetime AND a.savetime=d.savetime AND ....
De cette façon, tu utilises dans GW la vue ainsi créée à la place de tes tables.
Dans cette vue
--tu formates directement le champ savetime en tant que texte. (n'ayant pas de possibilité de test, il faudra voir quel est l'impact du TIMEZONE +01),
--tu prends les champs weatherdata de chaque table et tu leur donnes un nom explicite à l'intérieur d'une même vue,
--tu lies toutes tes tables sur leur champ savetime respectifs pour récupérer les données de chacune pour une même date/heure
(en espérant avoir la même date et heure dans chacune des tables ! sans cela il faudra que tu bricoles un peu le WHERE)
Les majuscules et miniscules ne sont pas significatives, uniquement pour la compréhension.
Je penses que le champ savetime est une clé primaire de chacune de tes tables, ce qui fait que le traitement sera plus rapide.
Tu as mes coordonnées, n'hésite pas à me faire parvenir les copies de qq unes de tes tables pour test si tu as des difficultés.
PS avant de faire la création de view tu fais déjà tourner le SELECT tout seul !!!
Jean
Station : VP2 Pro Console Vue + anémomètre à Ultra-sons
Logiciels : Cumulus 1.9.4 + Cumulus2SQL
Serveur local : Apache + MySQL +PHP
PC : W10
Support Audio : FR
merci pour votre aide mais pour la creation de la vue dans postgresql je ne m'en sors pas
j'arrive à creer la requette avec MS Access mais le champ date n'est toujours pas au bon format
connais tu la procedure pour creer la vue avec l'admin de postgresql ?
voici la backup de la base postgresql : http://dl.free.fr/uAn5CNdL0
Base : ws550
login : postgres
password : weather
Bonjour Wilfried,
J'ai téléchargé ta DB et je regarde ça dès que j'ai un moment.
Jean
Station : VP2 Pro Console Vue + anémomètre à Ultra-sons
Logiciels : Cumulus 1.9.4 + Cumulus2SQL
Serveur local : Apache + MySQL +PHP
PC : W10
Support Audio : FR
Tu peux essayer cela, ça fonctionne chez moi, tu peux essayer de rajouter des tables, faire des calculs comme le point de rosée, la température ressentie, etc...
Passe moi un MP si tu as d'autres questions particulières.
CREATE OR REPLACE VIEW meteo AS SELECT
(substr(cast(a.savetime as text),1,4)||
substr(cast(a.savetime as text),6,2)||
substr(cast(a.savetime as text),9,2)||
substr(cast(a.savetime as text),12,2)||
substr(cast(a.savetime as text),15,2)) AS savetime ,
a.weatherdata AS outdoor_temp,
b.weatherdata AS outdoor_hum,
c.raincounter AS raincounter,
c.counteramount AS counteramount,
d.weatherdata AS airpressure,
e.degree AS degree,
e.fluctuation AS fluctuation,
f.weatherdata AS wind
FROM outside_temp a,outside_hum b, rainfall c, airpressure as d, winddirection as e, windforce as f
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;
PS excuse moi de t'avoir appelé Wilfried, j'ai confondu avec wleger.
Jean
Pour créer la vue avec PGAdmin III, il faut sélectionner ta DB (WS550), ensuite dans la seconde ligne du haut (les icônes) sélectionner SQL,
Dans la fenêtre SQL tu fais un copier coller du texte en bleu de mon précédent message, et tu lances avec le triangle vert
En réponse, tu as : La requête a été exécutée avec succès en 13 ms, mais ne renvoie aucun résultat.
C'est tout !
Vous ne pouvez pas consulter les pièces jointes insérées à ce message.
Jean
Station : VP2 Pro Console Vue + anémomètre à Ultra-sons
Logiciels : Cumulus 1.9.4 + Cumulus2SQL
Serveur local : Apache + MySQL +PHP
PC : W10
Support Audio : FR
merci beaucoup pour ce travail et ton aide !
la liaison GaphWeather - WS550 (WS2-550) fonctionne !
il ne reste plus qu'un probleme : la sonde de précipitation
en effet dans la table rainfall de la base ws550 le champ raincounter est incrementé.
Avec GW je ne parviens donc pas à afficher les precipitations.
Avec WeatherProfessional il semble qu'il utilise la table rainfall mais en effectuant une soustraction avec l'enregistrement precedent pour calculer le volume des precipitations
explication en image
Question :
avec PostgreSQL et la vue METEO est il possible de creer une colonne pluie comme dans Weatherprofessional ?
Bonjour,
c'est sans doute possible, à l'aide d'un trigger, mais je ne maitrise pas.
Question : as-tu PHP opérationnel sur ta machine, si c'est le cas on peut trouver une solution.
Jean
Station : VP2 Pro Console Vue + anémomètre à Ultra-sons
Logiciels : Cumulus 1.9.4 + Cumulus2SQL
Serveur local : Apache + MySQL +PHP
PC : W10
Support Audio : FR
Bonsoir,
en regardant de plus près tes tables, ça ne semble pas spécialement une bonne idée de continuer à investir sur des modifs de la db, car tes tables sont très basiques et toutes les données élaborées vont devoir être calculées : point de rosée, wind chill, pluie instantanée, pluie quotidienne, UV, etc... Je pense que tu vas devoir conserver telles quelles tes tables et passer à un traitement spécifique. Il faut fournir à GW des données acceptables sous forme d'une table récap, (ou d'un fichier csv, mais ça serait il me semble ridicule) où l'ensemble des données nécessaires seront regroupées !
Si quelqu'un se sent d'attaque pour créer des triggers, pour récupération préalable de données dans des tables indépendantes, et calcul des données manquantes, il est le bienvenu, et perso ça m'intéresserai de voir jusqu'où on peut aller avec cette technique... donc merci d'avance pour toute info sur le sujet.
WeatherProfessionnal travaille pour lui, avec ses tables, en mode SQL pur, et ne semble absolument pas se préoccuper de fournir des possibilités d'interface avec les applications externes, y compris pour une publication sur le web (dolphinfr, dis-moi si je me trompe, je n'ai trouvé aucune doc en français ou anglais sur ce produit, uniquement un forum vide !). S'il y a des amateurs pour utiliser conjointement WeatherProfessionnal et GraphWeather, je vous déconseille vivement ce choix (dans l'immédiat), à moins de connaitre un peu la programmation (quel que soit le langage utilisé) ainsi que les DB.