Lazer

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.

Evitez les hard reboot, car les filesystems sous Linux ne sont pas démontés proprement. Au reboot, il fait un check automatique, mais quand il y a trop d'erreur, il ne peut pas y arriver tout seul, et la box ne reboote plus jamais tout seule sans SAV chez Fibaro. Le reboot logiciel ou l'extinction par le bouton arrière sont les 2 méthodes à privilégier d'un point de vue système. Après est-ce que ça fait une différence au niveau du logiciel Fibaro (moteur Z-Wave, base de données, etc), ça ne ne sais pas.

Oh punaise, avec la discussion sur les mensurations de la fille qui sort de la douche, il a fallut que je relise ton message 2 fois, parce que la première lecture, c'était pas ça

@Steven, tu penses aussi àma demande pour customiser l'expéditeur des emails ?

oui désolé je me suis endormi le nez sur la touche TAB. J'ai édité

Je ne pense pas que FIbaro soit en bourse, mais une introduction en bourse serait la pire connerie à faire pour une boite comme ça. Trop de problèmes de communication, aucun suivi sérieux des devs logiciels, etc.... ça donne plutôt l'impression d'une startup qui a plein de bonnes idées, mais qui est dépassée par les événements. Quant à la supposée modification de la norme EN, moi j'ai plutôt l'impression d'une bafouille marketing pour éviter d'avouer ses erreurs de conception. Orange avait sorti exactement la même phrase lors de la présentation de Homelive, comme quoi le détecteur Fibaro n'est pas aux norme parce que la loi a changé entre temps... sauf que ladite loi date de bien avant la sortie du module !!!

Le FGRM envoie forcément du 230VAC sur les 2 sorties, donc déjà pour le courant DC c'est mort. Cf mon montage avec des relais supplémentaires pour piloter un volet roulant Velux qui est également en DC : Votre avis ? Fibaro Fgrm Et Volet Roulant Velux En ce qui concerne la calibration, on peut arriver à la feinter en jouant avec les paramètres de delai, mais c'est un peu de la bidouille. Ton plus gros problème est de devoir passer par des relais afin de piloter les moteurs, ce qui te fait perdre la mesure de consommation (puisqu'un relai ne consomme quasiment rien)

Oui en effet, j'ai trouvé le problème, ça n'a pas été évident. Il a fallu que je teste avec un autre module. En fait c'est la sortie TP du bus 1-Wire qui n'envoie plus l'alimentation 3,3V, donc je pense que l'étage d'alimentation du module Fibaro est mort. A part ça, les 2 entrées IN1 et IN2 fonctionnent toujours. De plus, je pense que j'ai 1 ou plusieurs sondes DS18B20 qui sont mortes également, j'ai commandé et j'attends les nouvelles pour faire plus de tests. Donc pas encore réparé cette affaire

Très bien fdp2 Ce que j'ai compris du délestage, c'est qu'il faut réagir très rapidement avant que le disjoncteur ne coupe, c'est pour ça qu'on parle d'une seule seconde. Mon vieux disjoncteur est très tolérant et met un certain temps à couper, mais les nouveaux Linky ne rigolent pas sur ce point, car cela permet à EDF d'éviter les dépassement, même brefs sur leur réseau (et accessoirement cela permet au service commercial de "suggérer" un upgrade d'abonnement). Ensuite, le cycle de délestage du produit Hager, c'est le temps pendant lequel le délesteur coupe le circuit du chauffage moins prioritaire, car il part du principe que d'ici 4 minutes, les autres appareils seront arrêtés, donc on peut rallumer les radiateurs. En faisant notre propre délesteur en LUA (ou GEA...), on connait la consommation en permanence en interrogeant l'Eco Devices, donc il est facile de moduler ces 4 minutes statiques par un algorithme plus intelligent.

@Benjy, le 1er janvier 1970 00:00:00 UTC est un Timestamp Unix àzero, ça sent la variable qui n'est pas initialisée. Au moins tu appréciera qu'ils te l'ont affiché en GMT+1 heure française ...

Excellent Did, c'est exactement le concept auquel je pensais pour ma tablette qui sera accrochée un jour au mur. Bien pensé le coup du pic à brochette

Vous savez quoi ? Je viens de recevoir la box de Lionel... (pour rappel, sa box ne boote plus) La nuit va être longue (ou courte, selon le point de vue)

Par ici le nouveau sujet => http://www.domotique-fibaro.fr/index.php/topic/2767-v4019-b%C3%A9ta-26-11-2014/

Liste des modifications de la version beta 4.019: 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 Functionalities: Configuration > Backup now is Backup & Recovery Recovery Memory Status - can be checked on Backup & Recovery Backups - information about compatibility with current HC version Resolved Issues: #0001359: For some reason 1 smoke sensor doesnt show black box info. #0001524: 3.902 Alpha - HUE plugin won't create new user #0002037: Cannot delete device, but after a restart the devices shows as being deleted #0002048: JSON ENCODE / DECODE doesn't work properly #0001920: [ERROR] 09:23:47: line 44: attempt to index global 'json' (a nil value) #0001699: panel energii #0001849: Fibaro Door and Window Sensors do not report #0001852: Unable to delete devices #0001861: Since upgrading no scenes work #0001877: HC2 stops working on 4.017 #0001709: When adding Foscam generic camera to plugin the password field is misspelled "Passwrod" should be "Password" #0001824: Aeon Switch with energy meter. No more energy measurement/logging after upgrade to 4.017 beta. #0001935: Notification of the battery status #0001963: Event panel refreshed while browsing #0001869: Fast scrolling in event history #0001894: Log messages do not span columns #0001655: Changing pages results in spinning wheel #0001815: Power calcutaion is only working in rooms with Fibaro Wall plugs #0001790: Virtual Device icon change causes a crash #0001834: Get error 502 and 503 after virtual device import #0001701: Controlled device is set to Air Conditioner on dimmers #0001962: UI crashed after creation of magic scene #0001966: setting " How frequently GPS position from the user?s iPhone should be collected" is not saved after reboot hc2 #0001888: Execution of lua commands #0001907: Danalock POL_ZES100 (Z-Wave Danalock Square) sowing but not functional #0001596: universal sensor has not the normal picture and dallas 18b20 temp does not work #0001652: uni bin sensor breach scene does not work #0001548: Nie działa triger włączenia włącznika Duwi #0001812: HC2 doesn't respond anymore #0001593: Email address validation wont allow + to be used #0001651: HTML special characters being displayed in Virtual Device code #0001946: fibaro:getSelfId does not work #0001889: Unable to debug slider code #0001992: FGK-101 with a DS18B2 #0002005: After creation of a magic scene i'm unable to login to the fibaro home center (keeps loading) #0002023: Disarm sensors with scene Known Issues Breached sensoer with Arm Delay causes instant alarm after being armed Data range selection in event panel doesn't work properly For devices imported via Gateway Connection may have no icons

oh oui

rupture de stock ah bah comme ça, le problème de tentation est résolu :/ Merci quand même du super bon plan Moicphil

Ouh là là , surtout pas de main loop dans un VD pour faire du délestage Dans l'Eco-Devices : - cliquer sur Configuration pour le 1er compteur, puis configurer Alerte dépassement Puissance avec les bonnes valeurs (j'ai mis 10350 Watts en seuil haut, soit 45A sous 230V). - dans Notifications, configurer l'appel d'une URL sur action envoi si > seuil haut. Cette URL doit appeler une scène sur HC2. Sur HC2 : - créer une scène qui sera appelée par l'Eco Devices - dans cette scène, il y a la logique à créer pour délecter les radiateurs les moins importants, en plus on peut faire des scénarios différents selon l'heure (priorité à la cuisine, aux chauffage du salon ou des chambres, etc) Ainsi on aura une réactivité <1s, sans risque de bug du main loop (sans compter que le main loop a une tempo de 3s mini)

J'ai complètement démonté la mienne 2 fois, afin de sortir la carte mère du coffret. Ce qui implique de dévisser l'antenne, mais également de dévisser la prise d'antenne qui est fixée sur le boitier. Donc je ne la trouve pas si capricieuse que cela, àmoins qu'il y aie un défaut de fabrication sur certaines séries ? Je n'ai jamais eu aucun problème de portée pour ma part avec la box (enfin, si on exclue les problèmes de modules situés trop loin ou derrière des murs en béton, mais c'est normal)