DjMomo

Pour le capteur de fumée, c'est normal, je ne l'ai pas encore adapté pour, je voulais d'abord voir au niveau de la conso de courant.

Pour info, dans la base, les données sont horodatées en temps UTC, ceci afin de ne pas avoir de problèmes les jours de changement d'horaires été/hiver. Pour avoir l'heure réelle, il faut ajouter 2h en été et 1h en hiver. Ainsi 20110917123400 correspond à 12:34:00 UTC le 17/09/2011, soit 14:34:00 le 17/09/2011 heure de Paris. Et 20113112235945 correspond à 23:59:45 UTC le 31/12/2011, soit 00:59:45 le 01/01/2012 heure de Paris.

Fichier mis à jour Mickaël

Bon, ben t'as une version encore différente de la mienne. Peux-tu lancer xpl-log et me donner ce qu'il t'affiche ?

Bonjour Jean-François, Plus de news d'ici la fin de la journée. Pour info, ca tourne nickel sur une USBStation2. Moins de 5% de charge CPU (même avec les accès MySQL) et grosso modo, 8Mo de RAM exploitée.

Bon, j'ai de bonnes nouvelles, je pense avoir enfin sous la main, un fichier banalisé de log MYSQL pour les RXFCOM version TCP/IP (Patrick) et xPL (Mickaël et moi-même). Il permet indifféremment du type de récepteur RFXCOM et de capteur, de logger les infos de ce dernier dans une base unique, évolutive automatiquement lorsque vous rajoutez un capteur ou vous en remplaciez les piles (changement d'adresse). Cela permet, pour ce dernier point, de lier les valeurs de l'ancien capteur (ou avec les anciennes piles) avec le nouveau (nouvelles piles), et sans passer par PhpMyAdmin (faut toutefois développer la petite IHM qui va bien pour faire cela). Mickael, Patrick, je vous mets ca a disposition dans l'après midi afin que vous puissiez tester et me dire ce que vous en pensez.

Bonjour, Si tu débranches ta 9box du réseau, est-ce que cela le calme ?

C'est du perl, c'est grosso modo comme du php, avec quelques différences quand même.

Fiche technique du 211+ : (http://ukdl.synology.com/download/ds/DS211+/DataSheet/Synology_DS211+_Data_Sheet_fra.pdf). Perso, je tourne avec les ST32000641AS (2To Seagate Barracuda XT), se sont des SATA III et ils fonctionnent. Pas à leur capacité maximale du SATA (seulement en II et non en III), ils font 7200trs/mn, et en transfert FTP, je tourne aux alentours de 40Mo/s. Au moment de l'achat, c'étaient pour moi les disques ayant le meilleur rapport/qualité/disponibilité. Donc je ne sais pas ce que cela aurait donné en 5400trs/mn. Et oui, enfin, le blog est inclus dans le NAS, rien à faire si ce n'est l'activer via la Photostation.

Perso, j'essaie de faire un fichier banalisé qui permet de s'adapter à tous les capteurs sans avoir à le modifier dès lors que tu rajoutes un capteur. Te lister les modifications à apporter risque d'être long. Si tu peux être patient jusqu'en début de semaine prochaine, j'aurais très certainement terminé (ce sera peut être le cas même avant).

J'ai des Seagate dans mon DS211+, mais ce dernier n'ayant que quelques semaines, je ne pourrais pas te faire un retour pertinent sur la fiabilité des disques dans ce Syno là...

Je constate aussi parfois ce genre de problème. Ce que je fais, c'est de bien tout arrêter avant (cf script S99xpldaemon de Patrick), puis je relance xpl-hub puis xpl-mysql-logger. Si tu lances xpl-mysql-logger après avoir arrêté xpl-logger, parfois cela ne marche pas. Enfin, comme écrit dans mon post de ce matin 06:58, le format des trames entre version TCP/IP et xPL n'est pas la même, donc le script de Patrick ne devrait pas fonctionner. Il te faut remplacer dans xpl-mysql-logger (dans sub log) $ligne =~ m/.*\> \* - (.*)/; par $ligne =~ m/.*\> \* (\w+ .*)/; et supprime le # en début de ligne de # print $par1, "\n"; Cela te permettra de voir au moins les logs. Après, toujours dans le même post de ce matin, il faut reprendre une partie du code (ce que je suis en train de faire) pour qu'il soit compatible format xPL.

Alors, effectivement, moi aussi j'ai eu des soucis sur le xpl-hub si je ne force pas l'adresse de broadcast à 0.0.0.0. Par contre, pas besoin de la définir sur le xpl-logger. Et je n'ai pas de soucis de connexion à la BDD. As-tu créé un utilisateur avec un mot de passe qui puisse attaquer la BDD comme t'avait répondu Patrick ?

Je vais me baser sur l'exemple d'une seule sonde de température pour illustrer mes propos sur le format de la BDD. La différence entre les 2 tables mesures et relevés est là pour optimiser la BDD et ne pas la charger inutilement. Ce qu'il va se passer, c'est que la table mesures va grandir exponentiellement pour, dans quelques mois (vers les 6 mois), ne plus bouger (à 1 données près par semaine peut-être). Comment ? Grâce au lien entre la table relevés et la table mesures. La table mesures ne contient, comme son nom l'indique, que des mesures (valeur, unité). Pas de référence à un instant ou un capteur. Chaque couple valeur/unité est unique dans la table. Dans 6 mois, tu auras toutes les mesures de température effectuées (de -10 à +50° par exemple). Une ou plusieurs lignes de la table relevés vont alors pointer vers une ligne de la table mesures. Au bout de ces 6 mois, seule la table relevés va grandir, au rythme des relevés effectués, en pointant, à chaque fois, vers une ligne de la table mesures (qui elle, sera fixe). Pour la table relevés, elle va effectivement grossir, mais beaucoup moins que la tienne. Une ligne de ma table relevés (id_capteur, id_mesure, timestamp) est beaucoup moins gourmande en espace (entre 6 et 12 octets au maximum) que pour ton format de table (où tu y enregistres modèle capteur, type, localisation, mesure, date/heure, soit au minimum 11 octets, maxi 325 octets). Pour la table relevés, j'ai repris ton principe de si valeur mesurée = valeur précédente alors on ne l'enregistre pas dans la base. Par contre, il se peut que je ne l'ai pas mis en oeuvre correctement. [*]Pour le champ nouveau_capteur, c'est tout simplement car je ne t'ai pas expliqué à quoi il servait . Il est là pour que, lorsque tu changes les piles (et donc l'adresse de ton capteur), tu puisses lier les mesures du capteur entre ancienne et nouvelle adresse. Lié encore là au format de ma base. Au travers d'une IHM html, ce lien pourra être effectué, en changeant uniquement les id_capteur de la table relevés --> c'est à faire. J'espère que mon explication a été assez claire, sinon dis le moi Je reste ouvert à toute autre suggestion.

Salut, Ca y est, j'ai recu mon RXFLAN, version xPL. Alors, par rapport au tien, Patrick, y'a du changement. Les données sont plus envoyées sous la même forme. Fini les identifiant de capteurs par leur nom, c'est maintenant par catégorie (http://syno.haefling...egon_Scientific). Le format de l'adresse change, lui aussi. Mais en prime, on gagne l'unité sur la mesure et les données sont déparées par des slashs, plus faciles (quoique) à récupérer. Il a donc fallu que je revoie mon fichier de log pour la bdd. Je suis en plein dedans pour intégrer les 2 types de récepteurs et banaliser le tout (avec tes remarques sur les accès multiples à la bdd ). Exemple avec le xpl-logger brut : 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * rain2 0x4200/rainrate/0.00/mmh] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * rain2 0x4200/raintotal/25.40/mm] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * rain2 0x4200/battery/100] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * wind2 0xf700/gust/0.00/mps] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * wind2 0xf700/average-speed/0.00/mps] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * wind2 0xf700/direction/270.0] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * wind2 0xf700/battery/100] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * wind2 0xf700/gust/0.00/mps] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * wind2 0xf700/average-speed/0.00/mps] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * wind2 0xf700/direction/270.0] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * wind2 0xf700/battery/100] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * th2 0x1a01/temp/18.8/c] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * th2 0x1a01/humidity/83/wet] 192.168.1.11:52156 [xpl-trig/sensor.basic: rfxcom-lan.0004a31f6294 -> * th2 0x1a01/battery/100]

Bonjour, As-tu tenté la 3e option de l'image après avoir changé tes disques ? Ceci afin de forcer à étendre le volume avec l'espace disque inutilisé ?

Bonjour, Tout est indiqué là : http://www.synology....ng=enu&q_id=344 De basic à RAID 1 c'est possible sans perte de données (toutefois une sauvegarde est conseillée avant l'opération).

Les inconvénients, c'est que tu ne peux pas personnaliser les droits sur les sous-dossiers. Les utilisateurs auront accès soit à tous les sous-dossiers de la racine, soit à rien du tout. Les droits s'appliquent sur chaque dossier racine et sont propagés aux sous-dossiers de chacun d'eux. Si tu veux déplacer des fichiers dans le NAS lui-même, pourquoi n'utilises-tu pas le navigateur de fichiers dans le DSM ? Les fichiers seront déplacés uniquement dans le NAS, sans avoir à transiter par le PC qui a lancé l'opération.

Bonjour, Le lien que tu proposes ne renvoie pas vers la page de login. L'image est bien affichée (même s'il a fallu un moment avant qu'elle ne s'affiche).

Bonjour, La liste des disques durs compatibles avec le DS211+ se trouve ici : http://www.synology.com/support/hd.php?lang=fre&bays_id=2&product_id=66 Après, la marque, c'est un peu le goût et les couleurs de chacun...

Bonjour, http://www.synology.com/support/faq_show.php?lang=fre&q_id=344 3 disques différents oui, mais de taille supérieure ou égale au premier. Mais l'idéal reste quand même les mêmes modèles de disques.

N'ayant jamais utilisé je serai tenté de dire : past : sauvegarde précédente latest : dernière sauvegarde date du jour : sauvegarde de la journée en question...

C'est un routeur avec firmware officiel ou alors avec le firmware DD-WRT ?

Je viens de m'apercevoir qu'en tant qu'initiateur du topic, on a un outil de modération en bas de page, outil qui nous permet de fermer le topic créé. N'y aurait-il pas la possibilité d'y rajouter cette option de "résolu" ?

Bonjour, Une fonctionnalité qui, je pense, serait pas mal à intégrer, celle de pouvoir passer facilement un sujet à [RESOLU] sans avoir à modifier le titre du sujet. Cela permettrait de facilement clôturer un sujet (passage à résolu + verrouillage du topic) puis à chacun des membres de voir d'un coup d’œil les sujets effectivement résolus.