Lazer

Finalement, Jeedom, c'est presque aussi bien que Fibaro, on peut faire un backup de la conf Z-Wave. Ne manque plus que la mise à jour OTA des modules

Facile : /etc/init.d/fibaro-start restart

Super merci @Titof_44 Vu que je suis encore en 4.090 et que ça fonctionne toujours, je n'avais pas encore pris le temps de débugguer sur la box de test....

bah depuis qu'ils ont appris que tu testes Jeedom, tu comprends, ça les fait flipper quoi.....

Ca m'est arrivé le week-end dernier (en pleine nuit), ça faisait longtemps aussi. Toujours en 4.090

C'est un sujet abordé 100000 fois sur les forums, ici et ailleurs. Alors je le redis : Les volets Somfy sans fil (RTS ou IO Homecontrol) c'est propriétaire et compatible avec aucune solution standard du marché (Z-Wave ou autre) Seuls les volets Somfy filaires (3 fils : 1 phase montée, 1 phase descente, 1 neutre, ... et éventuellement 1 terre) sont compatibles avec tous les modules domotique du marché (Fibaro, Qubino, etc) Donc pour le RTS, tu n'as pas d'autre choix que d'utiliser un Rfxcom, lequel n'est pas supporté par la HC2. (remarque que tu pourrais utiliser aussi une ZIbase, mais bon... produit en fin de vie, les serveurs cloud sont maintenus à bout de bras, c'est pas trop pérenne de partir sur ça aujourd'hui). Donc tu peux le mettre le Rfxcom sur un Domoticz ou un Jeedom.... et là on peut se dire : quitte à mettre Jeedom, autant baser toute sa domotique dessus, et ne plus acheter de HC2. A méditer....

Génial

@kalimasta7075 Il n'y a pas d'erreur, je n'ai jamais dit que les volets roulants en 433Mhz Somfy RTS ne fonctionnent pas avec un Rfxcom. Concernant le EnOcean, comme dit lolocaledo65 c'est une évolution, et pas une disparition pure et simple. Mais ce qui est certain c'est qu'il ne restera pas sous sa forme actuelle. Et je ne sais pas si ils arriveront à garder la rétrocompatibilité car le Zigbee fonctionne à une autre fréquence (2.4GHz, comme le Wi-Fi). Bref pour le moment on n'a aucune info technique, donc wait & see. Mais pour avoir du EnOcean sous se forme actuelle, c'est hyper décevant compte tenu des promesses annoncées : - les capteurs solaires sans pile nécessitent des piles.... un comble (l'hiver quand les jours sont courts, pendant les vacances, etc.... j'ai des Try2Sys sans pile, et des Nodon avec pile, et je graphe tout à la minute près, je vois bien la différence) - les télécommandes nécessitent d'appuyer comme un boeuf sur le bouton pour espérer générer suffisamment d'énergie pour envoyer la trame EnOcean. Pas du tout Waf, le matin quand je ne suis pas réveillé je dois m'y reprendre à plusieurs fois. Rien à avoir avec la douceur du toucher d'une commande Z-Wave, ou même un simple interrupteur Legrand. - aucune sécurité, les trames sont vues par tous les contrôleurs EnOcean - réseau non maillé Bref, je suis content d'avoir essayé, parce qu'au moins je sais à quoi m'en tenir fasse aux promesses non tenues.... un peu d'argent perdu au passage, mais pas tant que ça car j'ai placé les capteurs au mieux pour qu'ils fonctionnent malgré la luminosité présente.

@Jerry, non je n'ai pas refait le self-test afin de ne pas m'exploser les oreilles, mais il serait quand même plus sérieux de le faire régulièrement afin de s'assurer que le détecteur fonctionne toujours.... àrépéter autant de fois qu'on a de détecteur.... bah du coup j'ai encore moins envie....

Le portail, c'est du 433 Mhz mais àRolling code, je ne pense pas que tu puisse le piloter avec un rfxcom, mais un FGS sur les borniers de la carte de contrôle fait généralement l'affaire. Les volets Rts ce n'est pas possible avec les modules Z-Wave. Pour les caméras IP, je ne suis pas forcément de bon conseil, car je me moque de les avoir dans la HC2, elles sont toutes gérées par Synology Surveillance Station (enregistrement sur disque) Mais n'importe quelle caméra qui diffuse en Mjpeg peut être affichée dans la HC2. Sinon si la caméra ne supporte que le h264, tu n'auras que les Snapshot dans la HC2. Enfin évite toutes les caméras grand public, qui sont totalement propriétaires et ne communiquent avec rien.

Disons que si tu as déjà des périphériques en 433MHz, tu seras bien obligé de les contrôler via un RFXCOM, que tu devras utiliser en passerelle sur Domoticz, Jeedom, etc Mais si tu fais une installation neuve, et que tu as le budget, alors le Z-Wave sera très largement supérieur : réseau sécurisé, maillé, avec retour d'état, nombreux choix de périphériques en croissance constante.

Pas cher, pas contre c'est sans garantie (cdiscount.... ) Tu as vu, c'est la même que la tienne, avec une petite antenne :

àma connaissance, c'est la seule méthode

Ca va devenir une vraie usine à gaz avec les labels... mais par contre j'ai pas compris cette tendance à ne plus utiliser les VG. Que ça soit Label ou VG, c'est sensiblement identique au niveau de la charge sur la DB. Et perso, j'en m'en moque d'avoir un label Vacances, je préfère une VG, j'ai pas besoin de consulter le label, puisque je suis le premier à savoir si je suis en vacances ou pas. Ce que je veux dire, c'est que pour mon usage, ce sont des VG techniques utilisées par les scènes/GEA, donc pas besoin de me l'afficher dans l'interface. (ça me fait penser que c'est un peu le même débat que les icones) Bon ceci dit je vais réfléchir à ajouter les labels sans trop complexifier le tout.

En LUA je ne crois pas que ce soit possible d'avoir une précision en dessous de la seconde.

Rfxcom je pense pas, c'est du 433MHz donc bas de gamme sans retour d'état, pas de tout la cible d'une box à600€. Le EnOcean c'est effectivement dommage, mais vu que ça va rapidement disparaître, c'est pas trop grave. Le EnOcean deviendra réellement intéressant dans sa prochaine itération, lorsqu'ils auront terminé leur fusion avec Zigbee. Dans tous les cas, n'oublie pas que Fibaro est le plus gros fabricant de modules Z-Wave, donc ils s'en moquent un peu des autres protocoles.....

Ok je vais essayer de l'intégrer dans une prochaine version.

Je fait un test très simple : if value == param[10][2] then Mais si tu remplaces par un string.match ou quelque chose dans le genre, tu devrais pouvoir faire des regex

J'ai un compteur Granola (faut de frappe volontaire..... ) à 1 impulsion par litre, branché uniquement sur le circuit d'eau chaude du ballon, et je ne dépasse jamais 10 L/min Donc ton 15L/min ne me semble pas aberrant en fonction de ce que tu mesures, de la pression, du débit (diamètre des tuyaux) chez toi. Dans le doute tu peux remplir un jerrican pour mesurer le débit réel. Ceci dit, il est tout à fait possible que tu loupes des impulsions. Perso mon compteur est branché sur un Raspberry PI, et il avait fallu que je m'applique particulièrement sur le code source du programme multithreadé en C pour être certain de ne pas louper des impulsions. Donc si toi tu passes par un IPX, puis une scène de la HC2, c'est sà»r que tu vas en laisser passer.... car entre le temps de déclenchement du trigger de la scène, le temps d'exécution LUA, la sauvegarde de la nouvelle valeur dans la variable globale, il se passe du temps. Et tu vas devoir jongler avec les instances des scènes, sachant que la HC2 ne permet pas de poser de mutex sur les variables globales (avec les conséquences qu'on connait => 503 erreur), alors le problème devient vite insoluble. Il faut que tu laisses l'IPX compteur seul de façon autonome, et la HC2 vient lire la valeur à intervalle régulier. Dans ce sens là , tu ne perdras pas d'infos, mais tu perdras le coté instantané de la lecture. A noter que Steven (je crois) avait constaté que son IPX800 v3 pouvait oublier de compter certaines impulsions, donc ce n'est pas infaillible non plus.

J'ai partagé en première page la version 1.20 du module virtuel (fichier Network_Monitor_v1.20.vfib), qui apporte la nouveauté suivante : - La dernière colonne de la table DEVICES permet d'annuler le monitoring d'un équipement particulier en fonction de la valeur d'une variable globale. C'est particulièrement utile pour monitorer, ou pas, certains équipements en fonction d'une condition externe (variable globale Vacances, etc). Voir les exemples donnés. Cette version tourne depuis 3 mois chez moi sans souci. J'en ai profité pour ajouter en première page de nouveaux exemples d'équipements à monitorer (IPX800, caméras Foscam et Hikvision, VRT-IP, etc...) Et voici le code source LUA du bouton Check pour ceux qui voudraient modifier leur VD sans avoir à en importer un nouveau : Network Monitor v1.20.lua

Bravo excellent

attention, l'utilisation de la fonction net.HTTPClient() est asynchrone. donc ton code ne s'exécute plus de façon linéaire, d'où les comportements étranges que tu constates. Tu ne peux plus utiliser la commande sleep(), et il faut que tu utilises setTimeout() qui est également asynchrone, comme net.HTTPClient() Regarde le code de ma scène Watchdog, il fait utilisation des 2 fonctions imbriquées. Berale24 avait aussi fait un tuto sur l'utilisation du setTimeout() sur le forum, et de mémoire il en existe un autre, très complet et en anglais sur le forum officiel.

Merci Fredric je vais faire ce test d'attendre plusieurs jours, car c'est comme cela que je vais l'utiliser... Mais pas en Panic, mais plutôt pour le réveil (certains matins je ne le réveille pas, non en fait c'est que je suis en déplacement)

Non et non. Et je ne prends pas beaucoup de risque en disant que ça ne sera jamais le cas. HC2 c'est Z-Wave uniquement.

Ca ne sert à rien, Fibaro a créé, mais n'a quasiment jamais pris en compte les demandes de ce bugtracker..... Sinon j'ai pu comparer les bips car j'en ai un qui est en batterie faible : - portée Z-Wave => bip très court (semble identique à celui quand on ouvre le module). - batterie faible => bip court, mais un peu plus long et plus fort que le précédent (pas très scientifique tout ça....). Particulièrement désagréable (mais n'explose pas les oreilles comme l'alarme incendie)