Lazer

Je regarde ça dès que j'ai quelques sondes dessus. Aller, je vais chercher un FGMS dans mon stock

Bon, je suis chaud patate pour tester une sonde en PULL depuis FHEM. Par contre j'ai besoin d'aide sur le chemin : http://IP:8083/fhem?cmd=jsonList%20EnOcean_Sensor_Cuisine&XHR=1 { "ResultSet": { "Results": { "ATTRIBUTES": { "IODev": "TCM310_0", "eep": "A5-04-01", "manufID": "02C", "room": "EnOcean", "subType": "roomSensorControl.01" }, "DEF": "01818E3F", "IODev": "TCM310_0", "LASTInputDev": "TCM310_0", "MSGCNT": "1537", "NAME": "EnOcean_Sensor_Cuisine", "NOTIFYDEV": "global", "NR": "23", "READINGS": { "humidity": { "TIME": "2014-11-28 23:28:10", "VAL": "62" }, "setpoint": { "TIME": "2014-11-28 23:28:10", "VAL": "null" }, "state": { "TIME": "2014-11-28 23:28:10", "VAL": "T: 19.0 H: 62 SP: 0 SW: 0" }, "switch": { "TIME": "2014-11-28 23:28:10", "VAL": "null" }, "teach-in": { "TIME": "2014-11-01 10:47:33", "VAL": "EEP A5-04-01 Manufacturer: Trio 2 Sys" }, "temperature": { "TIME": "2014-11-28 23:28:10", "VAL": "19.0" } }, "STATE": "T: 19.0 H: 62 SP: 0 SW: 0", "TCM310_0_DestinationID": "FFFFFFFF", "TCM310_0_MSGCNT": "1537", "TCM310_0_PacketType": "1", "TCM310_0_RSSI": "-91", "TCM310_0_ReceivingQuality": "bad", "TCM310_0_RepeatingCounter": "null", "TCM310_0_SubTelNum": "3", "TCM310_0_TIME": "2014-11-28 23:28:10", "TYPE": "EnOcean" } } } Merci Ce qui me permettra de faire quelques tests et de mettre à jour mon outil de graphs à la demande de Nico qui est visiblement trop pressé pour attendre dimanche

ah si tu as déjà d'autres VM, alors il ne vaut mieux pas formater le datastore ! Sinon tu perdras tout. Commence par faire le ménage (supprimer tes liens RDM), puis supprimer le répertoire de ta VM concernée. Je te laisse chercher un peu les commandes, mais au passage il me semble que ce problème est passé plusieurs fois sur le forum, chercher si quelqu'un avait posté la solution. Au fait, je ne conseille pas de mettre le lien RDM dans le répertoire de la VM, car si un jour tu veux déplacer tes VM vers un nouveau datastore sur un nouveau disque, ce sera plus compliqué (Fredo avait posté une procédure à ce sujet). Par ailleurs, je pense qu'un RDM c'est plus logique à la racine de datastore, car il peut potentiellement être attaché à n'importe quelle autre VM en fonction des besoins et évolutions de ta config.

c'est un problème récurant ça, quand tu as foutu la grouille avec tes disques RDM, il reste des locks (verrouillage) Essaye de faire le ménage : supprime le RDM et la VM complète ainsi que son répertoire. Si ça ne suffit pas, ne te prends pas la tête et reformate complètement le datastore.

Tant qu'àfaire, tu pourras me faire une petite texture en métal noir pour un battant ?

Hum... merci pour les infos Did. Je n'ai pas encore touché au miens, et tant qu'il est sous garantie je ne suis pas trop chaud. A l'occasion, il faudrait quand même que je vérifie que c'est identique sur le miens.

pour forcer la mise àjour : http://<IP>/services/startBetaUpgrade.php

Toujours pas de vue du réseau Z-Wave. La nouvelle option permet juste de faire ce qu'on faisait en LUA :

Prem's !!! c'est fait, je regarde ça

Benjy ouais moi aussi la fenetre de mise à jour est toujours pas terrible.... en plus en remote ça rame Nico oui avec le box de Lionel évidemment je ferai le test du FGMS ce soir

Sympa le changelog J'avais le problème de batterie sur le Secure SRT321 qui semble résolu (il faudra juste leur dire que Horstmann est devenu Secure ) Les évolutions du moteur Z-Wave ont l'air chouette. Je lance la mise à jour ...

La beta la plus rapide de l'histoire Fibaro Hop => http://www.domotique-fibaro.fr/index.php/topic/2794-v4020-beta-28-11-2014/

Beta software changes list 4.020: Beta version is designed for user testing and soon will be released as official. WARNING! After installing this upgrade backups from version 1.x and 3.x will be retained but hidden because they are incompatible with the version 4.x. In case of update from old version, v1.x, after that update all users will be deleted. Admin password will be reset. Also update to Beta software all devices will be automatically reconfigured to work with new system architecture. Reconfiguration progress will be shown in pop-up window. This update can last longer than previous. If this update lasts longer than 30 minutes, please go to main HC2 address (e.g. 192.168.0.1). If "System temporarily unavailable" text will appear during update, please wait - you will be redirected to the main page when all services start. New Features: Pre-Update Confirmation - installing update on 4.020 or newer will prompt user additional confirmation. Mesh Network Reconfiguration - available on Configuration -> Z-Wave Network Fixed Issues: Incidental marking devices as dead Horstmann Devices support Many other Z-Wave engine fixes Known Issues: Important! User Developed Plugins will be removed with this update. Please be sure you have your plugin source code. Important! Remote access is NOT available for this version. Devices Polling may not work properly - devices state in UI may be refreshed only after action taken. Previous: Breached senser with Arm Delay causes instant alarm after being armed Data range selection in event panel doesn't work properly Devices imported via Gateway Connection may have no icons Gateway Connection status of dead device between master and slave controller may be different Devices not properly configured on 3.X may not be converted properly Reconfiguration may not work properly in some cases On mobile clients devices may be visible in different categories than configured Advanced settings for some imported devices may not work properly Plugin for Sony TV will not work with newest Sony Firmware Horstmann Thermostat HRT4-ZW higher battery usage in some cases Doorlocks some functions may not work properly

ils ont pas trainé

@fdp2 regarde ici : http://www.domotique-fibaro.fr/index.php/topic/2306-erreur-n°-3/?p=37707 Ce n'est qu'un résumé, je n'ai pas détaillé les étapes, qui se basent en partie sur les travaux présentés dans le sujet HC2 USB Recovery Tweaks C'est trop délicat de poster tous les détails de la manip, car cela demande beaucoup de travail de présentation, donne trop de détails techniques qui ne devrait pas être mis entre toutes les mains (mieux vaut être familier de Linux, et ne pas intervertir les clés USB, etc ...), et est limite vis à vis de Fibaro qui est censé assurer le support.

voilà le chacal voilà , v4.019 installée, par contre ça rame trop mon accès distant, je vais attendre ce soir pour jouer avec.

non, je n'ai pas testé mon clone de clé système, peut-être qu'il pose problème en effet. Il faudrait que je fasse des tests complémentaires. Mais au final ce n'est pas si gênant que ça, puisque maintenant on sait qu'on peut remonter n'importe quelle HC2 à partir de n'importe quel clone de clé recovery. Reste à savoir si on peut physiquement remplacer la clé système SLC.

A part ça, j'ai cliqué sur le bouton maudis... même pas de confirmation, rien, ça démarre tout seul. J'ai peur (ou pas, c'est pas ma box et je sais revenir en arrière .... n'est ce pas Lionel )

Krikroff, ton fournisseur d'eau ne t'as pas installé un compteur à relevé radio ? Ils ont mis ça dans ma ville, et je vois ma consommation d'eau par tranche de 24h, ça permet de détecter une variation anormale, et de constater que je suis bien à 0 pendant les vacances.

Oui j'ai pensé à ça aussi Nico, car mon processeur est un 64 bit, et celui de Lionel un 32 Bits. Par contre, le système s'exécute en 32 bits sur les 2 box, donc je trouve quand même bizarre que le bootloader soit différent, surtout qu'il a été généré à partir de la même clé de recovery sur les 2 box ! root@fghc2:~# uname -a Linux fghc2 2.6.32-5-686 #1 SMP Fri Feb 15 15:48:27 UTC 2013 i686 GNU/Linux

Good news, la box de Lionel est opérationnelle Plusieurs problèmes, les 2 clés sont touchées : Clé système : Les file-systems de cette clé sont corrompus. Cela se produit généralement lors d'une coupure de courant, mais pas uniquement. J'ai déjà vu des serveurs où le file-system est corrompu sans raison apparente. Donc aucune panne matérielle du coté de cette clé 2 Go à mémoire SLC. Les file-systems sont trop endommagés, je n'ai pas pu les réparer (commande fsck). Clé Recovery : Cette clé pose également souci, j'ai des I/O Error lorsque j'essaye d'en faire une copie avec la commande dd. Ce n'est pas rassurant, car je crains une panne matérielle cette fois-ci. Des tests complémentaires me permettront d'en savoir plus. J'ai tout de même réussi à la monter sur mon serveur Linux, et à récupérer manuellement les fichiers contenant la dernière sauvegarde comme décrit dans mon sujet HC2 USB Recovery Tweaks. Par contre l'image système de recovery est corrompue (le md5sum contenu dans le fichier ne correspond pas à celui que je calcule sur le fichier image.gz). Remise en état : J'ai tenté de recréer la clé interne à partir d'une copie de la mienne, ça n'a pas fonctionné. Le kernel Linux ne boote même pas. J'ai pas cherché plus loin, il était déjà tard. J'ai booté sur la copie de ma clé de Recovery (celle générée à partir de ma propre clé comme décrit dans l'autre topic), et j'ai pu réinstaller un système de base en v3.548 Puis mise à jour en v3.590 Stable Actuellement la box est opérationnelle, et fonctionne grâce à copie de ma clé de Recovery. Il faut ensuite que je répare ou génère une nouvelle clé de recovery pour Lionel. Détail intéressant : la box de Lionel est une 1ère version, alors que ma box est une nouvelle version. Donc avec ma clé de recovery (plus récente), je peux remonter une box plus ancienne. C'est plutôt une bonne nouvelle pour la communauté. Notamment, ma clé recovery est en v3.548 de base, donc je ne passe même pas par la v1 quand je fais un recovery. Je suis persuadé qu'on peut se créer des clé de recovery à la version désirée (v3.590, voir même v4... ) histoire de gagner du temps de mise à jour pour ceux qui font des recovery très fréquents. Là je vais monter en v4.019 Beta histoire de faire quelques tests (notamment l'inclusion de modules et plugins), mais je suis maintenant assuré de pouvoir revenir en version stable par la suite.

En effet, je viens d'aller jeter un oeil. Mais c'est quand même bien creux comme article.... plein de belles promesses marketing, mais ce n'est pas avec la box Homelive qu'on va faire une "maison intelligente". Bref.... Orange quoi :/ PS : j'adore cette photo issue du dossier. Un salon immense, une TV aux proportions riquiqui en comparaison, un home-cinéma.... et des canapés qui ne sont pas dirigés vers l'écran. Bref, encore une fois, je me demande bien quelle est la cible de leur pub Homelive, de cet article, et de cette photo d'illustration... :/

Oui Phil, j'ai pensé àla même chose, je trouve la solidité du contact un peu léger, comparé aux détecteurs d'alarme dédié. C'est pour ça que je les ai cerclé au rislan dans mes explications ci-dessus.

@Krikroff, depuis que j'ai des sondes EnOcean, je constate que lorsqu'il fait mauvais pendant plusieurs jours, surtout en ce moment car les jours sont courts, alors les modules n'ont plus assez de batterie pour tenir la nuit. Sachant que je compte alimenter le Virtual Sensor en Push depuis ma passerelle FHEM, serait-il possible que le Virtual Sensor nous informe de la date/heure de dernière mise à jour, afin de différencier une information à jour d'une information qui n'est plus à jour. Idéalement, il faudrait un visuel pour le signaler (icone qui change, ou message texte en dessous), et une API et/ou fonction LUA afin de récupérer cette information. Par extension, en utilisant GEA on pourrait détecter une valeur trop ancienne, et en informer l'utilisateur via une notification. Cela me servirait également pour mon outil de graphs en base SQL, afin de ne pas stocker des données qui ne sont pas à jour. J'espère ne pas trop en demander....

lol les gars @Krikroff, reprenons, je vois 4 méthodes d'arrêt/reboot : débranchement de l'alimentation électrique = arrêt électrique = hard reboot => à proscrire car Linux ne peut pas démonter les file-systems proprement arrêt via appui long sur le bouton situé à l'arrière => arrêt électrique immédiat de la carte mère, fonctionnalité gérée par le BIOS => équivalent à l'arrêt du dessus, donc à proscrire arrêt via appui bref sur le bouton situé à l'arrière => Linux est arrêté proprement reboot via l'interface web ou l'API => les applis Fibaro se ferment, la base de données est cohérente, et Linux s'arrête proprement. Je pense que les 2 dernières solutions sont complètement équivalents, en fait l'une sert à arrêter la box, l'autre sert à la rebooter. Les 2 premières solutions ne devraient jamais être utilisées, sauf en cas de plantage complet de la box ce qui ne laisse pas le choix.