GraphWeather et Base MySQL

[jmm1]

Bonjour,

Question bete que je n'ai pas trouvé dans les sujets :
Si je veux aller piocher mes données dans une base MySQL contenant plusieurs tables corespondant a plusieurs sytemes d'acquision, a quel endroit de la configuration du plugin puis-je spécifier le nom de la table a utiliser ?
Merci d'avance.

[TiToine]

Bonjour,

Le nom de la table est a mettre dans le fichier source pour la version 1.6.1. Pour la version 2.0.80a il faut la mettre dans le gestionnaire de sources, options > préférences > Général > Sources de données. On ne peut mettre qu'une seule source de donnée, donc une table.

[jturlier]

Petite précision : 1 table par plugin, comme tu en as 2 optionnels, tu peux accéder à 3 tables.
La seule contrainte est qu'elles doivent être ds la même base de données.
Tu as aussi la possibilité de lancer 2 fois GW.

[jmm1]

Oui merci, j'avais vu pour les 3 plugins.
Ca a l'air de bien se connecter, de bien balayer mes tables sans erreur..
J'ai bien les bonnes correspondances de champs, et j'ai bien bien vérifié mes patterns pour les colonnes de type date et time (de type 2008-04-12 et 08:05:00.)
Hélas mes graphes restent désespérement vides, les dates de plage affichées sur le graphique sont figées au 01/01/1970 en start et stop, quoi que je mette comme valeur dans le panneau de controle au niveau de la plage de date a traiter. j'ai encore du louper qque chose. C'est vrais que c'est beaucoup plus complexe a paramétrer qu'il n'y parait de prime abord quand on découvre le produit dont l'interface a l'air assez simple.

Format de ma table :
mysql> describe localstation;
+-------------+----------------------+------+-----+------------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+----------------------+------+-----+------------+-------+
| mdate | date | | PRI | 0000-00-00 | |
| mtime | time | | PRI | 00:00:00 | |
| in_temp | double(2,1) | YES | | 0.0 | |
| out_temp | double(2,1) | YES | | 0.0 | |
| in_humid | int(3) unsigned | YES | | 0 | |
| out_humid | int(3) unsigned | YES | | 0 | |
| dewpoint | double | YES | | 0 | |
| windchill | double | YES | | 0 | |
| windspeed | double(3,1) | YES | | 0.0 | |
| winddir | double | YES | | 0 | |
| rain_tot | double(4,1) | YES | | 0.0 | |
| rain_24 | double(3,1) | YES | | 0.0 | |
| rain_01 | double(3,1) | YES | | 0.0 | |
| press_abs | double(4,1) | YES | | 0.0 | |
| press_rel | double(4,1) | YES | | 0.0 | |
| storm | smallint(1) unsigned | YES | | 0 | |
| Forecast | tinyint(4) | YES | | -1 | |
| Tendency | tinyint(4) | YES | | -1 | |
| winddirname | char(3) | YES | | --- | |
+-------------+----------------------+------+-----+------------+-------+
19 rows in set (0.00 sec)

Configuration du plugin qui va interroger cette table :

[GENERAL]
DataFilter=1
PressureShift=0.0
[SQL]
Server=xxxxxxx (private)
Base=meteo
Login=yyyyyyy (private)
Driver=MySQL ODBC 3.51 Driver
Password= zzzzzz (private)
[MAP]
SQLUnits=0
TimeType=2
Timezone=1
Timestamp=
Date=mdate
DateFormat=%Y-%m-%d
Time=mtime
TimeFormat=%H:%M:%S
DateDST=1
Probe_00=press_abs
Probe_01=press_rel
Probe_02=rain_tot
Probe_03=
Probe_04=in_temp
Probe_05=out_temp
Probe_06=in_humid
Probe_07=out_humid
Probe_08=
Probe_09=windspeed
Probe_10=winddir
Probe_11=
Probe_12=windchill
Probe_13=
Probe_14=
Probe_15=
Probe_16=
Probe_17=rain_01
Probe_18=rain_24
Probe_19=
Probe_20=
Probe_21=
Probe_22=
Probe_23=
Probe_24=
Probe_25=
Probe_26=
Probe_27=
Probe_28=
Probe_29=
Probe_30=
Probe_31=
Probe_32=

[jturlier]

TimeFormat=%H:%M:%S
devrait en principe être
TimeFormat=%H:%M:%s

[jturlier]

Oublie ma précédente réponse, je crains que les formats date et time de mysql ne soient pas appropriés. En ce qui me concerne, et quelle que soit le moteur (Mysql, postgressql et mssql, mes dates sont en format string. Antoine pourra nous dire s'il est possible de traiter ce genre de champ (qui ne peut pas être du ts unix étant donné que tu as 1 champ date et un champ heure)

[jturlier]

Si c'est bien ça le pb, et que tu ne puisses pas recharger ta table en modifiant lest types des champs, tu as sans doute la possibilité de créer une view (que tu attaqueras avec GW) sur ta table, où les champs mdate et mtime seront convertis en string avec une fonction date_format.... à voir

[TiToine]

Salut,

Normalement ces champs sont lus sans problèmes. Il faudrait que tu m'envoies ta base ou une partie pour que je teste.

Antoine.

[jmm1]

Bon, si je remplace %S par %s dans le patern d'heure du plugin MySQL, alors des que je clique sur "nouvel onglet" l'application crashe avec un dr Watson a la clé. des que je remet %S, ca ne crashe pas, mais ca ne dessine rien.

Si je supprime la défiinition du pattern d'heure, que je n'utilsie plus que le pattern de date, alors il y a une trace sur le graphique mais qui ne correspond qu'a une seule mesure par jour... dommage...

[jmm1]

Bon, il y a bien un souci qui fait crasher l'application suivant le pattern que l'on entre comme format d'heure dans le plugin MySQL.

mon champ de type time est de format 22:35:04
mon pattern devrait être, comme le fait judicieusement remarquer Antoine, %H:%M:%s (s minuscule). Mais le %s fait crasher l'appli, et si je ne le met pas, bien sur, aucun heure ne correspond au pattern. Si je met autre chose que %s, par exemple %S, l'appli ne crashe plus. j'en déduis donc que c'est la bonne lecture de mon champ heure qui fait planter GraphWeather.

Quelqu'un aurait il une idée ? (sachant que ma base servant a mon systeme domotique et à d'autres applications, il est bien entendu hors de question que je change sa structure).
Merci.

[jturlier]

Bonjour, comme je te l'ai indiqué précédemment, tu as sans doute la possibilité de créer une vue sur ta table, je pense que ça devrait fonctionner puisque date_format convertit en string (et que les strings sont OK ds GW) à moins que que le pb ne soit lié au traitement de "time":

CREATE VIEW VueMeteo AS select mdate, date_format(mtime,"%H%i%s") as mtime,in_temp,out_temp,........ from TableMeteo;

Si le pb est lié au traitement de time, tu peux alors grouper les champs (J'ai un champ unique pour date et heure ds mes tables donc ça devrait aussi être bon !)
CREATE VIEW VueMeteo AS select concat( date_format(mdate,"%Y%m%d"), date_format(mtime,"%H%i%s") as DateHeure,.....

Si tout ça ne fonctionne pas, ça peut être le traitement des secondes ds GW, et alors tu les supprimes, aucun relevé ne nécessitant en principe ce niveau de détail !

Cela ne prend aucune ressource disque excepté le texte de la requête. Il est souhaitable que tu aies au moins un champ en index (Il ne devrait pas y avoir de pb si tu as une clé primaire) pour accélérer le traitement.
Tu remplaces TableMeteo Par VueMeteo ds le source du plugin de GW et tu mets le format du temps conforme à celui utilisé ds ta requête, ici %H%M%S.
Cela ne prend que quelques secondes pour créer la requête et te permettra d'attendre une correction éventuelle si c'est un bug.
Personnellement je préfère utiliser Mysql administrator pour ce genre de manip, mais n'importe quel outil permettant d'exécuter du SQL est OK.
Evite aussi d'utiliser les `pour entourer les noms de champs pour garder la compatibilité avec les normes SQL Officielles. (tant que tu n'utilises pas de caractères spéciaux ou d'espaces ds tes noms de champs, ça ne pose pas pb "_" est correct.)

[rdem]

Bonjour,

J'ai eu le même problème quand j'ai démarré avec graphweather.
Je l'ai résolu en incorporant un nouveau champ "timestamp" dans ma base et en l'alimentant automatiquement par un trigger.
Pour plus de précision voir mon message de l'époque : viewtopic.php?f=2&t=335&p=2460&hilit=trigger#p2460

Raphaël

[jturlier]

Bonjour Raphaël,
tu as raison c'est une solution valide qd tu crées ta table, et que tu as une source de données avec son format non modifiable : le trigger se déclenche qd tu fais une opé de modif des data de ta table (Update Insert ou Delete).
A ce que j'ai compris du pb de jmm1, c'est que la table était déjà chargée, donc ds ce cas la solution du trigger ne peut pas fonctionner, d'où la suggestion d'une View.
Par contre je ne sais pas si ça a fonctionné puisqu'il n'y a eu aucun feedback.

[rdem]

Re,

Le trigger que j'ai proposé ne fonctionne effectivement que pour les nouveaux enregistrements (et c'est tout son intérêt), mais rien n'empêche de faire un update sur tous les enregistrements en utilisant la même formule que pour le trigger.

Raphaël

[jturlier]

Raphaël,
C'est bien vu !
je n'avais pas pensé à ça, créer le champ et faire une query d'update à partir des champs existants. Je dois vieillir !