Lazer

V2-4 également pour mon module qui a planté. Avec le Toolkit de Krikroff, dans les données brutes de l'API : "zwaveInfo": "3,3,67" "zwaveVersion": "2,4"

J'envisage 2 solutions : - appeler EDF et leur demander de déplacer ton compteur dans ta maison (service payant). Le câble actuellement utilisé pour la téléinfo vers le Calybox pourra être utilisé pour le téléreport vers le petit truc rond dans le coffret de rue. - acheter un compteur sur eBay ou LBC, et l'installer dans ta maison, juste après le disjoncteur de branchement. C'est ce que j'ai fait chez moi, et expliqué en page 2 de ce topic. Ca fonctionne très bien ainsi, et c'est relativement facile àfaire.

Moi je n'ai jamais constaté que le gestionnaire d'event ne soit pas fiable. Je veux dire que je vois tous les événements que je m'attends à y trouver. D'ailleurs, c'est même très pratique pour détecter un module qui est hors de portée Z-Wave : tu le déclenches (mouvements, appui sur l'interrupteur, réveil, etc...) et tu vois dans les events si il apparait ou pas. Par contre, dans mes événements, la plupart des infos sont des remontées des capteurs de T°C, HR%, LUX, etc... et ça a tendance à être assez bavard par moment !!! Donc si tu ne prends que le dernier événement via l'API, tu risques de louper des événements qui se succèdent trop vite.

Si ça marche déjà comme ça, pas de problème alors Oui, effectivement, parser des pages HTML/JSON/XML c'est pas franchement optimal pour un script qui s'exécute sur la HC2. J'espère que Fibaro va améliorer ce langage de script, car y'a du potentiel, mais on pourrait vraiment faire des trucs beaucoup plus puissants assez facilement.

Si les triggers de ta scène se réveillent constamment à chaque événement, fait gaffe que ça ne surcharge pas ta HC2. Bon après ça dépend du nombre de modules que tu vas surveiller. Pour savoir comment a été allumé la lumière, j'avais imaginé la solution suivante : - si une scène allume la lumière, création d'une variable globale juste avant - si un détecteur de mouvement allume la lumière, création d'une variable globale juste avant - ensuite, lorsque l'événement associé à l'allumage de lumière se déclenche automatiquement (suite aux 2 conditions précédentes ou à appui sur l'interrupteur), il suffit de regarder l'état des variables globables pour en déduire la source de l'événement. En ce qui concerne l'API HTTP, c'est le principe même des interfaces Web 2.0 en AJAX. Toutes les requêtes sont effectuées par du Javascript en asynchrone en mode HTTP vers le serveur Web situé en local. Cela évite de recharger complètement la page comme ce serait le cas si c'était réalisé de manière traditionnelle en PHP. Le panneau des graphiques de consommation fonctionne de la même façon. A mon avis, c'est la meilleur façon de faire. Ce qu'on peut éventuellement reprocher à Fibaro, c'est de ne pas (encore) avoir mis à disposition une API pour consulter les événement en LUA.

Fredric, Finalement, même bug que toi depuis ce soir. Le détecteur de mouvement s'est transformé en capteur de température, avec les valeurs 0°C et 255°C, donc à chaque mouvement, il signale un risque d'incendie, avec notification Mail et Push sur tous les smartphones et tablettes de la maison... le concert quoi Le réveil du module ne rétablie pas la situation, qui reste toujours en capteur de température. Plutôt que de l'exclure et de le réinclure, sachant que ça va se reproduire, je vais l'éteindre et attendre sagement que Fibaro corrige le bug (dans la HC2 ou le firmware du module, je ne saurais dire). Du coup ça me refroidit bien, et je vais attendre avant d'en acheter d'autres...

Pour récupérer les events par l'API HTTP, c'est simple : http://<IP>/api/panels/event?from=1352509026&to=1392509026&type=time Le From et le To sont des Timestamps UNIX. J'ai constaté que les events sont supprimés au bout d'un certain temps, et que plus tu génères d'événements, plus ce temps diminue. Logique puisque la HC2 doit attribuer une mémoire de taille fixe pour stocker les événements.

Merci pour tes suggestions, je note et j'essaierai d'intégrer ça dans la prochaine release. Sinon, pour info j'ai intégré les graphs de luminosité en Lux (testé avec un capteur Fibaro Motion Sensor), et je suis en train de travailler sur des relevés de consommation en Wh avec prise en compte HC/HP (si on a un Eco-Devices en plus) afin de calculer précisément les coà»ts en € sur de longues périodes... genre en combien de temps je rentabilise le remplacement des lampes à incandescences par des LED, combien ça coute de se chauffer, etc... Bon par contre, j'espère que vous n'êtes pas pressés, car j'avance tout doucement.

Effectivement. Mais pour Fredric, on ne sais pas, je crois qu'on a seulement parlé du compteur jusqu'à présent. Je n'ai rien trouvé pour amplifier le signal de téléinfo. Les caractéristiques du câble données dans ce document : http://bernard.lefrancois.free.fr/ERDF-NOI-CPT_O2E.pdf au chapitre 1.2 expliquent qu'on peut aller jusqu'à 500m... dans des conditions idéales. En tout cas ça fonctionne pour le Calybox qui doit disposer d'un circuit analogique d'entrée de meilleure conception que celui de l'Eco-Devices. En tout cas, si le disjoncteur de branchement est situé dans le coffret de rue, il est possible d'y connecter un disjoncteur modulaire dessus, avec un Eco-Devices, et un boitier CPL pour transporter le réseau Ethernet jusqu'à la maison.

T'as un exemple de code source de la page ? Avec tous les pros du LUA sur le forum, y'a moyen de t'aider.

Un compteur ça ne saute pas, ou alors c'est grave. Le disjoncteur de branchement doit être dans la maison.

Non il n'y a pas de retour d'état, ou alors il va falloir aller le chercher loin dans le circuit... ce n'est généralement pas prévu. Lors de l'installation, les butées sont réglées pour que l'électronique arrêt les moteurs en fin de course, c'est tout bête. Mais du coup, c'est difficilement domotisable tout ça, autrement que par un bête contact sec

Si c'est libre de potentiel, c'est intéressant car c'est plus facilement domotisable alors. Tu as une photo ou la référence de ton boitier de contrôle ?

voilà En fait, plombier/chauffagiste/électronicien, tous les mêmes

Elle n'est pas de moi, j'ai appris ça quand je faisais de l'électronique. Donc on va dire que c'est open-source PS : pour l'explication complète, les pistes sont des petites tubes transportant la fumée d'un composant àun autre, lesquels sont en fait de simples conteneurs àfumée. Lorsqu’une fuite survient, le circuit ne fonctionne plus.

Non surtout pas de 220V, sinon la fumée emprisonnée dans les composants va s'échapper. Il faudrait mettre un FGS àce moment là.

J'ai eu un souci similaire avec un Fibaro Universal qui est en extérieur, sans visibilité directe avec la HC2. En fait c'était le signal Z-Wave qui ne passait pas à tout les coups. Depuis que j'ai ajouter un autre module, grâce au routage la communication se fait à tout les coups. Donc vérifie la portée de ton capteur, ça pourrait être le même problème.

Le paramètre 4 c'est pour que le module repasse automatiquement à OFF après l'avoir positionné sur ON. Ainsi cela simule une impulsion : dans ton script LUA ou bloc, tu dis au module de passer à ON, et automatiquement le module repassera à OFF une seconde plus tard. En fait c'est exactement ce que réalise ta télécommande. Tu n'auras pas de retour d'état avec ce système. En fait, à chaque impulsion; la porte va repartir en sens inverse de l'ordre précédemment donné. C'est ultra basique comme fonctionnement. Aussi, si tu renvoies une impulsion avant que la porte ne soit fermée (ou complètement ouverte), celle-ci va s'arrêter, puis repartir en sens inverse. Le FGRM ne peut pas convenir car les portes de garages ne se commande pas comme les volet, ça fonctionne par impulsion, et c'est tout. Pour le retour d'état, il faut des capteurs comme le suggère Diuck, mais chaque capteur a ses propres limitations, donc au final il faudrait 2 ou 3 capteurs pour avoir des informations complètes sur le statut de la porte. Si tu voulais utiliser un FGRM, il faudrait attraper les phases d'alimentation du moteur directement.... sauf que sur un moteur de garage, les phases sont en 12 ou 24V, ce qui ne sera de toutes façon pas compatible avec le FGRM. Ca ferait un beau projet de concevoir une interface électronique de pilotage de porte de garage (et de portail) par un FGRM.

En effet, ça me semble être exactement ça :

A priori, les volets bubendorf ne fonctionnent pas avec les FGRM, on en a déjàparlé plusieurs fois sur le forum, tu peux faire une recherche. Ceci dit, il n'y a pas longtemps j'ai vu passer ici un lien vers le forum TLD où le gars a carrément démonté son moteur pour modifier le câblage et le rendre compatible... Tu trouveras le lien quelque part ici.

C'est quand même étrange... La Main loop est vide. Et le bouton par défaut est celui pour lister les ID. Vérifie quand même que ton bouton par défaut n'est pas celui qui fait Start.

C'est pratique, mais comme l'utilisation de la pince est exclusive, tu ne peux pas mesurer le courant et la tension en même temps. Et la tension secteur varie facilement de 5V d'une seconde àl'autre, donc pour les calculs de puissance, ce n'est pas très précis. Au final, 2 équipements séparés c'est toujours mieux, mais plus cher. Enfin, on divague...

Euh, bizarre. Tu veux dire qu'il clique automatiquement sur le bouton enregistrement, et que dans Synology tu vois les fichiers qui s'enregistrent ? Si c'est le cas, ça doit avoir le même comportement pour tous les VD sur la HC2. J'ai pas trop envie de rebooter pour tester, je suis plutôt du genre à aimer les gros uptime

Je pense que la solution de JossAlf de convertir le mode bloc en LUA avec la petite modif est le plus simple dans l'immédiat pour ton besoin de volets. Après, en fonction de tes besoins futurs, de tes connaissances, de ta motivations, tu pourras doucement faire évoluer tout ça vers du LUA, avec le Scheduler.

Après avoir survécu avec ça pendant de nombreuses années (le bouton rotatif a fini par lâcher, irréparable) : Je suis passé au Voltcraft VC280 et j'en suis plutôt content, excellent rapport qualité/prix pour l'usage que j'en fait (bricolage à la maison)